xknazo-KOMPLET-opr

Prepis

1

2

3 ANOTÁCIA Diplomová práca sa zaoberá architektúrou siete IMS a analýzou vplyvu zaťaženia na túto sieť. Architektúra IMS je sieťou novej generácie. Konverguje pevné a mobilné siete a umožňuje rýchle zavádzanie nových multimediálnych služieb. Prvá kapitola je zameraná na popis architektúry IMS, jej jednotlivých prvkov a ich funkciu. Druhá kapitola je venovaná základným protokolom v systéme IMS, hlavne signalizačnému protokolu SIP. Tretia kapitola sa zameriava na problematiku teórie front. Pre simuláciu siete IMS bolo vybrané prostredie Open IMS Core popísané v štvrtej kapitole. Ďalšia kapitola je venovaná nástroju IMS Bench SIPp slúžiacemu ku generovaniu a testovaniu protokolu SIP so zameraním na IMS. Záverečná kapitola sa venuje realizácii vlastnej IMS siete. Začiatok tejto kapitoly sa zaoberá popisom jednotlivých spojení, generovaných nástrojom IMS Bench SIPp. V ďalšej časti sú vytvorené a podrobne analyzované záťažové testy zamerané na realizovanú IMS sieť. V závere kapitoly popisujeme realizáciu reálneho hovoru medzi zariadeniami s operačným systémom Android. KĽÚČOVÉ SLOVÁ IMS, SIP, S-CSCF, fronta, záťaž, test, Poisson, Android ABSTRACT This master s thesis deals with architecture of the IMS network and analysis of the affects when loading the network. Architecture of IMS is a network of new generation. It convergates fixed and mobile networks and it enables quick installation of new multimedia services. The first chapter is focused on the description of the IMS architecture, its components and their function. The next chapter is devoted to the main protocols in the IMS system. It is mainly about signalization protocol SIP. The third chapter focuses on the queueing theory. For simulation of the IMS network, Open IMS Core enviroment was chosen, described in the fourth chapter. Next chapter is dedicated to the IMS Bench SIPp tool used for generating and testing the SIP protocol with focus on the IMS. The final chapter dedicates to the realization of an IMS network. The begining of this chapter deals with the description of individual conections generated by the IMS Bench SIPp tool. In the next part load tests focused on the created IMS network are created and analyzed in detail. The end of the chapter describes the implementation of the real finished call between devices and the Android operating system. KEY WORDS IMS, SIP, S-CSCF, queue, load, test, Poisson, Android iii

4 KŇAZOVICKÝ, P. Vliv zatížení centrálního serveru na IMS síť. Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, s. Vedoucí diplomové práce Ing. Tomáš Mácha. iv

5 Prehlásenie Prehlasujem, že svoju diplomovú prácu na tému Vliv zatížení centrálního serveru na IMS síť som vypracoval samostatne pod vedením vedúceho diplomovej práce a s použitím odbornej literatúry a ďalších informačných zdrojov, ktoré sú všetky citované v práci a uvedené v zozname literatúry na konci práce. Ako autor uvedenej diplomovej práce ďalej prehlasujem, že v súvislosti s vytvorením tejto práce som neporušil autorské práva tretích osôb, predovšetkým som nezasiahol nedovoleným spôsobom do cudzích autorských práv osobnostných a som si plne vedomý následkov porušenia ustanovenia 11 a nasledujúcich autorského zákona č. 121/2000 Sb., vrátane možných trestnoprávnych dôsledkov vyplývajúcich z ustanovení 152 trestného zákona č. 140/1961 Sb. V Brne dňa podpis autora Poďakovanie Ďakujem vedúcemu diplomovej práce Ing. Tomášovi Máchovi za veľmi užitočnú metodickú pomoc a cenné rady pri spracovaní práce. V Brne dňa podpis autora v

6 OBSAH Zoznam skratiek... 8 Zoznam obrázkov Zoznam tabuliek Úvod Systém IMS Požiadavky IMS Hlavné komponenty CSCF (Call Session Control Function) HSS (Home Subscriber Server) SLF (Subscription Locator Function) AS (Application Server) MRF (Media Resource Function) BGCF (Breakout Gateway Control Function) PSTN GW (Public Switched Telephony Network GateWay) Spoplatnenie služieb (Charging) Kľúčové protokoly v IMS SIP (Session Initiation Protocol) Architektúra SIP Formát správy Identifikácia volaného DIAMETER RTP (Real-time Transport Protocol) RTCP (RTP Control Protocol) SDP (Session Description Protocol) MEGACO (MEdia GAteway COntrol protocol) Teória front Základná terminológia Klasifikácia systému front Kendallova klasifikácia Rozšírená klasifikácia Symboly použité pre označenie vstupu a obsluhy Význam symbolov v modeloch systémov front Typy rozdelenia pravdepodobnosti Rovnomerné rozdelenie R(a,b) Exponenciálne rozdelenie Ex(δ) Normálne rozdelenie N(a, σ 2 ) Poissonovo rozdelenie Po(λ) Markovský systém riadenia do front Vstupný tok Obsluha fronty vi

7 4 Open IMS Core Inštalácia Spustenie komponentov Test komunikácie Vytvorenie nových užívateľov Zachytávanie komunikácie IMS Bench SIPp Špecifikácia pre výkonové ohodnotenie Inštalácia Konfigurácia Spustenie testu Zhromaždenie výsledkov Generovanie správy Realizácia IMS siete Test scenárov Volanie Výmena správ Registrácia, odregistrácia, pre-registrácia Záťažové testy Test s registráciami Test s výmenou správ Test s volaniami Reálny hovor Záver Použitá literatúra Prílohy Príloha A: Nastavenie manažéra testu Príloha B: Obsah DVD vii

8 ZOZNAM SKRATIEK AAA AS BGCF CAMEL CAP CPS CSCF DNS FHoSS GGSN GPRS GSM HLR HSS IETF IHS IMS IM-SSF IP IPsec MEGACO MGCF MGW MHT MRF MRFC MRFP OSA-SCS PCM PSTN PSTN GW PTP QoS RADIUS RTCP RTP SAPS SCF SDP SER SGW SIP Authentication Authorization Accounting Application Server Breakout Gateway Control Function Customized Applications for Mobile network Enhanced CAMEL Application Part Calls Per Second Call Session Control Function Domain Name System FOKUS Home Subscriber Server Gateway GPRS Support Node General Packet Radio Service Groupe Spécial Mobile Home Location Register Home Subscriber Server Internet Engineering Task Force Inadequately Handled Scenarios IP Multimedia Subsystem IP Multimedia Service Switching Function Internet Protocol Internet Protocol security Media Gateway Control Protocol Media Gateway Controller Function Media Gateway Multipurpose Internet Mail Extension HTML Multimedia Resource Function MRF Controller MRF Processor Open Service Access-Service Capability Server Pulse Code Modulation Public Switched Telephone Network Public Switched Telephony Network GateWay Precision Time Protocol Quality of Service Remote Authentication Dial In User Service Real-Time Transport Control Protocol Real-time Transport Protocol Scenario Attempts Per Second Service Control Function Session Description Protocol SIP Express Router Signaling Gateway Session Initiation Protocol 8

9 SLF SLF SSH SUT TCP THIG THO TLS UA UAC UAS UDP UMTS URI VoIP WLAN Subscriber Location Function Subscription Locator Function Secure Shell System Under Test Transmission Control Protocol Topology Hiding Inter-working Gateway Teória Hromadnej Obsluhy Transport Layer Security User Agent User Agent Client User Agent Server User Datagram Protocol Universal Mobile Telecommunications System Uniform Resource Identifier Voice over Internet Protocol Wireless Local Area Network 9

10 ZOZNAM OBRÁZKOV Obr. 1.1: Všeobecný prehľad IMS architektúry [4] Obr. 1.2: Architektúra IMS z pohľadu komponentov a rozhraní [3] Obr. 1.3: Vzájomné prepojenie databázy HSS a serverov CSCF Obr. 1.4: Tri typy aplikačných serverov [2] Obr. 1.5: Prepojenie siete IMS s PSTN [2] Obr. 2.1: Formát SIP správy [1] Obr. 2.2: Hlavička RTP protokolu Obr. 3.1: Schéma systému front [9] Obr. 3.2: Hustota pravdepodobnosti rovnomerného rozdelenia náhodného procesu Obr. 3.3: Distribučná funkcia rovnomerného rozdelenia Obr. 3.4: Hustota pravdepodobnosti exponenciálneho rozdelenia náhodného procesu Obr. 3.5: Distribučná funkcia exponenciálneho rozdelenia Obr. 3.6: Hustota pravdepodobnosti normálneho rozdelenia náhodného procesu Obr. 3.7: Distribučná funkcia normálneho rozdelenia Obr. 3.8: Hustota pravdepodobnosti Poissonovho rozdelenia náhodného procesu Obr. 3.9: Distribučná funkcia Poissonovho rozdelenia Obr. 3.10: Náhodný príchod požiadaviek do systému [9] Obr. 3.11: Príklad náhodného procesu so stacionárnymi a nestacionárnymi príchodmi [9] Obr. 3.12: Stavový automat pre systém front typu M / M / 1 [9] Obr. 4.1: Architektúra Open IMS Core [11] Obr. 4.2: Nabootovanie livecd Open IMS Core Obr. 4.3: Úvodná obrazovka prostredia livecd Open IMS Core Obr. 4.4: Webové rozhranie pre konfiguráciu a spúšťanie IMS prvkov Obr. 4.5: Poslanie správy v konzolovom režime Obr. 4.6: Uskutočnenie hovoru v konzolovom režime Obr. 4.7: Výmena správ v grafickom režime Obr. 4.8: Uskutočnenie volania v grafickom režime Obr. 4.9: Vytvorenie užívateľa pomocou konfiguračného skriptu Obr. 4.10: Záložka USER IDENTITIES na webovom rozhraní HSS Obr. 4.11: Nastavenie mena užívateľa Obr. 4.12: Nastavenie súkromnej identity užívateľa Obr. 4.13: Nastavenie verejnej identity užívateľa Obr. 4.14: Pridruženie užívateľa s jeho súkromnou identitou Obr. 4.15: Pridruženie súkromnej identity užívateľa s jeho verejnou identitou Obr. 4.16: Pridanie domény siete k verejnej identite užívateľa Obr. 4.17: Zachytené pakety v programe Wireshark Obr. 4.18: Graf prichádzajúcich SIP správ na server S-CSCF pri uskutočnenom volaní: a) bez ďalšieho provozu na pozadí b) s provozom na pozadí Obr. 5.1: Celkový prehľad testovaného systému pomocou IMS Bench SIPp [13] Obr. 5.2: Procedúra výkonového testu pre IMS [14] Obr. 5.3: Hlavné menu užívateľského rozhrania konfiguračného skriptu ims_bench.pl Obr. 5.4: Sekcia nastavenia testovaného systému Obr. 5.5: Sekcia nastavenia SUT Obr. 5.6: Sekcia nastavenia časového profilu generovaného toku Obr. 5.7: Sekcia nastavenia generovaného toku Obr. 5.8: Sekcia definovania užívateľov Obr. 5.9: Sekcia nastavenia Obr. 5.10: Ukážka spusteného manažéra

11 Obr. 5.11: Ukážka spusteného generátora záťaže Obr. 6.1: Schéma zapojenia testovej siete Obr. 6.2: Signalizácia spojenia medzi IMS užívateľmi Obr. 6.3: Ukážka SIP správy INVITE Obr. 6.4: Priebeh výmeny správy medzi IMS užívateľmi Obr. 6.5: Ukážka SIP správy MESSAGE Obr. 6.6: Priebeh registrácie IMS užívateľa Obr. 6.7: Ukážka SIP správy REGISTER Obr. 6.8: Počet scenárov za sekundu v teste s registráciami Obr. 6.9: Histogram zaťaženia v teste s registráciami Obr. 6.10: Pravdepodobnostné rozdelenie zaťaženia v teste s registráciami Obr. 6.11: Vyťaženie procesorov na strojoch S-CSCF a HSS behom testu s registráciami Obr. 6.12: Dostupná pamäť na strojoch S-CSCF a HSS behom testu s registráciami Obr. 6.13: Percento nezvládnutých scenárov behom testu s registráciami Obr. 6.14: Oneskorenie 1. transakcie registračných scenárov behom testu s registráciami Obr. 6.15: Oneskorenie 2. transakcie registračných scenárov behom testu s registráciami Obr. 6.16: Oneskorenie transakcie pre-registračného scenára behom testu s registráciami Obr. 6.17: Oneskorenie 1. transakcie registračného scenára behom testu s registráciami Obr. 6.18: Oneskorenie 1. transakcie odregistračného scenára behom testu s registráciami Obr. 6.19: Počet scenárov za sekundu v teste s výmenou správ Obr. 6.20: : Histogram zaťaženia v teste s výmenou správ Obr. 6.21: : Pravdepodobnostné rozdelenie v teste s výmenou správ Obr. 6.22: Vyťaženie procesorov na strojoch S-CSCF a P-CSCF behom testu s výmenou správ Obr. 6.23: Dostupná pamäť na strojoch S-CSCF a P-CSCF behom testu s výmenou správ Obr. 6.24: Percento nezvládnutých scenárov behom testu s výmenou správ Obr. 6.25: Oneskorenie transakcie výmeny správy behom testu s výmenou správ Obr. 6.26: Histogram oneskorenia transakcie výmeny správy behom testu s výmenou správ 73 Obr. 6.27: Počet scenárov za sekundu v teste s volaniami Obr. 6.28: Histogram zaťaženia v teste s volaniami Obr. 6.29: Pravdepodobnostné rozdelenie v teste s volaniami Obr. 6.30: Vyťaženie procesorov na strojoch S-CSCF a P-CSCF behom testu s volaniami Obr. 6.31: Dostupná pamäť na strojoch S-CSCF a P-CSCF behom testu s volaniami Obr. 6.32: Percento nezvládnutých scenárov behom testu s volaniami Obr. 6.33: Oneskorenie nastavenia relácie behom testu s volaniami Obr. 6.34: Histogram oneskorenia nastavenia relácie behom testu s volaniami Obr. 6.35: Oneskorenie inicializácie relácie behom testu s volaniami Obr. 6.36: Histogram oneskorenia inicializácie relácie behom testu s volaniami Obr. 6.37: Oneskorenie ukončenia relácie behom testu s volaniami Obr. 6.38: Histogram oneskorenia ukončenia relácie behom testu s volaniami Obr. 6.39: Schéma zapojenia siete pre reálny hovor Obr. 6.40: Menu aplikácie IMSDroid Obr. 6.41: Nastavenie identít užívateľa a servera P-CSCF v aplikácii IMSDroid Obr. 6.42: Uskutočnené volanie v aplikácii IMSDroid Obr. 6.43: Diagram signalizácie hovoru v rámci aplikácie IMSDroid Obr. 6.44: Videohovor v aplikácii IMSDroid

12 ZOZNAM TABULIEK Tab. 2.1: Typy žiadostí SIP správ [6] Tab. 2.2: Triedy SIP odpovedí [6] Tab. 4.1: Vybrané príkazy v konzolovom režime programe OpenIC_Lite Tab. 4.2: Voliteľné príkazy pre skript add-imscore-user_newdb.sh Tab. 5.1: Ovládanie manažéra [13] Tab. 5.2: Ovládanie generátora záťaže [13] Tab. 5.3: Voliteľné príkazy pre skript doreport.pl Tab. 6.1: Prehľad vykonaných scenárov behom testu s registráciami Tab. 6.2: Prehľad záťaže v rámci testu s registráciami Tab. 6.3: Vyťaženie procesora na stroji s S-CSCF v rámci testu s registráciami Tab. 6.4: Vyťaženie procesora na stroji s HSS v rámci testu s registráciami Tab. 6.5: Dostupná pamäť na stroji s S-CSCF v rámci testu s registráciami Tab. 6.6: Dostupná pamäť na stroji s HSS v rámci testu s registráciami Tab. 6.7: Nezvládnuté scenáre behom testu s registráciami Tab. 6.8: Oneskorenie 1. transakcie registračných scenárov behom testu s registráciami Tab. 6.9: Oneskorenie 2. transakcie registračných scenárov behom testu s registráciami Tab. 6.10: Oneskorenie transakcie pre-registračného scenára behom testu s registráciami Tab. 6.11: Oneskorenie 1. transakcie registračného scenára behom testu s registráciami Tab. 6.12: Oneskorenie 1. transakcie odregistračného scenára behom testu s registráciami Tab. 6.13: Prehľad vykonaných scenárov behom testu s výmenou správ Tab. 6.14: Prehľad záťaže v rámci testu s výmenou správ Tab. 6.15: Vyťaženie procesora na stroji s S-CSCF v rámci testu s výmenou správ Tab. 6.16: Vyťaženie procesora na stroji s P-CSCF v rámci testu s výmenou správ Tab. 6.17: Dostupná pamäť na stroji s S-CSCF v rámci testu s výmenou správ Tab. 6.18: Dostupná pamäť na stroji s P-CSCF v rámci testu s výmenou správ Tab. 6.19: Nezvládnuté scenáre behom testu s výmenou správ Tab. 6.20: Oneskorenie transakcie výmeny s správy behom testu s výmenou správ Tab. 6.21: Prehľad vykonaných scenárov behom testu s volaniami Tab. 6.22: Prehľad záťaže v rámci testu s volaniami Tab. 6.23: Vyťaženie procesora na stroji s S-CSCF v rámci testu s volaniami Tab. 6.24: Vyťaženie procesora na stroji s P-CSCF v rámci testu s volaniami Tab. 6.25: Dostupná pamäť na stroji s S-CSCF v rámci testu s volaniami Tab. 6.26: Dostupná pamäť na stroji s P-CSCF v rámci testu s volaniami Tab. 6.27: Nezvládnuté scenáre behom testu s volaniami Tab. 6.28: Oneskorenie nastavenia relácie behom testu s volaniami Tab. 6.29: Oneskorenie inicializácie relácie behom testu s volaniami Tab. 6.30: Oneskorenie ukončenia relácie behom testu s volaniami

13 ÚVOD V dnešnej dobe globálneho rozvoja Internetu sa aj poskytovatelia telekomunikačných služieb snažia ponúknuť zákazníkom nové služby, na ktoré už klasická mobilná sieť nie je dimenzovaná. Architektúra IMS je sieťou novej generácie slúžiaca k prevádzke mobilných a fixných zariadení. Konverguje služby prenosu hlasu v klasických telefónnych systémoch, prenosu dát a ďalších multimediálnych služieb (video, obrázky, text, atď.). Podporuje siete založené na prepínaní paketov, ako aj klasické siete s prepínaním okruhov. Nezávisle na prístupovej sieti poskytuje multimediálne služby založené na protokole IP pri použití signalizácie pomocou SIP protokolu. Architektúra IMS sa označuje za službu fixnej/mobilnej konvergencie a má za cieľ nahradiť doterajšie rozdelenie na paketové prepínanie (PS) a kruhové prepínanie (CS). Prvá kapitola diplomovej práce je zameraná na podrobnejšie vysvetlenie architektúry IMS. Sú v nej popísané jednotlivé prvky systému a ich funkcia. Druhá kapitola sa zaoberá popisom základných protokolov v systéme IMS. Popis je zameraný hlavne na dva základné protokoly tejto architektúry (SIP, DIAMETER), ale sú spomenuté aj ďalšie. Tretia kapitola sa zameriava na problematiku teórie front, kde je uvedená klasifikácia systémov front, typy rozdelenia pravdepodobnosti. Koniec kapitoly sa venuje Markovskému modelu zaraďovania do front, pretože väčšina príkladov z komunikačných sietí sa radí do tejto triedy. Štvrtá kapitola je venovaná open source platforme Open IMS Core. Tento systém bol vytvorený Fraunhoferovým inštitútom FOKUS v Berlíne pre testovanie technológie IMS. Kapitola je venovaná inštalácii systému pomocou stiahnutia prednastaveného prostredia livecd Open IMS Core, spusteniu jednotlivých komponentov, pridanie nových užívateľov a otestovanie komunikácie pomocou nainštalovaného IMS klienta. Piata kapitola sa venuje nástroju IMS Bench SIPp slúžiacemu ku generovaniu záťaže a testovaniu SIP protokolu pre potreby IMS siete. Taktiež poskytuje nástroj ku generovaniu správy o teste, ktorá je v súlade so špecifikáciou ETSI TS , pre výkonové testovanie IMS/NGN sietí. V rámci kapitoly je uvedená inštalácia a konfigurácia daného nástroja, spustenie testu, zhromaždenie nameraných výsledkov a vygenerovanie správy. Šiesta kapitola sa zaoberá praktickou realizáciou IMS siete, kde na viacerých počítačoch sú spustené jednotlivé prvky IMS, poprípade ďalšie prvky pre výkonové testovanie. Kapitola sa venuje priebehom jednotlivých spojení generovaných nástrojom IMS Bench SIPp, záťažovým testom pre danú IMS sieť a nakoniec realizácii reálneho hovoru medzi zariadeniami s operačným systémom Android. Diplomová práca má za cieľ oboznámenie s architektúrou IMS a popis jej najdôležitejších protokolov. Ďalšou časťou je ozrejmiť problematiku teórie front, slúžiacej pri moderných telekomunikačných systémoch založených na prepínaní paketov, k matematickému základu pre zaistenie kvality služieb. Očakávaným výsledkom práce je aj analýza realizovanej IMS siete pomocou záťažových testov a ukážka reálneho hovoru. 13

14 1 SYSTÉM IMS IP multimédia subsystém, lepšie známy ako IMS (IP Multimedia Subsystem), je architektúra, ktorá konverguje dátové, hlasové a mobilné siete. Hlavnou úlohou IMS je pokročilá podpora prevádzky multimediálnych služieb, založených na technológií IP (Internet Protocol) v mobilnom sieťovom prostredí. IMS ja postavený na širokom spektre protokolov, z ktorých väčšinu vyvinula spoločnosť IETF (Internet Engineering Task Force). Signalizáciu má na starosti protokol SIP (Session Initiation Protocol), ale samotný prenos dát je paketový a založený na protokole IP. [1], [5] Na Obr. 1.1 je zobrazený prehľad IMS architektúry. Jadro IMS siete je rovnaké pre užívateľov z rôznych typov prístupových sietí. Obr. 1.1: Všeobecný prehľad IMS architektúry [4] Do IMS je možný prístup nielen z paketovo orientovaných sietí (napr. UMTS, WLAN), ale aj zo sietí založených na prepínaní okruhov (PSTN). 1.1 POŽIADAVKY IMS Pri vývoji IMS boli kladené požiadavky hlavne na podporu: vytvárania IP multimediálnych relácií; mechanizmov pre zaistenie kvality služieb (QoS); 14

15 roamingu; schopnosti siete kontrolovať tok dát a s tým súvisiace spoplatnenie služieb; spolupráce paketovo orientovaných sietí so sieťami založenými na prepínaní okruhov. [2] 1.2 HLAVNÉ KOMPONENTY Komponenty IMS (Obr. 1.2) je možné rozdeliť do 6 skupín: databázy (HSS, SLF); služby (AS, MRFC, MRFP); podporné entity (THIG, SEG, PDF); smerovanie a manažment relácií (CSCF); prvky pre vnútornú komunikáciu (BGCF, MGCF, IM-MGW); spoplatnenie služieb (charging). [1] Obr. 1.2: Architektúra IMS z pohľadu komponentov a rozhraní [3] CSCF (Call Session Control Function) za: Server CSCF je základný prvok v IMS. Spracováva SIP signalizáciu a je zodpovedný správu kvality služieb (QoS); smerovanie a prenos volania; integráciu služieb s profilmi užívateľov a komunikačné oprávnenia; nastavenie funkcií kódovania. [4] 15

16 Na základe funkcií, ktoré vykonáva sa delí na 3 typy: P-CSCF, I-CSCF, S-CSCF. [2] I-CSCF (Interrogating-CSCF) Server I-CSCF je SIP proxy server a slúži ako brána do každej IMS siete. Zaisťuje priradenie konkrétneho S-CSCF daným SIP klientom pri registrácii, a to dotazovaním sa na HSS (Home Subscriber Server) databázu. Rozhoduje, či je alebo nie je povolený prístup do iných sietí. Môže byť použitý pre zachovanie anonymity danej siete. Napomáha chrániť prvky S-CSCF a HSS pred nepovoleným prístupom z cudzích sietí. Práve preto má významnú úlohu v rámci bezpečnosti IMS a uskutočňuje smerovanie medzi dvoma sieťami. Jeho ďalšou úlohou je presmerovanie SIP požiadaviek na server S-CSCF, a to v prípade, že boli prijaté z inej siete ako domovskej. Môže taktiež voliteľne šifrovať časti SIP správ, ktoré obsahujú citlivé informácie o doméne (napr. DNS mená serverov a ich kapacity). Táto funkcia sa nazýva THIG (Topology Hiding Inter-network Gateway). Server I-CSCF je zvyčajne umiestnený v domovskej sieti, ale existujú aj špeciálne prípady (napr. I-CSCF THIG), kedy je umiestnený v navštívenej sieti. [2] P-CSCF (Proxy-CSCF) Je to prvý kontaktný prvok užívateľa s IMS sieťou. Všetky dáta od/do užívateľa prechádzajú cez tento prvok a slúži tak aj k autentizácii a kontrole dôveryhodnosti daného užívateľa. Kontroluje SIP signalizáciu a zaručuje smerovanie žiadostí a odpovedí. Ponúka aj funkcie spojené so zabezpečením, a to pomocou protokolu IPsec (Internet Protocol security). Konkrétne sa jedná o ochranu integrity, overenie formátu SIP požiadavku od užívateľa, generovanie informácií o využívaní služieb. Server P-CSCF je pridelený užívateľovi behom IMS registrácie a po celú dobu sa nemení. Užívateľ tak celý čas komunikuje len s jedným serverom P-CSCF. Umožňuje taktiež kompresiu a dekompresiu správ, pretože SIP je textovo orientovaný protokol, a tak správy môžu byť aj dosť objemné. Využíva sa to hlavne pri rádiovom spojení. P-CSCF je umiestnený buď v navštívenej alebo domovskej sieti. Ak je základná sieť založená na GPRS (General Packet Radio Service), tak je server P-CSCF umiestnený v sieti, kde je GGSN (Gateway GPRS Support Node). Obe sú tak umiestnené buď v navštívenej alebo domovskej sieti. [2] S-CSCF (Serving-CSCF) Môžeme ho nazvať aj mozgom IMS, pretože prakticky všetky SIP správy prechádzajú cez tento prvok. Má na starosti ovládanie registračných procesov, smerovanie, vykonáva dohľad nad spojením a na základe užívateľských profilov poskytuje služby klientom. Pomocou databázy HSS si overí užívateľa, ktorý môže následne začať využívať služby IMS. Komunikácia medzi HSS a S-CSCF je na základe protokolu DIAMETER. Má na starosti aj preklad telefónnych čísel na SIP URI (Uniform Resource Identifier) adresu. Uplatňuje taktiež politiku operátora, ktorá môže zahrňovať napríklad to, že užívateľ nemusí byť pre určité služby autorizovaný. V sieti je väčšinou viacero serverov S-CSCF kvôli rozšíriteľnosti a zálohovaniu. Každý z nich obsluhuje niekoľko užívateľov, čo závisí na kapacite uzlov. 16

17 Server S-CSCF je vždy umiestnený v domovskej sieti. [2] HSS (Home Subscriber Server) Je centrálnym úložiskom v sieti operátora a nachádzajú sa v ňom užívateľské dáta, ako napr. registračné informácie, preferované služby, lokalizácia užívateľa, bezpečnostné informácie (autorizácia a autentizácia) a pridelený S-CSCF server užívateľovi. Technicky je obdobou prvku HLR (Home Location Register), ktorá sa vyskytuje v sieti GSM (Groupe Spécial Mobile). [2] Sieť môže obsahovať aj viac ako jednu HSS databázu. Používa sa pri vysokom počte užívateľov, kedy by jedna databáza nestačila. Je však nutné, aby všetky informácie týkajúce sa jedného užívateľa boli uložené v jednom HSS. [2] Pri registrácii do IMS domény sa z databázy HSS sťahuje užívateľský profil na server CSCF. Pre vytvorenie spojenia HSS poskytuje informácie, na ktorom CSCF je užívateľ obsluhovaný. Vzájomné prepojenie CSCF a HSS je zobrazené na Obr Obr. 1.3: Vzájomné prepojenie databázy HSS a serverov CSCF SLF (Subscription Locator Function) Sieť s jedinou databázou HSS nepotrebuje SLF. Naopak siete s viac ako jednou HSS ju vyžadujú. Je to jednoduchá databáza, ktorá obsahuje mechanizmus pre vyhľadávanie adresy HSS, kde sa nachádza hľadaný profil užívateľa. Tento mechanizmus využívajú servery I-CSCF, S-CSCF a AS. Server pošle dotaz s adresou užívateľa k SLF a ako odpoveď dostane adresu HSS, ku ktorej je užívateľ priradený. [2] Komunikácia medzi databázami HSS a SLF je pomocou protokolu DIAMETER AS (Application Server) Aplikačný server je SIP entita a v rámci IMS je využívaný ako zdroj služieb. Komunikácia prebieha pomocou protokolu SIP (medzi AS a S-CSCF) a protokolu DIAMETER (medzi AS a HSS). V závislosti na aktuálnej službe môže aplikačný server pracovať v nasledujúcich módoch: SIP proxy; SIP UA (User Agent); SIP B2BUA (Back-to-Back User Agent). [2] Na Obr. 1.4 sú zobrazené tri typy aplikačných serverov, konkrétne: 17

18 1. SIP AS (Application Server). Je natívny aplikačný server, ktorý poskytuje IP multimediálne služby založené na protokole SIP. Predpokladá sa, že nové IMS služby budú vyvinuté len v SIP AS. 2. OSA-SCS (Open Service Access-Service Capability Server). Poskytuje rozhranie do sústavy OSA aplikačných serverov, ktoré je možné potom umiestniť aj mimo sieť operátora. Tento prvok predstavuje na jednej strane aplikačný server, ale na druhej rozhranie medzi OSA aplikačným serverom a OSA programovacím aplikačným rozhraním. 3. IM-SSF (IP Multimedia Service Switching Function). Špecializovaný aplikačný server, ktorý umožňuje používanie služieb CAMEL (Customized Applications for Mobile network Enhanced). Sú to aplikácie pre rozšírenie mobilnej siete, ktoré boli vyvinuté pre sieť GSM v rámci architektúry IMS. Poskytuje prvok SCF (Service Control Function), ktorý prináša funkciu riadenia služieb pre IMS spojenie. Pre komunikáciu medzi IM-SSF a SCF je využívaný protokol CAP (CAMEL Application Part). [2] MRF (Media Resource Function) Obr. 1.4: Tri typy aplikačných serverov [2] Funkcia MRF poskytuje zdroj prostriedkov v domovskej sieti. Poskytuje sieti prevod medzi rôznymi kodekmi, získanie štatistík, uskutočňuje rôzne druhy analýz a zdroje prehrávania. Skladá sa z dvoch prvkov: MRFC (MRF Controller): riadi tok multimediálnych dát a poskytuje služby konferencie; MRFP (MRF Processor): je riadený prvkom MRFC, spracováva požiadavky od serverov S-CSCF a AS. [2] 18

19 1.2.6 BGCF (Breakout Gateway Control Function) Je SIP server, ktorý zahrňuje funkciu smerovania založenú na telefónnych číslach. Je použitý len v spojeniach zahájených IMS užívateľom a smerovaných ku sieti s prepínaním okruhov (napr. PSTN). Jeho hlavné funkcie sú: výber siete v ktorej sa vyskytuje vzájomná komunikácia domén s prepínaním okruhov; výber vhodnej PSTN brány, ak prebieha komunikácia v rovnakej sieti, kde sa nachádza aj prvok BGCF. [2] PSTN GW (Public Switched Telephony Network GateWay) Poskytuje rozhranie, ktoré umožňuje prístup k sieti IMS zo siete s prepínaním okruhov (napr. PSTN). Prepojenie IMS so sieťou s prepínaním okruhov je znázornené na Obr Obr. 1.5: Prepojenie siete IMS s PSTN [2] Brána PSTN je rozdelená do nasledujúcich funkcií: SGW (Signaling Gateway). Uskutočňuje konverziu protokolov na nižších vrstvách. MGCF (Media Gateway Control Function). Centrálny prvok PSTN GW. Implementuje prostriedky pre konverziu protokolov v rámci signalizácie medzi IP a telekomunikačnou sieťou. MGW (Media Gateway). Zodpovedá za prepojenie IMS ku sieti s prepínaním okruhov. Poskytuje konverziu mediálneho obsahu prenášaného protokolom RTP (Real-time Transport Protocol) do časových slotov PCM (Pulse Code Modulation) a naopak. Podľa potreby umožňuje aj prekódovanie obsahu Spoplatnenie služieb (Charging) Jedným z najdôležitejších funkcií siete IMS je spoplatnenie služieb. Sú definované dva typy spoplatnenia. Offline spoplatnenie je určené užívateľom, ktorý platia za svoje služby periodicky (napr. na konci mesiaca). Online spoplatnenie, tiež známe ako kreditné spoplatnenie, je používané pre poplatok za predplatené služby. Oba typy spoplatnenia môžu byť využívané súčasne. Užívateľ môže mať napríklad predplatené hlasové služby a zároveň predplatenú kartu s kreditom, ktorý ma cenu 10 minút videa. [2] 19

20 2 KĽÚČOVÉ PROTOKOLY V IMS Medzi kľúčové protokoly v IMS patria SIP a DIAMETER. Okrem nich sú v podkapitolách popísané protokoly RTP, RTCP, SDP a MEGACO. Do systému IMS patria ale aj mnohé ďalšie protokoly. 2.1 SIP (SESSION INITIATION PROTOCOL) Protokol SIP je používaný pre ustanovenie, modifikáciu a ukončenie multimediálnych relácií v IP sieti. Je to textovo orientovaný signalizačný protokol. Existujú dva typy SIP správ: žiadosť (request) a odpoveď (response). Bol vyvinutý v roku 1999 spoločnosťou IETF s nasledujúcimi cieľmi: neutralita na transportnom protokole schopnosť práce so spoľahlivými (TCP, SCTP) aj nespoľahlivými (UDP) protokolmi; smerovanie požiadaviek priamo alebo pomocou proxy; oddelenie signalizácie od popisu média možnosť pridania novej aplikácie alebo média; rozšíriteľnosť; mobilita účastníka. [1], [6] Architektúra SIP Prvky v SIP môžeme klasifikovať na dva typy: UA (User Agent) a server. UA je koncový bod spojenia. Posiela a prijíma SIP žiadosti a odpovede. UA môže zastupovať SIP telefón (hardvérový alebo softvérový) alebo bránu do ďalších sietí. Pozostáva z dvoch častí: UAC (User Agent Client) inicializuje spojenie (posiela žiadosti); UAS (User Agent Server) prijíma, preposiela a odmieta žiadosti. Posiela odpovede pre prichádzajúce žiadosti pre užívateľa. [1] Server SIP je logický prvok cez ktorý prechádza SIP správa pri ceste k cieľu. Je používaný pre smerovanie a presmerovanie žiadostí. Rozlišujeme tri typy serverov: Proxy server prijíma a predáva SIP žiadosti od UA alebo ďalšieho proxy servera. Redirect server prijíma žiadosti o spojenie od UA alebo proxy serverov. Túto žiadosť posiela naspäť s informáciou, komu má žiadosť ďalej poslať, aby sa dostala k danému cieľu. Registrar server prijíma len registračné žiadosti od UA a podľa nich si aktualizuje svoju databázu koncových zariadení v rámci svojej domény. [1], [6] Formát správy Na Obr. 2.1 je znázornená SIP správa, pozostávajúca z troch častí: záhlavie, hlavička a telo správy. Záhlavie sa mení v závislosti na tom, či SIP správa je typu žiadosť alebo odpoveď. [1] Typy žiadostí sú uvedené v Tab Odpovede sú uvádzané vždy trojmiestnym číslom a triedy odpovedí sú uvedené v Tab Hlavička obsahuje informácie ku žiadosti. Napríklad iniciátora žiadosti, príjemcu a identifikátor volaného. Označuje taktiež charakteristiku tela správy, ktoré nesie samotnú textovo orientovanú informáciu. [1] 20

21 Tab. 2.1: Typy žiadostí SIP správ [6] Obr. 2.1: Formát SIP správy [1] METÓDY ACK BYE CANCEL INFO INVITE MESSAGE NOTIFY OPTIONS PRACK PUBLISH REFFER REGISTER SUBSCRIBE UPDATE Tab. 2.2: Triedy SIP odpovedí [6] TRIEDA 1xx 2xx 3xx 4xx 5xx 6xx POPIS Finálne potvrdenie pre správu INVITE Ukončenie relácie Zrušenie relácie Prenos signalizácie Mid-call Zostavenie relácie Prenos správy Prenos Požiadavka na voliteľné možnosti Dočasné potvrdenie Nahranie súčasného stavu na server Prenos užívateľského URI Registrácia užívateľského URI Oznámenie žiadosti na udalosť Nahranie informácii o relácii POPIS Dočasná alebo informatívna žiadosť je zapracovaná ale nie je kompletná Úspech žiadosť je kompletne spracovaná Presmerovanie overenie žiadosti v inej lokalite Chyba klienta žiadosť nie je uskutočnená Chyba servera žiadosť nie je uskutočnená Globálna chyba chybná žiadosť, mala by byť znovu vyslaná 21

22 2.1.3 Identifikácia volaného Pre identifikáciu UA v rámci protokolu SIP sa používa URI. Týmto spôsobom sú špecifikovaní nielen koncoví účastníci, ale aj brány, či iné zariadenia. Je možné si vybrať medzi SIP URI alebo SIPS URI. SIPS podporuje zabezpečenie pomocou protokolu TLS (Transport Layer Security). [6] Identifikátor URI má tvar: userinfo@hostport[parameters][headers] userinfo užívateľské meno alebo telefónne číslo; hostport názov domény alebo IP sieťovej adresy a port; parameters definuje špecifické URI parametre, ako napríklad transport, TTL (Time To Live); headers málo využívaná forma, ktorá nesie extra informácie. [1] Identifikátory SIP URI môžu mať napríklad nasledujúci tvar: sip:pavel.knazovicky@vutbr.cz sip:pavel@vutbr.cz; transport = tcp sip:root@ ;8001 sip: @vutbr.cz;user = phone [1] 2.2 DIAMETER DIAMETER je AAA (Authentication, Authorization, Accounting) protokol vyvinutý spoločnosťou IETF. Poskytuje AAA služby pre rôzne prístupové technológie. Vychádza z protokolu RADIUS (Remote Authentication Dial In User Service), ale oproti nemu má výhody, konkrétne: využitie spoľahlivých transportných protokolov (TCP alebo SCTP); možnosť zabezpečenia prenosu na transportnej vrstve (TLS); prepracovanejšia detekcia porúch a možnosti na zotavenie z nich; lepšia možnosť rozšírenia. Medzi hlavné funkcie protokolu DIAMETER (ako zo skratky AAA vyplýva) patria: Autentizácia technika overenia identity užívateľa. Tým sa zaručí, že komunikácia je dôveryhodná. Autorizácia - proces získavania prístupu k informáciám, funkciám a ďalším objektom. Skladá sa z: autentizácie subjektu, vyhľadania v zozname oprávnených subjektov a udelenia oprávnenia alebo odoprenia prístupu. Účtovanie zber informácií, napr. o užívaní prostriedkov a služieb pre potreby účtovania za poskytnuté služby, plánovania a správy. Informácie môžu zahrňovať identitu užívateľa, typy používaných služieb a časy používania týchto služieb. [7] 2.3 RTP (REAL-TIME TRANSPORT PROTOCOL) Podporuje prenos multimediálnych dát (audio, video) v reálnom čase medzi dvomi a viac účastníkmi. Nezaručuje doručenie dát a ani správne poradie jednotlivých paketov, ale definuje ich poradové čísla. Tým môžu multimediálne aplikácie rozpoznať chýbajúce pakety. 22

23 Pre transport využíva protokol UDP. Formát RTP hlavičky (Obr. 2.2) obsahuje nasledujúce položky: Version (V) verzia RTP, ktorá je vždy nastavená na hodnotu 2; Padding (P) identifikuje vyplňujúce oktéty; Extension (X) identifikuje rozšírenú hlavičku; CSRC count (CC) počet multiplexovaných zdrojov v rozšírenej hlavičke; Marker (M) definovaný konkrétnym profilom média, je závislý na type prenášaných dát; Payload Type (PT) identifikuje formát prenášaného multimediálneho obsahu; Sequence Number sekvenčné číslo k identifikácii paketu; Timestamp časová značka označujúca okamžik prvého oktétu dát v pakete, používa sa pre plánovanie prehrávania dát; Synchronization source (SSRC) identifikuje jednotlivých účastníkov relácie RTP; Contributing source (CSRC) zoznam zdrojov dát. [1], [6] Obr. 2.2: Hlavička RTP protokolu Vlastnosti protokolu RTP môžeme zhrnúť do nasledujúcich bodov: zaisťuje koncové spojenie medzi bodmi pre multimediálne dáta v reálnom čase; nezaručuje doručenie dát, takže vyžaduje podporu nižších vrstiev; pre zostavenie dát poskytuje časové značky a číslovanie; zisťuje a riadi parametre spojenia na základe informácií z koncových bodov spojenia; protokol RTP je len rámcom pre implementáciu aplikácií a je otvorený pre nové formáty dát. 2.4 RTCP (RTP CONTROL PROTOCOL) Je riadiaci protokol RTP, ale na rozdiel od neho poskytuje mechanizmy včasného doručenia paketov alebo zaistenie kvality služieb. Poskytuje taktiež kontrolný a identifikačný mechanizmus pre prenosy dát. Rozdeľujeme 5 typov RTCP paketov: SR (Sender Report) generovaný aktívnymi vysielačmi, obsahuje štatistiky prenosu a príjmu dát; RR (Receiver Report) generovaný nevysielajúcimi užívateľmi, obsahuje štatistiky príjmu dát; SDES (Source Description Items) obsahuje informácie o zdroji dát; BYE signalizuje odhlásenie užívateľa; APP (Application) špecifické funkcie (definované profilom média). [1] Paket RTCP je zložený z viacerých jednotlivých RTCP paketov spojených do jedného UDP datagramu. [6] 23

24 2.5 SDP (SESSION DESCRIPTION PROTOCOL) Je textovo orientovaný protokol k popisu multimediálnych relácií. Pomocou SDP sú prenášané detaily potrebné pri nadväzovaní spojenia pri VoIP (Voice over IP), multimediálnych konferenciách, či iných spojeniach. Pri vysielaní ku viacerým užívateľom slúži k oznámeniu výskytu existujúcich relácií a poskytuje potrebné informácie k pripojeniu k daným reláciám. Býva zapuzdrený v protokole SIP pri nadväzovaní spojenia a iniciátor relácie v ňom informuje, ako bude samotný prenos prebiehať. Protokol SDP môže obsahovať nasledujúce informácie: názov a účel relácie; čas, po ktorom je relácia aktívna; zoznam médií v relácii; informácie o doručení; veľkosť šírky pásma využívaného reláciou; kontaktné informácie užívateľa odpovedajúceho na reláciu. [6] Správa SDP má formát <TYP>=<HODNOTA>, kde typ je vždy len jeden znak a hodnota môže byť niekoľko reťazcov oddelených medzerou. [6] 2.6 MEGACO (MEDIA GATEWAY CONTROL PROTOCOL) Je označovaný taktiež ako štandard H.248. Používa sa medzi media gateway a media gateway controller k ovládaniu signalizácie a spojenia behom multimediálnej relácie. Existuje ako v textovej, tak aj binárnej podobe. Využíva transportné protokoly TCP a UDP. Komunikácia je realizovaná pomocou dvoch prvkov: koncový fyzické pripojenie (napríklad analógová telefónna linka) alebo abstraktné pripojenie (napríklad prenos zvukového súboru); kontext popisuje spojenie medzi koncovými prvkami. Pre správu logických entít používa protokol MEGACO príkazy, ako napríklad: Add pridanie zakončenia kontextu; Modify zmena parametrov zakončenia; Subtract odstránenie zakončenia z kontextu; Move presun určitého zakončenia z jedného kontextu na iný. [1] 24

25 3 TEÓRIA FRONT Odborne nazývaná taktiež THO (Teória Hromadnej Obsluhy), sa zaoberá popisom, analýzou a návrhom obslužných systémov a ich sietí. Tieto systémy slúžia k obsluhe požiadaviek (zákazníkov) vstupujúcich do systému s cieľom maximálneho efektu z hľadiska obsluhy alebo zákazníka. Prvý krát sa o teórii front zmienil dánsky matematik A. K. Erlang, ktorý v roku 1908 riešil problém zameraný na skrátenie čakacej doby vybavenia telefónnych hovorov pre firmu Copenhagen Telephone. [8], [9] V minulosti sa teória front využívala pri klasických telekomunikačných službách založených na princípe prepínania okruhov. Napomáhala pri dimenzovaní počtu liniek medzi telefónnymi ústredňami a pre stanovanie spojovacích polí v týchto systémoch. Postupom času je ale technológia prepínania okruhov nahradzovaná technológiou prepínania paketov. V rámci tejto technológie sú dátové toky priradené rôznym službám. Jednotlivé služby majú rôzne požiadavky na parametre prenosu. Moderné siete musia garantovať určité parametre spojenia, aby jednotlivé služby mohli byť uskutočnené v odpovedajúcej kvalite. Práve pre to je teória front v rámci technológie prepínania paketov matematickým základom pre zaistenie kvality služieb. Teória front využíva teóriu pravdepodobnosti, matematické štatistiky a teóriu náhodných funkcií. [9] 3.1 ZÁKLADNÁ TERMINOLÓGIA Cieľom systému front (Obr. 3.1) je nevytvárať pred obslužnými kanálmi príliš dlhé fronty a zároveň dostatočne využiť obslužné zariadenia. Obr. 3.1: Schéma systému front [9] Vstupné požiadavky prichádzajú do systému a radia sa do fronty. Požiadavka na začiatku fronty je obsluhovaná kanálom obsluhy a po obslúžení odchádza zo systému. Proces obsluhy je zvyčajne náhodný. [9] Systémy front môžeme rozdeliť podľa: zdrojov požiadaviek: uzavreté (obslúžená jednotka sa vracia do zdroja), otvorené (obslúžená jednotka sa nevracia do obsluhy), konečné (uzavreté systémy), nekonečné (ak potenciálny počet požiadaviek je veľmi vysoký a značne prevyšuje kapacitu systému); vstupného toku požiadaviek: podľa počtu prichádzajúcich požiadaviek (jednotlivo, skupinovo), podľa okamžiku príchodu požiadaviek (deterministické, náhodné, zmiešané); radu fronty: FIFO (požiadavky sú vyberané na obsluhu v tom poradí, v akom prišli do systému), LIFO (posledná prichádzajúca požiadavka je najskôr obslúžená), SIRO (náhodné), PRI (podľa priorít); 25

26 disciplíny fronty: absolútne netrpezlivá (prvok nevstúpi do systému, ak jeho všetky zariadenia sú obsadené), bez netrpezlivosti (prvky čakajú, až kým ich obsluha nie je realizovaná), čiastočne netrpezlivá (prvok čaká vo fronte po určitú dobu a ak nezačne jeho obsluha, tak systém opúšťa); čakacieho priestoru: nulový (prvok musí byť ihneď obslúžený, inak je odmietnutý), nenulový (dovoľuje čakací stav akejkoľvek alebo určitej dĺžky), so stratami (systémy s tzv. odmietnutím, kedy požiadavka môže opustiť systém, alebo do neho vôbec nevstúpiť), bez strát (žiadna požiadavka nie je odmietnutá); počtu kanálov a ich kapacít: obmedzený, neobmedzený; usporiadania kanálov: jednokanálové (iba jeden kanál obsluhy), viackanálové (niekoľko uzlov obsluhy usporiadaných sériovo, alebo v určitej sieťovej štruktúre); doby obsluhy: deterministická, náhodná. 3.2 KLASIFIKÁCIA SYSTÉMU FRONT Pre rôznorodosť systémov front bolo nutné vypracovať klasifikáciu pre potrebnú matematickú analýzu. Jej vlastnosťami by malo byť dostatočná presnosť a podrobnosť, a zároveň aplikovateľnosť na všetky typy front. Klasifikácia musí rešpektovať tri základné parametre systému front: informácie o vstupnom toku; informácie o čakacej fronte; počet obslužných kanálov. [9] Kendallova klasifikácia Britský štatistik D. G. Kendall zaviedol najčastejší spôsob klasifikácie systémov front. Klasifikácia je popísaná pomocou troch parametrov a vyjadrená v tvare: A / B / N. Význam jednotlivých parametrov je nasledujúci: A typ pravdepodobnostného rozdelenia popisujúci intervaly medzi príchodmi požiadavkou do systému; B typ pravdepodobnostného rozdelenia popisujúci dobu trvania obsluhy; N počet kanálov obsluhy Rozšírená klasifikácia Na rozdiel od predchádzajúcej je rozšírená o ďalšie tri parametre a vyjadrená v nasledujúcom tvare: A / B / N / K / S / Y. Význam jednotlivých parametrov je nasledujúci (prvé tri parametre sú uvedené v 3.2.1): K maximálny počet požiadavkou v systéme (obmedzenie dĺžky fronty); S počet zdrojov požiadavkou (obmedzenie vstupného toku); Y režim fronty (napr. FIFO, LIFO, SIRO). 26

27 3.2.3 Symboly použité pre označenie vstupu a obsluhy Typ vstupu určuje typ rozdelenia dôb medzi príchodmi dvoch po sebe nasledujúcich požiadaviek. Typ obsluhy určuje rozdelenie dôb obsluhy. Je definovaných niekoľko symbolov odpovedajúcich rôznym typom rozdelenia: D deterministický vstup alebo obsluha (konštantný interval); M Markovský-Poissonovský systém; exponenciálne rozdelenie časových intervalov; E k Erlangovo rozdelenie k-teho radu; N normálne rozdelenie; U rovnomerné rozdelenie; G obecný prípad (ľubovoľné rozdelenie). Príkladom je systém front označený M / D / 1, kde máme exponenciálne rozloženie intervalov medzi príchodmi požiadaviek (M), doba obsluhy je konštantná (D) a obslužná linka je len jedna (1) Význam symbolov v modeloch systémov front Pre lepšiu prehľadnosť v popise systémov front je dobré si vysvetliť význam používaných symbolov: intenzita vstupu (priemerný počet požiadaviek vstupujúcich do systému za jednotku času); μ intenzita obsluhy (priemerný počet požiadaviek obslúžených kanálom za jednotku času); koeficient daný podielom intenzít vstupu a obsluhy; koeficient využitia systému; pravdepodobnosť, že v systéme je práve n požiadaviek; priemerný počet požiadaviek systému; priemerná dĺžka fronty; priemerná doba zotrvania požiadavky v systéme; priemerná doba čakania; priemerný počet obsadených kanálov. 3.3 TYPY ROZDELENIA PRAVDEPODOBNOSTI Pri náhodných procesoch je vhodné popísať typy rozdelenia pravdepodobnosti. Medzi základné typy patria rozdelenia: rovnomerné, normálne, Poissonovo a exponenciálne. Prevzaté z [10] Rovnomerné rozdelenie R(a,b) Náhodný proces X má rovnomerné rozdelenie na intervale (a,b) práve vtedy, ak jeho hustota pravdepodobnosti je určená vzťahom: 1,, ; ;, R 0, inak 3.1. Hustota pravdepodobnosti je uvedená na Obr Rovnomerné rozdelenie má náhodný proces X reprezentujúci dobu čakania na pravidelne opakujúcu sa činnosť (napríklad doba čakania na autobus). 27

28 1 b a Obr. 3.2: Hustota pravdepodobnosti rovnomerného rozdelenia náhodného procesu Distribučná funkcia je zobrazená na Obr. 3.3 a má nasledujúci tvar: 0, 1, 3.2.,, Obr. 3.3: Distribučná funkcia rovnomerného rozdelenia Charakteristiky polohy a variability sú odvodené nasledovne: X 2 X , Exponenciálne rozdelenie Ex(δ) Náhodný proces má exponenciálne rozdelenie s parametrom δ práve vtedy, ak jeho hustota pravdepodobnosti je určená vzťahom: 1 e, 0 0, Hustota pravdepodobnosti je zobrazená na Obr Exponenciálne rozdelenie má náhodný proces X reprezentujúci náhodne vyskytujúce sa udalosti (napríklad doba čakania na obsluhu). 28

29 1 δ Obr. 3.4: Hustota pravdepodobnosti exponenciálneho rozdelenia náhodného procesu Distribučná funkcia je zobrazená na Obr. 3.5 a má nasledujúci tvar: 1 e, 0 0, Obr. 3.5: Distribučná funkcia exponenciálneho rozdelenia Charakteristiky polohy a variability sú odvodené nasledovne: X X 3.7, Normálne rozdelenie N(a, σ 2 ) Náhodný proces X má normálne (Gaussovo) rozdelenie s parametrami a, σ 2 práve vtedy, ak jeho hustota pravdepodobnosti je určená vzťahom: 1 σ 2 π e,,,, Normálne rozdelenie má náhodný proces X reprezentujúci napríklad náhodnú chybu v meraní. Je veľmi dôležité, pretože sa najčastejšie vyskytuje, veľa ďalších rozdelení sa mu približuje a môžeme aj mnohé rozdelenia ním nahradiť. Grafom hustoty pravdepodobnosti je tzv. Gaussova (Gaussova-Laplacova) krivka (Obr. 3.6). Na obrázku je vidieť, že parameter a určuje, kde má krivka maximum. Naopak parameter σ určuje ako ďaleko sú od hodnoty a vzdialené inflexné body, čiže ako je krivka roztiahnutá do šírky. 29

30 1 σ 2π Obr. 3.6: Hustota pravdepodobnosti normálneho rozdelenia náhodného procesu Distribučná funkcia je zobrazená na Obr. 3.7 a má nasledujúci tvar: 1 2 e d Obr. 3.7: Distribučná funkcia normálneho rozdelenia Špeciálny prípad normálneho rozdelenia je normované normálne rozdelenie, kedy a = 0 a σ 2 = 1. V tomto prípade označujeme hustotu pravdepodobnosti symbolom φ(x) a má tvar: 1 2 π e,,, Distribučná funkcia pri tomto rozdelení má symbol Φ(x) a má tvar: 1 2 e d Normované normálne rozdelenie je užitočné preto, že jeho vybrané hodnoty distribučnej funkcie môžeme nájsť v tabuľkách učebníc štatistiky Poissonovo rozdelenie Po(λ) Náhodný proces X má Poissonovo rozdelenie s parametrom λ, ak hodnoty x k (k = 0,1,..) nadobúda s pravdepodobnosťami: X λ! e, λ 0, 0,1,2,

31 Hustota pravdepodobnosti je zobrazená na Obr Poissonovo rozdelenie s parametrom λ má náhodný proces X reprezentujúca počet prípadov, u ktorých nastal sledovaný jav s neobmedzenou realizáciou pokusov za jednotku času (napríklad počet gólov za futbalový zápas). Obr. 3.8: Hustota pravdepodobnosti Poissonovho rozdelenia náhodného procesu Distribučná funkcia je zobrazená na Obr. 3.9 a má nasledujúci tvar: λ! e e λ! Obr. 3.9: Distribučná funkcia Poissonovho rozdelenia Charakteristiky polohy a variability sú odvodené nasledovne: X λ X λ 3.15, MARKOVSKÝ SYSTÉM RIADENIA DO FRONT Väčšina príkladov z oblasti komunikačných sietí sa radí do triedy Markovských modelov. Pri tejto triede má vstupný tok príchodu požiadaviek a taktiež doba obsluhy 31

32 Poissonovo rozdelenie pravdepodobnosti. V rámci Kendallovej klasifikácie je označený ako M / M / x. [9] Vstupný tok Hlavná charakteristika vstupného toku je jeho intenzita vstupu, daná počtom prichádzajúcich požiadaviek vstupujúcich do systému v určitom časovom intervale. Udáva priemerný počet požiadaviek vstupujúcich do systému, označuje sa symbolom λ a má rozmer čas -1. Náhodný príchod požiadaviek do systému v čase T = t 2 t 1 je zobrazený na Obr [9] Obr. 3.10: Náhodný príchod požiadaviek do systému [9] Ak n určuje počet požiadaviek za čas T, platí: Všeobecne môžeme definovať dva typy priemerov: časový a súborový. Časový priemer sa počíta za daný časový interval u jedinej entity. Súborový priemer sa počíta u všetkých entít v konkrétnom alebo len krátkom časovom intervale. [9] Dôležitou vlastnosťou náhodných procesov je stacionarita. Ak náhodný proces je nestacionárny, tak ho nemôžeme analyzovať alebo simulovať. V niektorých prípadoch je možné nestacionárny proces rozdeliť na niekoľko čiastkových stacionárnych procesov. Všeobecne platí, že predĺžením časového úseku sledovania procesu je zaistenie stacionarity zložitejšie. Na Obr je uvedený príklad stacionárneho a nestacionárneho procesu. Nestacionárne príchody Stacionárne príchody Obr. 3.11: Príklad náhodného procesu so stacionárnymi a nestacionárnymi príchodmi [9] t 32

33 Ďalšou dôležitou vlastnosťou vstupného toku je ergodicita. Náhodný proces je ergodický, ak jeho časový a súborový priemer sa rovnajú. Existuje len pri stacionárnych procesoch. Ergodický systém je štatisticky stály. [9] Obsluha fronty Dôležitá informácia pri analýze systémov front je doba obsluhy jednotlivých požiadaviek. Táto doba predstavuje časových interval dvoch po sebe odchádzajúcich požiadaviek zo systému. K intenzite vstupu definujeme taktiež intenzitu obsluhy. Udáva priemerný počet jednotiek obslúžených za jednotku času, označuje sa symbolom µ a má rozmer čas -1. Ak m určuje počet obslúžených požiadaviek za čas T, platí: Pri systéme front, kde požiadavka po obslúžení opustí systém platí, že intenzita obsluhy sa rovná intenzite prevádzky. Z intenzity obsluhy môžeme jednoducho definovať strednú dobu obsluhy. Je daná prevrátenou hodnotou intenzity obsluhy (1/µ). Udáva priemernú dobu obsluhy jednej požiadavky v systéme. [9] Pri skúmaní systému front môžu nastať pri sledovaní za dostatočne krátku dobu t nasledujúce udalosti (v zátvorke sú uvedené pravdepodobnosti jednotlivých udalostí): prichádza nová požiadavka ( t * λ); je ukončená obsluha požiadavky v obsluhe fronty (µ * t); je ukončená obsluha požiadavky a zároveň aj nová požiadavka (1 µ * t); nedochádza k žiadnej zmene (1 λ * t). [9] Pomocou stavového automatu (Obr. 3.12) môžeme popísať zmenu počtu požiadaviek v systéme. Číslo 0 značí, že v systéme nie je žiadna požiadavka a číslo 1, že v systéme sa nachádza práve jedna požiadavka. Obr. 3.12: Stavový automat pre systém front typu M / M / 1 [9] Zmeny stavov môžeme taktiež vyjadriť pomocou matice pravdepodobnosti prechodov a pre daný typ systému front má tvar: μ 1 μ 33

34 4 OPEN IMS CORE Open IMS Core je open source platforma slúžiaca k testovaniu IMS sietí, vyvinutá Fraunhoferovým inštitútom FOKUS v Berlíne. Obsahuje základné komponenty jadra IMS siete, a to servery CSCF (I-CSCF, S-CSCF, P-CSCF) a jednoduchú databázu užívateľov HSS. Ukážka architektúry tohto prostredia je zobrazená na Obr Servery CSCF slúžia ako hlavné smerovacie prvky pre akúkoľvek SIP signalizáciu a sú postavené na SER (SIP Express Router). Databázu HSS zastupuje FHoSS (FOKUS Home Subscriber Server), kde sú užívateľské informácie uložené v databáze MySQL. [11] Sh Cx HSS Cx ISC SIP AS Mw I-CSCF Mw P-CSCF Mw S-CSCF SIP Gm Gm Gm DIAMETER IMS klient IMS klient IMS klient Obr. 4.1: Architektúra Open IMS Core [11] 4.1 INŠTALÁCIA Open IMS Core je možné nainštalovať len na operačnom systéme postavenom na linuxovom jadre. Na oficiálnych stránkach projektu [11] si môžeme vybrať z dvoch spôsobov stiahnutia a následnej inštalácie tohto prostredia: podľa návodu, postupnou inštaláciou balíčkov; stiahnutím image súboru, s prednastaveným prostredím, spustiteľným na ľubovoľnom virtuálnom stroji. 34

35 Pre potreby diplomovej práce bola zvolená možnosť stiahnutia livecd Open IMS Core zo stránky [12]. Jedná sa o ekvivalent prednastaveného prostredia pod linuxovou distribúciou Ubuntu z oficiálnej stránky projektu. A tiež je tu možnosť jednoduchšej konfigurácie a spúšťanie jednotlivých prvkov IMS cez webové rozhranie. Po nabootovaní livecd (Obr. 4.2) máme okrem inštalácie aj možnosť vyskúšať si dané prostredie bez zásahu do systému. Samotná inštalácia je užívateľsky jednoduchá. Obr. 4.2: Nabootovanie livecd Open IMS Core Po nabehnutí systému sa štandardne prihlásime ako užívateľ root s heslom password. Úvodná obrazovka je zobrazená na Obr Obr. 4.3: Úvodná obrazovka prostredia livecd Open IMS Core 35

36 4.2 SPUSTENIE KOMPONENTOV V rámci prostredia Open IMS Core máme preddefinovaných dvoch užívateľov (Alice, Bob). Pred samotným spustením IMS klienta je ale potrebné spustiť servery CSCF a databázu užívateľov HSS. Ako bolo vyššie spomenuté, v danom prostredí sa navyše nachádza aj webové rozhranie na adrese umožňujúce jednoduchšiu konfiguráciu a spúšťanie jednotlivých prvkov IMS siete. Prihlasovacie údaje sú užívateľské meno: admin, heslo: password. Obr. 4.4: Webové rozhranie pre konfiguráciu a spúšťanie IMS prvkov V jednotlivých záložkách nájdeme konfiguračné súbory IMS prvkov. Záložka Global (Obr. 4.4) obsahuje tlačidlá štartu, zastavenia a reštartu IMS jadra s možnosťou meniť IP adresu jadra. Prednastavene je jadro na IP adrese Nachádza sa tu aj tabuľka stavu jednotlivých IMS prvkov, ako aj čísla portov a procesov na ktorých počúvajú. 4.3 TEST KOMUNIKÁCIE Po úspešnom spustení serverov CSCF a databázy užívateľov HSS môžeme pristúpiť k spusteniu IMS klienta. V danom prednastavenom prostredí Open IMS Core máme nainštalovaný program OpenIC_Lite slúžiaci ako IMS klient. Môžeme si zvoliť z jeho dvoch režimov: konzolový alebo grafický. Konzolový režim spustíme v adresári /opt/openic/bin, kde sa nachádzajú skripty našich preddefinovaných užívateľov (Alice, Bob), a to príkazom:./start.alice.sh./start.bob.sh Po spustení môžeme pomocou? vypísať dostupné príkazy v konzolovom režime. Význam najdôležitejších príkazov je uvedený v Tab Z danej tabuľky je jasné, že 36

37 registrácia klienta je možná pomocou príkazu r. Po úspešnej registrácii oboch klientov je poslaná správa s textom skusobna sprava od užívateľa Alice ku užívateľovi Bob (Obr. 4.5) pomocou príkazu m bob@open-ims.test skusobna sprava. Obr. 4.5: Poslanie správy v konzolovom režime Uskutočnenie volania medzi užívateľmi, zo strany Alice ku Bob, je uskutočnené pomocou príkazu c bob@open-ims.test. Na Obr. 4.6 je vidieť, že daný hovor má ID = 0. Užívateľ Bob má možnosť hovor prijať príkazom y 0 alebo ho odmietnuť príkazom n 0. Užívateľ Alice má možnosť zrušiť svoje volanie behom vyzváňania príkazom a 0. Behom prebiehajúceho hovoru ho môžu obaja ukončiť príkazom h 0. Tab. 4.1: Vybrané príkazy v konzolovom režime programe OpenIC_Lite PRÍKAZ x r <expires> ur ura p <stat> [<exp>] m <uri> <msg> c <uri> y <id> n <id> a <id> h <id> VÝZNAM ukončenie aplikácie registrácia koncového bodu (UE) odregistrovanie koncového bodu (UE) odregistrovanie všetkých kontaktov zverejnenie informácií o sebe zaslanie správy s textom <msg> ku užívateľovi <uri> zahájenie volania ku užívateľovi <uri> prijatie prichádzajúceho hovoru s daným <id> odmietnutie prichádzajúceho hovoru s daným <id> zrušenie odchádzajúceho volania s daným <id> behom vyzváňania ukončenie prebiehajúceho hovoru s daným <id> Obr. 4.6: Uskutočnenie hovoru v konzolovom režime Grafický režim môžeme spustiť taktiež pomocou pred pripraveného skriptu, v adresári /opt/openimscore, príkazmi (pre oboch užívateľov):./start.alice.gui.sh./start.bob.gui.sh Po spustení sa nám zobrazí jednoduché grafické rozhranie, kde v ľavom dolnom rohu je zobrazený stav registrácie. Pre zaregistrovanie zvolíme v menu File-Sign In. 37

38 Ak potrebujeme pridať všetky známe kontakty do zoznamu Phonebook, zvolíme v menu Contact-Add contact. Vyplníme povinné položky Last Name, First Name a SIP URI. Pridanie potvrdíme kliknutím na tlačidlo Save. V zozname Phonebook sa zobrazí pridaný užívateľ, kde po pravom kliknutí na myške sa zobrazí menu. Pre poslanie správy klikneme na Send Message (ukážka výmeny správ je zobrazená na Obr. 4.7). Pre uskutočnenie volania slúži možnosť Call (ukážka hovoru je zobrazená na Obr. 4.8) Obr. 4.7: Výmena správ v grafickom režime Obr. 4.8: Uskutočnenie volania v grafickom režime 38

39 4.4 VYTVORENIE NOVÝCH UŽÍVATEĽOV V prostredí Open IMS Core sú dve možnosti vytvorenia nových užívateľov. Buď pomocou konfiguračného skriptu, alebo pomocou webového rozhrania k databáze HSS. Oboma postupmi docielime rovnaký výsledok, ale všeobecne pre nového užívateľa musíme vytvoriť názov užívateľa, jeho súkromnú a verejnú identitu. Konfiguračný skript pre vytvorenie nového užívateľa sa nachádza v adresári /opt/openimscore/ser_ims/cfg. Prehľad voliteľných parametrov nájdeme v Tab Samotný skript spustíme nasledujúcim príkazom (Obr. 4.9):./add-imscore-user_newdb.sh u nazov_uzivatela a Pretože daný skript obsahuje chybu, je potrebné ho upraviť pre správne fungovanie. V skripte musíme odstrániť riadkové komentáre v generovaných skriptoch začínajúce znakmi --. Poprípade môžeme pred ne zadať znak #, správne definujúci riadkový komentár v rámci jazyka MySQL. Obr. 4.9: Vytvorenie užívateľa pomocou konfiguračného skriptu Tab. 4.2: Voliteľné príkazy pre skript add-imscore-user_newdb.sh PRÍKAZ VÝZNAM -u <user> meno užívateľa, napr. pavel -t <tel-uri> telefónny identifikátor zdroja, napr. tel: r <realm> doména, prednastavene je open-ims.test -i <impi> súkromná identita, napr. pavel@open-ims.test, parameter u ju prepíše -b <impu> verejná identita, napr. sip:pavel@open-ims.test, parameter u ju prepíše -p <password> heslo, prednastavene sa berie hodnota z parametra u -a automatické použitie nami vytvoreného skriptu pre vytvorenie užívateľa -d automatické použitie nami vytvoreného skriptu pre vymazanie užívateľa -c odstráni skript po vytvorení užívateľa (štandardne sa neodstraňujú) Webové rozhranie k databáze HSS pre vytvorenie užívateľa sa nachádza na adrese Prihlasovacie údaje sú užívateľské meno: hssadmin, heslo: hss. Po prihlásení sa nám otvorí hlavné okno, kde vyberieme záložku USER IDENTITIES. Možnosti tejto záložky sú zobrazené na Obr Z jednotlivých názvov je jasné, že sa jedná o nastavenie mena užívateľa, jeho súkromnej a verejnej identity. Pre vytvorenie nového užívateľa lucka najskôr klikneme na položku Create v menu IMS Subscription a vyplníme nasledujúce údaje (Obr. 4.11): Name: lucka meno užívateľa; Capabilities Set: cap_set1 súbor priradených vlastností; Prefered S-CSCF: scscf1 preferovaný server S-CSCF. Vytvorenie potvrdíme tlačidlom Save. 39

40 Obr. 4.10: Záložka USER IDENTITIES na webovom rozhraní HSS Obr. 4.11: Nastavenie mena užívateľa Pre vytvorenie súkromnej identity klikneme na položku Create v menu Private Identiy. Vyplníme nasledujúce údaje (Obr. 4.12): Identity: lucka@open-ims.test súkromná identita užívateľa; Secret Key: lucka heslo; Authentication Schemes výber autentizačných schém; o Default: Digest-AKAv1-MD5 štandardne použité autentizačné schéma; o AMF (Authentication Managment Field): 0000 využívané pri autentizácii, 4B; o OP (Operator ID): ID operátora, 32B; o SQN (Sequence Number): sekvenčné číslo, 12B. Vytvorenie potvrdíme tlačidlom Save. 40

41 Obr. 4.12: Nastavenie súkromnej identity užívateľa Pre vytvorenie verejnej identity klikneme na položku Create v menu Public User Identity. Vyplníme nasledujúce údaje (Obr. 4.13): Identity: sip:lucka@open-ims.test verejná identita užívateľa; Baring: necháme odškrtnuté doplnková služba pre obmedzenie volaní; Service Profile: default_sp profil služieb; Charging-Info Set: default_charging_set nastavenie spojené s účtovaním; Can Register: zaškrtneme možnosť registrácie; IMPU Type: Public_User_Identity typ verejnej identity pre IMS klientov; Položka User-Status informuje o stave, či je užívateľ registrovaný, alebo nie. Vytvorenie potvrdíme tlačidlom Save. 41

42 Obr. 4.13: Nastavenie verejnej identity užívateľa Po vytvorení identít je potrebné ich navzájom asociovať. Nájdeme nami vytvoreného užívateľa kliknutím na položku Search v menu IMS Subscription. V položke Associate IMPI pridružíme užívateľovi jeho súkromnú identitu (Obr. 4.14), čo potvrdíme tlačidlom Add. Obr. 4.14: Pridruženie užívateľa s jeho súkromnou identitou V položke Search v menu Private Identity nájdeme nami vytvorenú súkromnú identitu užívateľa. V položke Associate IMPU pridružíme súkromnej identite užívateľa jeho verejnú identitu (Obr. 4.15), čo potvrdíme tlačidlom Add. Obr. 4.15: Pridruženie súkromnej identity užívateľa s jeho verejnou identitou 42

43 V položke Search v menu Public User Identity nájdeme nami vytvorenú verejnú identitu užívateľa. V položke Add Visited-Networks pridáme doménu siete, do ktorej je užívateľ priradený, čiže open-ims.test (Obr. 4.16). Pridanie potvrdíme tlačidlom Add. Obr. 4.16: Pridanie domény siete k verejnej identite užívateľa 4.5 ZACHYTÁVANIE KOMUNIKÁCIE Pre zachytávanie komunikácie v rámci diplomovej práce je zvolený voľne dostupný program Wireshark. Umožňuje paketové zachytávanie toku dát, aj ich neskoršiu analýzu. Podporuje analýzu VoIP komunikácie aj množstvo rôznych protokolov s ich následným dešifrovaním. Pre spustenie zachytávania klikneme v menu Caputre-Interfaces alebo klikneme na ikonu. Zachytávanie paketov uskutočníme na rozhraní (localhost). Zachytené pakety pomocou programu Wireshark sú zobrazené na Obr Obr. 4.17: Zachytené pakety v programe Wireshark V rámci diplomovej práce je potrebné analyzovať prichádzajúce SIP správy na server S-CSCF. Na Obr môžeme vidieť graf počtu prichádzajúcich SIP správ na centrálny server behom uskutočneného volania medzi IMS užívateľmi. Pri grafe a) vidíme, že len pri 43

44 ustanovení a ukončení hovoru sú posielané SIP správy na centrálny server. Pri grafe b) bola vytvorená aj ďalšia komunikácia behom hovoru (výmena správ medzi užívateľmi). Obr. 4.18: Graf prichádzajúcich SIP správ na server S-CSCF pri uskutočnenom volaní: a) bez ďalšieho provozu na pozadí b) s provozom na pozadí 44

45 5 IMS BENCH SIPP V rámci diplomovej práce je potreba generovať rôznu záťaž na IMS sieť. Z tohto dôvodu vznikla potreba vybrať vhodný nástroj pre generovanie SIP správ. Ako najvhodnejšie bola vybraná open source aplikácia IMS Bench SIPp. Jedná sa o modifikovanú verziu nástroja SIPp slúžiaceho ku generovaniu záťaže a testovaniu SIP protokolu. Modifikácie boli realizované z dôvodu ovládania scenárov použitím veľkého počtu užívateľov namiesto jednej SIP transakcie medzi dvomi užívateľmi. Aktuálne poskytnuté scenáre umožňujú: úspešné volanie; úspešnú výmenu správ; registráciu; odregistráciu; pre-registráciu. IMS Bench SIPp poskytuje nástroje k monitorovaniu a zaznamenávaniu dát systémových informácií z SUT (System Under Test) a komponentov testovaného systému. Taktiež poskytuje nástroj ku generovaniu správy o teste, ktorý generuje a vypočíta detailný prehľad o SUT behom spusteného testu. Vygenerovaná správa je v súlade so špecifikáciou ETSI TS , pre výkonové testovanie IMS/NGN. [14] MANAŽÉR SIPp #1 SIPp #2 SUT... Monitorovanie pamäte a procesora SIPp #n Tok SIP správ (TCP alebo UDP) Komunikácia medzi manažérom a SIPp alebo systémovým monitoringom (TCP) Komunikácia medzi SIPp (TCP) Obr. 5.1: Celkový prehľad testovaného systému pomocou IMS Bench SIPp [13] Testovací systém (Obr. 5.1) pozostáva z jedného manažéra riadiaceho celý test, jedného alebo viacerých záťažových generátorov a nástrojov pre sledovanie systému SUT 45

46 (vyťaženie procesora a pamäte). Jedná sa o logické komponenty a viacero z nich môžu byť spustené na rovnakom stroji. [13] Pri konfigurácii testu manažér priradí každému generátoru záťaže pevný počet užívateľov vytvorením preddefinovanej databázy obsahujúcej potrebné informácie pre správnu komunikáciu užívateľov v rámci IMS čo docielime pomocou konfiguračného skriptu. Ten taktiež generuje rozmiestnenie všetkých potrebných súborov k hostiteľským strojom každého generátora záťaže. Ten generuje tok SIP správ smerom k SUT v súlade so štatistickou distribúciou každého definovaného scenára manažérom. Manažér taktiež oznamuje celkový počet vygenerovaných scenárov, počet nezvládnutých scenárov IHS (Inadequately Handled Scenarios) a systémové informácie z hostiteľského stroja. Monitoruje chyby a môže zastaviť test, ak je prekročená hranica percenta nezvládnutých scenárov IHS. [14] Generátor záťaže môže generovať tok v dvoch módoch. UDP mód priradzuje každému užívateľovi jedinečnú kombináciu IP adresa a UDP port, čím sa stáva nastavenie viac reálne. Štandardne má ale generátor záťaže svoju IP adresu a priraďuje rôzne UDP porty k užívateľom. TCP mód priraďuje generátoru záťaže jednu IP adresu a vytvára jeden pár TCP portov k SUT. Prvý port je používaný pre serverové scenáre, druhý pre klientské scenáre. [13] IMS Bench SIPp nie je limitovaný len pre testovanie IMS. Je vysoko konfigurovateľný a schopný komunikovať s takmer hocijakou SIP aplikáciou. Avšak nájdeme aj obmedzenia. Kvôli zmenám oproti SIPp napríklad nie je podporovaný iný transportný protokol ako UDP alebo TCP a taktiež chýba podpora IPv6. [14] 5.1 ŠPECIFIKÁCIA PRE VÝKONOVÉ TESTOVANIE IMS/NGN Ako už bolo spomenuté, organizácia ETSI vytvorila špecifikáciu pre výkonové testovanie IMS/NGN. Špecifikácia pozostáva z troch častí. Prvá popisuje všeobecný úvod k prostrediu použitého k testu. Druhá časť uvádza konfiguráciu systému a odpovedajúci návrh dosiahnuteľného cieľa. Tretia časť definuje ohodnotenie testu z definície nastavenia a časového profilu toku dát. [14] Test meria správanie systému pri narastajúcom počte užívateľov vyžadujúcich obslúženie systémom. Pozostáva z testovacieho systému a systému, ktorý testujeme SUT. Pre testovací systém sú definované tri hlavné funkcie: vykonávanie scenárov podľa definovaného profilu toku dát; voliteľne možnosť simulácie rôznych charakteristických rysov na sieťových rozhraniach, napr. šírka pásma, oneskorenie, chybovosť; zaistenie synchronizačného mechanizmu v prípade viacerých fyzických systémov medzi prvkami testu. [14] Špecifikácia definuje scenár ako jednu interakčnú sekvenciu medzi dvomi užívateľmi. Pokus o scenár je definovaný ako príklad scenára vykonaného testom. Veľmi dôležitý termín je jednotka SAPS (Scenario Attempts Per Second) popisujúci priemerný počet scenárov zahájených testovacím systémom. [14] Popísané sú tiež jednotlivé fázy testu. Prvá je pre-registračná fáza k registrovaniu určitého počtu užívateľov. Nasleduje inicializačná fáza s postupným zaťažovaním SUT. Posledná je fáza výpočtu testu, kedy je SUT zaťažovaný preddefinovaným množstvom SAPS narastajúcim po určitej dobe, až kým počet IHS neprekročil definovaný prah. Testovací 46

47 systém rozhodne, či scenár je vyhodnotený ako úspešný alebo naopak. Jednotlivé fázy testu sú zobrazené na Obr Pre-registračná fáza Inicializačná fáza Fáza výpočtu testu Systémová záťaž [SAPS] Návrh dosiahnuteľnej kapacity objektu Žiadna záťaž Úvodná záťaž Nárast záťaže Nárast záťaže Nárast záťaže Nárast záťaže Nárast záťaže Čas testu [s] 5.2 INŠTALÁCIA Obr. 5.2: Procedúra výkonového testu pre IMS [14] Inštalácia bola uskutočnená pod prostredím Open IMS Core na linuxovej distribúcii Ubuntu. Postup je prebraný z oficiálnej stránky [13] nástroja IMS Bench SIPp. Pre správne fungovanie sú vyžadované nasledujúce požiadavky: jadro musí byť prekompilované s časovou frekvenciou 1000 Hz za účelom merania času s milisekundovou presnosťou; pre synchronizáciu každého fyzického stroja v rámci testu sa používa protokol PTP (Precision Time Protocol), Preto je potrebné nainštalovať jeho deamon ptpd; generovanie náhodných čísel pre štatistickú distribúciu vyžaduje GSL knižnicu; pre používanie konfiguračného skriptu potrebujeme Perl XML:Simple modul; pre potreby generovania celkovej správy musíme nainštalovať nástroj pre vykreslenie grafov gnuplot; pre potreby SIPp procesu k otvoreniu veľkého počtu socketov musíme upraviť systémové hranice v súbore /etc/security/limits.conf pridaním nasledujúcich riadkov: soft nofile hard nofile Behom práce bola zistená aj potreba nainštalovať baličky libgd-dev (pre správne fungovanie nástroja gnuplot) a libssl-dev (pre úspešnú kompiláciu IMS Bench SIPp). Nasledujúcim príkazom stiahneme aktuálne zdrojové kódy IMS Bench SIPp do zložky ims_bench: svn co branches/ims_bench ims_bench Prepneme sa do adresára ims_bench a spustíme kompiláciu: 47

48 make rmtl make ossl make mgr make cpumem Pri vypísaní chyby musíme skontrolovať, či v systéme máme nainštalované všetky potrebné požiadavky uvedené vyššie. 5.3 KONFIGURÁCIA Pri konfigurácii testovacieho systému pre spustenie testu vychádzame z dvoch možností: použitia konfiguračného skriptu ims_bench.pl, kde zadávame potrebné parametre pomocou užívateľského rozhrania a všetky potrebné konfiguračné súbory a spúšťacie skripty sa nám vygenerujú automaticky; manuálnej konfigurácie všetkých elementov. [13] Pre potreby diplomovej práce sme vybrali konfiguráciu pomocou skriptu, preto ďalší text bude zameraný na túto možnosť. Pre spustenie konfiguračného skriptu sa prepneme do adresára ims_bench a napíšeme nasledujúci príkaz:./scripts/ims_bench.pl Obr. 5.3: Hlavné menu užívateľského rozhrania konfiguračného skriptu ims_bench.pl Úvodná obrazovka užívateľského rozhrania je uvedená na Obr Pohyb v danom rozhraní je spracovaný pomocou menu, kde ovládanie je užívateľsky jednoduché a intuitívne. Číslom 1 v hlavnom menu sa dostaneme do sekcie nastavenia testovacieho systému (Obr. 5.4), kde máme možnosť nastaviť: TransportTCP: zapnutie používania TCP módu behom testu; ExecuteSIPp: spustenie generátorov záťaže pomocou manažéra. Nevýhodou je ich spustenie na pozadí, takže lepšou možnosťou je spustiť ich ručne.; MaxTimeOffset: maximálna časová odchýlka (v µs), povolená medzi generátormi záťaže a manažérom. Kontrola je zahájená na začiatku testu za účelom vyhnúť sa spusteniu testu s neplatným meraním času. Číslo nula znamená bez kontroly, čo sa ale nedoporučuje.; ManagerIP: IP adresa manažéra; a: vstup do sekcie generátorov záťaže, kde môžeme definovať ich IP adresy a taktiež cestu pre ich automatické spustenie. 48

49 Obr. 5.4: Sekcia nastavenia testovaného systému Číslom 2 v hlavnom menu sa dostaneme do sekcie nastavenia SUT (Obr. 5.5), kde máme možnosť nastaviť: RestartCmd: príkaz vykonávajúci cez SSH (Secure Shell) reštart Open IMS Core na stroji, kde sa nachádza SUT; IP: IP adresa SUT; Port: port, na ktorom má SUT počúvať generovaný tok SIP správ. Obr. 5.5: Sekcia nastavenia SUT Číslom 3 v hlavnom menu sa dostaneme do sekcie nastavenia časového profilu generovaného toku (Obr. 5.6), kde máme možnosť nastaviť: StepTransientTime: čas (v sekundách) po štarte kroku, do ktorého sú dáta ignorované; PreRegistrationMaxIHS: povolené percento z nedostatočne zvládnutých registrácií behom pre-registračnej fázy; StirTime: trvanie (v minútach) inicializačnej fázy, kedy je SUT postupne zaťažovaný z hodnoty definovanej v InitialSAPS; StirMaxIHS: povolené percento z nedostatočne zvládnutých scenárov behom inicializačnej fázy; StepTime: trvanie (v minútach) každého kroku fázy výpočtu testu; InitialSAPS: záťaž aplikovaná na SUT v prvom kroku (v jednotách SAPS); StepNumber: počet krokov behom fázy výpočtu testu; StirSteps: počet krokov behom inicializačnej fázy; PreRegistrationRate: registračná rýchlosť behom pre-registračnej fázy (v počte pokusov o registráciu za sekundu); SAPSIncreaseAmount: nárast systémovej záťaže každým krokom (v jednotkách SAPS). 49

50 Obr. 5.6: Sekcia nastavenia časového profilu generovaného toku Číslom 4 v hlavnom menu sa dostaneme do sekcie nastavenia generovaného toku dát (Obr. 5.7), kde môžeme nastaviť: Edit scenario mix: percentuálne podiely scenárov behom testu, ako aj povolené percento IHS v rámci nich; RegistrationExpire: doba (v sekundách), po ktorej užívateľom vyprší registrácia; RingTimeDistr: náhodná distribúcia vyzváňacieho času (výber medzi poissonovým a exponenciálnym rozdelením); PMMDataSize: priemerná dĺžka správ (v bajtoch); HoldTimeDistr: náhodná distribúcia dĺžky hovoru (výber medzi poissonovým a exponenciálnym rozdelením); HoldTime: priemerná dĺžka hovoru (v sekundách); PMMDataSizeDistr: náhodná distribúcia dĺžky správ (výber len rovnomerného rozdelenia); RingTime: priemerný vyzváňací čas (v sekundách). Obr. 5.7: Sekcia nastavenia generovaného toku Číslom 5 v hlavnom menu sa dostaneme do sekcie definovania užívateľov (Obr. 5.8), kde môžeme nastaviť: PublicIdentityFormat: formát používaný ku generovaniu verejnej identity užívateľov; PrivateIdentityFormat: formát používaný ku generovaniu súkromnej identity užívateľov; 50

51 DontPreRegisterButUseSippIP: vynechanie pre-registračnej fázy a použitie IP adresy generátora záťaže ako užívateľskú doménu; TotalProvisionedSubscribers: celkový počet užívateľov; UserRealm, UserDomain: primárna doména, do ktorej náležia definovaný užívatelia; PercentRoamingSubscribers: percento cudzích užívateľov; UserPasswordFormat: formát používaný ku generovaniu hesiel užívateľov; PercentRegisteredSubscribers: percento z celkového počtu užívateľov, ktorí budú registrovaní behom pre-registračnej fázy. Obr. 5.8: Sekcia definovania užívateľov Číslom 6 v hlavnom menu sa dostaneme do sekcie nastavenia (Obr. 5.9), kde môžeme nastaviť: OutputPath: cesta, kde bude vytvorený adresár obsahujúci všetky potrebné súbory nutné pre spustenie testu; BasePath: cesta k adresáru o úroveň vyššie, kde sa nachádzajú súbory pre spustenie testu vygenerované v OutputPath. Obr. 5.9: Sekcia nastavenia Po nastavení všetkých parametrov vygenerujeme všetky potrebné súbory pre test stlačením písmena q v hlavnom menu. Štandardne sa v adresári ims_bench vytvorí nový adresár ims_bench_x (namiesto x je poradové číslo vygenerovanej konfigurácie), kde sa všetky tieto súbory nachádzajú. 5.4 SPUSTENIE TESTU Pred samotným spustením testu musíme nakopírovať potrebné súbory na všetky generátory záťaže. Prepneme sa do adresára ims_bench_x, do ktorého sme si vygenerovali súbory. Pre skopírovanie môžeme spustiť pred pripravený skript príkazom:./prepare.sh 51

52 Ďalšou možnosťou je manuálne skopírovanie súborov ims_users_x.inf a run_x.sh (namiesto x je poradové číslo generátora záťaže) do adresára /usr/local/sipp na stroj generátora záťaže. V adresári ims_bench_x spustíme manažéra príkazom:../manager f manager.xml Ak sme pri konfigurácii nenastavili automatické spustenie generátorov záťaže manažérom, tak sa prepneme do zložky /usr/local/sipp na stroji generátora záťaže. Manuálne ho spustíme príkazom:./run_x.sh Klávesov e v manažérovi môžeme zahájiť test po spustení všetkých definovaných generátorov záťaže a nástrojov pre monitorovanie testovaného systému. Spustený manažér je zobrazený na Obr Môžeme vidieť, že manažér zobrazuje globálne zhrnutie uskutočnených scenárov, ako aj aktuálne percento IHS pre daný krok. Ovládanie manažéra je uvedené v Tab Tab. 5.1: Ovládanie manažéra [13] Obr. 5.10: Ukážka spusteného manažéra KLÁVESA POPIS # zmena nastavenia displeja e spustenie testu 0-9,<,>,D,q klávesy priamo poslané prvkom testu T zmeranie časového rozdielu v µs t žiadosť o časovú značku v textovom formáte 52

53 g r l W/w žiadosť časovača reštart prvkov testu nahranie scenára žiadosť procesora Spustený generátor záťaže je zobrazený na Obr Konkrétne sa jedná o obrazovku scenára, v ktorej sú uvedené toky správ pre daný scenár (v tomto prípade registrácia) a ďalšie dôležité informácie. Ovládanie generátora záťaže je uvedené v Tab Tab. 5.2: Ovládanie generátora záťaže [13] Obr. 5.11: Ukážka spusteného generátora záťaže KLÁVESA POPIS <,> výber jednotlivých scenárov; zobrazené dáta súvisia s aktuálne vybraným scenárom 1 prepnutie na obrazovku scenára 2 prepnutie na obrazovku štatistiky 3 prepnutie na obrazovku repartition 4 prepnutie na obrazovku premenné 5 prepnutie na obrazovku TDM map 6,7,8,9,0 prepnutie na odpovedajúcu obrazovku sekundárnej repartition D obrazovka ladenia +,-,*, / prispôsobenie rýchlosti q ukončenie p zastavenie generovania toku dát 53

54 5.5 ZHROMAŽDENIE VÝSLEDKOV Každý prvok testovaného systému si svoje štatistiky ukladá na lokálny systém, pretože posielanie výsledkov v reálnom čase manažérovi by zbytočne zaťažovali šírku pásma. Z tohto dôvodu je potreba zhromaždiť výsledky, ak používame viacero fyzických systémov. Výsledky sa ukladajú do súborov s koncovkou csv. Pred samotným generovaním správy je potreba tieto výsledky pospájať. Súbory s koncovkou csv z jednotlivých prvkov systému preto skopírujeme do zložky ims_bench_x na stroj manažéra, kde zlúčenie spustíme príkazom:../scripts/getresults.pl merge Zlúčením vytvoríme súbory sipp.csv a sipp_retrans.csv. Po dokončení zlučovania môžeme čiastkové súbory vymazať príkazom:../scripts/getresults.pl -clean 5.6 GENEROVANIE SPRÁVY Pre generovanie správy je v rámci IMS Bench SIPp určený skript doreport.pl. Generuje správu vo formáte MHT (Multipurpose Internet Mail Extension HTML) obsahujúcu grafy a štatistiky o teste. Vstupné dáta pre generovanie správy sú z nasledujúcich zdrojov: dáta zo zlúčených csv súborov (pokusy o scenár, meranie času, výsledky,...); vyťaženie procesora a pamäte monitorovaného systému pomocou cpumem; všeobecné informácie o teste (začiatky krokov, rýchlosť,...) zo súboru report.xml vygenerovaného manažérom; ďalšie súvisiace informácie (názov, mapovanie s csv súborom,...). [13] Správa sa skladá z viacerých častí. Prvá časť sa týka zhrnutia a je automaticky vytvorená, bez možnosti konfigurácie. Ďalšia časť obsahuje grafy a tabuľky so štatistikami o meraní, ako napr. pokusy o scenár za sekundu, čas odozvy, využitie procesora a iné. Táto časť je už konfigurovateľná, a to pomocou súboru reportconfig.xml. [13] Skript doreport.pl sa doporučuje spúšťať z adresára, odkiaľ bol spustený aj manažér, čiže ims_bench_x. Je to z dôvodu toho, že skript potrebuje násť csv dátové súbory, report.xml a iné v aktuálnej zložke. Voliteľné príkazy pre tento skript sú uvedené v Tab Príklad vygenerovania skriptu je pomocou nasledujúceho príkazu:../scripts/doreport.pl -i ims_bench.xml Tab. 5.3: Voliteľné príkazy pre skript doreport.pl PRÍKAZ VÝZNAM -r súbor so surovými dátami z testu (štandardne report.xml) -c konfiguračný súbor pre skript (štandardne reportconfig.xml) -b voliteľná možnosť pridania HTML hlavičky zo súboru zahrnutú v úvode správy -i konfiguračný súbor pre IMS Bench SIPp. Obsahuje parametre testu -F vetvenie gnuplot (výhoda pri viac jadrových procesoroch). F0 zakazuje vetvenie.; štandardne zapnuté -? nápoveda 54

55 6 REALIZÁCIA IMS SIETE Pre potreby diplomovej práce bola vytvorená testová sieť pozostávajúca zo štyroch počítačov s rovnakou hardvérovou konfiguráciou (procesor Pentium 4 3Ghz, pamäť 1,5GB). Na všetkých bola nainštalovaná linuxová distribúcia Ubuntu pomocou livecd Open IMS Core uvedenej v časti 4.1. Taktiež bol na nich nainštalovaný nástroj IMS Bench SIPp pomocou návodu uvedeného v časti 5.1. Prehľad zapojenia a jednotlivé úlohy počítačov sú zobrazené na Obr Obr. 6.1: Schéma zapojenia testovej siete Servery CSCF a databáza HSS boli spustené pod prostredím Open IMS Core. Pre načúvanie SIP požiadaviek boli štandardne nakonfigurované, konkrétne: port 4060 pre P-CSCF, port 5060 pre I-CSCF a port 6060 pre port S-CSCF. Jeden z hostiteľských počítačov bol taktiež nakonfigurovaný ako DNS server k prekladu domény (open-ims.test), na ktorej je jadro IMS spustené. V databáze HSS bolo vytvorených užívateľov (user0000 až user9999) za účelom potreby veľkého množstva užívateľov pre test. Generátor záťaže a manažér testu nástroja IMS Bench SIPp boli spustení na jednom stroji. Generované správy SIP boli posielané na server P-CSCF. 6.1 TEST SCENÁROV Ako už bolo spomenuté, nástroj IMS Bench SIPp ponúka scenáre vykonávajúce nasledujúce možnosti: úspešné volanie, úspešná výmena správ, registrácia, odregistrácia, pre-registrácia. Priebehy spojení jednotlivých scenárov si ukážeme v nasledujúcom texte. Programom Wireshark sme odchytili jednotlivé pakety daného scenára. Pre túto potrebu sme v rámci 55

56 zapojenia testovej siete vymenili sieťový prvok prepínača za opakovač. Tým sme získali možnosť odchytiť aj pakety, ktoré danému sieťovému rozhraniu nepatria Volanie Priebeh, ustálenie a ukončenie spojenia pri volaní generovaného nástrojom IMS Bench SIPp je zobrazený na Obr Spojenie je inicializované užívateľom user154 na porte 7154 k užívateľovi user724 na porte Obaja sa nachádzali v domovskej sieti s doménou open-ims.test. Z obrázka môžeme spozorovať, že vyzváňanie hovoru trvalo približne 5 sekúnd a dĺžka samotného hovoru trvala približne 46 sekúnd. Celé spojenie je definované pomocou signalizácie SIP. Obr. 6.2: Signalizácia spojenia medzi IMS užívateľmi Správa INVITE je žiadosťou o zostavenie spojenia a taktiež nesie v sebe SDP správu špecifikujúcu parametre spojenia. Správou TRYING je signalizované spracovanie prijatej žiadosti. Odpoveďou na správu INVITE je RINGING, signalizuje taktiež vyzváňanie volaného užívateľa. Následnou správou OK je hovor prijatý a je v nej zapuzdrená aj SDP správa špecifikujúca parametre spojenia. Správa ACK už len signalizuje potvrdenie na príjem odpovede na správu INVITE. Behom hovoru sa o prenos stará protokol RTP. Žiadosť o ukončenie spojenia je poslaná správou BYE. Následná správa OK signalizuje úspešné realizovanie ukončenia spojenia. 56

57 Odchytený paket so správou INVITE je zobrazený na Obr Správa je poslaná z IP adresy , port 7154 (užívateľ user154) na IP adresu , port 4060 (server P-CSCF). Táto správa obsahuje, ako bolo vyššie spomenuté, aj ponuku protokolu SDP. Ponuka obsahuje požiadavky na šírku pásma a taktiež vlastnosti všetkých možných kodekov použiteľných pre túto reláciu Výmena správ Obr. 6.3: Ukážka SIP správy INVITE Priebeh výmeny správy je zobrazený na Obr Správa je poslaná užívateľom user544 na porte 7544 ku užívateľovi user375 na porte Obr. 6.4: Priebeh výmeny správy medzi IMS užívateľmi Správa MESSAGE obsahuje informácie potrebné pre transport správy medzi užívateľmi a taktiež obsahuje samotný text správy. Úspešné prijatie správy je signalizované protistranou správou OK. 57

58 Odchytený paket so správou MESSAGE je zobrazený na Obr Správa je poslaná z IP adresy , port 7544 (užívateľ user544) na IP adresu , port 4060 (server P-CSCF). Obr. 6.5: Ukážka SIP správy MESSAGE Registrácia, odregistrácia, pre-registrácia Priebeh spojenia registrácie a odregistrácie je podobný s jediným rozdielom, že v požiadavke správy je uvedená operácia, ktorú chceme vykonať. Pri pre-registrácii je poslaná len správa REGISTER, ktorá je potvrdená správou OK. Priebeh registrácie pomocou SIP správ je zobrazený na Obr. 6.6, kde je registrácia inicializovaná užívateľom user205 na porte Obr. 6.6: Priebeh registrácie IMS užívateľa Správa REGISTER obsahuje informácie o aktuálnej IP adrese a porte, na ktorom môže byť užívateľ zastihnutý. Registrácia je časovo limitovaná, a tak sa musí periodicky opakovať. Pretože sa v IMS sieťach uskutočňuje overovanie registrácie, odpovedá registračný server správou 401 UNAUTHORIZED obsahujúcou výzvu pre doplnenie potrebných údajov. Po doplnení hlavičky o tieto údaje zasiela užívateľ novú správu REGISTER. Úspešné zakončenie procesu registrácie je nakoniec potvrdené správou OK. 58

59 Odchytený paket so správou REGISTER je zobrazený na Obr Správa je poslaná z IP adresy , port 7205 (užívateľ user205) na IP adresu , port 4060 (server P-CSCF). 6.2 ZÁŤAŽOVÉ TESTY Obr. 6.7: Ukážka SIP správy REGISTER Pre zaťaženie vytvorenej IMS siete boli v rámci diplomovej práce vytvorené tri testy. Prvý test je vykonaný so scenármi registrácie, pre-registrácie a odregistrácie. Druhý test je zameraný na výmenu správ a tretí na volania Test s registráciami V rámci tohto testu bolo registrovaných 1500 užívateľov v pre-registračnej fáze rýchlosťou 10 registrácií za sekundu, konštantnou distribúciou pokusov a s nastaveným prahom IHS na 5%. Nastavenie manažéra testu je uvedené v prílohe diplomovej práce. Fáza výpočtu bola nakonfigurovaná so začiatočnou rýchlosťou 4 scenáre za sekundu (cps calls per second), s nárastom kroku o 4 cps a celkovým počtom piatich krokov. Trvanie každého kroku bolo nastavené na 6 minút. Náhodná distribúcia pokusov o scenár bola nastavená na poissonovo rozdelenie, pretože je považovaný za najviac realistický model distribúcie v telekomunikácií. Percento IHS v rámci jednotlivých scenárov bolo nastavené na 100% z dôvodu nájdenia dosiahnuteľnej kapacity testovaného systému. Rozdelenie použitia jednotlivých scenárov bolo nasledovné: registrácia 20%; odregistrácia 20%; pre-registrácia 60%. Celkový čas testu bol 32 minút a 34 sekúnd. Celkový prehľad vykonaných scenárov behom testu je uvedený v Tab Behom viacerých testov bola zistená skutočnosť, že po prekročení približne 15 registrácii za sekundu padne jadro IMS a všetky ďalšie scenáre sú zahadzované. Konkrétne zlyhá rozhranie Cx, ktoré je chybne implementované v rámci prostredia Open IMS Core. Vývojári z FOKUS to zdôvodňujú tým, že toto prostredie je určené pre skúšobné a nie záťažové testovanie IMS siete. Preto pri zlyhaní rozhrania Cx (prechod medzi 3. a 4. krokom) boli prvky jadra IMS reštartované, čím bolo dosiahnuté pokračovanie testu s menším množstvom neúspešným scenárov. 59

60 Tab. 6.1: Prehľad vykonaných scenárov behom testu s registráciami SCENÁR REGISTRÁCIA ODREGISTRÁCIA 5676 PRE-REGISTRÁCIA 3814 SPOLU ÚSPEŠNÝ POKUS NEÚSPEŠNÝ POKUS CELKOVÝ POČET Prehľad záťaže jednotlivých krokov testu je uvedený v Tab Graf na Obr. 6.8 reprezentuje počet scenárov za sekundu generovaných testovacím systémom. Os x predstavuje dobu testu v sekundách, os y veľkosť záťaže v SAPS. Tab. 6.2: Prehľad záťaže v rámci testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [SAPS] EFEKTÍVNA ZÁŤAŽ SMERODATNÁ ODCHÝLKA [SAPS] 9,93 0,85 0,00 4,08 2,03 0,00 7,97 3,00 1,00 11,88 3,48 5,00 15,75 3,94 7,00 20,07 4,37 9,00 MINIMUM [SAPS] MAXIMUM [SAPS] 11,00 11,00 16,00 23,00 31,00 34,00 Obr. 6.8: Počet scenárov za sekundu v teste s registráciami Histogram zaťaženia v SAPS pre každý krok je zobrazený na Obr Os x predstavuje počet scenárov za sekundu, os y percento výskytu daného zaťaženia. Z obrázku je vidieť, že to odpovedá poissonovej distribúcii popísanej v kapitole diplomovej práce. Pre každý krok je zobrazený teoretický aj praktický priebeh zaťaženia. Stred každej krivky približne odpovedá parametru λ, ktorý je definovaný ako požadovaná záťaž daného kroku. 60

61 Obr. 6.9: Histogram zaťaženia v teste s registráciami Pravdepodobnostné rozdelenie zaťaženia v SAPS je zobrazené na Obr Os x predstavuje počet scenárov za sekundu, os y pravdepodobnosť. Pre každý krok je uvedený teoretický, aj praktický priebeh. Stred každej krivky približne odpovedá parametru λ, ktorý je definovaný ako požadovaná záťaž daného kroku. Rozdelenie odpovedá teoretickým predpokladom uvedeným v kapitole diplomovej práce. Obr. 6.10: Pravdepodobnostné rozdelenie zaťaženia v teste s registráciami V rámci nasledujúcich grafov je zahrnutá ako referenčná beziérová krivka záťaže v SAPS (zelená krivka). V priebehu registrácií sú najviac vyťažené prvky S-CSCF a HSS v rámci jadra IMS siete, tak bolo monitorované vyťaženie procesorov a dostupnej pamäte na hostiteľských počítačoch, kde sú tieto prvky spustené. Prehľad vyťaženia procesora na stroji so spusteným serverom S-CSCF je uvedené v Tab. 6.3 a na stroji so spustenou databázou HSS je uvedené v Tab Graf vyťaženia procesorov je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y vyťaženie procesorov v percentách. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spustenou databázou HSS. Je vidieť, že s narastajúcou záťažou stúpa aj vyťaženie procesorov na oboch sledovaných počítačoch. Menšie vyťaženie procesorov na začiatku 4. kroku je spôsobený reštartom IMS prvkov. 61

62 Tab. 6.3: Vyťaženie procesora na stroji s S-CSCF v rámci testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU S-CSCF 17,67 9,27 6,54 7,66 7,53 0,46 13,43 9,57 1,99 20,67 12,09 4,90 29,76 18,95 0,00 48, 07 22,91 1,85 MINIMUM [%] MAXIMUM [%] 61,69 38,61 58,69 100,00 100,00 100,00 Tab. 6.4: Vyťaženie procesora na stroji s HSS v rámci testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU HSS 38,06 16,82 11,27 11,68 6,87 0,00 23,87 11,88 2,99 36,49 15,23 8,42 48,94 21,00 7,84 69,65 19,82 22,01 MINIMUM [%] MAXIMUM [%] 90,00 48,95 100,00 100,00 100,00 100,00 Obr. 6.11: Vyťaženie procesorov na strojoch S-CSCF a HSS behom testu s registráciami Prehľad dostupnej pamäte na stroji so spusteným serverom S-CSCF je uvedené v Tab. 6.5 a na stroji so spustenou databázou HSS je uvedené v Tab Graf dostupnej pamäte je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y dostupnú pamäť v MB. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spustenou databázou HSS Je vidieť, že s narastajúcou záťažou sa znižuje dostupná pamäť na oboch sledovaných počítačoch. Uvoľnenie pamäte v rámci stroja so spusteným serverom S-CSCF na začiatku 4. kroku je spôsobený reštartom IMS prvkov. 62

63 Tab. 6.5: Dostupná pamäť na stroji s S-CSCF v rámci testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM S-CSCF MINIMUM [MB] 347,50 1,68 343, ,28 0,51 343, ,92 1,45 337, , 46 2,32 329, , 60 10,69 326, , 97 3,40 335, 59 MAXIMUM [MB] 349, , , ,86 371, ,20 Tab. 6.6: Dostupná pamäť na stroji s HSS v rámci testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM HSS MINIMUM [MB] 113,01 2,35 109,33 107,37 1,20 105,24 101,28 2,23 97,43 91,66 3,33 85,96 77,29 5,82 68,09 47,53 10,84 33,50 MAXIMUM [MB] 116,46 109,27 105,24 97,30 85,89 68,09 Obr. 6.12: Dostupná pamäť na strojoch S-CSCF a HSS behom testu s registráciami Prehľad nezvládnutých scenárov IHS je uvedený v Tab Graf reprezentujúci percento nezvládnutých scenárov je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y percento nezvládnutých scenárov. Ako bolo spomenuté vyššie, po prekročení rýchlosti približne 15 registrácii za sekundu nám padne rozhranie Cx a tým pádom sú všetky scenára zahadzované (začiatok 4. kroku). Nasledoval reštart prvkov jadra IMS siete, čím sa postupne zminimalizovali chybne vykonané scenáre. Avšak rýchlosť registrácií bola privysoká, pretože stále dochádzalo k určitému počtu nezvládnutých scenárov. Tým pádom bola už prekročená dosiahnuteľná hranica testovaného systému. 63

64 Tab. 6.7: Nezvládnuté scenáre behom testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] PERCENTO IHS SMERODATNÁ ODCHÝLKA [%] 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 14,75 28,63 0,00 0,83 4,61 0,00 MINIMUM [%] MAXIMUM [%] 0,00 0,00 0,00 0,00 100,00 46,43 Obr. 6.13: Percento nezvládnutých scenárov behom testu s registráciami Prehľad prvej registračnej transakcie v rámci všetkých registračných scenárov je uvedený Tab Ide o oneskorenie medzi poslaním správy REGISTER a príchodom správy 401 UNAUTHORIZED. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou narastá priemerný čas transakcie. Tab. 6.8: Oneskorenie 1. transakcie registračných scenárov behom testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE 1. TRANSAKCIE SMERODATNÁ ODCHÝLKA [ms] 46,71 105,03 13,08 20,81 19,12 13,04 32,22 64,49 12,77 45,99 81,60 12,98 80,07 144,23 12,86 169,86 450,08 12,78 MINIMUM [ms] MAXIMUM [ms] 879,39 325, , , , ,25 64

65 Obr. 6.14: Oneskorenie 1. transakcie registračných scenárov behom testu s registráciami Prehľad druhej registračnej transakcie v rámci všetkých registračných scenárov je uvedený v Tab Ide o oneskorenie medzi poslaním druhej správy REGISTER a príchodom správy OK. Graf oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou narastá taktiež priemerný čas transakcie. Tab. 6.9: Oneskorenie 2. transakcie registračných scenárov behom testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE 2. TRANSAKCIE SMERODATNÁ ODCHÝLKA [ms] 39,95 57,91 22,22 28,60 19,06 18,80 35,22 33,14 18,53 48,53 55,50 18,36 73,06 85,62 18,73 143,37 195,54 18,30 MINIMUM [ms] MAXIMUM [ms] 951,79 325,79 812,40 904, , ,97 Obr. 6.15: Oneskorenie 2. transakcie registračných scenárov behom testu s registráciami Prehľad registračnej transakcie v rámci scenára pre-registrácie je uvedený v Tab Jedná sa o oneskorenie medzi poslaním správy REGISTER a príchodom správy OK. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou narastá taktiež priemerný čas transakcie. 65

66 Tab. 6.10: Oneskorenie transakcie pre-registračného scenára behom testu s registráciami KROK POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE TRANSAKCIE SMERODATNÁ ODCHÝLKA [ms] 47,59 27,66 35,54 66,46 94,69 35,50 97,22 149,79 35,29 155,78 265,02 35,57 300,26 505,75 35,53 MINIMUM [ms] MAXIMUM [ms] 370, , , , ,88 Obr. 6.16: Oneskorenie transakcie pre-registračného scenára behom testu s registráciami Prehľad prvej registračnej transakcie v rámci scenára registrácie je uvedený v Tab Jedná sa o oneskorenie medzi poslaním správy REGISTER a príchodom správy 401 UNAUTHORIZED. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou narastá taktiež priemerný čas transakcie. Tab. 6.11: Oneskorenie 1. transakcie registračného scenára behom testu s registráciami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE 1. TRANSAKCIE SMERODATNÁ ODCHÝLKA [ms] 46,71 105,03 13,08 24,32 23,80 13,13 37,87 80,09 13,09 52,18 95,04 13,11 89,56 158,67 12,87 173,35 401,49 13,12 MINIMUM [ms] MAXIMUM [ms] 879,39 325, , , , ,25 66

67 Obr. 6.17: Oneskorenie 1. transakcie registračného scenára behom testu s registráciami Prehľad prvej registračnej transakcie v rámci scenára odregistráciee je uvedený v Tab Jedná sa o oneskorenie medzi poslaním správy REGISTER a príchodom správy 401 UNAUTHORIZED. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou narastá taktiež priemerný čas transakcie. Tab. 6.12: Oneskorenie 1. transakcie odregistračného scenára behom testu s registráciami KROK POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE 1. TRANSAKCIE SMERODATNÁ ODCHÝLKA [ms] 17,57 12,62 13,04 25,95 39,68 12,77 39,62 64,29 12,98 70,21 126,97 12,86 166,54 493,31 12,78 MINIMUM [ms] MAXIMUM [ms] 134,20 715,13 808, , ,55 Obr. 6.18: Oneskorenie 1. transakcie odregistračného scenára behom testu s registráciami Test s výmenou správ V rámci tohto testu bolo registrovaných 1500 užívateľov v pre-registračnej fáze rýchlosťou 10 registrácií za sekundu, konštantnou distribúciou pokusov a s nastaveným prahom IHS na 5%. Nastavenie manažéra testu je uvedené v prílohe diplomovej práce. 67

68 Fáza výpočtu bola nakonfigurovaná so začiatočnou rýchlosťou 40 cps, s nárastom kroku o 40 cps a celkovým počtom piatich krokov. Trvanie každého kroku bolo nastavené na 11 minút. Náhodná distribúcia pokusov o scenár bola nastavená na poissonovo rozdelenie. Percento IHS v rámci scenára výmeny správ bolo nastavené na 1%. Priemerná dĺžka správy bola nastavená na 140 bajtov s rovnomerným rozdelením distribúcie dĺžky správy. Celkový čas testu bol 57 minút a 34 sekúnd. Celkový prehľad vykonaných scenárov behom testu je uvedený v Tab Tab. 6.13: Prehľad vykonaných scenárov behom testu s výmenou správ SCENÁR REGISTRÁCIA 1500 VÝMENA SPRÁVY SPOLU ÚSPEŠNÝ POKUS NEÚSPEŠNÝ POKUS CELKOVÝ POČET Prehľad záťaže jednotlivých krokov testu je uvedený v Tab Graf na Obr reprezentuje počet scenárov za sekundu generovaných testovacím systémom. Os x predstavuje dobu testu v sekundách, os y veľkosť záťaže v SAPS. Tab. 6.14: Prehľad záťaže v rámci testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [SAPS] EFEKTÍVNA ZÁŤAŽ SMERODATNÁ ODCHÝLKA [SAPS] MINIMUM [SAPS] 9,93 0,96 0,00 40,09 6,16 21,00 80,19 9,38 54,00 120,28 11,35 85,00 159,91 13,01 125,00 200,26 16,75 0,00 MAXIMUM [SAPS] 11,00 59,00 108,00 160,00 201,00 248,00 Obr. 6.19: Počet scenárov za sekundu v teste s výmenou správ Histogram zaťaženia v SAPS pre každý krok je zobrazený na Obr Os x predstavuje počet scenárov za sekundu, os y percento výskytu daného zaťaženia. Zodpovedá to poissonovej distribúcii popísanej v kapitole diplomovej práce. Pre každý krok je zobrazený teoretický aj praktický priebeh zaťaženia. Stred každej krivky približne odpovedá parametru λ, ktorý je definovaný ako požadovaná záťaž daného kroku. 68

69 Obr. 6.20: Histogram zaťaženia v teste s výmenou správ Pravdepodobnostné rozdelenie zaťaženia v SAPS je zobrazené na Obr Os x predstavuje počet scenárov za sekundu, os y pravdepodobnosť. Pre každý krok je uvedený teoretický, aj praktický priebeh. Stred každej krivky približne odpovedá parametru λ, ktorý je definovaný ako požadovaná záťaž daného kroku. Rozdelenie odpovedá teoretickým predpokladom uvedeným v kapitole diplomovej práce. Obr. 6.21: Pravdepodobnostné rozdelenie v teste s výmenou správ V rámci nasledujúcich grafov je zahrnutá ako referenčná beziérová krivka záťaže v SAPS (zelená krivka). Pre ukážku bolo monitorované vyťaženie procesora a dostupnej pamäte na hostiteľských počítačoch so spustenými servermi S-CSCF a P-CSCF. Prehľad vyťaženia procesora na stroji so spusteným serverom S-CSCF je uvedené v Tab a na stroji so spustenou databázou HSS je uvedené v Tab Graf vyťaženia procesorov je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y vyťaženie procesorov v percentách. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spusteným serverom P-CSCF. S narastajúcou záťažou nepatrne stúpa aj vyťaženie procesorov. 69

70 Tab. 6.15: Vyťaženie procesora na stroji s S-CSCF v rámci testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU S-CSCF 16,57 9,74 3,9 4,88 5,79 0,00 7,53 6,19 0,50 9,95 6,68 1,48 12,54 6,92 2,50 15,76 7,35 0,99 MINIMUM [%] MAXIMUM [%] 95,52 50,49 59,80 60,50 60,00 51,22 Tab. 6.16: Vyťaženie procesora na stroji s P-CSCF v rámci testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU S-CSCF 2,43 3,19 0,00 4,06 5,16 0,00 7,76 5,18 1,49 7,90 5,34 0,99 11,21 7,02 0,99 13,17 7,00 0,52 MINIMUM [%] MAXIMUM [%] 18,14 33,17 53,54 54,41 71,29 47,50 Obr. 6.22: Vyťaženie procesorov na strojoch S-CSCF a P-CSCF behom testu s výmenou správ Prehľad dostupnej pamäte na stroji so spusteným serverom S-CSCF je uvedený v Tab a na stroji so spusteným serverom P-CSCF je uvedený v Tab Graf dostupnej pamäte je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y dostupnú pamäť v MB. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spusteným serverom P-CSCF. S narastajúcou záťažou sa nepatrne znižuje dostupná pamäť na oboch sledovaných počítačoch. 70

71 Tab. 6.17: Dostupná pamäť na stroji s S-CSCF v rámci testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM S-CSCF MINIMUM [MB] 224,63 2,23 221,35 218,57 0,37 217,77 215,71 0,81 213,38 211,52 0,70 210,37 207,61 0,72 206,38 203,45 0,67 202,52 MAXIMUM [MB] 230,51 221,30 218,45 214,37 210,40 206,56 Tab. 6.18: Dostupná pamäť na stroji s P-CSCF v rámci testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM P-CSCF MINIMUM [MB] 247,66 1,36 246,04 243,48 0,58 242,02 239,35 0,66 238,58 235,33 0,69 234,61 231,27 0,82 230,63 227,21 0,55 226,16 MAXIMUM [MB] 251,65 246,07 242,91 238,82 234,85 230,39 Obr. 6.23: Dostupná pamäťť na strojoch S-CSCF a P-CSCF behom testu s výmenou správ Prehľad percenta nezvládnutých scenárov IHS je uvedený v Tab Graf reprezentujúci toto percento je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y percento nezvládnutých scenárov. Scenáre začali byť zahadzované až v prechode do 5. kroku testu, kedy rýchlosť narástla na 200 cps. Aj keď sa jedná o minimálne percento IHS, tak rýchlosť 200 cps môžeme určiť ako dosiahnuteľnú hranicu testovaného systému. 71

72 Tab. 6.19: Nezvládnuté scenáree behom testu s výmenou správ KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] PERCENTO IHS SMERODATNÁ ODCHÝLKA [%] 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,01 0,16 0,00 0,12 0,97 0,00 MINIMUM [%] MAXIMUM [%] 0,00 0,00 0,00 0,00 4,22 12,39 Obr. 6.24: Percento nezvládnutých scenárov behom testu s výmenou správ Prehľad oneskorenia transakcie výmeny správy je uvedený v Tab Jedná sa konkrétne o oneskorenia medzi poslaním správy MESSAGE a príchodom správy OK. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. S narastajúcou záťažou nepatrne narastá taktiež priemerný čas transakcie. Histogram tohto oneskorenia je uvedený na Obr Os x predstavuje oneskorenie v milisekundách, os y percento výskytu daného oneskorenia. Krivky predstavujú jednotlivé kroky testu. Pre všetky kroky bolo najčastejšie oneskorenie výmeny správy medzi 2 2,5 ms. Tab. 6.20: Oneskorenie transakcie výmeny s správy behom testu s výmenou správ KROK POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE SPRÁVY SMERODATNÁ ODCHÝLKA [ms] 2,50 1,74 1,86 2,63 2,06 1,87 2,77 2,47 1,87 2,87 2,65 1,85 3,00 2,65 1,87 MINIMUM [ms] MAXIMUM [ms] 56,92 112,63 82,19 97,17 97,12 72

73 Obr. 6.25: Oneskoreniee transakcie výmeny správy behom testu s výmenou správ Obr. 6.26: Histogram oneskorenia transakcie výmeny správy behom testu s výmenou správ Test s volaniami V rámci tohto testu sa vyskytol problém. Aj pri záťaží vytvorenéhoo jedného volania za sekundu sa po určitej dobe vyťažil procesor na stroji so spusteným serverom P-CSCF na 100% a všetky ďalšie vytvorené volania boli zahadzované. Preto bol vymenený počítač, na ktorom bol spustený serverr P-CSCF, za výkonnejší. Konkrétne sa jednalo o počítač s procesorom Inter Core 2 Duo 3 Ghz a pamäťou 3 GB. Po týchto zmenách bol výkon lepší, ale len nepatrne. Testovaný systém začal zahadzovať vytvorené volania po navýšení na rýchlosť vytvorenia troch volaní za sekundu. Opäť to bolo z dôvodu vyťaženia procesora na stroji so spusteným serverom P-CSCF. Preto sme sa rozhodli vytvoriť pol hodinový test len so záťažou dvoch volaní za sekundu. V pre-registračnej fáze bolo registrovaných 1500 užívateľov rýchlosťou 10 registrácií za sekundu, konštantnou distribúciou pokusov a s nastaveným prahom IHS na 5%. Nastavenie manažéra testu je uvedené v prílohe diplomovej práce. Fáza výpočtu bola nakonfigurovaná, ako bolo spomenuté vyššie, s rýchlosťou 2 cps a dobou trvanie 30 minút. Náhodná distribúcia pokusov o vytvorenie volania bola nastavená na poissonovo rozdelenie. Percento IHS v rámci scenára volania bolo nastavené na 1%. Priemerná dĺžka vyzváňaniaa hovoru bola nastavená na 3 sekundy s exponenciálnym rozdelením distribúcie dĺžky vyzváňania. Priemerná dĺžka samotného hovoru bola nastavená na 30 sekúnd s exponenciálnym rozdelením distribúcie dĺžky hovoru. Celkový čas testu bol 32 minút a 34 sekúnd. Celkový prehľad vykonaných scenárov behom testu je uvedený v Tab

74 Tab. 6.21: Prehľad vykonaných scenárov behom testu s volaniami SCENÁR REGISTRÁCIA 1500 VOLANIE 3621 SPOLU 5121 ÚSPEŠNÝ POKUS NEÚSPEŠNÝ POKUS CELKOVÝ POČET Prehľad záťaže testu je uvedený v Tab Graf na Obr reprezentuje počet scenárov za sekundu generovaných testovacím systémom. Os x predstavuje dobu testu v sekundách, os y veľkosť záťaže v SAPS. Tab. 6.22: Prehľad záťaže v rámci testu s volaniami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [SAPS] EFEKTÍVNA ZÁŤAŽ SMERODATNÁ ODCHÝLKA [SAPS] 9,93 1,02 0,00 2,01 1,44 0,00 MINIMUM [SAPS] MAXIMUM [SAPS] 11,00 8,00 Obr. 6.27: Počet scenárov za sekundu v teste s volaniami Histogram zaťaženia v SAPS je zobrazený na Obr Os x predstavuje počet scenárov za sekundu, os y percento výskytu daného zaťaženia. Červená krivka odpovedá praktickému priebehu zaťaženia, zelená krivka teoretickému priebehu poissonovej distribúcie. Priebeh odpovedá teoretickým predpokladom. Obr. 6.28: Histogram zaťaženia v teste s volaniami 74

75 Pravdepodobnostné rozdelenie zaťaženia v SAPS je zobrazené na Obr Os x predstavuje počet scenárov za sekundu, os y pravdepodobnosť. Červená krivka odpovedá praktickému priebehu zaťaženia, zelená krivka teoretickému priebehu poissonovej distribúcie. Priebeh odpovedá teoretickým predpokladom. Obr. 6.29: Pravdepodobnostné rozdelenie v teste s volaniami V rámci nasledujúcich grafov je zahrnutá ako referenčná beziérová krivka záťaže v SAPS (zelená krivka). Pri teste bolo monitorované vyťaženie procesora a dostupnej pamäte na hostiteľských počítačoch so spustenými servermi S-CSCF a P-CSCF. Prehľad vyťaženia procesora na stroji so spusteným serverom S-CSCF je uvedené v Tab a na stroji so spusteným serverom P-CSCF je uvedené v Tab Graf vyťaženia procesorov je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y vyťaženie procesorov v percentách. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spusteným serverom P-CSCF. Tab. 6.23: Vyťaženie procesora na stroji s S-CSCF v rámci testu s volaniami KROK POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU S-CSCF MINIMUM [%] PRE-REG 10 16,64 6,70 9,85 53, ,68 7,84 0,00 64,56 Tab. 6.24: Vyťaženie procesora na stroji s P-CSCF v rámci testu s volaniami KROK POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] SMERODATNÁ ODCHÝLKA [%] CPU P-CSCF MINIMUM [%] PRE-REG 10 2,59 2,85 0,99 24, ,65 10,52 1,01 83,42 MAXIMUM [%] MAXIMUM [%] 75

76 Obr. 6.30: Vyťaženie procesorov na strojoch S-CSCF a P-CSCF behom testu s volaniami Prehľad dostupnej pamäte na stroji so spusteným serverom S-CSCF je uvedený v Tab a na stroji so spusteným serverom P-CSCF je uvedený v Tab Graf dostupnej pamäte je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y dostupnú pamäť v MB. Fialová krivka predstavuje stroj so spusteným serverom S-CSCF, hnedá krivka stroj so spusteným serverom P-CSCF. Tab. 6.25: Dostupná pamäť na stroji s S-CSCF v rámci testu s volaniami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM S-CSCF MINIMUM [MB] 216,46 2,19 212,65 212,88 0,48 211,98 MAXIMUM [MB] 221,85 211,98 Tab. 6.26: Dostupná pamäť na stroji s P-CSCF v rámci testu s volaniami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [MB] SMERODATNÁ ODCHÝLKA [MB] RAM P-CSCF MINIMUM [MB] MAXIMUM [MB] 2028,62 1, , , ,59 0, , ,95 Obr. 6.31: Dostupná pamäť na strojoch S-CSCF a P-CSCF behom testu s volaniami 76

77 Prehľad percenta nezvládnutých scenárov IHS je uvedený v Tab Graf reprezentujúci toto percento je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y percento nezvládnutých scenárov. Tab. 6.27: Nezvládnuté scenáree behom testu s volaniami KROK PRE-REG POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [%] PERCENTO IHS SMERODATNÁ ODCHÝLKA [%] 0,00 0,00 0,00 0,03 0,88 0,00 MINIMUM [%] MAXIMUM [%] 0,00 33,33 Obr. 6.32: Percento nezvládnutých scenárov behom testu s volaniami Prehľad oneskorenia nastavenia relácie, je uvedené v Tab Jedná sa konkrétne o oneskorenie, kedy volajúci poslal správu INVITE a volaný prijal správu ACK. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. Tab. 6.28: Oneskorenie nastavenia relácie behom testu s volaniami KROK 1 2 POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE NASTAVENIAA RELÁCIE SMERODATNÁ ODCHÝLKA [ms] 126,80 68,47 12,21 MINIMUM [ms] MAXIMUM [ms] 615,70 Obr. 6.33: Oneskorenie nastavenia relácie behom testu s volaniami 77

78 Histogram tohto oneskorenia je uvedený na Obr Os x predstavuje oneskorenie v milisekundách, os y percento výskytu daného oneskorenia. Najčastejšie oneskorenie sa pohybovalo okolo 100 ms. Obr. 6.34: Histogram oneskorenia nastavenia relácie behom testu s volaniami Prehľad oneskorenia inicializácie relácie, je uvedené v Tab Jedná sa konkrétne o oneskorenie, kedy volajúci poslal správu INVITE a volaný túto správu prijal. Graf tohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. Tab. 6.29: Oneskorenie inicializácie relácie behom testu s volaniami KROK 1 2 POŽADOVANÁ ZÁŤAŽ [SAPS] ONESKORENIE INICIALIZÁCIE RELÁCIE PRIEMER [ms] SMERODATNÁ ODCHÝLKA [ms] 53,79 38,70 3,48 MINIMUM [ms] MAXIMUM [ms] 520,09 Obr. 6.35: Oneskorenie inicializácie relácie behom testu s volaniami Histogram tohto oneskorenia je uvedený na Obr Os x predstavuje oneskorenie v milisekundách, os y percento výskytu daného oneskorenia. Najčastejšie oneskorenie sa pohybovalo okolo 40 ms. 78

79 Obr. 6.36: Histogram oneskorenia inicializácie relácie behom testu s volaniami Prehľad oneskorenia ukončenia relácie, je uvedené v Tab Jedná sa konkrétne o oneskorenie medzi správou BYE a korešpondujúcou správou OK. Graf ohto oneskorenia je zobrazený na Obr Os x predstavuje čas testu v sekundách, os y oneskorenie v milisekundách. Tab. 6.30: Oneskorenie ukončenia relácie behom testu s volaniami KROK 1 2 POŽADOVANÁ ZÁŤAŽ [SAPS] PRIEMER [ms] ONESKORENIE UKONČENIA RELÁCIE SMERODATNÁ ODCHÝLKA [ms] 75,40 53,12 3,07 MINIMUM [ms] MAXIMUM [ms] 526,20 Obr. 6.37: Oneskorenie ukončenia relácie behom testu s volaniami Histogram tohto oneskorenia je uvedený na Obr Os x predstavuje oneskorenie v milisekundách, os y percento výskytu daného oneskorenia. Najčastejšie oneskorenie sa pohybovalo okolo 50 ms. 79

80 Obr. 6.38: Histogram oneskorenia ukončenia relácie behom testu s volaniami 6.3 REÁLNY HOVOR Pre ukážku v rámci diplomovej práce bol vytvorený reálny hovor pomocou IMS klienta nainštalovaného na múdrom telefóne (smartphone) s operačným systémom Android. Schéma zapojenia tejto siete je uvedená na Obr Konkrétne sa jedná o aplikáciu IMSDroid slúžiacu ako open source IMS klient pre zariadenia s operačným systémom Android. Je postavený na kostre doubango, ktorá bola navrhnutá aby efektívne pracovala na systémoch mobilných zariadení s obmedzenou pamäťou a nižším výpočtovým výkonom. [15] Obr. 6.39: Schéma zapojenia siete pre reálny hovor Pomocou prísupového bodu boli pripojené do siete dva múdre telefóny s pridelenou IP adresou v rozsahu adries danej siete. Úvodné menu po spustení aplikácie IMSDroid je znázornené na Obr Najskôr nastavíme v sekcii Options je správne identity užívateľa a nastavenie servera P-CSCF (Obr. 6.41). Po tomto nastavení sa v hlavnom menu môžeme registrovať do IMS siete pomocou ikony Sign In. 80

81 Obr. 6.40: Menu aplikácie IMSDroid Obr. 6.41: Nastavenie identít užívateľa a servera P-CSCF v aplikácii IMSDroid V rámci aplikácie IMSDroid boli prihlásení do IMS siete užívatelia Alice a Bob. Uskutočnený hovor je zobrazený na Obr Obr. 6.42: Uskutočnené volanie v aplikácii IMSDroid Pomocou programu Wireshark boli odchytené jednotlivé pakety uskutočneného volania, z ktorých bol vytvorený diagram signalizácie daného hovoru (Obr. 6.43). Vidíme, že vyzváňanie hovoru trvalo približne 5 sekúnd a samotný hovor trval približne 31 sekúnd. 81

82 Hovor je inicializovaný užívateľom Alice na IP adrese ku užívateľovi Bob na IP adrese Signalizácia odpovedá teoretickým predpokladom. Obr. 6.43: Diagram signalizácie hovoru v rámci aplikácie IMSDroid Aplikácia IMSDroid ponúka okrem hovoru aj ďalšie možnosti, ako napríklad výmenu správ, videohovor, posielanie súborov atď. Ukážka videohovoru je zobrazená na Obr Obr. 6.44: Videohovor v aplikácii IMSDroid 82