Sít¥ nových generací a jejich bezpe£nostní problémy pro
Transkript
Sít¥ nových generací a jejich bezpe£nostní problémy pro
FAKULTA ELEKTROTECHNIKY A INFORMATIKY VYSOKÁ KOLA BÁSKÁ - TECHNICKÁ UNIVERZITA OSTRAVA Sít¥ nových generací a jejich bezpe£nostní problémy pro integrovanou výuku VUT a VB-TUO Garant p°edm¥tu: Miroslav Voz¬ák Autor textu: Miroslav Voz¬ák Libor Michalek © 2014 Vznik t¥chto skript byl podpo°en projektem £. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpo£tem eské republiky. Za odbornou nápl¬ tohoto vydání odpovídají auto°i. Miroslav Voz¬ák je docentem na Fakult¥ elektrotechniky a informatiky VB-Technické univerzity v Ostrav¥, kde p°edná²í p°edm¥t Sít¥ nových generací. Libor Michalek je odborným asistentem na Fakult¥ elektrotechniky a informatiky VB-Technické univerzity v Ostrav¥. Rukopis nepro²el ºádnou jazykovou úpravou. Vznik skript byl podpo°en projektem £. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpo£tem eské republiky. Tato publikace nepro²la redak£ní ani jazykovou úpravou. © Miroslav Voz¬ák, Libor Michalek, 2014, VB-Technická univerzita Ostrava Autor: Katedra: Název: Místo, rok, vydání: Po£et stran: Vydala: Náklad Miroslav Voz¬ák, Libor Michalek Katedra telekomunika£ní techniky Sít¥ nových generací a jejich bezpe£nostní problémy pro integrovanou výuku VUT a VB-TUO Ostrava, 2014, 1. vydání 119 Vysoká ²kola bá¬ská-Technická univerzita Ostrava CD-ROM, 30 ks Neprodejné ISBN 978-80-248-3558-7 Tato publikace vznikla zejména jako podp·rný text pro studenty p°edm¥tu Sít¥ nových v rámci projektu OPVK s názvem Spole£né aktivity VUT a VB-TUO p°i vytvá°ení obsahu a nápln¥ odborných akreditovaných kurz· ICT, Registra£ní £íslo projektu - CZ.1.07/2.2.00/28.0062. Skriptum je psáno v systému LATEX, jenº je voln¥ ²i°itelný pod licencí LATEX- Project Public License (LPPL). generací a jejich bezpe£nostní problémy pro integrovanou výuku VUT a VB-TUO LATEX © 2014 doc. Ing. Miroslav Voz¬ák, Ph.D. Ing. Libor Michalek, Ph.D. Vysoká ²kola bá¬ská-Technická univerzita Ostrava 17. listopadu 15 708 33 Ostrava Poruba eská republika mailto:[email protected] http://comtech.vsb.cz ISBN 978-80-248-3558-7 Obsah 1 Úvod do teorie hromadné obsluhy 1.1 1.2 1.3 1.4 1 Vlastnosti front . . . . . . . . . . . Základní t°ídy proces· . . . . . . . Náhodné procesy . . . . . . . . . . Charakteristiky náhodných veli£in 1.4.1 Stacionarita . . . . . . . . . 1.4.2 Stacionarita v ²ir²ím smyslu 1.4.3 Ergodicita vstupního toku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 P°ehled nej£ast¥j²ích rozd¥lení 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 Binomické rozd¥lení . . . . . . Poissonovo rozd¥lení . . . . . . Geometrické rozd¥lení . . . . . Rovnom¥rné diskrétní rozd¥lení Bernoulliho rozd¥lení . . . . . . Normální (Gaussovo) rozd¥lení Exponenciální rozd¥lení . . . . Erlangovo rozd¥lení . . . . . . . Rovnom¥rné rozd¥lení . . . . . Gamma rozd¥lení . . . . . . . . 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Markovovské °et¥zce, procesy a °e²ení vybraných úloh SHO 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Diskrétní Markovovy °et¥zce . . . . . . . . . . . P°echodová matice . . . . . . . . . . . . . . . . Markovovské procesy . . . . . . . . . . . . . . . Procesu vzniku a zániku v systémech hromadné Littleho vztah . . . . . . . . . . . . . . . . . . . Poissonovský proces . . . . . . . . . . . . . . . 3.6.1 S£ítání a d¥lení Poissonovských proces· Aplikace procesu vzniku a zániku v SHO . . . . . . . . . . . . . . . . . . . obsluhy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Systém Systém Systém Systém M/M/1 s nekone£nou £ekací °adou . M/M/1/L s kone£nou £ekací °adou . M/M/S s nekone£nou £ekací °adou . M/M/S/L s kone£nou £ekací °adou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Úvod . . . . . . . . . . . . . . . Vlastnosti . . . . . . . . . . . . Funk£nost . . . . . . . . . . . . Instalace . . . . . . . . . . . . . Denovaní Cisco IOS soubor· . Vytvo°ení jednoduché topologie Aplikace funkce Trac Shaping 5.7.1 Zadání . . . . . . . . . . 13 14 16 17 17 19 19 20 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 GNS3 5.1 5.2 5.3 5.4 5.5 5.6 5.7 8 9 9 10 10 10 11 11 12 12 13 4 Vybrané modely systém· hromadné obsluhy 4.1 4.2 4.3 4.4 2 2 3 4 6 7 7 21 22 23 25 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 27 28 28 28 29 31 31 5.8 5.7.2 Propojení VirtualBox a GNS3 5.7.3 e²ení . . . . . . . . . . . . . Metody obsluhy paketových front . . 5.8.1 Zadání . . . . . . . . . . . . . 5.8.2 e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Octave Queueing Package 6.1 6.2 6.3 6.4 6.5 M/M/1 model . . 6.1.1 Zadání . . 6.1.2 e²ení . . M/M/n model . 6.2.1 Zadání . . 6.2.2 e²ení . . Erlang-B model . 6.3.1 Zadání . . 6.3.2 e²ení . . Erlang-C model . 6.4.1 Zadání . . 6.4.2 e²ení . . Engsetova rovnice 6.5.1 Zadání . . 6.5.2 e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 OPNET Modeler 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 Postup návrhu nového projektu a scéná°e . . . . . . . . . Nastavení sluºeb v Application Cong . . . . . . . . . . . Nastavení Prole Cong . . . . . . . . . . . . . . . . . . . 7.3.1 Voice_prf - prol pro telefonii VoIP . . . . . . . . 7.3.2 Http_prf - prol pro sluºbu HTTP . . . . . . . . . 7.3.3 Nastavení atribut· na Voice stanicích . . . . . . . Nastavení atribut· na http stanici . . . . . . . . . . . . . . Nastavení atribut· na Media-Serveru . . . . . . . . . . . . Kongurace p°ístupové sít¥ UTRAN . . . . . . . . . . . . 7.6.1 Nastavení p°enosové kapacity pro klienty telefonie . 7.6.2 Nastavení p°enosové kapacity pro HTTP klienta . Simulace sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . Analýza výsledk· . . . . . . . . . . . . . . . . . . . . . . . 7.8.1 Animace sít¥ . . . . . . . . . . . . . . . . . . . . . DES . . . . . . . . . . . . Entity . . . . . . . . . . . Sou£ásti SimEvents . . . . Simulace systému M/M/5 8.4.1 Zadání . . . . . . . 8.4.2 e²ení . . . . . . . 42 42 42 43 43 44 45 45 45 46 46 46 47 47 47 49 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Queuing Theory in MATLAB 8.1 8.2 8.3 8.4 31 33 35 36 36 . . . . . . 49 51 52 53 54 54 55 55 55 55 55 55 56 57 59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 60 60 61 61 61 9 OMNeT++ 9.1 9.2 63 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 1. generace . . . . . . . . . . . . . . . . . . . 10.2 2. generace . . . . . . . . . . . . . . . . . . . 10.2.1 Vývoj GSM . . . . . . . . . . . . . . . 10.2.2 Struktura sít¥ GSM . . . . . . . . . . 10.3 Mobilní stanice (MS) . . . . . . . . . . . . . 10.4 Subsystém základnových stanic (BSS) . . . . 10.5 Sí´ový spojovací subsystém (NSS) . . . . . . . 10.6 Opera£ní a podp·rný subsystém (OSS) . . . . 10.7 3. generace . . . . . . . . . . . . . . . . . . . 10.7.1 Vývoj UMTS . . . . . . . . . . . . . . 10.7.2 Struktura sít¥ UMTS . . . . . . . . . . 10.8 4. generace . . . . . . . . . . . . . . . . . . . 10.9 Zabezpe£ení sít¥ GSM . . . . . . . . . . . . . 10.9.1 Autentizace uºivatele . . . . . . . . . . 10.9.2 Utajení identity uºivatele . . . . . . . 10.9.3 Utajení p°ená²ených dat a signalizace 10.9.4 Zabezpe£ení sít¥ UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 9.4 Instalace . . . . . . . . . . . . . . . . . INET Framework . . . . . . . . . . . . 9.2.1 Postup instalace INETu . . . . Aplikace sm¥rovacího protokolu OSPF 9.3.1 Zadání . . . . . . . . . . . . . . 9.3.2 e²ení . . . . . . . . . . . . . . 9.3.3 Simulace . . . . . . . . . . . . . Aplikace sm¥rovacího protokolu BGP . 9.4.1 Zadání . . . . . . . . . . . . . . 9.4.2 e²ení . . . . . . . . . . . . . . 9.4.3 Simulace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Mobilních sít¥ a jejich zabezpe£ení 78 11 Bezpe£nostní rizika mobilní komunikace 11.1 11.2 11.3 11.4 Klonování SIM karty . . . . . . . . Jednosm¥rná autentizace . . . . . . Prolomitelnost algoritmu A5 . . . . Absence zabezpe£ení v páte°ní síti 63 63 63 65 65 65 70 72 72 72 76 . . . . . . . . . . . . 78 79 79 80 81 82 83 83 84 84 84 86 86 87 88 88 90 91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1 IMSI catcher pomocí USRP . . . . . . . . . 12.1.1 Instalace a kongurace softwaru . . . 12.1.2 Pr·b¥h útoku . . . . . . . . . . . . . 12.2 Pasivní odposlech pomocí USRP . . . . . . 12.2.1 Podvrºená BTS a aktivní odposlech 12.3 Pasivní odposlech pomocí OsmocomBB . . 12.3.1 Instalace a kongurace . . . . . . . . 12.3.2 Pr·b¥h útoku OpenBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Demonstrace realizovaných útok· 91 92 92 92 94 94 95 96 97 98 100 100 102 13 Bezpe£nostní problémy VoIP 13.1 Zabezpe£ení signalizace ve standardu H.323 . . . . 13.1.1 Autentizace H.323 terminál· . . . . . . . . 13.1.2 Bezpe£nostní proly . . . . . . . . . . . . . 13.2 Zabezpe£ení signaliza£ního protokolu SIP . . . . . 13.2.1 Autentizace v SIP . . . . . . . . . . . . . . 13.3 Systém mezidoménové d·v¥ry . . . . . . . . . . . . 13.3.1 Vkládání ov¥°ené identity . . . . . . . . . . 13.3.2 Mezidoménová d·v¥ra s pouºitím S/MIME 13.3.3 Mezidoménová d·v¥ra s pouºitím TLS . . . 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 110 110 112 112 115 115 116 116 NGN PRO VUT A VB-TUO 1 Úvod do teorie hromadné obsluhy Teorie hromadné obsluhy je matematická disciplína zkoumající obsluºné systémy, kterými m·ºou býti nap°. telekomunika£ní sít¥, dopravní situace, jídelny, obchody, apod. Obsluºný systém m·ºe mít r·znou konguraci, obecn¥ obsahuje vstupy, kterými p°icházejí poºadavky s r·znou intenzitou (r·zný po£et poºadavk· za vte°inu), dále je zde °ada (fronta) pro £ekání na obsluhu a obsluhová místa, která lze denovat rychlostí/intenzitou obsluhy (po£et odbavených poºadavk· za vte°inu) 1.1. Koncept bloku £ekání na obsluhu m·ºe obsahovat jednu £i více vstupních front s r·znou velikostí a s r·zným zp·sobem °azení nebo obsluhou poºadavk·, p°ípadn¥ dopln¥ných i o systém ochrany p°ed zahlcením. Blok obsluhy m·ºe mít jednu, £i více obsluºných jednotek. V závislosti na pom¥ru intenzity p°íchodu poºadavk· a výkonnosti bloku obsluhy m·ºe docházet k pozdrºení poºadavk· ve frontách, p°ípadn¥ dokonce i k odmítnutí poºadavku (ztrát¥), hrozí-li (nebo uº i do²lo k) zahlcení fronty £i doba £ekání poºadavku na obsluhu p°ekro£ila £asový limit závislý na typu sluºby. U model· hromadné obsluhy je £asto cílem m¥°ení vzájemných vazeb mezi základními ukazateli charakterizujícími kvalitu a efektivitu systému hromadné obsluhy a nalezení optimálního provozního reºimu vzhledem ke zvolenému kritériu optimalizace systému zpravidla vede podstatnému sníºení moºnosti vzniku front, nebo sníºení celkových ztrát z d·vodu £ekání. Na druhou stranu je také nutné se zabývat i ekonomickou stránkou problému sníºení pravd¥podobnosti vzniku front je ve v¥t²in¥ p°ípad· dosaºeno roz²í°ením kapacity obsluºného za°ízení, tedy za cenu navr²ení prost°edk· na systém. Cílem je tedy nalézt optimální relaci mezi ur£itou mírou kvality poskytovaných sluºeb (p°edstavovanou dobou obsluhy, ztrátami a dal²ími kvalitu sniºujícími parametry) a náklady na dosaºení dané kvality sluºby (kdy se náklady pak promítnou do ceny sluºby pro zákazníka) [30]. Obrázek 1.1: Bloky Systému hromadné obsluhy Jak jiº bylo zmín¥no, tak vstupní poºadavky p°icházejí do systému hromadné obsluhy a °adí se do fronty. Proces p°íchodu vstupních poºadavk· se nazývá vstupní tok. Poºadavek z £ela fronty je obsluhován kanálem obsluhy. Po obslouºení poºadavek odchází ze systému; tomuto procesu °íkáme výstupní tok. Proces obsluhy je obvykle náhodný [20]. Náhodné procesy popisují takové zm¥ny systém· v £ase, které souvisí s p·sobením náhodných faktor·. Realizací náhodných proces· jsou reálné funkce, u kterých pr·b¥h není dop°edu znám. Podle spojitosti £asu a stavu se náhodné procesy d¥lí na: procesy s diskrétním £asem a diskrétními stavy (°et¥zce), procesy s diskrétním £asem a spojitými stavy, procesy se spojitým £asem a nespojitými stavy, procesy se spojitým £asem a spojitými stavy. 1 1 ÚVOD DO TEORIE HROMADNÉ OBSLUHY 1.1 Vlastnosti front Systémy front se mohou li²it v °ad¥ hledisek [20]. Rozd¥lení t¥chto hledisek je následující: Podle po£tu generovaných poºadavk· zdroj vstupních jednotek m·ºe být kone£ný nebo nekone£ný. Systém je otev°ený, kdyº zdroj vstupních jednotek je nekone£ný a po obsluze se model nestará o to, co se d¥je s obslouºenými poºadavky. V p°ípad¥ uzav°eného systému po£et vstupních poºadavk· je kone£ný a obslouºené poºadavky se £asem vrátí do vstupního toku. Vstupní tok m·ºe být deterministický (nap°. pravidelné p°íchody, p°íchody na objednávku) nebo náhodný, p°i£emº jednotky mohou vstupovat do systému jednotliv¥ nebo po skupinách. D·leºitým parametrem systému obsluhy je ztrátovost, která p°edstavuje nevy°ízené poºadavky. Na základ¥ toho, jestli se ztrátovost v modelu front p°ipou²tí nebo nep°ipou²tí, daný model je: bezeztrátový nebo pracuje se ztrátami. 1.2 Základní t°ídy proces· Posloupností nezávislých náhodných veli£in nazýváme posloupnost {Xn }∞ n=−∞ takovou, ºe pro jakoukoliv k -tici (i1 , i2 , ..., ik ), k = 1, 2, ... platí P (Xi1 ≤ x1 , Xi2 ≤ x2 , ..., Xik ≤ xk ) = k Y (1.1) P (Xij ≤ xj ). j=1 Bodový proces N (t) nazýváme: vzájemn¥ disjunktních interval· (s1 , s1+t1 ), (s2 , s2+t2 ), ..., (sk , sk+tk ) tvo°í N (s1 , s1+t1 ), N (s2 , s2+t2 ), ..., N (sk , sk+tk ) posloupnost nezávislých náhodných veli£in. procesem regenerativním procesem rekurentním procesem homogenním, procesem nezávislými p°ír·stky práv¥ kdyº pro libovolnou k -tici práv¥ kdyº posloupnost dob mezi událostmi {τn } je posloupností nezávislých náhodných veli£in. práv¥ kdyº posloupnost dob mezi událostmi {τn } je posloupností nezávislých a stejn¥ rozd¥lených náhodných veli£in, tzn. Ak (t) = A(t), k = 1, 2, ... jestliºe pro kaºdé s ∈ R má N (s, t) stejné rozd¥lení pravd¥podobnosti jako N (0, t) a tedy N (t). To znamená, ºe musí platit vn (s, t) = vn (0, t) = vn (t) pro libovolné s, t ∈ R+ , n ∈ N. Je-li N (t) homogenní bodový proces, potom platí E(N (t)) = tE(E(N (t)) = tµ , kde µ = E(N (1)) je pr·m¥rný po£et událostí za jednotku £asu (hustota procesu). P°edpoklad homogenity se obvykle vztahuje na ur£itý (nedlouhý) £asový úsek a tímto postupem lze pracovat po £ástech s homogenními procesy. Pro kaºdý homogenní bodový proces existuje: lim t→0+ 2 s 1 − v0 (t) =λ≥0 t (1.2) NGN PRO VUT A VB-TUO kde λ se nazývá intenzitou (parametrem) homogenního procesu. procesem ordinárním práv¥ kdyº pro libovolné s ≤ 0 platí lim t→0+ 1 − v0 (s, t) − v1 (s, t) =0 t (1.3) To znamená, ºe ve velmi krátkém £asovém intervalu je pravd¥podobnost, ºe nastane více neº jedna událost °ádov¥ men²í, neº je délka tohoto intervalu. 1.3 Náhodné procesy Náhoda je p°í£inou toho, ºe výsledek n¥kterých £inností £i proces· nelze s jistotou p°edpov¥d¥t. Tyto £innosti a procesy se nazývají náhodnými pokusy. Jednotlivé výsledky náhodného pokusu nebo skupiny t¥chto výsledk· se nazývají náhodné jevy, jedná se tedy o takové jevy, které provedením náhodného pokusu bu¤ nastanou nebo nenastanou. Mnoºina v²ech moºných výsledk· náhodného pokusu tvo°í tzv. výb¥rový prostor [20]. Náhodnou prom¥nnou známe tehdy, pokud jsou známy hodnoty, které tato prom¥nná nabývá a pravd¥podobnosti, s jakými tyto hodnoty nabývá. Potom tvrdíme, ºe známe rozd¥lení náhodné prom¥nné. Náhodné prom¥nné budeme ozna£ovat velkými písmeny. Rozd¥lení náhodné prom¥nné popisujeme distribu£ní funkcí, která je denovaná následovn¥: (1.4) F (x) = P [X < x] kde P (X < x) je pravd¥podobnost, ºe náhodná veli£ina X nabývá hodnotu men²í neº x. Distribu£ní funkce je neklesající, zleva spojitá a platí lim F (x) = 0, lim F (x) = 1 x→∞ x→−∞ (1.5) Pro diskrétní náhodnou prom¥nnou X je F skoková funkce (po £ástech konstantní) se skoky v bode xk , k = 1, 2, ..., které jsou hodnotami náhodné prom¥nné X . Pravd¥podobnosti v bod¥ k (1.6) pk = P [X = x] a rozd¥lení takovéto náhodné veli£iny se nazývá diskrétní rozd¥lení a platí: F (x) = X (1.7) pi , xi <x p°i£emº X (1.8) pk = 1. k Pro spojité náhodné prom¥nné existuje nezáporná funkce f , kterou nazýváme a platí: rozd¥lení Z hustota ∞ F (x) = P (X < x) = f (x) dx. (1.9) −∞ 3 1 ÚVOD DO TEORIE HROMADNÉ OBSLUHY P°íklad funkce náhodné prom¥nné a její hustoty. Náhodná prom¥nná X s distribu£ní funkcí F je spojitá: x≤0 0, x , 0<x<2 F (x) = 2 1, x≥2 (1.10) P°edpokládanou hustotu najdeme derivací F (x). x≤0 0, 1 , 0 < x<2 f (x) = 2 1, x≥2 (1.11) Gracká interpretace hustoty distribu£ní funkce náhodné prom¥nné je na 1.2. Obrázek 1.2: Hustota funkce náhodné prom¥nné 1.4 Charakteristiky náhodných veli£in Mezi charakteristiky náhodných veli£in pat°í momenty. Momentem prvního °ádu je st°ední hodnota, coº je £íslo, kolem kterého jsou rozloºeny hodnoty náhodné prom¥nné. St°ední hodnota. St°ední hodnota je pro spojitou náhodnou veli£inu ur£ená vztahem: Z ∞ xF (x) dx, E(X) = µ = (1.12) −∞ a pro diskrétní vztahem: E(X) = µ = N X xi p i (1.13) i=1 Rozptyl. Centrální moment druhého °ádu náhodné veli£iny se nazývá rozptylem (disperze) a charakterizuje kolísání náhodné prom¥nné kolem st°ední hodnoty. Rozptyl je ur£en vztahem: D(X) = E[(X − E(X))2 ]. 4 (1.14) NGN PRO VUT A VB-TUO Sm¥rodatná odchylka. Sm¥rodatná odchylka je druhou mocninou rozptylu a je rovn¥º £asto pouºívanou charakteristikou náhodné prom¥nné, ozna£ujeme ji následovn¥: σ= p D(x). (1.15) Pro diskrétní náhodnou prom¥nnou platí: D(X) = X pk (xk − E(X))2 (1.16) k a pro spojitou náhodnou prom¥nnou platí: Z ∞ (x − E(X))2 f (x) dx. D(X) = (1.17) −∞ Pro výpo£et disperze £asto pouºíváme vztah: D(X) = E(X 2 ) − (E(X))2 . (1.18) Je moºné dokázat, ºe platí: E(a + bX) = a + bE(X) eby²evova nerovnost. D(a + bX) = b2 D(X) (1.19) P°esnost odhadu st°ední hodnoty po£ítáme pomocí eby²evovy nerovnosti: P (|X − E(X)| ≥ ε ≥ D(X) ε2 . (1.20) P°íklady charakteristik Gaussova a Poissonova rozd¥lení. Dv¥ velmi £asto vyuºívané funkce rozd¥lení jsou normální (Gaussovské) a Poissonovo rozd¥lení. Náhodná veli£ina normálního rozd¥lení je spojitá a normální rozd¥lení je matematicky vyjád°eno následovn¥: −(X−µ)2 1 f (X) = − √ e 2σ2 σ 2π (1.21) kde µ je st°ední hodnotou a σ sm¥rodatnou odchylkou náhodné veli£iny X . Ze vztahu je z°ejmé, ºe kdyº náhodná veli£ina má normální rozd¥lení, lze ji zcela charakterizovat pomocí dvou parametr·: st°ední hodnoty a sm¥rodatné odchylky. Náhodná veli£ina Poissonova rozd¥lení je naopak diskrétní. Pr·b¥h Poissonova rozd¥lení lze vyjád°it vztahem: f (X) = ∞ X pk δ(X − k) (1.22) k=0 5 1 ÚVOD DO TEORIE HROMADNÉ OBSLUHY Obrázek 1.3: Gaussova k°ivka - pr·b¥h hustoty normálního rozd¥lení kde pro pravd¥podobnost pk platí: pk = P (X = k) = λk −λ e . k! (1.23) Pro st°ední hodnotu a rozptyl budou platit následující vztahy: E(X) = λ a σ 2 = E(X 2 ) − µ2 = λ (1.24) Jak je vid¥t náhodnou veli£inu s Poissonovským rozd¥lením lze popsat pomocí jediného parametru λ. Existuje °ada situací, kdy náhodná veli£ina je závislá na £ase. Nap°íklad p°i sledování intenzity provozu v lokální síti bude po£et p°enesených paket· za sekundu zna£n¥ odli²ný v pracovní dob¥ a mimo tuto dobu, tj. náhodná veli£ina vyjad°ující £etnost paket· za sekundu bude závislá na £ase, kdy daný pokus, tj. po£ítání paket·, bude proveden. asov¥ závislá náhodná veli£ina je ozna£ena pojmem stochastický proces X(t). V p°ípad¥ stochastického procesu také budou distribu£ní funkce a funkce rozd¥lení £asov¥ závislé. Tyto funkce pak umoº¬ují odvodit momenty, jako st°ední hodnota, rozptyl, atd. Zp¥tné odvození v²ak nemusí být v kaºdém p°ípad¥ realizovatelné. V p°ípad¥ stochastického procesu je to obdobné. Stochastický proces X (t) je mnoºina náhodných veli£in v £ase. Pro názornost m·ºeme denovat n libovolných £asových okamºik· t1 , t2 , ...tn . Pro tyto £asové okamºiky pak dostaneme n náhodných veli£in X(t1 ), X(t2 ), ..., X(tn ) . 1.4.1 Stacionarita D·leºitou vlastností stochastických proces· je jejich stacionarita. Prakticky, kdyº stochastický proces není stacionární, není moºné ho analyzovat £i simulovat. V n¥kterých p°ípadech v²ak nestacionární proces je moºné rozd¥lit na n¥kolik díl£ích proces· denovaných pro krat²í £asové úseky a tyto díl£í procesy uº jsou bu¤ stacionární, nebo kvazistacionární. Následn¥ pak analýzu nestacionárního procesu lze p°evést na analýzu stacionárních díl£ích proces·. Jsou denovány dva typy stacionarity: stacionarita v uº²ím smyslu (striktní stacionarita) a stacionarita v ²ir²ím smyslu. Stochastický proces je stacionární v uº²ím smyslu, kdyº jeho statistický popis se nem¥ní posunem po£átku v £asové ose. M·ºeme vzít n £asových okamºik· a následn¥ denovat n náhodných veli£in X(t1 ), X(t2 ), ..., X(tn ) . 6 NGN PRO VUT A VB-TUO P°esun po£átku sou°adnice o α lze vyjád°it jako X(t1 − α), X(t2 − α), ..., X(tn − α) . Aby podmínka pro striktní stacionaritu byla spln¥na, tak musí platit: f (X1 , X2 , ..., Xn ; t1 , t2 , ..., tn ) = f (X1 , X2 , ..., Xn ; t1 − α, t2 − α), ..., tn − α) (1.25) V p°ípad¥, ºe spojitá náhodná veli£ina bude striktn¥ stacionární, bude platit, ºe f (X; t) = f (X; t − α) a to pro libovolnou hodnotu α, coº znamená, ºe funkce rozd¥lení nebude závislá na £ase, tj. budou konstantní f (X; t) = f (X). Z toho vyplývá, ºe st°ední hodnota i rozptyl budou konstantní, tj. µ(t) = µ a σ 2 (t) = σ 2 . Funkci rozd¥lení druhého °ádu lze psát jako f (X1 , X; t1 , t2 ) . V p°ípad¥ striktn¥ stacionárního stochastického procesu musí platit vztah, ºe f (X1 , X; t1 , t2 = f (X1 , X; t1 − α, t2 − α). V p°ípad¥, ºe t2 − t1 = τ lze odvodit, ºe f (X1 , X; t1 , t2 = f (X1 , X; t1 − α, t2 + t1 − t1 − α) = f (X1 , X; t1 − α, t1 + (t2 − t1 ) − α) = f (X1 , X; t1 − α, t1 − α + τ ) = f (X1 , X; τ ). Znamená to, ºe funkce rozd¥lení druhého °ádu nebude závislá na mí°e posunu α , ale pouze na vzájemné vzdálenosti dvou náhodných veli£in τ . Dokud se vzdálenost τ nem¥ní, tak velikost posunu nemá vliv na funkci rozd¥lení druhého °ádu. 1.4.2 Stacionarita v ²ir²ím smyslu Stochastický proces je stacionární v ²ir²ím smyslu, kdyº jeho st°ední hodnota je konstantní, tj. nezávislá na £ase a funkce autokorelace je pouze funkcí vzdáleností t2 − t1 = τ , tj. RXX (t1 , t2 ) = E{X(t1 )X ∗ (t2 )} = RXX (t1 − t2 ) = RXX (τ ) (1.26) kde X ∗ (t) je komplexní dopln¥k k funkci X(t) [10]. 1.4.3 Ergodicita vstupního toku Problém ergodicity je pom¥rn¥ rozsáhlý a v tomto textu bude popsán pouze v souvislosti s pr·m¥rem. Ergodický systém je statisticky stálý. Z hlediska pr·m¥r· je náhodný proces ergodický, kdyº se jeho £asový pr·m¥r rovná jeho souborovému pr·m¥ru. P°íkladem m·ºe být analýza zatíºení server· v dané organizaci. Pro stanovení souborového pr·m¥ru se po£ítá po£et p°icházejících poºadavk· na v²echny servery za pom¥rn¥ krátký £asový interval, nap°. b¥hem hlavní provozní hodiny. Kdyº takto získaná pr·m¥rná hodnota se shoduje s pr·m¥rnou hodnotou p°íchod· u konkrétn¥ vybraného serveru za del²í £asový interval, nap°. 24 hodin, tak p°íchody budou ergodické. Ergodicita v²ak existuje pouze u stacionárních proces·. Kdyº proces není stacionární, pak nelze o£ekávat, ºe hodnota vypo£ítaná krátkodobým a dlouhodobým zpr·m¥rováním bude stejná. Proto, aby byla p°i výpo£tech spojených s dimenzováním kapacity server· (p·vodn¥ telefonních úst°eden) zaji²t¥na stacionarita, byl výpo£et proveden pro hodnoty nam¥°ené b¥hem hlavní provozní hodiny. Shrneme si uvád¥né kritéria stacionarity a ergodicity náhodných proces·: Stacionarita v uº²ím smyslu distribu£ní funkce se nem¥ní p°i zm¥n¥ po£átku, od n¥hoº po£ítáme £as. Stacionarita v ²ir²ím smyslu st°ední hodnota je konstanta a autokorela£ní funkce závisí jen na £asovém posunutí τ . Ergodicita náhodného procesu st°ední hodnota p°es soubor realizací je rovna £asové st°ední hodnot¥. 7 2 PEHLED NEJAST JÍCH ROZD LENÍ 2 P°ehled nej£ast¥j²ích rozd¥lení Nejprve si uvedeme nej£ast¥ji pouºívaná rozd¥lení diskrétní: Binomické rozd¥lení, Poissonovo rozd¥lení, Rovnom¥rné diskrétní rozd¥lení, Geometrcké rozd¥lení, Bernoulliho rozd¥lení. Poté si uvedeme rozd¥lení spojitá: Normální (Gaussovo) rozd¥lení, Exponenciální rozd¥lení, Erlangovo rozd¥lení, Rovnom¥rné rozd¥lení, Gamma rozd¥lení. Rozd¥lení se denuje funkcí, která ur£uje pravd¥podobnost s jakou náhodná prom¥nná nabývá hodnoty k = 0, 1, ..., n. 2.1 Binomické rozd¥lení Binomické rozd¥lení popisuje £etnost výskytu náhodného jevu v n nezávislých pokusech, v nichº má jev stále stejnou pravd¥podobnost. Pokud speciáln¥ n = 1, jde o alternativní rozd¥lení. n k n−k pk = P [X = k] = p q k (2.1) kde q = 1 − p a p ∈ (0, 1). St°ední hodnota je vyjád°ena jako: E(X) = n n−1 X X n − 1 n k n−k k p q = np pr q (n−1)−r = np. k r (2.2) r=0 k=0 A disperze jako: D(X) = n X k=0 n k n−k (k − np) p q = npq. k 2 ísla n a p nazýváme parametry binomického rozd¥lení. 8 (2.3) NGN PRO VUT A VB-TUO 2.2 Poissonovo rozd¥lení Poissonovo rozd¥lení pravd¥podobnosti pat°í mezi diskrétní rozd¥lení, má jeden parametr λ > 0 (vyjad°uje po£et výskyt· události za jednotku £asu). Poissonovo rozd¥lení pravd¥podobnosti má náhodná veli£ina, která vyjad°uje po£et výskyt· málo pravd¥podobných, °ídkých jev· v ur£itém £asovém, resp. objemovém intervalu. Poissonovo rozd¥lení se pouºívá k aproximaci binomického rozd¥lení pro velký po£et pokus·, tzn. n → ∞ a malou pravd¥podobnost výskytu sledovaného jevu v jednom pokusu, tzn. p → 0. Obvykle m·ºeme binomické rozd¥lení 1 aproximovat Poissonovým tehdy, pokud n > 30 a p ≤ 10 . V takovém p°ípad¥ je λ = np. Pro toto rozd¥lení platí: pk = P [X = k] = λk −λ e . k! (2.4) Pro st°ední hodnotu platí: E(X) = ∞ ∞ X X λ λk−1 −λ k e−λ = λ e = λe−λ eλ = λ. k! (k − 1)! k=0 (2.5) k=1 A pro rozptyl platí. D(X) = E(X 2 ) − [E(X)]2 = λ2 + λ − λ2 = λ (2.6) Parametrem Poissonova rozd¥lení je λ. Toto £íslo je st°ední hodnotou a zárove¬ i disperzí náhodné prom¥nné s Poissonovým rozd¥lením. 2.3 Geometrické rozd¥lení Náhodná veli£ina X má geometrické rozd¥lení, jestliºe nabývá hodnot z mnoºiny 1, 2, 3, ... s pravd¥podobnostmi: pk = P [X = k] = (1 − p)pk (2.7) kde 0 < p < 1. St°ední hodnota je vyjád°ena jako: E(X) = ∞ X kpk = p(1 − p) k=1 ∞ X kp(k−1) = p(1 − p) k=1 ∞ X k=1 pk = p 1−p (2.8) Rozptyl je vyjád°en jako: D(X) = ∞ X k=1 k 2 pk − ( p 2 p ) = 1−p (1 − p)2 (2.9) 9 2 PEHLED NEJAST JÍCH ROZD LENÍ 2.4 Rovnom¥rné diskrétní rozd¥lení Náhodná veli£ina X má diskrétní rozd¥lení, jestliºe nabývá hodnot z mnoºiny 1, 2, 3, ..., m s pravd¥podobnostmi: pk = P [X = k] = 1 m (2.10) St°ední hodnota je vyjád°ena jako: E(X) = ∞ X k=1 k 1 m+1 = m 2 (2.11) Rozptyl je vyjád°en jako: D(X) = (m2 − 1) (m + 1)(2m + 1) (m + 1)2 − = 6 4 12 (2.12) 2.5 Bernoulliho rozd¥lení Pokud ozna£íme úsp¥²nost pokus X = 1 a neúsp¥²nost X = 0 , potom p0 = P [X = 0] = 1 − p p1 = P [X = 1] = p (2.13) kde p, 0 ≤ p ≤ 1 , je pravd¥podobnost, ºe pokus je úsp¥²ný. Pokud ozna£íme po£et pokus· n , potom X = X1 + XX2 + ... + Xn ,, kde Xi = 1 (anebo Xi = 0), pokud je i-tý pokus úsp¥²ný (anebo neúsp¥²ný). Potom: E(X) = E(X1 ) + E(X2 ) + ... + E(Xn ) = np. (2.14) Rozptyl je vyjád°en jako: D(X) = (m + 1)(2m + 1) (m + 1)2 (m2 − 1) − = 6 4 12 (2.15) Spojité rozd¥lení je ur£eno svou funkcí hustoty rozd¥lení pravd¥pobnosti f (x). 2.6 Normální (Gaussovo) rozd¥lení Náhodná veli£ina X má rozd¥lení normální, jestliºe má hustotu: −(X−µ)2 1 f (X) = √ e 2σ2 σ 2π − ∞ < x < ∞, kde µ ∈ (−∞, ∞) a σ > 0 jsou parametry normálního rozd¥lení. 10 (2.16) NGN PRO VUT A VB-TUO St°ední hodnota normálního rozd¥lení je: (2.17) E(X) = µ. Rozptyl je vyjád°en jako: 1 D(X) = √ σ 2π Z ∞ (x − µ)2 e −(x−µ)2 2σ 2 dx = σ 2 . (2.18) −∞ Parametr normálního rozd¥lení µ se tedy rovná st°ední hodnot¥ náhodné prom¥nné a parametr σ její sm¥rodatné odchylce. 2.7 Exponenciální rozd¥lení Náhodná veli£ina X má rozd¥lení exponenciální, jestliºe má hustotu: f (x) = λe−λ , x > 0 0, x ≤ 0 (2.19) St°ední hodnota: ∞ Z E(X) = λ 1 . λ (2.20) 1 −λx 1 e dx = 2 . λ λ (2.21) xe−λx dx = 0 Pro disperzi platí: Z ∞ (x − D(X) = λ 0 Tato st°ední hodnota je p°evrácenou hodnotou parametru λ. Disperze je druhou mocninou její p°evrácené hodnoty. 2.8 Erlangovo rozd¥lení Náhodná veli£ina X má rozd¥lení Erlangovo, jestliºe pro hustotu platí: ( f (x) = λe −λx (λx)k−1 (k−1)! , x>0 0, x ≤ 0 (2.22) Pro st°ední hodnotu platí: E(X) = k . λ (2.23) Pro disperzi platí: D(X) = k . λ2 (2.24) Speciálním p°ípadem Erlangova rozd¥lení pro k = 1je rozd¥lení exponenciální. 11 2 PEHLED NEJAST JÍCH ROZD LENÍ 2.9 Rovnom¥rné rozd¥lení Náhodná veli£ina X má rozd¥lení rovnom¥rné na intervalu (a, b), jestliºe pro hustotu platí: f (x) = 1 b−a , a<x<b 0, x (2.25) Pro st°ední hodnotu platí: E(X) = a+b . 2 (2.26) Pro disperzi platí: (b − a)2 . 12 D(X) = (2.27) 2.10 Gamma rozd¥lení Náhodná veli£ina X má rozd¥lení Gamma, jestliºe pro hustotu platí: ( f (x) = λe−λx (λx)(α−1) , Γ(α) x≥0 0, x < 0, α > 0, λ > 0 (2.28) Pro st°ední hodnotu platí: Z Γ(α) = ∞ e−x xα−1 dx. 0 Pro α = n se dá indukcí odvodit, ºe Γ(n) = (n − 1)! 12 (2.29) NGN PRO VUT A VB-TUO 3 Markovovské °et¥zce, procesy a °e²ení vybraných úloh SHO Markovovské °et¥zce jsou nejjednodu²²ím p°ípadem tzv. stochastických proces·. Markovovské °et¥zce s diskrétním £asem se ozna£ují jako DTMC Discrete Time Markov Chain a se spojitým £asem jako CTMC Continuous Time. V oblasti °e£ových signál· se velmi £asto potkáváme se skrytými Markovovskými modely HMM - Hidden Markov Model. 3.1 Diskrétní Markovovy °et¥zce P°edstavme si stopa°e, který stopuje z m¥sta do m¥sta. Nech´ Xn p°edstavuje m¥sto, ve kterém se nachází po n dnech. Ozna£me nav²tívená m¥sta písmenem i. Jde o náhodný proces, ve kterém dop°edu nevíme, kam se stopa° dostane, protoºe jde o proces, který závisí jen od toho, ve kterém m¥st¥ práv¥ stopa° stopuje, protoºe to, kam se dostane, je náhodné. Takové procesy m·ºeme popsat markovovským °et¥zcem. Pro náhodné prom¥nné X1 , X2 , ... z Markovovského °et¥zce a pro v²echny i1 < i2 ... < in platí: P [Xn = i1 , X2 = i2 , ..., Xn−1 ] = in−1 ] = P [Xn = j/Xn−1 = in−1 ] (3.1) Markovovy °et¥zce pat°í do skupiny náhodných proces· a jsou charakterizovány jako bezpap°i p°echodu mezi stavy, tzn. ºe pravd¥podobnostní rozd¥lení stavu po dal²ím p°echodu závisí pouze od sou£asného stavu a ne od posloupnosti stav·, které vedli do stavu sou£asného. m¥´ové Denice. Stochastický proces Xt : t ∈ T p°edstavuje Markovovský proces, pokud pro v²echny stavy si ∈ S a 0 = t0 < t1 < ... < tn < tn+1 , Xtn+1 závisí pouze od p°ede²lé hodnoty Xtn a nikoliv od p°ede²lých hodnot Xt0 , Xt1 , ..., Xtn−1 : P (Xtn+1 ≤ sn+1 |Xtn = sn , Xtn−1 ≤ sn−1 , ..., Xt0 = s0 ) = P (Xtn+1 ≤ sn+1 |Xtn = sn ) (3.2) Obecn¥ pravd¥podobnost p°echodu z jednoho stavu do druhého se m·ºe m¥nit s £asem, ale pro homogenní Markovovský °et¥zec není £asová závislost a pravd¥podobnost p°echodu je pouze funkcí stavu. V tom p°ípad¥ ozna£ujeme pravd¥podobnost p°echodu ze stavu i do stavu j jako pij = P (SN +1 = j/SN = i) , tzn. pravd¥podobnost, ºe budeme ve stavu j závislí na pravd¥podobnosti, ºe jsme byli ve stavu j . Vhodnou reprezentací pro stavy v homogenním Markovovském °et¥zci je p°echodový pravd¥podobnostní stavový diagram. Moºné stavy v °et¥zci jsou p°ímo spojeny a p°edstavují pravd¥podobnost p°echodu z jednoho stavu do druhého 3.1. Jedná se o ohodnocený orientovaný graf, kde: vrcholy jsou stavy, hrany odpovídají nenulovým intenzitám p°echodu, a ohodnocení hran je rovno t¥mto intenzitám. 13 3 MARKOVOVSKÉ ET ZCE, PROCESY A EENÍ VYBRANÝCH ÚLOH SHO Obrázek 3.1: P°echodový stavový diagram: Bernoulliho pokusy 3.2 P°echodová matice Pokud je kone£ný po£et stav·, tak p°echody mezi stavy mohou býti reprezentovány matici p°echod· mezi stavy. Její prvky p°edstavují pravd¥podobnosti p°echod· pij : p11 p12 p21 p22 P = ... ... pM 1 pM 2 ... p1M ... p2M ... ... ... pM M (3.3) Sou£et pravd¥podobností v jednotlivých °ádcích matice P je roven jedné, jde o náhodnou (stochastickou) matici. P = M X pij = 1 i = 1, 2, ..., M. (3.4) j=1 Nech´ πji : i = 0, 1, 2, ..., j = 1, 2, ..., M je pravd¥podobnost, ºe Markovovský °et¥zec je ve i ,) stavu j po i−tm kroku (p°echodu). Denujeme vektor pravd¥podobností π i = (π1i , π2i , ..., πM reprezentující pravd¥podobný stav, do kterého se dostaneme po i krocích. Platí tedy: π n+1 = π n P k , (3.5) kde mocnina k p°edstavuje k − tou mocninu matice p°echod· P . P°íklad s absorp£ním stavem. Uvaºujme o Markovovském °et¥zci, který je zobrazen schématem p°echod· mezi stavy 3.2 P°echodová matice je: 1/6 1/2 0 1/3 1/4 0 1/2 1/4 P = 0 0 1 0 0 1/4 3/4 0 (3.6) P°edpokládejme, ºe systém je ve stavu 1 s pravd¥podobností 1 a m¥jme na pam¥ti, ºe sou£et pravd¥podobností v kaºdém °ádku je roven jedné. V 0-tém kroku (systém je na po£átku) vypadá vektor pravd¥podobností následovn¥: π 0 = (π11 , π21 , π31 , π41 ) = (1, 0, 0, 0). 14 (3.7) NGN PRO VUT A VB-TUO Obrázek 3.2: P°echodový stavový diagram s absorp£ním stavem A to znamená, ºe startujeme ze stavu 1. Po první iterakci (prvním kroku) vypadá vektor pravd¥podobností následovn¥: π 1 = (π11 , π21 , π31 , π41 ) = (1/6, 1/2, 0, 1/3). (3.8) Po druhém kroku, který spo£teme jako π 2 = π 1 P je vektor pravd¥podobností (0.152778, 0.166667, 0.5, 0.180556). Po t°etím kroku, který spo£teme jako π 3 = π 2 P je vektor pravd¥podobností (0.06713 0.121528, 0.71875, 0.092593). Pravd¥podobnost se na kumuluje ve stavu 3 a z obrázku 3.2 je vid¥t, ºe ze stavu 3 není ºádná pravd¥podobnost p°echodu do jiného stavu, jde tedy o absorp£ní stav. Proces se tímto ukon£í ve stavu 3, a platí π ∞ = (0010). Následující tabulka ukazuje postupné interakce: Krok Stav 1 Stav 2 Stav 3 Stav 4 0 1 2 3 4 5 6 7 8 0 0.5 0.166667 0.121528 0.056713 0.033975 0.017562 0.009888 0.005295 0 0 0.5 0.71875 0.848958 0.916884 0.954897 0.975325 0.986565 0 0.333333 0.180556 0.092593 0.052758 0.028035 0.015529 0.008394 0.004603 1 0.166667 0.152778 0.06713 0.04157 0.021107 0.012011 0.006392 0.003537 P°íklad bez absorp£ního stavu. Uvaºujme o Markovovském °et¥zci, který je zobrazen schématem p°echod· mezi stavy 3.3 P°echodová matice je: 1/6 1/2 0 1/3 1/4 0 1/2 1/4 P = 1 0 0 0 0 1/4 3/4 0 (3.9) Máme zjistit, do kterého stavu bychom se dostali po sedmém kroku. Následující tabulka ukazuje postupné iterakce do sedmého kroku. 15 3 MARKOVOVSKÉ ET ZCE, PROCESY A EENÍ VYBRANÝCH ÚLOH SHO Obrázek 3.3: P°echodový stavový diagram bez absorp£ního stavu. Krok Stav 1 Stav 2 Stav 3 Stav 4 0 1 2 3 4 5 6 7 0 0.5 0.166667 0.121528 0.306713 0.226683 0.179888 0.245493 00 0 0.5 0.21875 0.130208 0.317925 0.256764 0.198488 0.333333 0.180556 0.092593 0.219425 0.191229 0.144725 0.184513 1 0.166667 0.152778 0.56713 0.343654 0.264162 0.418623 0.371506 Jak jsme vid¥li v p°ede²lém p°íkladu, tak systém m·ºe konvergovat do ustáleného stavu. Mnoºina stav· C se nazývá jako uzav°ená, pokud ºádný stav mimo mnoºinu C nelze dosáhnout ze stavu z mnoºiny C. Absorp£ní stav je uzav°ená mnoºina pouze s jedním £lenem. Markovovský °et¥zec se nazývá ireducibilní (nerozloºitelný, pokud neexistují uzav°ené mnoºiny jiné neº mnoºina v²ech stav·. V²eobecné Markovovské °et¥zce mohou být rozloºené do jednoho anebo vícero °et¥zc·. Pokud existuje absorp£ní stav, pak °et¥zec není ireducibilní. Markovovský °et¥zec dosáhl ustáleného stavu, pokud se pravd¥podobnostní rozd¥lení stav· nem¥ní z kroku na krok. Proto rozd¥lení ustáleného stavu je závislé na po£áte£ních podmínkách. Nech´ rozd¥lení ustáleného stavu je π = (π1 , π2 , ..., πM ), pro ustálenost platí: π = πP 3.3 Markovovské procesy Markovovský proces byl denován jako proces, který má p°echody mezi stavy v bodech, které jsou vzdáleny konstantních T sekund. Semi-markovovský proces je zev²eobecn¥ním, ve kterém interval mezi t¥mito p°echody je náhodná prom¥nná. Pokud má interval mezi p°echody exponenciální rozd¥lení, tak semi-markovovský proces se stává Markovovským procesem. Pojem Markov je synonymem s pojmem bez-pam¥´ový. St°ední hodnota intervalu m·ºe záleºet na aktuálním stavu £i stupni, ale budoucí vývoj procesu závisí pouze od aktuálního stavu anebo stupn¥. Zvlá²tní t°ídou Markovovského procesu je proces vzniku a zániku birth and death process, kde stav je po£et £len· v populaci a stav se zm¥ní v £ase. Vloºený markovovský °et¥zec je d·leºitým prost°edkem analýzy systém· hromadné obsluhy - queuing system. 16 NGN PRO VUT A VB-TUO 3.4 Procesu vzniku a zániku v systémech hromadné obsluhy Budeme pouºívat ozna£ení A/R/S, kde A p°edstavuje proces p°íchod·, R proces obsluhy a S p°edstavuje po£et obsluºných míst. Nap°. M/M/1 ozna£uje Poissonovský p°íchod poºadavk·, exponenciální rozd¥lení obsluhy a jeden server. M p°edstavuje bez-pam¥´ovost (markovovskou) pro proces p°íchod· a rovn¥º pro dobu obsluhy. V modelu M/G/1 p°edstavuje G dobu obsluhy se v²eobecným rozd¥lením. Zna£ení M/M/S/N p°edstavuje systém, kde je Poissonovský p°íchod, exponenciální obsluha, S obsluºných míst (server·) a místo pro N poºadavk· v£etn¥ práv¥ obsluhovaných. Zajímavý je p°edev²ím p°ípad, kdy S = N , coº je my²lenkou ErlangB rovnice. Na popis procesu p°íchod· v systémech hromadné obsluhy existují dva postupy: Pravd¥podobnostní rozd¥lení pro po£et p°íchod· v £asovém intervalu, Pravd¥podobnostní rozd¥lení pro interval mezi p°íchody. V souvislosti se systémy hromadné obsluhy, Poissonovský proces m·ºe býti popsán jako mající p°íchody s Poissonovským rozd¥lením v intervalu anebo jehoº £asy mezi p°íchody mají exponenciální rozd¥lení. Budeme uvaºovat jednoduché p°ípady, kde proces p°íchodu je Poissonovský s konstantní rychlostí. Ale existují daleko sloºit¥j²í modely, které je moºné pouºít na modelování. tekutý model - uid ow model, ve kterém data p°icházejí konstantní rychlostí po dobu daného £asového intervalu. Tato rychlost m·ºe kolísat podle základního Markovovského °et¥zce. Jednou z vlastností tekutého modelu je, ºe zachytává kontinuální tok informací na p°enosových linkách realisti£t¥j²ím zp·sobem, neº je to v Poissonovském modelu. Moºný problém Poissonovského modelu je, ºe zprávy p°icházejí okamºit¥. Dal²ím £asto pouºívaným modelem zdroje provozu je Markovovsky modulovaný Poisso- novský proces MMPP - Markov Modulated Poisson process, ve kterém základní Marko- vovský °et¥zec °ídí pr·m¥rnou rychlost p°íchod·. V telekomunika£ních systémech existují dv¥ základní rozdílné formy interpretace doby obsluhy. V tradi£ních sítích s p°epojováním okruh·, doba obsluhy p°edstavuje £as trvání hovoru. Stejná my²lenka m·ºe být pouºita i v po£íta£ových sítích, kde jsou zdroje sít¥ pouºity uºivatelem výhradn¥ po ur£itou dobu. V paketov¥ orientovaných sítích, prezentuje doba obsluhy £as pot°ebný na p°enos informace. Poslední komponenta systému hromadné obsluhy se týká po£tu obsluºných míst a s tím souvisí po°adí obsluhy, t.j. disciplína obsluhy. Tato disciplína m·ºe být nap°. FIFO (první p°ijde první je obslouºen), LIFO (poslední p°ijde první je obslouºen), anebo v náhodném po°adí (random). 3.5 Littleho vztah V systémech hromadné obsluhy má velké uplatn¥ní Littleho vztah 3.4, ktorý hovo°í o pr·m¥rném po£tu poºadavk· v systému. N = λD (3.10) 17 3 MARKOVOVSKÉ ET ZCE, PROCESY A EENÍ VYBRANÝCH ÚLOH SHO N je pr·m¥rný po£et zpráv v systému, D je pr·m¥rné zpoºd¥ní a λ je pr·m¥rná rychlost p°íchodu 3.4. Obrázek 3.4: Gracká reprezentace Littleho vztahu. Uvaºujeme tedy o systému, ve kterém jsou poºadavky obsluhované dle po°adí p°íchodu. P°edpokládejme, ºe odchozí zpráva strávila v systému p°im¥°ený £as D v sekundách. Nový poºadavek p°ichází pr·m¥rnou rychlostí λ zpráv za sekundu, a tedy v systému z·stává v pr·m¥ru N zpráv. V anglosaské literatu°e jsou parametry Littleho vztahu prezentovány následovn¥: N - Average number in system, D - Average delay, λ - Average arrival rate. P°íklad. Do SHO p°ichází 3 typy zpráv. P°edpokládejme, ºe zát¥º je taková, ºe v SHO nejsou dostupné pot°ebné £ekací °ady. Charakteristika p°íchodu poºadavk· je následující: T°ída 1: zprávy p°icházejí pr·m¥rnou rychlostí 120 za minutu a zpráva opustí systém po 200 ms. T°ída 2: zprávy p°icházejí pr·m¥rnou rychlostí 20 za minutu a systém zpracuje 6 zpráv za minutu. T°ída 3: zprávy p°icházejí pr·m¥rnou rychlostí 10 za minutu a kaºdá zpráva pot°ebuje 30 sekund na zpracování. Pr·m¥rná doba obsluhy pro kaºdou t°ídu v sekundách je: 0.2 s, 10 s, 30 s. Jelikoº zde není pam¥´ a server je trvale dostupný, tak vý²e uvedené hodnoty povaºujeme za pr·m¥rné hodnoty zpoºd¥ní kaºdé t°ídy v systému. Pouºitím Littleho vztahu pro kaºdou t°ídu zvlá²´, platí: N 1 = 0.2(120/60) = 0.4 N 2 = 10(20/60) = 3.33 N 3 = 30(10/60) = 5 N = N 1 + N 2 + N 3 = 8.73 18 NGN PRO VUT A VB-TUO 3.6 Poissonovský proces M¥°ení provozu v v hlasových a datových systémech ukázala, ºe v mnohých aplikacích generování volání a zpráv je moºné modelovat jako Poissonovský proces. Slu£ováním a d¥lením proces· dostáváme Poisson·v proces. Poissonovský proces p°íchod· je speciální p°ípad procesu vzniku. M·ºeme tedy uvaºovat o procesu vzniku a zániku, který modeluje ur£ité systémy hromadné obsluhy, ve kterých p°íchody poºadavk· mají exponenciální rozd¥lení poºadavk· na obsluhu a p°icházejí Poissonovskou rychlostí. Obrázek 3.5: Poissonovo a exponenciální rozd¥lení p°íchod·. Poissonovský proces je moºné odvodit jako limitní p°ípad Bernoulliho rovnice a tedy i vlastnosti Poissonova procesu je moºné odvodit z Bernoulliho rovnice. memoryless uniformita - první vlastnost je bezpam¥´ovost. znamená, ºe daný po£et p°íchod· v intervalu je rovnom¥rn¥ rozloºených v intervalu. pokud se díváme na proces z jednoho £i z druhého sm¥ru (dop°edu £i zp¥t), vidíme stejný model s identickými pravd¥podobnostmi. reverzibilita Vztah mezi Poissonovským a exponenciálním rozd¥lením je zobrazen v 3.5. Poissonovo rozd¥lení je diskrétní náhodná prom¥nná (t.j. po£et p°íchod· v £asovém intervale), zatímco exponenciáln¥ rozd¥lená náhodná prom¥nná je spojitá náhodná prom¥nná (t.j. interval mezi p°íchody). Exponenciální rozd¥lení má rovn¥º vlastnost bezpam¥´ovosti. Pravd¥podobnost p°íchodu v intervalu záleºí jen na trvání intervalu a ne od p°ede²lého p°íchodu. Poissonovský proces je proces, ve kterém £asy mezi p°íchody jsou nezávislé a exponenciáln¥ rozd¥lené. 3.6.1 S£ítání a d¥lení Poissonovských proces· Pokud jsou dva procesy nezávislé a Poissonovské s pr·m¥rnými rychlostmi p°íchod· λ1 a λ2 , potom sou£et proces· je Poissonovský s pr·m¥rnou rychlostí p°íchod· λ1 + λ2 , jak je znázorn¥no v 3.6. V p°ípad¥ rozd¥lení p°edpokládejme následující p°ípad zobrazený v 3.7, kde Poissonovské p°íchody jsou umís´ovány bu¤ do jednoho anebo dvou £ekacích °ad s pravd¥podobnostmi P a 1 − P . Vzniknou tak dva Poissonovské procesy. P°íchod do první £ekací °ady je Poissonovský s pr·m¥rnou rychlostí P λ p°íchod·/sec. a pro druhou £ekací °adu je to op¥t Poissonovské rozd¥lení s pr·m¥rnou rychlostí (1 − P )λ p°íchod·/sec. 19 3 MARKOVOVSKÉ ET ZCE, PROCESY A EENÍ VYBRANÝCH ÚLOH SHO Obrázek 3.6: Sou£et Poissonovských proces·. Obrázek 3.7: D¥lení Poissonovských proces·. 3.7 Aplikace procesu vzniku a zániku v SHO Zobecn¥ný proces vzniku z Poissonovského procesu slouºil jako model procesu p°íchod·. Byl uvaºován jeden p°íchod v intervalu. Ale v modelech systém· hromadné obsluhy jsou pro nás zajímavé nejen p°íchody do systému, ale rovn¥º odchody ze systému, coº m·ºe být roz²í°ením procesu vzniku. Umoºn¥ním nár·stu a poklesu po£tu £len· populace b¥hem jednoho intervalu, dostaneme proces vzniku a zániku 3.8. Obrázek 3.8: P°echodový stavový diagram pro proces vzniku a zániku. Stejn¥ tak jako v p°ípad¥ procesu vzniku, díváme se na zm¥ny v £asovém intervalu (t, t+σ). Op¥t p°edpokládáme, ºe σ je tak malé, ºe se m·ºe vyskytnout nanejvý² jeden p°íchod s pravd¥podobností λn σ , kdyº velikost populace je n. Pravd¥podobnost odchodu ve stejném intervalu je µn σ . Pravd¥podobnost p°íchodu i odchodu v intervalu je σ 2 a proto ji m·ºeme zanedbat. 20 NGN PRO VUT A VB-TUO 4 Vybrané modely systém· hromadné obsluhy Proces vzniku a zániku modeluje situaci, ve které máme Poissonovský p°íchody poºadavk· a nároky na obsluhu s exponenciálním rozd¥lením. Obsluºné místa poskytují kaºdému zákazníkovi takový rozsah obsluhy, jaký poºaduje. Výsledkem dokon£ení obsluhy poºadavku je odchod poºadavku (zákazníka) ze systému. Poºadavky £ekají na obsluhu v £ekací °ad¥. Z pohledu modelu vzniku a zániku, p°íchody a odchody korespondují se vznikem a zánikem. Volbou rozdílných hodnot λj a µj vznikají rozdílné situace. Pokud £as obsluhy p°edstavuje jednodu²e dobu trvání hlasového hovoru, tak potom p°edpoklad exponenciálního rozd¥lení je od·vodn¥nou aproximací reality. Pro dal²í aplikace, kde obsluha p°edstavuje £as pot°ebný na p°enos zprávy, je náro£n¥j²í zd·vodnit p°edpoklad exponenciálního rozd¥lení. Navzdory tomuto faktu °ada studií ukázala, ºe exponenciální rozd¥lení je vhodnou aproximací v mnohých aplikacích. 4.1 Systém M/M/1 s nekone£nou £ekací °adou První model, kterým se budeme zabývat, je M/M/1/∞ s neomezenou £ekací °adou (ozna£ován rovn¥º jako M/M/1). V tomto p°ípad¥ poºadavky p°icházejí Poissonovskou rychlostí λ za sekundu v pr·m¥ru a kaºdý zákazník poºaduje exponenciální rozd¥lení obsluhy s pr·m¥rnou hodnotou 1/µ. P°íchody korespondují se vznikem a odchody se zánikem, proto jsou parametry procesu λn = λ a µn = µ;, tzn. nezávisle na stavu, ve kterém se práv¥ nacházíme. P°echodový stavový diagram je zobrazen v 4.1. Obrázek 4.1: P°echodový stavový diagram pro M/M/1. Pravd¥podobnost, ºe v systému je n zákazník· (obsluhovaných a rovn¥º v £ekací °ad¥) je daná: Pn = (1 − ρ)ρn ; n = 0, 1, ... (4.1) kde ρ = λ/µ. P°edpokládáme, ºe ρ < 1 a pokud by tomu tak nebylo, tak ve jmenovateli pro N je záporné £íslo anebo 0, tzn. ºe pr·m¥rný po£et p°íchod· b¥hem pr·m¥rné doby obsluhy (1/µ) by byl men²í neº 1. Pokud by tomu tak nebylo, tak £ekací °ada by se permanentn¥ plnila (£ekací °ada by byla nestabilní). N je náhodná prom¥nná reprezentující po£et zákazník· v systému a platí: N= ρ 1−ρ (4.2) 21 4 VYBRANÉ MODELY SYSTÉM HROMADNÉ OBSLUHY t.j. st°ední hodnota po£tu poºadavk· v systému a pro rozptyl platí: V ar(N ) = ρ (1 − ρ)2 (4.3) Parametr ρ se nazývá intenzita provozu (vyuºití, zatíºení). Aplikováním Littleho vztahu dostáváme pr·m¥rné zpoºd¥ní v systému M/M/1/∞ jako: 1 D= N 1 µ = = λ 1−ρ µ−λ (4.4) P°i velmi malém zatíºení ρ ∼ = 0 je £as p°enosu zprávy D ∼ = 1/µ. Pokud zatíºení nar·stá ρ → 1, máme D → ∞. Pr·m¥rnou délku £ekací °ady lze vyjád°it následovn¥: Q= ρ2 (1 − ρ) (4.5) V grafu 4.2 je vykreslen pr·m¥rný po£et poºadavk· a pr·m¥rné zpoºd¥ní p°i p°enosu zprávy 1/µ v závislosti na zatíºení systému. Obrázek 4.2: Zatíºení vs. pr·m¥rné zpoºd¥ní a po£et poºadavk· v systému. Nelineární tvary t¥chto k°ivek jsou charakteristické pro výsledky s £ekacími °adami. Pro nízké zatíºení je lineární nár·st zát¥ºe. Za kolenem k°ivky m·ºeme charakterizovat systém jako nestabilní, nebo´ malé zm¥ny v zatíºení p°iná²ejí velké zm¥ny v pr·m¥rném zpoºd¥ní a po£tu poºadavk· v systému. 4.2 Systém M/M/1/L s kone£nou £ekací °adou P°ípad M/M/1/L reprezentuje nejjednodu²²í p°ípad £ekací °ady, ve kterém nejsou rychlosti p°íchod· a odchod· konstantní. Poºadavky p°icházejí rychlostí λ, dokud jich je v systému mén¥ 22 NGN PRO VUT A VB-TUO neº L, tzn. kapacita celého systému - obsluhovaných i £ekajících zárove¬. Pokud se £ekací °ada (fronta) naplní, p°icházející poºadavky budou odmítnuty (v p°ípad¥ telefonie m·ºe být tento provoz sm¥rován alternativními trasami). Vyjád°ení intenzity p°íchod· je následující: λj = λ; j < L 0; j ≥ L (4.6) Protoºe doba obsluhy obsluhovaného poºadavku má exponenciální rozd¥lení, rychlost odchodu z·stává na µn = µ pro v²echny n. P°echodový stavový diagram je zobrazen v obr. 4.3 Obrázek 4.3: P°echodový stavový diagram pro M/M/1/L. Pro po£et poºadavk· v systému platí: ( Pn = (1−ρ)ρn ; 1−ρL+1 n≤L 0; n > L (4.7) Pro P0 platí: P0 = 1−ρ 1 − ρL+1 (4.8) Pravd¥podobnost, ºe zákazník p°ichází do pln¥ obsazeného systému je: PL = (1 − ρ)ρL 1 − ρL+1 (4.9) Pokud si zobrazíme parametry pravd¥podobnosti blokování v grafu 4.4, tak lépe pochopíme chování tohoto SHO. Dle p°edpoklad·, pravd¥podobnost blokování roste s nár·stem zatíºení a klesá s nár·stem kapacity L, p°i£emº L reprezentuje velikost £ekací °ady (fronty). 4.3 Systém M/M/S s nekone£nou £ekací °adou Nyní se budeme zabývat modelem M/M/S s nekone£nou °adou £ekání, ve kterém je S ≥ 1 obsluºných míst. Pokud je po£et poºadavk· men²í neº po£et obsluºných míst, tak v²echny poºadavky budou obslouºeny sou£asn¥. 23 4 VYBRANÉ MODELY SYSTÉM HROMADNÉ OBSLUHY Obrázek 4.4: Závislost pravd¥podobnosti blokování na zatíºení systému typu M/M/1/L. Pokud je po£et poºadavk· v systému M/M/S v¥t²í neº po£et obsluºných míst, tak se vytvá°í °ada £ekání (fronta). Pokud je °ada nekone£ná, tak intenzita (rychlost) p°íchodu poºadavk· (resp. zákazník·) je nezávislá na po£tu poºadavk· v systému λn = λ a platí: µn = nµ; n ≤ S Sµ; n > S (4.10) P°echodový stavový diagram pro tento p°ípad je na obr. 4.5. Obrázek 4.5: P°echodový stavový diagram pro M/M/S. Pro pravd¥podobnost n poºadavk· v systému platí: Pn = Pn ρn /n!; n ≤ S Pn ρn /(S!n−S ); n > S (4.11) a pro P0 , tj. pravd¥podobnost, ºe je systém prázdný, platí: S−1 X P0 = [ n=0 ρn SρS + ]−1 n! S!(S − ρ) (4.12) Aby tento vztah mohl platit, tak: λ ρ = <1 Sµ S 24 (4.13) NGN PRO VUT A VB-TUO Jmenovatel nesmí být tedy záporný anebo roven nule. V principu jde o stejnou podmínku pro stabilitu jako u modelu M/M/1 s nekone£nou £ekací °adou. Ve spojitosti s tímto modelem je zajímavá pravd¥podobnost, ºe p°icházející poºadavek nalezne v²echny obsluºná místa obsazená a musí tedy £ekat v £ekací °ad¥. Pro takovouto pravd¥podobnost platí: Pc (S, ρ) = ∞ X Pn = n=S SρS S!(S−ρ) PS−1 ρn SρS n=0 n! + S!(ρ−S) (4.14) Pokud za P0 dosadíme p°ede²lou rovnici, tak dostaneme: Pc (S, ρ) = ∞ X Pn = P0 n=S SρS S!(S − ρ) (4.15) To je pravd¥podobnost, ºe v²echna obsluºná místa jsou obsazena a nové p°íchozí poºadavky musí £ekat.Tento vztah je Erlang C rovnice, která byla aplikovaná ve spojitosti s hlasovým provozem v telefonní síti. V p°ípad¥, ºe sa jedná o £ekající volání, tak volajícímu se oznámí nap°. V²ichni na²i operáto°i jsou momentáln¥ obsazeni, £ekejte prosím ... V tomto p°ípad¥ £as obsluhy p°edstavuje rovn¥º £as p°idrºení volání, coº se dá modelovat exponenciálním rozd¥lením. Obsluºná místa p°edstavují trunky, které jsou obsazeny po dobu hovoru. Pro M/M/S s °adou £ekání je pr·m¥rný po£et zpráv ve front¥ dán jako: Q= P0 ρS Sρ S! (S − ρ)2 (4.16) Z Littleho vztahu dostaneme pr·m¥rné zpoºd¥ní ve front¥, £ili dobu strávenou v °ad¥ £ekání z pohledu pravd¥podobnosti blokování jako: DQ = Q PC ρ = λ λ(S − ρ) (4.17) Zahrnutím pr·m¥rné doby obsluhy dostaneme pr·m¥rný £as, který poºadavek stráví v systému: D= 1 1 + PC µ S−ρ (4.18) 4.4 Systém M/M/S/L s kone£nou £ekací °adou Dal²í £asto pouºívaný vztah získáme, pokud vezmeme v úvahu model M/M/S s kone£nou £ekací °adou. V p°ípad¥, ºe je fronta plná, není moºné do ní za°adit ºádný dal²í p°íchozí poºadavek, tzn. λn = 0 pro n ≥ L, kde L je celkový po£et poºadavk· v systému. Takovýto systém hromadné obsluhy lze popsat následovn¥: µn = nµ; n ≤ S Sµ; n > S (4.19) 25 4 VYBRANÉ MODELY SYSTÉM HROMADNÉ OBSLUHY λn = λ; n ≤ L 0; n > L (4.20) P°echodový stavový diagram pro p°ípad L = S je zobrazen na obr. 4.6. Obrázek 4.6: P°echodový stavový diagram pro M/M/S/L. Pokud budeme p°edpokládat, ºe L = S , tak v tomto p°ípad¥ budou obsluhovány pouze poºadavky, které jsou v systému. Pro systém M/M/S/S platí: Pn = P0 ρn ; n! P0 = [ n = 1, 2, ..., S X ρn S ]−1 n! (4.21) (4.22) n=0 Pokud p°íchozí poºadavek najde v²echna obsluºná místa obsazená, tak musí opustit systém a chování je stejné jako bez £ekací °ady. Pravd¥podobnost této události p°edstavuje Erlang B vztah, který je dán: PB (S, ρ) = ρS S! PS n=0 ρ (4.23) n /n! Erlangova B rovnice sa pouºívá na dimenzování kanál· v telefonii. Doba trvání volání má exponenciální rozd¥lení a rychlost p°íchod· poºadavk· je Poissonovská. Obsluºná místa v tomto p°ípad¥ jsou kanály. Zajímavou otázkou je volba po£tu kanál· pro p°íslu²nou hodnotu provozu tak, aby p°icházející volání na²ly volný kanál s dostate£n¥ vysokou pravd¥podobností. Pokud jsou v²echny kanály obsazeny, volání je blokováno a opou²tí systém hromadné obsluhy (obsazovací tón). V p°ípad¥, ºe pro model M/M/S budeme uvaºovat nekone£ný po£et obsluºných míst S → ∞, tak p°icházející poºadavek bude vºdy zpracován a platí: nf ty X P0 = [ n=0 Pn = ρn −1 ] = e−ρ n! e−ρ ρn ; n! (4.24) n = 1, 2, ... Samoz°ejm¥, to je Poissonovské rozd¥lení se st°ední hodnotou ρ. 26 (4.25) NGN PRO VUT A VB-TUO 5 GNS3 5.1 Úvod Open-source program GNS3 (Graphical Network Simulator) umoº¬uje emulaci komplexních sí´ových °e²ení. Vyuºívá známou ideu z prost°edk· jako VMWare nebo Virtual PC, které dokáºí emulovat hardware, na kterém následn¥ mohou b¥ºet r·zné opera£ní systémy v tzv. virtuálním prost°edí. Jádrem °e²ení GNS je aplikace Dynamips, která je zodpov¥dná za b¥h r·zných verzí Cisco IOS (Cisco Internetwork Operating System) na emulaci Cisco sm¥rova£· prost°ednictvím b¥ºných PC. Nad tímto jádrem b¥ºí aplikace Dynagen zabezpe£ující vytvo°ení a funk£nost uºivatelsky p°ív¥tiv¥j²í nadstavby nad Dynamipsem. Dynagen umoº¬uje vytvá°et pomocí kongura£ních soubor· sí´ové topologie. GNS3 je grackou nadstavba nad Dynagenem, zast°e²uje celou emulaci a konguraci jednoduchým aplika£ním Drag & Drop grackým rozhraním. Díky tomu se °e²ení dostává komfortem ovládání na úrove¬ komer£ních simulátor· sí´ových topologií (Packet Tracker, Routers, Boson Nets ...). V p°ípad¥ simulátor· je uºivateli p°ístupná pouze jistá mnoºina p°íkaz·, moºností a výpis· reálného Cisco sm¥rova£e na základ¥ konkrétní implementace autora. U GNS3 díky emulaci poskytuje plnou funk£nost Cisco IOS. GNS3 se jeví jako ideální aplikace pro výukový systém. Na vytvá°ení cvi£ných topologií je ale nutno pouºívat reálný systém IOS, které b¥ºí v emulátoru. Velkým kladem je open-source podstata °e²ení, pokra£ující vývoj aplikace GNS3 i aktivní komunita uºivatel· GNS3/Dynagenu/Dynamipsu. Vytvo°ení v¥t²í mnoºiny cvi£ných topologií s r·znými stupni kongurace je £asov¥ náro£ný úkol, ale benety plynoucí z pouºití pln¥ funk£ního emulátoru (v porovnání s r·znými simulátory) to bez problém· vyváºí. Na rozdíl od simulátoru Packet Tracer, který dokáºe za°ízení jen simulovat, GNS3 nabízí mnohem komplexn¥j²í °e²ení a v¥t²í moºnost implementace r·zných reálných za°ízení a emulovat tak reálné chování sí´ových komponent. Ovládání sí´ových prvk· je spolehliv¥j²í díky pouºití reálných IOS. Mezi nezpochybnitelné výhody pat°í nativní implementace virtuálních opera£ních systém· z programu VirtualBox, pomocí kterých je moºné otestovat skute£nou funk£nost v p°ípad¥ pouºívání pokro£ilých kongurací jako nap°. access list. [1, 35] 5.2 Vlastnosti Dostupné pro platformy Windows i Linux podpora emulace serie Cisco 1700 (1710 aº 1760), Cisco 2600 (od 2610 po 2650XM, 2691), Cisco 3600 (3620, 3640 a 3660), Cisco 3700 (3725, 3745), Cisco 7200 a také PIX Firewally podpora pro n¥kolik roz²i°ujících modul· pro Cisco sm¥rova£e (Ethernet a FastEthernet karty, 16 portový M-16ESW Ethernet switch modulu, sériové porty, ATM, POS) moºnost propojení s reálnou sítí nestabilita Dynampisu s n¥kterými IOSmi vysoké hardwarové nároky na CPU a RAM nutnost mít reálný systém IOS v souboru 27 5 GNS3 5.3 Funk£nost GNS3 je primárn¥ ur£en jako nástroj pro p°ípravu k certikát·m Cisco CCNA a Cisco CCNP, tedy jako prost°edek pro emulaci reálných sí´ových zapojení a jejich testování, odlad¥ní apod. Datová propustnost emulovaných sm¥rova£· se pohybuje kolem 1000 paket· za sekundu, zatímco reálné za°ízení dosahují sto aº tisíc krát vy²²í hodnoty. Nijak to v²ak nesniºuje hodnotu °e²ení, protoºe GNS3/Dynamips není ur£en jako skute£ný sm¥rova£. Po instalaci (která není identická na obou podporovaných platformách) je t°eba p°i spu²t¥ní programu poskytnout podporovaný a funk£ní obraz Cisco IOS (není sou£ástí instala£ního balí£ku) a namapovat ho p°es dialog na p°íslu²nou Cisco platformu. Pochopiteln¥, podmínkou pro práci s topologií je t°eba pouºívat jen takové Cisco modely, pro které máme namapované p°íslu²ející Cisco IOS. Pracovní prost°edí GNS3 je p°ehledné a uºivatelsky p°ív¥tivé. Topologie se sestavuje jednoduchým drag & drop systémem a kaºdá pouºitá sí´ová komponenta se dá samostatn¥ kongurovat. V p°ípad¥ sm¥rova£· je k dispozici n¥kolik emulovaných roz²i°ujících modul·, v závislosti na pouºitém modelu a IOS. Díky jednoduchému ovládání se dají jednodu²e vytvo°it rozsáhlé topologie. Po nastartování sm¥rova£· v topologii je moºné p°ipojit se k nim kliknutím na p°íslu²nou ikonku. GNS3 na to pouºívá program Putty, coº zajistí, ºe v nov¥ otev°eném okn¥ vidíme výstup ze sm¥rova£e tak, jako kdybychom ho m¥li p°ipojen p°es konzolový port prost°ednictvím sériového kabelu. Po inicializaci sm¥rova£e je moºná jeho dal²í kongurace a to p°esn¥ tak, jako u reálného za°ízení. Pozoruhodnou moºností je jednoduché propojení topologie emulované v GNS3 s reálným sí´ovým adaptérem v PC. Lze tak rozdistribuovat jednu rozsáhlou topologii na více PC (nap°íklad více autonomních systém·), nebo vytvá°et zajímavé cvi£ení pro více lidí pracujících sou£asn¥. Vytvo°enou sí´ovou topologii lze uloºit do vlastního kongura£ního souboru s p°íponou .net, kterou je moºné kdykoliv znovu v GNS3 otev°ít. Rovn¥º je moºné uchovat i zavád¥cí konguraci pouºitých sm¥rova£·, coº je moºné vyuºít k vytvo°ení u£ebních a cvi£ných úkol·. Velmi silným nástrojem je moºnost analýzy sí´ové komunikace prost°ednictvím sí´ového analyzátoru Wireshark na kterémkoliv míst¥ topologie. 5.4 Instalace Pomocí webového prohlíºe£e nav²tivte http://www.gns3.net. P°ejd¥te na odkaz Download. V sekci Download zvolte Vám vyhovující verzi. Pro Windows je nejjednodu²²í zvolit all-in-one installator Zde máme jistotu, ºe stáhneme v²echny pot°ebné komponenty, pro plné vyuºití nástroje GNS3. 5.5 Denovaní Cisco IOS soubor· Jak bylo zmín¥no v úvodu, GNS3 pracuje pod reálnými Cisco IOS. Na ty je v²ak nutná licence. Proto je t°eba po°ídit si legální formou licenci k image IOS, který jiº následn¥ m·ºete neomezen¥ pouºívat jako svou vlastní kopii. Podporovány jsou následující platformy: 1710 1720 1721 28 NGN PRO VUT A VB-TUO 1750 1751 1760 2610 2610XM 2611 2611XM 2620 2620XM 2621 2621XM 2650XM 2651XM 2691 3620 3640 3660 3725 3745 7200 5.6 Vytvo°ení jednoduché topologie ekneme si, jak p°idat jeden router na plochu, spustit jej a nakongurovat jej pomocí konzoly. Ukáºeme si také jak najít idlepc hodnotu pro IOS, který pouºíváme. Je to velmi d·leºitý krok, protoºe b¥ºící IOS vyuºívá celé jedno jádro procesoru. Nicmén¥ v p°ípad¥ vyuºití idlepc výrazn¥ redukujeme vyuºití CPU. Umoºní nám to p°ivést IOS do idle reºimu, kdyº není aktivní vyuºíván. Klikn¥te na router v okn¥ Node Types korespondující s va²í IOS verzí. V na²em p°ípad¥ jde o platformu 3700. Klasicky postupem drag & drop vezm¥te router a p°emíst¥te jej do st°ední horní £ásti (pracovní oblast), viz. obr. 5.1. Takto máme p°ipravený router pro konguraci. Pravým tla£ítkem my²i klikn¥te na router a vyberte Congure. Klikn¥te na R1 a pak na Slots. V slot0 vyberte adaptér který kon£í FE, toto nám p°idá k routeru FastEthernet adaptér. Dále klikn¥te na slot1 a vyberte NM-4T, toto nám p°idá £ty°i serial rozhraní routeru, viz. obr. 5.2 Klikn¥te na OK. Klikn¥te op¥t pravým tla£ítkem my²i na router a zvolte Start a poté Console. Tím se dostanete do kongura£ní konzole, viz. obr. 5.3. Pravým tla£ítkem my²i klikn¥te na router R1 a vyberte volbu Idle PC. Zobrazí se vám okno, ve kterém m·ºete vybrat ze seznamu nejvíce vyhovující hodnotu pro Idle PC. Pravd¥podobn¥ nejvhodn¥j²í jsou ozna£eny hv¥zdi£kou. Vyberte proto jednu z t¥chto hodnot (v na²em p°ípad¥ jsme vybrali £íslo 10) a klikn¥te na OK. Obdrºíte zprávu, ºe idlepc hodnota byla aplikována. Tento proces m·ºete opakovat a hledat tak hodnotu, která nejmén¥ zat¥ºuje Vá² CPU. 29 5 GNS3 Obrázek 5.1: Náhled okna GNS Obrázek 5.2: P°idání jednotlivých adapter· k routeru 30 NGN PRO VUT A VB-TUO Obrázek 5.3: Náhled kongura£ní konzole v GNS3 5.7 Aplikace funkce Trac Shaping V prvním p°íkladu bude prezentována jednoduchá topologie, v níº bude aplikován Trac Shaping jako zp·sob °ízení provozu v síti. Rovn¥º bude v p°íkladu prezentovány jednoduché nastavení programu pro práci s Putty. Pro vytvo°ení hostings vyuºijeme program VPCS, který je sou£ástí all-in-one instala£ního souboru GNS3. 5.7.1 Zadání Sestavte sí´ podle schématu na obr. 5.4 a p°i°a¤te IP adresy v²em za°ízením v síti s vyuºitím adres z rozsahu 192.168.0.0/16 pro oblast WAN sít¥ a 172.16.0.0/16 pro koncové sít¥ LAN. K adresování pouºijte zásady podsí´ování (Subnetting). Na sm¥rova£ích aktivujte sm¥rovací protokol EIGRP. Na vstupech do WAN sítí implementujte QoS nástroj Trac Shaping. Pro hlasový provoz rezervujte p°enosovou kapacitu 10 Mbit/s, pro p°enos videa 40 Mbit/s a pro ostatní datový provoz (web, e-mail, ...) 50 Mbit/s. Zkontrolujte funk£nost zapojení. Zkontrolujte správnost sm¥rování podle EIGRP. Zachy´te pomocí programu Wireshark komunikaci mezi sm¥rova£i. Jako koncové jednotky pouºijte virtuální jednotky VPCS. 5.7.2 Propojení VirtualBox a GNS3 GNS3 umoº¬uje propojení virtuálních opera£ních systém· z Oracle VirtualBoxu. Pro nastavení propojení je doporu£eno vyuºívat vºdy nejnov¥j²í verze obou program·. Pro nastavení propojení p°ejdeme v GNS3 na Edit - Preferences a zvolíme poloºku VirtualBox. Klikneme na tla£ítko Test Settings. Po chvíli by se m¥la objevit zpráva VBoxwrapper and VirtualBox API have successfully started . P°ejdeme na záloºku VirtualBox Guest a vyjmeme z VM List virtuální po£íta£e, které chceme pouºít. Do prvního °ádku napí²eme jméno, pod kterým je chceme pouºívat. Klikneme na tla£ítko Save a virtuální opera£ní systém se objeví pod pat°i£ným názvem ve spodní £ásti okna, viz. obr. 5.5. 31 5 GNS3 Obrázek 5.4: Schéma zapojení Obrázek 5.5: Nastavení Virtualbox v prost°edí GNS3 32 NGN PRO VUT A VB-TUO 5.7.3 e²ení Pro zadanou topologii budeme pot°ebovat t°i routery a dva virtuální po£íta£e. Po p°idání router· na pracovní plochu programu provedeme jejich p°ejmenování (pravým kliknutím na router a výb¥rem poloºky Change the Hostname ) na RA, RB a resp. na RC. Pro propojení jednotlivých komponent· vyuºijeme linky typu FastEthernet a kv·li zachování £ísel port· ze zadání p°íkladu je budeme p°idávat v následujícím po°adí: PC1-RA, RA-RB, RB-RC, RC-PC2. Celou topologii spustíme pomocí menu Device - Start. Nastavíme Idle PC pro routery. Pro p°ístup do kongura£ní konzole router· klikneme pravým tla£ítkem my²i na router a zvolíme Console. Dále uº s routerem pracujeme jako s normálním fyzickým Cisco za°ízením s plnou podporou p°íkaz·. Jako první krok musíme provést konguraci rozhraní router· a sí´ových karet ve virtuálních opera£ních systémech. Pro routery bude kongurace vypadat takto: RA(config)#interface fastEthernet 0/0 RA(config-if)#ip address 172.16.0.2 255.255.255.0 RA(config-if)#no shutdown RA(config-if)#exit RA(config)# interface fastEthernet 0/1 RA(config-if)#ip address 192.168.0.1 255.255.255.0 RA(config-if)#no shutdown RB(config)#interface fastEthernet 0/0 RB(config-if)#ip address 192.168.0.2 255.255.255.0 RB(config-if)#no shutdown RB(config-if)#exit RB(config)# interface fastEthernet 0/1 RB(config-if)#ip address 192.168.1.1 255.255.255.0 RB(config-if)#no shutdown RC(config)#interface fastEthernet 0/0 RC(config-if)#ip address 192.168.1.2 255.255.255.0 RC(config-if)#no shutdown RC(config-if)#exit RC(config)# interface fastEthernet 0/1 RC(config-if)#ip address 172.16.1.2 255.255.255.0 RC(config-if)#no shutdown Jednotlivým PC p°i°adíme jejich IP adresy podle schématu v zadání v závislosti na pouºitém virtuálním opera£ním systému. Nesmíme zapomenout nakongurovat na po£íta£ích výchozí brány. Dal²ím krokem v po°adí je vytvo°ení jednoduchého sm¥rovacího protokolu. V p°íkladu zvolíme dle zadání protokol EIGRP. Ten kongurujeme na routerech: RA(config)#router eigrp 1 RA(config-router)#no auto-summary RA(config-router)#network 172.16.0.0 0.0.0.255 RA(config-router)#network 192.168.0.0 0.0.0.255 RB(config)#router eigrp 1 RB(config-router)#no auto-summary RB(config-router)#network 192.168.0.0 0.0.0.255 RB(config-router)#network 192.168.1.0 0.0.0.255 33 5 GNS3 RC(config)#router eigrp 1 RC(config-router)#no auto-summary RC(config-router)#network 192.168.1.0 0.0.0.255 RC(config-router)#network 172.16.1.0 0.0.0.255 Do reºimu kongurace EIGRP lze vstoupit pomocí p°íkazu router igrp 1, kde 1 je £íslo autonomního systému a pro na²e pot°ebu bude vºdy 1. Údaj 0.0.0.255 je tzv. wildcard maska. Na pozicích, kde byly v b¥ºné masce sít¥ uvedeny jedni£ky, má wildcard maska uvedeny nuly. Pro pozice s nulovými hodnotami bit· v b¥ºné masce sít¥ pak platí, ºe jsou ve wildcard masce nahrazeny bity s hodnotou jedna. V podstat¥ jde o jakousi inverzn¥ zapsanou sí´ovou masku 255.255.255.0 (/24). P°íkaz no auto-summary zabrání automatické sumarizaci sítí na rozhraní dvou r·zných t°ídních sítí. Správnost kongurace sm¥rovacího protokolu si m·ºeme ov¥°it pomocí p°íkazu show ip route v privilegovaném reºimu, kde bychom m¥li vid¥t v²echny 4 sít¥, viz. obr 5.6 Obrázek 5.6: Výpis kongurace sm¥rova£e a jeho sítí Prvním krokem p°i implementaci podpory QoS dle zadání je denice sí´ové provozu a rezervace p°enosové rychlosti pro jednotlivé sluºby. RA(config)#access-list RA(config)#access-list RA(config)#access-list RC(config)#access-list RC(config)#access-list RC(config)#access-list 101 102 103 101 102 103 permit permit permit permit permit permit ip ip ip ip ip ip 172.16.0.0 172.16.0.0 172.16.0.0 172.16.1.0 172.16.1.0 172.16.1.0 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 172.16.1.0 172.16.1.0 172.16.1.0 172.16.0.0 172.16.0.0 172.16.0.0 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255 dscp dscp dscp dscp dscp dscp 46 34 0 46 34 0 Parametr DSCP ur£uje jednotlivý druh provozu, hodnota 46 znamená p°enos hlasu, 34 video a 0 neprioritní data. Dále je t°eba vytvo°it t°ídy pro hlasový provoz, video a data. RA(config)#class-map VOICE RA(config-cmap)#match access-group 101 RA(config)#class-map VIDEO RA(config-cmap)#match access-group 102 RA(config)#class-map DATA RA(config-cmap)#match access-group 103 RC(config)#class-map VOICE RC(config-cmap)#match access-group 101 RC(config)#class-map VIDEO RC(config-cmap)#match access-group 102 RC(config)#class-map DATA RC(config-cmap)#match access-group 103 34 NGN PRO VUT A VB-TUO Následn¥ je nutné vytvo°it pravidla pro zacházení s denovanými druhy provozu. RA(config)#policy-map PM RA(config-pmap)#class VOICE RA(config-pmap-c)#shape average 10000000 RA(config-pmap)#class VIDEO RA(config-pmap-c)#shape average 40000000 RA(config-pmap)#class DATA RA(config-pmap-c)#shape average 50000000 RC(config)#policy-map PM RC(config-pmap)#class VOICE RC(config-pmap-c)#shape average 10000000 RC(config-pmap)#class VIDEO RC(config-pmap-c)#shape average 40000000 RC(config-pmap)#class DATA RC(config-pmap-c)#shape average 50000000 Posledním krokem je p°i°azení t¥chto pravidel ke správnému rozhraní a pro správný sm¥r. RA(config)#interface fastethernet 0/1 RA(config-if)#service-policy output PM RC(config)#interface fastethernet 0/0 RC(config-if)#service-policy output PM Správnost kongurace QoS je moºné zkontrolovat pomocí následujících p°íkaz·: RA#show class-map RA#show policy-map RA#show policy-map interface V p°ípad¥, ºe jsou pouºity virtuální opera£ní systémy na bázi Linuxu, m·ºeme pro otestování funk£nosti pouºít oby£ejný ping dopln¥n o n¥které parametry. sudo ping 172.16.1.1-Q 0xb8-s 65000-f Parametr -Q s hodnotou 0xb8 p°edstavuje zápis ToS - p°edch·dce DSCP. P°epo£et DSCP na ToS je uveden v tab. 5.1. Parametr -s 65000 znamená velikost pingu 65000 byt· a parametr -f znamená tzv. ood ping, který je pot°ebný pro dostate£né vytíºení sít¥ a aktivaci funkce Trac Shaping. Tabulka 5.1: Mapování DSCP na ToS DSCP class (hex) ToS (hex) voice video data ef 0xB8 af41 0x88 0 0x00 5.8 Metody obsluhy paketových front V druhém p°íkladu se podíváme na metody obsluhy paketových front, ukáºeme si pouºití funkce VPCS na otestování základní funk£nosti topologie a sm¥rování. Na záv¥r otestujeme funk£nost QoS. 35 5 GNS3 5.8.1 Zadání Sestavte sí´ podle schématu na obr. 5.7 a p°i°a¤te IP adresy v²em za°ízením v síti s vyuºitím adres z rozsahu 192.168.0.0/16 pro oblast WAN sít¥ a 172.16.0.0/16 pro koncové sít¥ LAN. K adresování pouºijte zásady podsí´ování (Subnetting). Na sm¥rova£ích aktivujte sm¥rovací protokol RIP. Na sériových rozhraních sm¥rova£· implementujte metodu obsluhy paketových front LLQ (Low Latency Queuing) v kombinaci s CBWQF (Class-based Weighted Fair Queuing). Pro hlasový provoz vytvo°te LLQ frontu a rezervujte pro ni p°enosovou kapacitu 32 kbit/s. Pro p°enos videa rezervujte 56 kbit/s. Ostatní p°enosovou rychlost pouºijte pro datový provoz. Pro tento typ provozu pouºijte metodu obsluhy paketových front WFQ (Weighted Fair Queuing) a nástroj Wrede (Weighted Random Early Detection). Rychlost sériových linek nastavte na 128 kbit/s. Zkontrolujte funk£nost zapojení a správnost sm¥rování podle RIP. Obrázek 5.7: Schéma zapojení 5.8.2 e²ení Topologii sestavíme podobn¥ jako v prvním p°ípad¥, následn¥ p°istoupíme ke konguraci a vloºení dvou virtuálních za°ízení VPCS (Virtual PC Simulator). VPCS je program který lze spustit v opera£ních systémech Windows a Linux. Jelikoº se v p°íkladech zabýváme tvorbou pouºíváním GNS3 v opera£ním systému Windows, budeme se v postupu zabývat výhradn¥ tímto systémem. VPCS má omezenou funkcionalitu a je vhodný zejména pro kontrolu konektivity topologie, protoºe dovoluje pouºití p°íkaz· ping a traceroute. VPCS oproti virtuálnímu systému VirtualBox ²et°í opera£ní pam¥´ a výpo£etní výkon. Je sou£ástí all-in-one instala£ního balíku a m·ºeme ho najít v instala£ním adresá°i GNS3. Spou²tí se pomocí souboru vpcs-start. Pro integraci VPCS do GNS3 vyuºijeme Symbol Library pomocí menu Edit - Symbol Manager, viz. obr. 5.8. 36 NGN PRO VUT A VB-TUO 1. Vybereme ikonu computer v £ásti Available Symbols, 2. klikneme na ²ipku, 3. V °ádku Name vepí²eme název VPCS, 4. zm¥níme typ za°ízení na Cloud, 5. klikneme na tla£ítko Apply, 6. klikneme na OK. Obrázek 5.8: P°idání za°ízení VPCS Na hlavní obrazovce programu se v £ásti Node Types zobrazí ikona po£íta£e s názvem VPCS. Na pracovní plochu umístíme dv¥ VPCS za°ízení. Klikneme na za°ízení C1 pravým tla£ítkem my²i a vybereme Congure. Zvolíme poloºku C1 a p°ejdeme na kartu NIO UDP a klikneme na Add. Parametry nastavíme podle obr. 5.9. Stejným zp·sobem nastavíme i za°ízení C2, kde zm¥níme hodnotu Local port na 30001 a Remote port na 20001. Tímto jsme nakongurovali ob¥ VPCS za°ízení a m·ºeme je p°ipojit do topologie pomocí p°i°azených UDP port· p°es linku FastEthernet . Mezi routery RA-RB a RB-RC je pouºita sériová linka, na v²ech ostatních spojích jsou pouºity FastEthernet linky. Nastavení sm¥rova£· Nejd°íve nastavíme IP adresy pro jednotlivé porty router·. 37 5 GNS3 Obrázek 5.9: Nastavení VPCS RA(config)#interface fastEthernet 0/0 RA(config-if)#ip address 172.16.0.2 255.255.255.0 RA(config-if)#no shutdown RA(config-if)#exit RA(config)#interface serial 0/0 RA(config-if)#ip address 192.168.0.2 255.255.255.0 RA(config-if)#no shutdown RA(config-if)#exit RB(config)#interface serial 0/0 RB(config-if)#ip address 192.168.1.2 255.255.255.0 RB(config-if)#no shutdown RB(config-if)#exit RB(config)#interface serial 0/1 RB(config-if)#ip address 192.168.0.1 255.255.255.0 RB(config-if)#no shutdown RC(config)#interface fastEthernet 0/0 RC(config-if)#ip address 172.16.1.2 255.255.255.0 RC(config-if)#no shutdown RC(config-if)#exit RC(config)#interface serial 0/0 RC(config-if)#ip address 192.168.1.1 255.255.255.0 RC(config-if)#no shutdown Po konguraci rozhraní p°ejdeme k nastavení sm¥rovacího protokolu RIP. Do reºimu kongurace protokolu RIP se dostaneme pomocí p°íkazu router rip. P°íkazem version 2 se aktivuje verze 2 sm¥rovacího protokolu RIP. P°íkaz no auto-summary zabrání automatické sumarizaci sítí na rozhraní dvou r·zných t°íd sítí. 38 NGN PRO VUT A VB-TUO RA(config)#router rip RA(config-router)#version 2 RA(config-router)#no auto-summary RA(config-router)#network 172.16.0.0 RA(config-router)#network 192.168.0.0 RB(config)#router rip RB(config-router)#version 2 RB(config-router)#no auto-summary RB(config-router)#network 192.168.0.0 RB(config-router)#network 192.168.1.0 RC(config)#router rip RC(config-router)#version 2 RC(config-router)#no auto-summary RC(config-router)#network 192.168.1.0 RC(config-router)#network 172.16.1.0 Ov¥°íme funk£nost topologie a sm¥rování pomocí VPCS. Spustíme program vpcs-start, který je umíst¥n v instala£ním adresá°i GNS3. Objeví se p°íkazový °ádek, pomocí kterého je moºné ovládat jednotlivé virtuální systémy. VPCS dovoluje pouºívat sou£asn¥ aº 9 virtuálních za°ízení. P°epínání mezi nimi probíhá pomocí napsání £isla konkrétního p°ístroje do konzole a stisknutí Enter. Nastavení ip adresy probíhá pomocí p°íkazu ip. Nastavme tedy IP adresy na²ich dvou za°ízení a jejich výchozí brány pomocí p°íkaz·, viz. obr. 5.10. Obrázek 5.10: Nastavení IP adres VPCS za°ízení Otestujeme funk£nost zapojení a sm¥rování pomocí p°íkaz· ping a tracert, viz. obr. 5.11. Prvním krokem p°i implementaci podpory QoS dle zadání je denice t°íd pro jednotlivé druhy sí´ové provozu. RA(config)#class-map VOICE RA(config-cmap)#match ip dscp 46 RA(config)#class-map VIDEO RA(config-cmap)#match ip dscp 34 RB(config)#class-map VOICE RB(config-cmap)#match ip dscp 46 RB(config)#class-map VIDEO RB(config-cmap)#match ip dscp 34 RC(config)#class-map VOICE RC(config-cmap)#match ip dscp 46 RC(config)#class-map VIDEO RC(config-cmap)#match ip dscp 34 Následn¥ je nutné vytvo°it pravidla pro zacházení s d°íve denovanými druhy provozu. P°íkazem priority 32 se rezervuje p°enosová rychlost na 32 kbit/s pro LLQ fronty. P°íkazem bandwidth 56 se rezervuje p°enosová rychlost 56 kbit/s pro CBWFQ fronty. P°íkazem 39 5 GNS3 Obrázek 5.11: Výsledky testování pomocí ping a tracert fair-queue se nastavuje pouºití WFQ metody uvnit° fronty pro danou t°ídu provozu. Nástroj WRED se aktivuje pro danou t°ídu provozu p°íkazem random-detect DSCP-based. RA(config)#policy-map PM RA(config-pmap)#class VOICE RA(config-pmap-c)#priority 32 RA(config-pmap)#class VIDEO RA(config-pmap-c)#bandwidth 56 RA(config-pmap)#class class-default RA(config-pmap-c)#fair-queue RA(config-pmap-c)#random-detect dscp-based RB(config)#policy-map PM RB(config-pmap)#class VOICE RB(config-pmap-c)#priority 32 RB(config-pmap)#class VIDEO RB(config-pmap-c)#bandwidth 56 RB(config-pmap)#class class-default RB(config-pmap-c)#fair-queue RB(config-pmap-c)#random-detect dscp-based RC(config)#policy-map PM RC(config-pmap)#class VOICE RC(config-pmap-c)#priority 32 RC(config-pmap)#class VIDEO RC(config-pmap-c)#bandwidth 56 RC(config-pmap)#class class-default RC(config-pmap-c)#fair-queue RC(config-pmap-c)#random-detect dscp-based Posledním krokem je p°i°azení t¥chto pravidel ke správnému rozhraní a pro správný sm¥r. RA(config)#interface serial 0/1/0 RA(config-if)#service-policy output PM 40 NGN PRO VUT A VB-TUO RB(config)#interface serial 0/1/0 RB(config-if)#service-policy output PM 29 RB(config)#interface serial 0/1/1 RB(config-if)#service-policy output PM RC(config)#interface serial 0/1/1 RC(config-if)#service-policy output PM Pro ov¥°ení funk£nosti paketových front op¥t pouºijeme p°íkaz ping, kterému nastavíme p°íznak ood-ping a hodnotu DSCP vyjád°enou pomocí ToS. sudo ping 172.16.1.1-f-Q 0xb8-s 65000 Zkontrolujeme paketové ltry pomocí p°íkazu RA # show policy-map interface, viz. obr. 5.12. Obrázek 5.12: Kontrola funk£nosti paketových ltr· 41 6 OCTAVE QUEUEING PACKAGE 6 Octave Queueing Package Dopl¬ující balí£ek Queueing , d°íve známý jako qnetworks, je kolekce funkcí napsaných v GNU Octave pro analýzu obsluhových systém· a Markovových °et¥zc·. [12, 19] Queueing poskytuje funkce pro analýzu následujících typ· systém· hromadné obsluhy: M/M/1 M/M/m M/M/∞pro M/M/1/k (1 obsluhová linka, kone£ný po£et poºadavk·) M/M/m/k (více obsluhových linek, kone£ný po£et poºadavk·) Pro analýzu Markovových °et¥zc· jsou k dispozici funkce: Birth-Death procesy Pr·m¥rná doba absorpce St°ední doba prvního p°echodu O£ekávaná doba poºadavku v systému 6.1 M/M/1 model Tento model p°edpokládá jednu obsluºnou linku s dobou obsluhy, která se °ídí exponenciálním rozd¥lením a p°edpokládá p°íchod poºadavk· do systému také pod exponenciálním rozd¥lením. [5, 8, 13, 37] M/M/1 systém je sloºen z jednoho serveru p°ipojeného k neomezenému po£tu FIFO front. Jedná se o exponenciální rozd¥lení mezi p°íchody poºadavk· (Poisson·v proces) s exponenciální intenzitou p°íchod· ºádostí λ. Doba obsluhy je exponenciální s pr·m¥rnou intenzitou obsluhy µ. Systém je stabilní, pokud λ < µ. 6.1.1 Zadání Pro obsluhový systém typu M/M/1 vypo£ítejte pomocí nástroje Queueing Package v²echny dostupné výstupní parametry. Zvolte si vstupní parametry tak, aby obsluhový systém byl stabilní. 6.1.2 e²ení Syntaxe zápisu v prost°edí Octave : [U, R, Q, X, p0] = qsmm1 (lambda, mu) kde vstupní parametry jsou: lambda (λ) - intenzita poºadavk· (λ ≥ 0). mu (µ) - intenzita obsluhy (µ > λ). výstupní parametry jsou: U - vyuºití systému, 42 NGN PRO VUT A VB-TUO R - pr·m¥rný £as poºadavku strávený v systému, Q - pr·m¥rný po£et poºadavk· v systému, X - propustnost systému, je-li systém ergodický (µ > λ), tak X = λ, p0 - po£áte£ní pravd¥podobnost. Bylo zvoleno: λ=0.6 µ=0.75 Ur£íme vyuºití systému U, £as, který stráví poºadavek v systému R, pr·m¥rný po£et poºadavk· v systému Q a po£áte£ní pravd¥podobnost p0 , tedy pravd¥podobnost,ºe v systému nebude ºádná linka obsazena. Syntaxe zápisu bude vypadat následovn¥: octave-3.6.4.exe:3> [u,r,q,x,p0]=qsmm1(0.6,0.75) Výsledek: u = 0.8000 r = 6.6667 q = 4.0000 x = 0.60000 p0 = 0.20000 6.2 M/M/n model Jedná se o model, který má n linek pro obsluhu. Podmínkou pro stacionaritu tohoto systému je λ <1 n·µ (6.1) Jde vlastn¥ o stejnou podmínku, jako v p°edchozím p°ípad¥, o podmínku, aby intenzita odchod· byla v¥t²í neµ intenzita p°íchod·. Podobným zp·sobem jako v p°edchozím p°ípad¥ získáme následující vztahy pro pn . Situace je o to komplikovan¥j²í, ºe pravd¥podobnost odchodu jednoho uºivatele ze systému se v tomto p°ípad¥ d¥lí na více p°ípad·, neº v p°edchozí situaci. Zde bude t°eba odli²it, zda je v systému 0, 1, . . . c 1 £i c a více uºivatel·. 6.2.1 Zadání Pro obsluhový systém typu M/M/n vypo£ítejte pomocí nástroje Queueing Package v²echny dostupné výstupní parametry. Zvolte si vstupní parametry tak, aby obsluhový systém byl stabilní. 43 6 OCTAVE QUEUEING PACKAGE 6.2.2 e²ení Syntaxe zápisu v prost°edí Octave : [U, R, Q, X, p0, pm] = qsmm1 (lambda, mu, m) kde vstupní parametry jsou: lambda (λ) - intenzita poºadavk· (λ ≥ 0). mu (µ) - intenzita obsluhy (µ > λ). výstupní parametry jsou: U - vyuºití systému R - pr·m¥rný £as poºadavku strávený v systému Q - pr·m¥rný po£et poºadavk· v systému X - propustnost systému, je-li systém ergodický (µ > λ), tak X = λ. p0 - po£áte£ní pravd¥podobnost, pm - pravd¥podobnost, ºe bude v²ech m linek obsazeno. Bylo zvoleno: λ=0.6 µ=0.75 m=10 Ur£íme vyuºití systému U, £as, který stráví poºadavek v systému R, pr·m¥rný po£et poºadavk· v systému Q a po£áte£ní pravd¥podobnost p0 , tedy pravd¥podobnost,ºe v systému nebude ºádná linka obsazena a pravd¥podobnost pm . Syntaxe zápisu bude vypadat následovn¥: octave-3.6.4.exe:6> [u,r,q,x,p0,pm]=qsmmm(0.6,0.75,10) Výsledek: u = 0.080000 r = 1.3333 q = 0.80000 x = 0.60000 p0 = 0.44933 pm = 1.4452e-008 44 NGN PRO VUT A VB-TUO 6.3 Erlang-B model Erlang je bezrozm¥rná jednotka pouºívaná v telefonii jako statistická hodnota míry provozního zatíºení. Je pojmenovaná podle dánského telekomunika£ního inºenýra A.K.Erlanga, zakladatele teorie hromadné obsluhy. Provozní zatíºení jedno Erlangu odpovídá nep°etrºitému obsazení jedné obsluhové linky po dobu obsluhy. Pro dimenzování telefonní sít¥ byl po£átkem 20. století vyvinut velmi silný nástroj v podob¥ Erlangových rovnic. Tyto rovnice jsou i v sou£asné dob¥ velmi uznávaným a pouºívaným nástrojem v oblasti provozního zatíºení. Erlang B rovnice viz. vztah 6.2 dokáºe ur£it, s jakou pravd¥podobností PN budou v²echny kanály obsazené, pokud známe nabízené zatíºení A a po£et kanál· N ve spojovacím svazku. PN = E1,N (A) = AN N! N P Ai i! i=0 (6.2) Rovnice musí spl¬ovat podmínky: tok poºadavk· vzniká náhodn¥, s exponenciálním rozloºením odstup· mezi p°icházejícími sousedními poºadavky, to znamená, ºe £ím v¥t²í odstup, tím men²í je po£et t¥chto p°ípad·. Doba obsluhy má podobné rozd¥lení, tj. exponenciáln¥ ubývá t¥ch poºadavk·, které mají del²í dobu obsluhy. Tok poºadavk· je ustálený, teoreticky jako by vznikal z nekone£ného po£tu zdroj· poºadavk·. Existuje plná dostupnost poºadavk· na v²echny obsluhové linky. Odmítnuté poºadavky se nevracejí do vstupního toku, tj. neexistují opakované poºadavky. Tyto obsazují systém na nulovou dobu. Nevzniknou sou£asn¥ dva poºadavky. 6.3.1 Zadání Pro obsluhový systém typu M/M/n vypo£ítejte pomocí nástroje Queueing Package pravd¥podobnost, ºe budou v²echny linky obsazeny. Zvolte si vstupní parametry tak, aby obsluhový systém byl stabilní. 6.3.2 e²ení Syntaxe zápisu v prost°edí Octave : B = erlangb (A, M) kde vstupní parametry jsou: A - nabízené zatíºení, denované jako A = µλ , kde λ je intenzita p°íchod· a µ je intenzita obsluhy kaºdého uºivatele. 45 6 OCTAVE QUEUEING PACKAGE M - po£et identických linek v OS (m ≥ 1). výstupní parametry jsou: B - pravd¥podobnost, ºe budou v²echny linky obsazeny Bylo zvoleno: λ=60 µ=10 m=10 Syntaxe zápisu bude vypadat následovn¥: octave-3.6.4.exe:5> B=erlangb(6,10) Výsledek: B = 0.043142 Coº znamená, ºe pro 10 linek bude p°i zvolené intenzit¥ vstupního toku 4,3 % pravd¥podobnost, ºe bude v²ech 10 linek obsazeno. 6.4 Erlang-C model Erlang C rovnice (viz. obr. 6.4) vyjad°uje pravd¥podobnost toho, ºe p°icházející poºadavek v náhodném okamºiku bude £ekat. Parametr W je £ekací doba a p°edpokladem pro správnou A platnost tohoto vztahu je N < 1. PC (W > 0) = E2,N (A) = AN N! NP −1 i=0 Ai i! · + N N −A AN N! · (6.3) N N −A 6.4.1 Zadání Pro obsluhový systém typu M/M/n vypo£ítejte pomocí nástroje Queueing Package pravd¥podobnost £ekání poºadavku. Zvolte si vstupní parametry tak, aby obsluhový systém byl stabilní. 6.4.2 e²ení Syntaxe zápisu v prost°edí Octave : C = erlangc (A, M) kde vstupní parametry jsou: A - nabízené zatíºení, denované jako A = µλ , kde λ je intenzita p°íchod· a µ je intenzita obsluhy kaºdého uºivatele. M - po£et identických linek v OS (m ≥ 1). 46 NGN PRO VUT A VB-TUO výstupní parametry jsou: C - pravd¥podobnost, ºe budou v²echny linky obsazeny a poºadavek bude £ekat v teoreticky £asov¥ neomezené front¥ Bylo zvoleno: λ=60 µ=10 m=10 Syntaxe zápisu bude vypadat následovn¥: octave-3.6.4.exe:10> C=erlangc(6,10) Výsledek: C = 0.10130 Coº znamená, ºe pro 10 linek bude p°i zvolené intenzit¥ vstupního toku 10,1 % pravd¥podobnost, ºe bude dal²í poºadavek £ekat ve front¥. 6.5 Engsetova rovnice Engsetova rovnice zobec¬uje Erlangovu rovnici tím, ºe denuje kone£ný po£et volajících (uºivatel· vstupujících do OS). S AN N Pb (N, A, S) = N P i S A i (6.4) i=0 6.5.1 Zadání Pro obsluhový systém typu M/M/n vypo£ítejte pomocí nástroje Queueing Package pravd¥podobnost ztráty. Zvolte si vstupní parametry tak, aby obsluhový systém byl stabilní. 6.5.2 e²ení Syntaxe zápisu v prost°edí Octave : B = engset (A, M, N) kde vstupní parametry jsou: A - nabízené zatíºení, denované jako A = µλ , kde λ je intenzita p°íchod· a µ je intenzita obsluhy kaºdého uºivatele. M - po£et identických linek v OS (m ≥ 1). N - kone£ný po£et p°íchozích poºadavk· výstupní parametry jsou: 47 6 OCTAVE QUEUEING PACKAGE B - pravd¥podobnost, ºe budou v²echny linky obsazeny Bylo zvoleno: λ=60 µ=10 M=100 N=200 Syntaxe zápisu bude vypadat následovn¥: octave-3.6.4.exe:26> B=engset(6,100,200) Výsledek: B = 0.83398 Coº znamená, ºe pro 100 linek a 200 p°íchozích uºivatel· do systému bude p°i zvolené intenzit¥ vstupního toku 83,3 % pravd¥podobnost, ºe bude dal²í poºadavek £ekat ve front¥. 48 NGN PRO VUT A VB-TUO 7 OPNET Modeler OPNET Modeler je softwarové vývojové prost°edí vhodné pro návrh a analýzu komunika£ních sítí. Pat°í do celkového softwarového balíku OPNET (Optimum Network Performance) od americké rmy Riverbed Technology, d°íve OPNET Technologies. Usnad¬uje návrh komunika£ních sítí: dimenzování sítí, návrh protokol· a simulaci chování aplikací s velkou moºností exibility testování. OPNET Modeler je hierarchicky a objektov¥ orientován. Gracké prost°edí umoº¬uje reálné rozmís´ování jednotlivých sí´ových komponent. Na nejniº²í úrovni je chování jednotlivých komponent popsáno zdrojovým kódem v jazyce C/C++. Dále obsahuje ²iroké moºnosti v oblasti simulace a analýzy výsledk·. OPNET Modeler jiº v sob¥ obsahuje °adu knihoven jednotlivých sí´ových komponent p°eváºn¥ pro Ethernet, FDDI, IP, TCP, ATM, http, atd. Výsledky simulací tzv. statik lze generovat do zpráv ve formátech XML a HTML, nebo uloºit data do tabulek a také lze uloºit obsah okna do soubor· TIFF, GIF a BMP. Dále obsahuje prohlíºe£ animací, díky kterému lze prohlíºet pr·b¥h odsimulovaného projektu. [32] 7.1 Postup návrhu nového projektu a scéná°e Vytvá°ení prvotního modelu sít¥ m·ºeme povaºovat za obdobné jako u v¥t²iny ostatních projekt·. P°i spu²t¥ní Opnet Modeleru se vybere v Menu File → New → Project, pojmenuje se Projekt a Scéná° a spustí se pr·vodce vytvo°ení nového scéná°e . [15] V dal²ím kroku navolíme vytvo°ení prázdného scéná°e Create empty scenario. Tla£ítkem next se p°esuneme do dal²í nabídky, kde si jednodu²e m·ºeme zvolit velikost na²í sít¥ v poloºce Network Scale, konkrétn¥ pak rozloºení sít¥ v Enterprise pro p°esn¥j²í specikaci rozm¥r· (vzdáleností mezi jednotlivými prvky sít¥). V dal²ích krocích se nastaví rozm¥ry 10km x 10km, a pro rychlej²í práci s umíst¥ním prvk· je vybrána technologie v Model Family → UMTS + UMTS_Advanced, kde je t°eba zvolit ve vedlej²ím sloupci Include - Yes. Posledním krokem pr·vodce je pouze stru£né shrnutí námi nastavených úkon·. Kliknutím na Finish pr·vodce ukon£íme, poté se zobrazí prázdná plocha a vedle nabídka prvk· a spoj·, tzv. Object Palette Tree. Tento nástroj nám umoº¬uje sestavit sí´ umíst¥ním prvk· z palety objekt· na p°eddenovaný rozm¥r plochy. Obrázek 7.1 popisuje, jak vypadá model sít¥ sestavený z prvk· palety. Kliknutím pravého tla£ítka my²i na jednotlivé prvky je moºné upravit název prvku (výb¥rem druhé poloºky od shora Set Name). umts_rnc_ethernet_atm_slip = RNC, umts_sgsn_atm9_slip = SGSN, umts_ggsn_slip8 = GGSN, umts_node_b_3sector_adv = Node_B, umts_wkstn_adv = UE, ip32_cloud = Internet, etherenet4_slip8_gtwy = Router, ethernet_server_adv = Media_Server, Application_Config = Application_Config, Profile_Config = Profile_Config. Jednotlivé prvky mezi sebou propojíme následujícím zp·sobem: 49 7 OPNET MODELER Obrázek 7.1: Realizace datové sít¥ UMTS (vlevo rozmíst¥ní prvk·, vpravo paleta objekt·) Spojem ATM_adv jsou propojeny prvky: Node-B → RNC → SGSN, Spojem PPP_DS3 jsou propojeny prvky: SGSN → GGSN → IP cloud → Router, Spojem 10BaseT jsou propojeny prvky: Router → Media-Server, Stanice se p°ipojují bezdrátov¥ k p°íslu²nému prvku Node-B. Propojování prvk· je t°eba za£ít od p°ístupové £ásti sm¥rem k páte°ní, tzn. od eNode-B po Media-Server, aby se p°ede²lo p°ípadným chybám v propojení port·. Více stejných prvk· lze duplikovat výb¥rem a klasickým kopírováním, jako v systému windows, pomocí klávesových zkratek CTRL+C a vloºením CTRL+V. Dal²ím krokem je vytvo°ení velikosti bun¥k vybráním poloºky z menu Topology → Annotation Palette Open a z palety tvar kruhu, který se vloºí do mapy. Kliknutím pravým tla£ítkem my²i na tento objekt a zvolením Edit Attributes, se po té zm¥ní v poloºce ll:ll tak, aby byl kruh vypln¥ný. Nakonec se zm¥ní je²t¥ barva na ºlutou a objekt se pojmenuje nap°íklad Cell_1. Velikost bun¥k je dána pr·m¥rnou velikostí vysílacího výkonu Node-B. V dal²í, díl£í fázi simulací se nastaví pro kaºdou mobilní stanici dráha, po které se bude stanice pohybovat bu¤to sm¥rem ven ze sít¥ od uzlu Node-B nebo v rámci jedné £i dvou bun¥k (Node-B). Je nutné nastavit kaºdou dráhu zvlá²´ a to výb¥rem poloºky tory, → Dene trajec- Trajectory name, v prvním p°í- Topology viz. obr. 7.2. Kaºdá dráha se pojmenuje odli²ným názvem v kolonce pad¥ dráha 1 jako D1 a potvrdí se kliknutím na Dene Path. Otev°e se dal²í okno, kde se ponechá rychlost pohybu stanic po trajektorii 10km/h a kliknutím na st°ed vytvo°ených kruºnic (bun¥k) se zvolí po£átek. 50 NGN PRO VUT A VB-TUO Dal²ím kliknutím mimo dosah Node_B se dráha ukon£í a potvrdí v dal²í nabídce Com- plete. Zatím dráha není zobrazena, proto se musí p°i°adit k jednotlivé stanici. V p°ípad¥ dráhy D1 je p°i°azena na stanici UE_HTTP, výb¥rem z kontextového menu Edit Attributes a výb¥rem této dráhy v kolonce Trajectory. Takto se postupuje dále pro kaºdou stanici. Jakmile jsou p°i°azeny dráhy stanicím, je moºné dráhy jednotliv¥ editovat a upravovat. Je pot°eba nastavit zpoºd¥ní startu (Wait Time) pohybu stanice kv·li pot°ebné inicializaci sluºby. Z kontextového menu dráhy se v poloºce Wait Time nastaví minimální hodnota 200s. U kaºdé dráhy m·ºe být tato hodnota r·zná, ale vºdy v¥t²í neº 200s. Obrázek 7.2: Nastavení £ekací doby u dráhy D1 7.2 Nastavení sluºeb v Application Cong Aby bylo moºné provozovat v síti UMTS dané sluºby, je nutná jejich specikace v poloºce Application Cong. Pro denici spou²t¥ní, opakování a dob¥ trvání sluºeb se vyuºije nastavení v tzv. Prole Cong. Nastavení sluºby Voice Výb¥rem Edit Attributes z kontextového menu a pomocí + se rozbalí záloºka Application Denitions. O °ádek níºe Number of Rows se vybere po£et aplikací, které budou v dané síti provozovány, to znamená, ºe zm¥nou na hodnotu 2 nabídne moºnosti pro 2 sluºby. Rozkliknutím + u poloºky v záloºce Name pojmenujeme konkrétní sluºbu, v tomto p°ípad¥ hlasovou sluºbu Voice. Enter Application Name 51 7 OPNET MODELER V záloºce Description provedeme výb¥r a editujeme poloºkou Edit zmín¥ný Voice, zde aktivujeme typ hlasové sluºby GSM Quality Speech. Nastavení sluºby http U sluºby http byly provedeny tyto zm¥ny po editaci poloºkou Edit, viz. obr. 7.3. Page Interarrival Time (seconds) → constant (10) £as pro na£tení dal²ích webových stránek (10s), Page Properties → Object Size (bytes) → constant (500), small image - konstantní 500 Byt·, odpovídající na£ítání malých obrázk· Obrázek 7.3: Nastavení sluºby HTTP 7.3 Nastavení Prole Cong Na plo²e je prvek s názvem Prole Cong, který je t°eba upravit tak, aby bylo moºné spou²t¥ní a obsluhování jiº nadenovaných aplikací. Zvolíme tedy hodnotu 2 v záloºce Prole Conguration → Number of Rows a zde p°ejmenujeme vybrané prázdné poloºky na °ádku Prole Name, nap°íklad na jmenoAplikace_prf. 52 NGN PRO VUT A VB-TUO Jelikoº je pro kaºdou aplikaci p°ipraven prol, je nutné p°i°adit danou aplikaci odpovídajícímu prolu. Rozkliknutím poloºky Applications provedeme výb¥r po£tu sluºeb obsluhovaných v prolu, tzn. v poloºce Number of Rows se zvolí hodnota pouze jednu sluºbu). 1 (kaºdý prol má obsluhovat Následn¥ se otev°e dal²í °ádek, umoº¬ující vloºení dané aplikace. Symbolem + otev°eme dal²í nabídku, kde se do °ádku Name vybere d°íve vytvo°ená sluºba. Modikujeme pouze tyto konkrétní poloºky, viz. obr. 7.4. Obrázek 7.4: Kongurace sluºby Voice a HTTP v Prole Cong 7.3.1 Voice_prf - prol pro telefonii VoIP Applications - zde vloºíme aplikaci, která byla d°íve vytvo°ena v objektu Application cong, v tomto p°ípad¥ Voice sluºba. Rows = 1 - po£et aplikací, které se budou spou²t¥t s tímto prolem Name = voice - jméno aplikace, vytvo°ené v objektu Application cong Start Time Offset (seconds) = constant(5) - nastavuje, kdy se daná aplikace spustí Duration = constant(60) - doba trvání dané aplikace Repeatability - udává po£et opakování a £asový odstup k dal²ímu zopakování: Inter-repetition Time(seconds) = constant(0.1) - doba mezi opakováním aplikace Number of Repetitions = Unlimited - po£et opakování a £asový odstup k dal²ímu zopakování 53 7 OPNET MODELER Repetition Pattern = Serial - denuje, spu²t¥ní dal²ího p°enosu souboru v po°adí za sebou Operation Mode = Serial(Ordered) - ur£uje, v jakém po°adí se bude aplikace spou²t¥t Start Time (seconds) = constant (120) - ur£uje kdy bude prol spu²t¥n Duration (seconds) = End of Simulation - ur£uje dobu trvání prolu Repeatability = Once at Start Time - £asový odstup k dal²ímu zopakování 7.3.2 Http_prf - prol pro sluºbu HTTP Applications - vloºení aplikace, která byla d°íve vytvo°ena v objektu Application cong v tomto p°ípad¥ HTTP - web sluºba. Rows = 1 - po£et aplikací, které se budou spou²t¥t s tímto prolem. Name = http - jméno aplikace, vytvo°ené v objektu Application cong. Start Time Offset (seconds) = constant(5)- nastavuje, kdy se daná aplikace spustí. Duration = constant(60) - doba trvání dané aplikace. Repeatability - udává po£et opakování a £asový odstup k dal²ímu zopakování: Inter-repetition Time(seconds) = constant(0) - doba mezi opakováním aplikace Number of Repetitions = Unlimited - po£et opakování a £asový odstup k dal²ímu zopakování Repetition Pattern = Serial - denuje, kdy bude spu²t¥n dal²í p°enos souboru Operation Mode = Serial(Ordered) - ur£uje, v jakém po°adí se bude aplikace spou²t¥t. Start Time (seconds) = constant (90) - ur£uje kdy bude prol spu²t¥n Duration (seconds) = End of Simulation - ur£uje dobu trvání prolu Reapeatability = Once at Start Time - udává £asový odstup k dal²ímu zopakování První se po spu²t¥ní provozu sít¥ inicializuje prol (nap°. Voice_prf) ze strany klienta, neboli ú£astníka zahajující komunikaci. Poté je spu²t¥na sluºba Applications, jak ze strany serveru, tak ze strany odpovídajícího klienta. 7.3.3 Nastavení atribut· na Voice stanicích Mobilní stanice UE_voice1 bude v této síti zahajovat prvotní telefonii, proto je nutné nastavit v kontextovém menu Edit Attributes v záloºce Applications → Application: Supported Proles následující parametry: Number of Rows 1 Profile Name voice_prf Na druhé mobilní stanici UE_voice2 nastavíme práv¥ zmi¬ovanou sluºbu. Toto se provede editací záloºky Applications → Application: Supported Services. V nov¥ otev°eném okn¥ se vpravo dole vybere po£et °ádk· aplikací, takºe pro tento p°ípad jeden, jelikoº se zde bude spou²t¥t jedna sluºba, a to IP telefonie. Ve sloupci Name se vybere sluºba voice a v pravém sloupci se aktivuje na Supported. 54 NGN PRO VUT A VB-TUO 7.4 Nastavení atribut· na http stanici V záloºce Applications → Application: Supported Proles se aktivuje prol http_prf a navíc je pro komunikaci u této sluºby nutné zvý²it po£et opakovaného vysílání v záloºce TCP → TCP Parameters → Retransmission Thresholds → Maximum Connect Attempts (attempts) z p·vodní hodnoty 3 na 5. A nakonec zvý²ení po£áte£ního £asového limitu pro op¥tný p°enos v záloºce TCP → TCP Parameters → Initial RTO (sec) z p·vodních 3 na 10 sekund. U sluºby HTTP je to trochu jinak, pon¥vadº je to komunikace klient server, takºe mobilní stanice zahajuje p°enos dat (spou²tí prol) a server odpovídá spu²t¥ním sluºby. 7.5 Nastavení atribut· na Media-Serveru V záloºce Applications → Application: Supported Services se edituje vedlej²í sloupec, kde se aktivuje 1 °ádek → Rows 1 a vybere se sluºba prohlíºení webových stránek http. Posledním krokem je také úprava protokolu TCP stejn¥ jako u stanice HTTP. 7.6 Kongurace p°ístupové sít¥ UTRAN V¥t²í denovaná kapacita sí´ových prost°edk· by m¥la být zaji²t¥na u sluºby VoIP (voice) a to alespo¬ 64 kbps symetricky. Sluºb¥ HTTP, pro testovací ú£ely zcela posta£í kapacita 32 kbps. 7.6.1 Nastavení p°enosové kapacity pro klienty telefonie Editací kontextového menu na Voice klientech se zvolí záloºka UMTS → UMTS QoS Prole → Background → Bit Rate Cong a nastaví se tyto hodnoty: Conguration Maximum Bit Rate Uplink (kbps) 64 Maximum Bit Rate Downlink (kbps) 64 7.6.2 Nastavení p°enosové kapacity pro HTTP klienta Editací kontextového menu na HTTP klientech se zvolí záloºka UMTS → UMTS QoS Prole Conguration → Background → Bit Rate Cong a nastaví se tyto hodnoty: Maximum Bit Rate Uplink (kbps) 32 Maximum Bit Rate Downlink (kbps) 32 Tímto jsou v síti nastaveny pot°ebné aplikace a sluºby, nyní je moºno p°ejít k výb¥ru sledovaných statistik. Rychlost pro ideální výstupní charakteristiky se bude li²it, tyto nastavené rychlosti jsou pouze p°íkladové. 7.7 Simulace sít¥ V prost°edí OPNET Modeler je moºno vybrat charakteristiky, které budou analyzovány ve výsledcích simulace sít¥. Toto provedeme tak, ºe kliknutím na plochu pravým tla£ítkem my²i se vybere z kontextového menu poloºka Choose Individual DES Statistic. V nov¥ otev°eném okn¥ si pro modelovou situaci m·ºeme zvolit následující charakteristiky. 55 7 OPNET MODELER Global statistics HTTP Voice Node statistics - globální statistiky (výb¥r v²ech statistik pro kaºdou sluºbu) - statistiky pro jednotlivé uzly v síti Client HTTP Server HTTP Voice Application Voice Called Party charakteristika pro p°ijímací telefonní stanici Voice Calling Party charakteristika pro volající telefonní stanici P°ed samotným spu²t¥ním simulace je nutno nastavit tyto parametry, viz. obr. 7.5: Vybereme z hlavního menu záloºku Scenarios → Manage Scenarios a v nov¥ otev°eném okn¥ je zobrazen scéná°, který bude simulován Ve sloupci Results se nastaví poloºka collect (znovu zkompilovat) Ve sloupci Sim Duration nastavíme dobu simulace nap°. na 15 minut Hodnota minuty (minute(s)) se zm¥ní v posledním sloupci Time Units Kliknutím na OK spustíme simulaci Obrázek 7.5: Nastavení spou²t¥ní simulace 7.8 Analýza výsledk· Pro analýzu výsledk· simulace je v tomto simula£ním prost°edí p°ehledné a jednoduché gracké rozhraní, umoº¬ující vyobrazení výstupních dat ve form¥ graf·, viz. obr. 7.6. Výsledky snadno zobrazíme kliknutím pravým tla£ítkem na plochu nebo p°ímo na prvky UMTS sít¥ a výb¥rem poloºky View Results z kontextového menu, dále pak jiº konkrétní sluºbu v globálních statistikách Global Statistic nebo p°ímo na konkrétních objektech Object Statistic. Pro porovnání charakteristik slouºí výb¥r n¥kolika scéná°· z celého projektu v levém horním rohu na poloºce Results → Current Project a ozna£ením scéná°·, které se mezi sebou budou porovnávat. Výb¥r statistik je moºné provád¥t v globálních statistikách sít¥ tzv. Global Statistics, které vyobrazují celkový provoz dané sluºby, p°i£emº statistiky na konkrétních prvcích lze zobrazit v tzv. Object Statistics, které poskytují konkrétn¥j²í informace o provozu sluºby na konkrétním uzlu nebo stanici. 56 NGN PRO VUT A VB-TUO Obrázek 7.6: Provoz stanice Voice1 Nastavit lze statistiky p°ijatých a odeslaných dat stanicí, zpoºd¥ní, jitter, po£et opakování ºádostí o spojení (tzv.retransmise) nebo celková analýza protokol·, pouºitých pro sluºby. Tyto statistiky se nacházejí v levé dolní oblasti jiº otev°ených výsledk· simulace. Analýzou výsledk· v obr. 7.6 zjistíme, ºe maximální dosaºena p°enosová rychlost uploadu na rádiovém rozhraní stanice Voice1 a UTRAN sít¥, se pohybovala okolo 680 B/s. Dle provedeného nastavení prolu sluºby Voice (Voice), je zahájení p°enosu dat pro tuto sluºbu se£tením za£átku spu²t¥ní prolu a samotné sluºby, tzn. 120 + 5 = 125, tedy ve 125. sekund¥. Tato doba je v grafu ozna£ena písmenem A . Doba ozna£ená písmenem B vymezuje vysílací £as stanice Voice1 vzhledem k celkové simula£ní dob¥. Z toho lze odvodit, ºe celkový vysílací £as stanice Voice1 je 12 minut a 55 sekund (775 sekund)a celkový objem dat odeslaných rádiovým kanálem je 527 kB. 7.8.1 Animace sít¥ Prost°edí OPNET Modeler nabízí také n¥kolik nástroj·, pro znázorn¥ní £innosti sít¥. Tyto nástroje mohou být nápomocny p°i konkrétních aplikacích °e²ení problém·, p°i p°enosu dat sítí nebo také samotné pochopení principu vým¥ny informací mezi jednotlivými uzly sít¥ £i stanicemi. Aplikace Time Controller zobrazuje £asové hodnoty vzhledem k pohybu terminál· po nadenovaných trajektoriích. Nástroj pro 2D animaci sít¥ lze snadno spustit editací kontextového menu DES → Play 2D Animation. Kliknutím na záloºku se otev°e okno, ve kterém lze sledovat animaci £innosti sít¥, viz. obr. 7.7. Aplikaci Time Controller m·ºeme spustit v záloºce menu View → Show Time Controller. Tímto krokem je na obrazovku vyvoláno okno s £asovým ovládáním umoº¬ujícím £asové krokování pohybu terminál· po denovaných trajektoriích viz. obr. 7.8. P°í analýze pr·b¥hu samotné simulace a °e²ení problém· je velice uºite£ný DES Log, tedy nástroj logování událostí, zaznamenaných v pr·b¥hu simulace. Mohou zde být zobrazeny události r·zného charakteru od informa£ních zpráv aº po fatální chyby v komunikaci mezi uzly a stanicemi v sítí. Tento nástroj spustíme editací kontextového menu DES → Open DES Log, a kliknutím na jednotlivé události lze shlédnout podrobný p°ehled informací o události pop°ípad¥ návod k °e²ení problému, zp·sobujícího tuto událost. 57 7 OPNET MODELER Obrázek 7.7: Nástroj 2D animace £innosti sít¥ Obrázek 7.8: Aplikace Time Controller 58 NGN PRO VUT A VB-TUO 8 Queuing Theory in MATLAB SimEvents je roz²í°ení Matlab Simulinku o nástroje pro modelování a simulaci diskrétních událostních systém· s pouºitím zdroj· a server·. SimEvents mmoº¬uje modelovat událostmi °ízenou komunikaci mezi komponentami, která je vyuºita k analýze a optimalizaci zpoºd¥ní mezi dv¥ma body, propustnosti, ztrátovosti paket· a dal²ích výkonnostních charakteristik [3]. Knihovny p°eddenovaných blok·, jako jsou fronty, servery a switche umoº¬ují p°esn¥ reprezentovat námi poºadovaný systém a podle pot°eby nastavit zp·sob sm¥rování, procesní zpoºd¥ní, priorizaci a dal²í operace. Prost°ednictvím SimEvents m·ºeme navrhovat distribuované °ídicí systémy, hardwarové architektury a senzory, komunika£ní sít¥ pro letecký a automobilní pr·mysl a elektronické aplikace. M·ºeme také simulovat událostmi °ízené procesy jako spu²t¥ní naplánované události nebo fáze výrobního procesu, k ur£ení pot°ebných zdroj· a k ur£ení nedostatk·. SimEvents je sou£ástí distribuce Matlab od verze R2006a. Po instalaci se automaticky doplní do Simulink Library Browser. Vkládání jednotlivých blok· funguje metodou drag and drop . P°edtím, neº se za£ne vytvá°et model, je t°eba zm¥nit nastavení Simulinku na modelování diskrétn¥-událostních systém· p°íkazem v MATLABu simeventsstartup ('des') tento p°íkaz nastaví Simulink pro diskrétn¥-událostní simulace. Kdyº je t°eba kombinovat diskrétn¥-událostní systém se spojitým £asem, musíme pouºít hybridní nastavení simeventsstartup ('hybrid'). SimEvents zavádí do Simulink odli²ný typ propojení mezi bloky. Jedná se o entitové spojení. Od klasických signálních spojení se odli²ují jiným konektorem na vstupu i na výstupu. Zatímco klasické signální spoje musí sm¥°ovat od výstupu jednoho bloku na vstup jiného, entitové bloky mají konektory zam¥nitelné, viz. obr. 8.1. Obrázek 8.1: Entitové spojení 8.1 DES DES (Discrete Event Simulation) je diskrétn¥-událostní simulace nebo událostní simulace, která dovoluje p°echod stavu systému v závislosti na asynchronních diskrétních jevech, které se nazývají událostmi. Pro srovnání, simulace formáln¥ zaloºená na diferenciálních rovnicích, ve kterých je £as závislou prom¥nnou, je £asov¥ zaloºená simulace, protoºe p°echod stavu závisí od £asu. Simulink je navrºen pro £asov¥ zaloºené simulace, zatímco SimEvents je navrºen pro diskrétn¥-událostní simulace. Na²e volba r·zných zp·sob· simulace m·ºe záviset na jednotlivých jevech, které zkoumáme, nebo na zp·sobu výb¥ru, jak je zkoumat. Uvedeme n¥kolik p°íklad· pro ilustraci t¥chto rozdíl·: P°edpokládejme, ºe nás zajímá trajektorie vzlétajícího letadla. V tomto p°ípad¥ pouºijeme £asov¥ zaloºenou simulaci, protoºe hledání trajektorie vyºaduje °e²ení diferenciálních rovnic. 59 8 QUEUING THEORY IN MATLAB V jiné situaci p°edpokládejme, ºe nás zajímá, jak dlouho pr·m¥rn¥ £eká letadlo, kdyº p°ijde na °adu a m·ºe pouºít vzletovou dráhu. Av²ak nezajímá nás do detail· pohyb letadla, které má volnou dráhu a m·ºe vzlétnout. M¥li bychom pouºít diskrétn¥-událostní simulaci, ve které podstatné události zahrnují p°íchod nového letadla na vzletovou dráhu a uvoln¥ní vzletové dráhy na vzlet letadla, které £eká v °ad¥. A na konec p°edpokládejme, ºe nás zajímá, jak dlouho letadlo £eká v °ad¥, ale chceme do detail· namodelovat vzlet namísto pouºití statistického rozd¥lení na namodelování £asu, který kaºdé letadlo pot°ebuje k pouºití vzletové dráhy. V tomto p°ípad¥ bude nejlep²í pouºít kombinaci £asov¥ zaloºených a diskrétn¥-událostních simulací, kde £asov¥ zaloºený aspekt °ídí detaily vzletu letadel a diskrétn¥ událostní aspekt chování letadel £ekajících v °ad¥. 8.2 Entity Diskrétn¥-událostní simulace typicky zahrnuje diskrétní poloºky. Podle denice se tyto poloºky v SimEvents nazývají entity. Entity mohou procházet p°es sí´ zásobník·, server·, bran a p°epína£· b¥hem simulace. Entity mohou obsahovat data, která se v SimEvents nazývají atributy. V diskrétn¥-událostních simulacích je událost okamºitý diskrétní incident, který m¥ní stav prom¥nných, výstupy a výskyt dal²ích událostí. Podporované události v SimEvents jsou: postup entity z jednoho bloku do druhého, ukon£ení sluºby na entit¥ v serveru, nulové k°íºení signálu p°ipojeného do bloku, který je kongurován reagovat na nulové k°íºení; tyto události se také nazývají spou²t¥cími (náb¥ºnými) hranami, volání funkce, která je diskrétním vyvoláním poºadavku procházejícího z bloku do bloku speciálním signálem zvaným Functioncall signal (signál volající funkci); volání funkce je doporu£enou moºností, jak ud¥lat Stateow bloky a bloky v knihovn¥ Simulink odpovídající na asynchronní zm¥ny stav·. Události v simulaci mohou záviset jedna na druhé. Jedna událost m·ºe být základní p°í£inou dal²í události. P°íchod první entity v zásobníku zap°í£iní, ºe délka zásobníku se zm¥ní z 0 na 1. Jedna událost m·ºe spustit vznik dal²í události, ale pouze za ur£itých podmínek. Dokon£ení sluºby entity spustí p°íchod entity ze serveru, ale pouze v p°ípad¥, ºe následující blok je schopen p°ijmout p°íchod této entity. V tomto p°ípad¥ jedna událost umoºní vznik druhé události, ale formáln¥ se to nestává. Události nemají grackou reprezentaci. Jejich výskyt m·ºeme posoudit pozorováním jejich d·sledk· pouºitím Instantaneous Event Counting Scope bloku (blok okamºitého po£ítání událostí) nebo nástroje vytvá°ejícího záznamy o událostech. Oblasti vyuºití: Automatické °ízení a regulace Zpracování signálu a komunikace 8.3 Sou£ásti SimEvents Knihovna SimEvents obsahuje n¥kolik modul·, které jsou p°ehledn¥ rozt°íd¥ny v pod-knihovnách SimEvents, viz. obr. 8.2. 60 NGN PRO VUT A VB-TUO Obrázek 8.2: Moduly v SimEvents 8.4 Simulace systému M/M/5 8.4.1 Zadání Vytvá°ený model bude simulovat obsluhový systém s nekone£nou frontou a p¥ti linkami. Analyzujte dobu strávenou poºadavkem v systému, její hodnotu bude vykreslete do grafu. 8.4.2 e²ení Pro modelování tohoto systému vyuºijeme jako hlavní stavební prvek blok N-Server, který p°edstavuje blok N totoºných linek pracujících paraleln¥, v na²em p°ípad¥ N=5. Pokud bychom cht¥li simulovat linky s r·znými parametry, bylo by pot°eba vyuºit N blocks Single Server a kaºdému nastavit parametry samostatn¥, viz. obr. 8.3. Obrázek 8.3: Blokový diagram sestavený v SimEvents pro systém M/M/5 Blok Event-Based Random Number náhodn¥ vybírá jednu z linek, kterému se p°i°adí p°icházející poºadavek. Dále pouºijeme blok FIFO Queue, který simuluje frontu typu FIFO (First In First Out). Dal²ími pouºitími bloky jsou generátor a analýza entit. Entity v tomto p°ípad¥ reprezentují poºadavky vstupující do systému a jak je moºno vid¥t z popisku generátoru je jejich generovaní exponenciální. Po pr·chodu systémem je entita zachycena blokem Entity Sink. 61 8 QUEUING THEORY IN MATLAB Pro m¥°ení doby, kterou poºadavek strávil v systému, slouºí bloky Start Timer a Read Jakmile je vygenerována n¥jaká entita (poºadavek), p°i pr·chodu blokem Start Timer spustí m¥°ení £asu, které je pro danou entitu ukon£eno aº po pr·chodu blokem Read Timer. Blok Signal Scope zaznamenává jednotlivé £asy strávené poºadavkem v systému, viz. obr. 8.4. Timer. Obrázek 8.4: Pr·m¥rná £ekací doba poºadavku v systému Hodnoty získané simulací m·ºeme porovnat s teoretickými hodnotami vypo£tenými pomoci vzorc· pro M/M/n systémy. P°i simulaci byla nastavena intenzita vstupního toku λ = 0.5 a intenzita obsluhy µ = 0.2. Výpo£tem provozního zatíºení a následn¥ vyuºitím p°íslu²ných vzorc· je moºno zjistit pr·m¥rný £as stráveny poºadavkem v systému. Zatíºení systému: ρ= λ = 0.5 m·µ Po£áte£ní pravd¥podobnost: " p0 = 1 + m−1 X n=1 (mρ)n (mρ)m 1 + · n! m! 1−ρ #−1 = 0.0801 Pr·m¥rná doba strávená poºadavkem v systému: E[S] = 62 1 1 (mρ)m p0 + · · = 5.26 s µ µ m! m(1 − ρ)2 NGN PRO VUT A VB-TUO 9 OMNeT++ OMNeT++ je simula£ní nástroj zaloºený na C++, je ²í°en pod GNU GPL licencí pro nekomer£ní ú£ely je zcela zdarma a samotné vývojové prost°edí (IDE) je zaloºené na platform¥ Eclipse. OMNeT++ je primárn¥ ur£en k simulaci komunika£ních sítí, ale díky jeho exibilní architektu°e se dá vyuºít i v mnoha jiných odv¥tvích. [4, 34] 9.1 Instalace Popis instalace je pro verzi prost°edí OMNeT++ 4.4.1 pro systém Windows. Postup instalace star²ích verzí nebo verzí pro jiné opera£ní systémy se m·ºe li²it. 1. Na ociálních stránkách projektu <http://omnetpp.org> stáhneme nejnov¥j²í verzi simula£ního prost°edí OMNeT++ pro systémy Windows. 2. Umístíme a rozbalíme staºený soubor omnetpp-<ver>-src-windows.zip (kde <ver> ur£uje verzi simulátoru) tam, kde chceme OMNeT++ nainstalovat. Cesta k rozbalenému archivu by nem¥la obsahovat mezery (nap°. c:/omnetpp-4.4.1/). 3. P°esuneme se do nov¥ rozbalené sloºky (nap°. omnetpp-4.4.1 ), která obsahuje sloºky images, mys, aj. a soubory mingwenv.cmd, congure, a dal²í. 4. Spustíme soubor mingwenv.cmd otev°e se okno programu MINGW32, ur£ené pro konguraci prost°edí OMNeT++. 5. Zadáme p°íkaz ./configure a poté p°íkaz make prob¥hne kongurace prost°edí. 6. Simula£ní prost°edí po úsp¥²né konguraci spustíme souborem omnetpp.exe (nap°. C:/omnetpp-4.4.1/ide/omnetpp.exe). Zobrazí se nám uvítací okno, kde m·ºeme zvolit, kam chceme pokra£ovat. 9.2 INET Framework je roz²í°ení pro simula£ní nástroj OMNeT++. Obsahuje mnoho modul·, jako nap°íklad sm¥rova£e nebo sí´ové protokoly, slouºící pro simulaci po£íta£ových sítí v simulátoru. S vyuºitím INETu tak odpadá nutnost implementovat vlastnoru£n¥ jednotlivé prvky/£ásti sít¥. Jeho sou£ástí jsou i sm¥rovací protokoly OSPF, BGP a v nové verzi (INET 2.3.0) je podporován i protokol RIP. [2] Framework INET 9.2.1 Postup instalace INETu Jedním z moºných postup·, jak importovat INET do simulátoru, je jeho automatická instalace. Simulátor tuto moºnost nabídne po jeho prvním spu²t¥ní, viz. obr. 9.1. Problémem je v²ak fakt, ºe nemusí být nainstalována nejaktuáln¥j²í verze INETu a tudíº nemusí být dostupné v²echny moduly nap°íklad protokol RIP. Druhým zp·sobem instalace INETu je ru£ní import do OMNeTu. Toto se provede následujícím zp·sobem, viz. obr. 9.2. 1. Stáhneme nejnov¥j²í verzi modulu INET ze stránek projektu. 63 9 OMNET++ Obrázek 9.1: Automatická instalace modulu INET Obrázek 9.2: Importování modulu INET 64 NGN PRO VUT A VB-TUO 2. V prost°edí OMNeT++ importujeme modul File → Import → General → Existing Projects into Workspace → Select archive le → Zadáme cestu k souboru modulu INET → Tla£ítkem Finish potvrdíme import 3. Sestavíme modul INET v OMNeTu klikneme pravým tla£ítkem my²i na projekt INET a zvolíme Build project. 4. Prob¥hne p°eklad celého frameworku 9.3 Aplikace sm¥rovacího protokolu OSPF 9.3.1 Zadání Vytvo°te v simula£ním prost°edí OMNeT++ po£íta£ovou sí´ podle obr. 9.3 Nakongurujte sí´ pomoci modulu IPv4NetworkConfigurator Jako sm¥rovací protokol pouºijte protokol OSPF Vytvo°te v síti komunikaci p°es UDP protokol Vytvo°te události na p°eru²ení linky a její op¥tovné vytvo°ení a sledujte chování sm¥rova£· Obrázek 9.3: Architektura po£íta£ové sít¥ pro simulaci 9.3.2 e²ení Jako první zaloºíme v OMNeTu nový projekt: File → New → OMNeT++ Project. Projekt pojmenujeme OSPFNet. Abychom v na²em projektu mohli pouºívat modely z frameworku INET, je nutné p°idat referenci na INET: Klikneme pravým tla£ítkem my²i na projekt → Properties → Project references → za²krtneme INET → OK. [16] 65 9 OMNET++ Denice sít¥ v NED souboru http Dal²ím krokem je vytvo°ení samotné sít¥. K tomuto ú£elu slouºí soubory NED (Network ve kterém specikujeme detaily topologie. Vytvo°íme tedy nový soubor s p°íponou .ned. Pravým kliknutím my²í na ná² projekt -> New -> Network Description File. Název na²eho souboru zvolíme OSPFNet.ned. Soubory NED m·ºeme editovat jak v grackém reºimu, tak m·ºeme upravovat samotný zdrojový kód. P°epínat mezi ob¥ma reºimy lze v levém dolním rohu editoru, viz. obr. 9.4. Pro na²e pot°eby budeme pouºívat textový editor a zdrojový kód. DEscription), Obrázek 9.4: Výb¥r mezi grackým a textovým editorem Máme tedy vytvo°ený NED soubor. D°íve, neº za£neme vytvá°et topologii, musíme importovat modely, které budeme v síti pot°ebovat jsou to t°eba modely StandardHost, OSPFRouter nebo IPv4NetworkConfigurator. Poté m·ºeme p°ejít k samotné tvorb¥ sít¥. Nejd°íve si vytvo°íme sí´, kterou nazveme simpleOSPF. Pokra£ujeme denicí kanálu (Channel ), který ur£uje vlastnosti linek mezi jednotlivými prvky sít¥. Následuje vytvo°ení zmi¬ovaných sí´ových prvk· sm¥rova£·, p°epína£· a po£íta£·. D·leºitou sou£ástí je také model configurator, který má na starosti nap°íklad nastavování IP adres nebo cest. Aby byla celá sí´ reálná, pouºijeme je²t¥ modely LifecycleCotroller a ScenarioManager, pomocí kterých m·ºeme naplánovat t°eba vypnutí sm¥rova£e a donutit tak OSPF ke konvergenci. A jako poslední denujeme spojení (connections ) mezi za°ízeními. Architektura sít¥ je na obr. 9.5. Zdrojový kód .NED souboru je následující: import import import import 66 inet.nodes.ethernet.EtherSwitch; //import model· inet.nodes.inet.StandardHost; inet.nodes.ospfv2.OSPFRouter; inet.util.ThruputMeteringChannel; NGN PRO VUT A VB-TUO Obrázek 9.5: Architektura sít¥ import inet.networklayer.autorouting.ipv4.IPv4NetworkConfigurator; import inet.world.scenario.ScenarioManager; import inet.base.LifecycleController; network simpleOSPF { //sí´ s názvem simpleOSPF types: //kanál C, který pouºijeme p°i propojování za°ízení channel C extends ThruputMeteringChannel { delay = 0.1us; datarate = 100Mbps; thruputDisplayFormat = "#N"; } submodules: R1: OSPFRouter { gates: ethg[3]; } //sm¥rova£ má 3 ethernetové rozhraní R2: OSPFRouter {gates: ethg[3]; } R3: OSPFRouter {gates: ethg[3]; } H1: StandardHost {gates: ethg[1]; } H2: StandardHost {gates: ethg[1]; } H3: StandardHost {gates: ethg[1]; } SW1: EtherSwitch {gates: ethg[2]; } SW2: EtherSwitch {gates: ethg[2]; } SW3: EtherSwitch {gates: ethg[2]; } scenarioManager: ScenarioManager {} lifecycleController: LifecycleController {} //configurator automatické nastavení sít¥ configurator: IPv4NetworkConfigurator { parameters: config = xml("<config>"+ "<interface among='H1 R1' address='192.168.0.x' netmask='255.255.255.0' />"+ "<interface among='H2 R2' address='192.168.1.x' netmask='255.255.255.0' />"+ "<interface among='H3 R3' address='192.168.2.x' netmask='255.255.255.0' />"+ "<interface among='R1 R2' address='10.0.0.x' netmask='255.255.255.252' />"+ "<interface among='R1 R3' address='10.0.0.x' netmask='255.255.255.252' />"+ "<interface among='R2 R3' address='10.0.0.x' netmask='255.255.255.252' />"+ 67 9 OMNET++ "<route hosts='H*' destination='*' netmask='0.0.0.0' interface='eth0' />"+ "</config>"); addStaticRoutes = false; addDefaultRoutes = false; } connections: R1.ethg[0] R2.ethg[0] R3.ethg[0] R1.ethg[1] R3.ethg[2] <--> <--> <--> <--> <--> C C C C C <--> <--> <--> <--> <--> SW1.ethg[0]; SW1.ethg[1] <--> SW2.ethg[0]; SW2.ethg[1] <--> SW3.ethg[0]; SW3.ethg[1] <--> R2.ethg[1]; R3.ethg[1] <--> C R2.ethg[2]; C <--> H1.ethg[0]; C <--> H2.ethg[0]; C <--> H3.ethg[0]; <--> R1.ethg[2]; Inicializa£ní soubor omnetpp.ini Inicializa£ní soubor s p°íponou ini slouºí k nastavení parametr· simulace. M·ºeme zde vytvá°et nap°íklad události, které se spustí v ur£itý £as simulace. My vytvo°íme jednoduchou UDP komunikaci. P°idáme tedy do na²eho projektu ini soubor. Pravým kliknutím my²í na ná² projekt → New → Initialization File(ini) a pojmenujeme ho omnetpp.ini. Op¥t máme dv¥ moºnosti, jak upravovat ini soubory pomocí formulá°e nebo úpravou zdrojového kódu. Pro na²i sí´ nastavíme název sít¥, p°idáme odkaz na kongura£ní xml soubor pro sm¥rovací protokol OSPF. V dal²í £ásti souboru vygenerujeme n¥jaký sí´ový provoz UDP zprávy, které se budou posílat v pravidelných intervalech. A nakonec na£teme nastavení scenarioManageru zase z xml souboru. [General] network = simpleOSPF **.ospf.ospfConfig = xmldoc("Config.xml") **.numUdpApps = 2 **.udpApp[0].typename = "UDPBasicApp" **.udpApp[0].destPort = 1234 **.udpApp[0].messageLength = 32 bytes **.udpApp[0].sendInterval = 0.1s **.udpApp[0].startTime = 4s **.H2.udpApp[0].destAddresses = "H1" **.H1.udpApp[0].destAddresses = "H2" **.udpApp[1].typename = "UDPEchoApp" **.udpApp[1].localPort = 1234 *.scenarioManager.script = xmldoc("scenario.xml") Kongura£ní soubor protokolu OSPF Pro nastavení sm¥rování na v²ech sm¥rova£ích m·ºeme pouºít pouze jeden xml soubor. Vytvo°íme ho podobným zp·sobem, jako jsme do projektu p°idávali ini a ned soubory: Pravým kliknutím my²í na ná² projekt → New → File. Soubor pojmenujeme Cong.xml. Denujeme v n¥m oblasti OSPF, v na²em p°ípad¥ pouze jedinou oblast 0.0.0.0, a také nap°íklad nastavíme rozhraní sm¥rova£·, £i jejich cost. <?xml version="1.0"?> <OSPFASConfig > <!-- Areas --> 68 NGN PRO VUT A VB-TUO <Area id="0.0.0.0"> <AddressRange address="H1" mask="H1" status="Advertise" /> <AddressRange address="H2" mask="H2" status="Advertise" /> <AddressRange address="H3" mask="H3" status="Advertise" /> <AddressRange address="R1>R2" mask="R1>R2" status="Advertise" <AddressRange address="R2>R1" mask="R2>R1" status="Advertise" <AddressRange address="R1>R3" mask="R1>R3" status="Advertise" <AddressRange address="R2>R3" mask="R2>R3" status="Advertise" <AddressRange address="R3>R2" mask="R3>R2" status="Advertise" <AddressRange address="R3>R1" mask="R3>R1" status="Advertise" </Area> /> /> /> /> /> /> <!-- Routers --> <Router name="R1" RFC1583Compatible="true"> <PointToPointInterface ifName="eth1" areaID="0.0.0.0" interfaceOutputCost="1" /> <PointToPointInterface ifName="eth2" areaID="0.0.0.0" interfaceOutputCost="1" /> <BroadcastInterface ifName="eth0" areaID="0.0.0.0" interfaceOutputCost="2" routerPriority="2" /> </Router> <Router name="R2" RFC1583Compatible="true"> <PointToPointInterface ifName="eth1" areaID="0.0.0.0" interfaceOutputCost="2" /> <PointToPointInterface ifName="eth2" areaID="0.0.0.0" interfaceOutputCost="1" /> <BroadcastInterface ifName="eth0" areaID="0.0.0.0" interfaceOutputCost="1" routerPriority="2" /> </Router> <Router name="R3" RFC1583Compatible="true"> <PointToPointInterface ifName="eth1" areaID="0.0.0.0" interfaceOutputCost="4" /> <PointToPointInterface ifName="eth2" areaID="0.0.0.0" interfaceOutputCost="4" /> <BroadcastInterface ifName="eth0" areaID="0.0.0.0" interfaceOutputCost="1" routerPriority="2" /> </Router> </OSPFASConfig> Naplánování událostí v simulaci V simulaci m·ºeme naplánovat ur£ité události, které se spustí v ur£itý £as. Jedním zp·sobem, jak n¥jakou událost naplánovat, je pouºití scenarioManageru. Ten jsme denovali v ned souboru, v ini souboru jsme zadali název souboru s nastavením. Vytvo°íme tedy dal²í xml: Pravým kliknutím my²í na ná² projekt → New → File. Tentokrát ho pojmenujeme scenario.xml a v n¥m vytvo°íme 2 události - v £ase t=100 zru²íme linku mezi R1 a R2 a v £ase t=200 linku mezi R1 a R2 obnovíme. <scenario> <at t="100"> <disconnect src-module="R1" src-gate="ethg$o[1]" /> <disconnect src-module="R2" src-gate="ethg$o[1]" /> </at> <at t="200"> <connect src-module="R1" src-gate="ethg[1]" dest-module="R2" dest-gate="ethg[1]" channel-type="inet.util.ThruputMeteringChannel"> <param name="delay" value="0.1us" /> <param name="datarate" value="100Mbps" /> <param name="thruputDisplayFormat" value='"#N"' /> 69 9 OMNET++ </connect> </at> </scenario> 9.3.3 Simulace Projekt spustíme zeleným tla£ítkem I ve vrchní li²t¥ OMNeTu. Jestliºe projekt spou²tíme poprvé, nebo do²lo od posledního spu²t¥ní k n¥jakým zm¥nám, prob¥hne nejd°íve p°eklad a aº poté se spustí simula£ní rozhraní. Po startu simulace se objeví dv¥ okna, viz. obr. 9.6. V pravé £ásti je ovládání simulace krokování, spu²t¥ní, atp. (1), dále zprávy informující o práv¥ prob¥hnutých operacích/událostech v simulaci (2) a v levé £ásti pravého okna nadcházející události (3) nap°. naplánované události sm¥rovacího protokolu, nebo události, které jsme nakongurovali d°íve v scenarioManageru. V levém okn¥ je gracké zobrazení sít¥ a aktuální d¥ní (4). Obrázek 9.6: Ovládání simulace Na jednotlivé prvky v síti m·ºeme poklepat levým tla£ítkem my²i a zobrazit tak jejich parametry a vlastnosti. Jestliºe t°eba chceme zobrazit sm¥rovací tabulku sm¥rova£e R1, poklepeme my²í na sm¥rova£, zobrazí se nám jeho vnit°ní struktura, kde tentokrát poklepeme na routing table a následn¥ na vektor Routes. Sm¥rovací tabulka je uvedena na obr. 9.7. Zatím zde jsou pouze záznamy o p°ímo p°ipojených sítích. Jakmile spustíme simulaci tla£ítkem Run, po n¥jaké dob¥ dojde ke konvergenci sít¥ a sm¥rovací tabulky, stejn¥ tak jako dal²í parametry sít¥, se zm¥ní. Na obr. 9.8 m·ºeme vid¥t událost, která byla v po°adí 26. a nastala v £ase T. lo o vyslání Hello paketu ze sm¥rova£e R2 rozhraním eth0. Cílová IP adresa byla 224.0.0.5. Dal²í událost, kterou si rozebereme, je na²e plánované odstavení linky. Najdeme si tedy událost v okn¥ s událostmi scenario-event, at T=100, klikneme pravým tla£ítkem a zvolíme moºnost Express run until message . Tím se simulace znovu spustí a zastaví se t¥sn¥ p°ed vykonáním zvolené události. Podíváme se, co obsahuje sm¥rovací tabulka sm¥rova£e R1, viz. obr. 9.9. Jestliºe se v simulaci posuneme o jeden krok, dojde k odpojení linky a tím p°estanou být n¥které cesty platné. Sm¥rova£e tento fakt zaregistrují a za£nou aktualizovat své tabulky. Posuneme tedy simulaci o n¥jaký £as vp°ed a znovu se podíváme na sm¥rovací tabulku, viz. obr. 9.10. 70 NGN PRO VUT A VB-TUO Obrázek 9.7: Sm¥rovací tabulka sm¥rova£e R1 Obrázek 9.8: Událost £. 26 Obrázek 9.9: Sm¥rovací tabulka sm¥rova£e R1 p°ed odpojením linky 71 9 OMNET++ Obrázek 9.10: Sm¥rovací tabulka sm¥rova£e R1 po odpojení linky Kdyº porovnáme tabulky p°ed a po odpojení linky, zjistíme, ºe n¥které cesty pro sm¥rování paket· se zm¥nily. Konvergence tedy prob¥hla korektn¥. 9.4 Aplikace sm¥rovacího protokolu BGP 9.4.1 Zadání Vytvo°te v simulátoru OMNeT++ po£íta£ovou sí´ podle obr. 9.11 Mezi sm¥rova£i RA a RB aplikujte sm¥rovací protokol BGP V krajních sítích aplikujte protokol OSPF Vygenerujte UDP provoz Obrázek 9.11: Architektura po£íta£ové sít¥ pro simulaci 9.4.2 e²ení Zaloºení nového projektu Jako první zaloºíme v OMNeTu nový projekt: File → New → OMNeT++ Project. Projekt 72 NGN PRO VUT A VB-TUO pojmenujeme BGPNet. Abychom v na²em projektu mohli pouºívat modely z frameworku INET, je nutné p°idat referenci na INET: Klikneme pravým tla£ítkem my²i na projekt → Properties → Project references → za²krtneme INET → OK. Denice sít¥ v NED souboru Dal²ím krokem je vytvo°ení samotné sít¥. K tomuto ú£elu slouºí soubory NED (Network DEscription), ve kterém specikujeme detaily topologie. Vytvo°íme tedy nový soubor s p°íponou .ned : Pravým kliknutím my²í na ná² projekt → New → Network Description File. Název na²eho souboru zvolíme BGPNet.ned. Soubory NED m·ºeme editovat jak v grackém reºimu, tak m·ºeme upravovat samotný zdrojový kód. P°epínat mezi ob¥ma reºimy lze v levém dolním rohu editoru. Pro na²e pot°eby budeme pouºívat textový editor a zdrojový kód. Máme tedy vytvo°ený NED soubor. D°íve, neº za£neme vytvá°et topologii, musíme importovat modely, které budeme v síti pot°ebovat jsou to t°eba modely StandardHost, OSPFRouter nebo BGPRouter. Poté m·ºeme p°ejít k samotné tvorb¥ sít¥. Nejd°íve si vytvo°íme sí´, kterou nazveme simpleBGP. Pokra£ujeme denicí kanálu (Channel), který ur£uje vlastnosti linek mezi jednotlivými prvky sít¥. Následuje vytvo°ení zmi¬ovaných sí´ových prvk· sm¥rova£·, p°epína£· a po£íta£·. D·leºitou sou£ástí je také model congurator, který má na starosti nap°íklad nastavování IP adres nebo cest. A jako poslední denujeme spojení (connections ) mezi za°ízeními. Architektura sít¥ s podporou BGP protokolu je uvedena na obr. 9.12. Obrázek 9.12: Architektura po£íta£ové sít¥ s podporou BGP v prost°edí OMNeT Zdrojový kód .ned pro vytvo°ení architektury sít¥: import import import import import import inet.nodes.bgp.BGPRouter; inet.nodes.ethernet.EtherSwitch; inet.util.ThruputMeteringChannel; inet.networklayer.autorouting.ipv4.IPv4NetworkConfigurator; inet.nodes.inet.StandardHost; inet.nodes.ospfv2.OSPFRouter; network simpleBGP { types: channel C extends ThruputMeteringChannel { delay = 0.1us; datarate = 100Mbps; 73 9 OMNET++ } thruputDisplayFormat = "#N"; submodules: RA: BGPRouter {gates: pppg[1]; ethg[1]; } RB: BGPRouter {gates: pppg[1]; ethg[1]; } R1: OSPFRouter {gates: ethg[2]; } R2: OSPFRouter {gates: ethg[2]; } SW1: EtherSwitch {gates: ethg[2];} SW2: EtherSwitch {gates: ethg[2];} H1: StandardHost {gates: ethg[1];} H2: StandardHost {gates: ethg[1];} configurator: IPv4NetworkConfigurator { @display("p=94,54"); config = xmldoc("conf.xml"); addStaticRoutes = false; addDefaultRoutes = false; addSubnetRoutes = false; } connections: RA.pppg[0] <--> C <--> RB.pppg[0]; RA.ethg[0] <--> C <--> R1.ethg[0]; RB.ethg[0] <--> C <--> R2.ethg[0]; R1.ethg[1] <--> C <--> SW1.ethg[0]; R2.ethg[1] <--> C <--> SW2.ethg[0]; SW1.ethg[1] <--> C <--> H1.ethg[0]; SW2.ethg[1] <--> C <--> H2.ethg[0]; Inicializa£ní soubor omnetpp.ini Inicializa£ní soubor s p°íponou ini slouºí k nastavení parametr· simulace. M·ºeme zde vytvá°et nap°íklad události, které se spustí v ur£itý £as simulace. My vytvo°íme jednoduchou UDP komunikaci. P°idáme tedy do na²eho projektu ini soubor: Pravým kliknutím my²í na ná² projekt → New → Initialization File(ini) a pojmenujeme ho omnetpp.ini. Op¥t máme dv¥ moºnosti, jak upravovat ini soubory pomocí formulá°e nebo úpravou zdrojového kódu. Pro na²i sí´ nastavíme název sít¥, p°idáme odkaz na kongura£ní xml soubor pro sm¥rovací protokoly BGP a OSPF. V dal²í £ásti souboru vygenerujeme n¥jaký sí´ový provoz UDP zprávy, které se budou posílat v pravidelných intervalech. Výsledný zdrojový kód ini souboru: [General] network = simpleBGP **.bgp.dataTransferMode = "object" # OSPF configuration **.ospfConfig = xmldoc("OSPFconf.xml") # bgp settings **.bgpConfig = xmldoc("BGPconf.xml") **.numUdpApps = 2 **.udpApp[0].typename = "UDPBasicApp" **.udpApp[0].destPort = 1234 **.udpApp[0].messageLength = 32 bytes **.udpApp[0].sendInterval = 0.1s 74 NGN PRO VUT A VB-TUO **.udpApp[0].startTime = 4s **.H2.udpApp[0].destAddresses = "H1" **.H1.udpApp[0].destAddresses = "H2" **.udpApp[1].typename = "UDPEchoApp" **.udpApp[1].localPort = 1234 Kongura£ní soubor protokolu OSPF Pro nastavení sm¥rování na v²ech sm¥rova£ích m·ºeme pouºít pouze jeden xml soubor. Vytvo°íme ho podobným zp·sobem, jako jsme do projektu p°idávali ini a ned soubory: Pravým kliknutím my²í na ná² projekt → New → File. Soubor pojmenujeme OSPFconf.xml. Denujeme v n¥m oblasti OSPF, 0.0.0.1 a 0.0.0.2, také nastavíme rozhraní sm¥rova£·. <?xml version="1.0"?> <OSPFASConfig> <Area id="0.0.0.1"> <AddressRange address="10.10.10.4" mask="255.255.255.252" status="Advertise" /> </Area> <Area id="0.0.0.2"> <AddressRange address="10.10.10.8" mask="255.255.255.252" status="Advertise" /> </Area> <Router name="R1" RFC1583Compatible="true"> <PointToPointInterface ifName="eth0" areaID="0.0.0.1" interfaceOutputCost="10" /> <ExternalInterface ifName="eth1" advertisedExternalNetworkAddress="192.168.1.0" advertisedExternalNetworkMask="255.255.255.0" externalInterfaceOutputCost="10" externalInterfaceOutputType="Type2" forwardingAddress="0.0.0.0" externalRouteTag="0x00" /> </Router> <Router name="RA" RFC1583Compatible="true"> <PointToPointInterface ifName="eth0" areaID="0.0.0.1" interfaceOutputCost="10" /> </Router> <Router name="R2" RFC1583Compatible="true"> <PointToPointInterface ifName="eth0" areaID="0.0.0.2" interfaceOutputCost="10" /> <ExternalInterface ifName="eth1" advertisedExternalNetworkAddress="192.168.2.0" advertisedExternalNetworkMask="255.255.255.0" externalInterfaceOutputCost="10" externalInterfaceOutputType="Type2" forwardingAddress="0.0.0.0" externalRouteTag="0x00" /> </Router> <Router name="RB" RFC1583Compatible="true"> <PointToPointInterface ifName="eth0" areaID="0.0.0.2" interfaceOutputCost="10" /> </Router> </OSPFASConfig> Kongura£ní soubor protokolu BGP V dal²í fázi je nutno nastavit protokol BGP. Vytvo°íme dal²í kongura£ní xml soubor BGPconf.xml. Nastavíme Autonomní systémy a také parametry sm¥rovacího protokolu £asova£e. <?xml version="1.0" encoding="ISO-8859-1"?> <BGPConfig> <TimerParams> <connectRetryTime> 120 </connectRetryTime> <holdTime> 180 </holdTime> <keepAliveTime> 60 </keepAliveTime> <startDelay> 15 </startDelay> </TimerParams> 75 9 OMNET++ <AS id="65324"> <Router interAddr="10.10.10.1"/> <!--router RA--> </AS> <AS id="65248"> <Router interAddr="10.10.10.2"/> <!--router RB--> </AS> <Session id="1"> <Router exterAddr="10.10.10.2"/> <Router exterAddr="10.10.10.1"/> </Session> </BGPConfig> Kongura£ní soubor pro IPv4NetworkCongurator Pro IPv4NetworkCongurator pouºijeme externí soubor xml. V n¥m nastavíme jednotlivé rozhraní sí´ových prvk·. <?xml version="1.0"?> <config> <interface hosts='RA' names='ppp0' address='10.10.10.1' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='RA' names='eth0' address='10.10.10.5' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='RB' names='ppp0' address='10.10.10.2' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='RB' names='eth0' address='10.10.10.9' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='R1' names='eth0' address='10.10.10.6' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='R1' names='eth1' address='192.168.1.254' netmask='255.255.255.0' metric='1'/> <interface hosts='R2' names='eth0' address='10.10.10.10' netmask='255.255.255.252' groups='224.0.0.1 224.0.0.2 224.0.0.5' metric='1'/> <interface hosts='R2' names='eth1' address='192.168.2.254' netmask='255.255.255.0' metric='1'/> <interface hosts='H1' names='eth0' address='192.168.1.1' netmask='255.255.255.0' mtu='1500' metric='1'/> <interface hosts='H2' names='eth0' address='192.168.2.1' netmask='255.255.255.0' mtu='1500' metric='1'/> <route hosts='H*' destination='*' netmask='*' interface='eth0'/> </config> 9.4.3 Simulace Projekt spustíme zeleným tla£ítkem Run ve vrchní li²t¥ programu. Jestliºe projekt spou²tíme poprvé, nebo do²lo od posledního spu²t¥ní k n¥jakým zm¥nám, prob¥hne nejd°íve p°eklad a aº poté se spustí simula£ní rozhraní. Po startu simulace se objeví dv¥ okna, viz. obr. 9.13. V pravé £ásti je vid¥t ovládání simulace krokování, spu²t¥ní, atp. (1), dále zprávy informující o práv¥ prob¥hnutých operacích/událostech v simulaci (2). V levé £ásti pravého okna vidíme nadcházející události (3) nap°. naplánované události sm¥rovacího protokolu, nebo UDP komunikaci. V levém okn¥ pak vidíme gracké zobrazení sít¥ a aktuální procesy v síti (4). Na jednotlivé prvky v síti m·ºeme poklepat levým tla£ítkem my²i a zobrazit tak jejich parametry a vlastnosti. Jestliºe chceme zobrazit sm¥rovací tabulku BGP sm¥rova£e RA, po76 NGN PRO VUT A VB-TUO Obrázek 9.13: Ovládání simulace klepeme my²í na sm¥rova£, zobrazí se nám jeho vnit°ní struktura, kde tentokrát poklepeme na bgp a následn¥ na vektor _BGPRoutingTable. Takto zobrazíme sm¥rovací tabulku, kde zatím nevidíme ºádný záznam. Jakmile spustíme simulaci tla£ítkem Run, po ur£itém £ase si sm¥rova£e vym¥ní BGP zprávy a doplní záznamy do své sm¥rovací tabulky. Obrázek 9.14: Sm¥rovací tabulka protokolu BGP sm¥rova£e RA Na obr. 9.14 je zobrazena sm¥rovací tabulka protokolu BGP na sm¥rova£i RA. Je zde pouze jedna cesta do sít¥ 192.168.2.0/24 p°es next-hop 10.10.10.2. Sí´ je z autonomního systému 65248. Projekt bychom mohli roz²í°it o dal²í sm¥rova£e, p°idat dal²í podsít¥, nebo m·ºeme p°idat n¥jaké záloºní linky a poté n¥kterou trasu p°eru²it a sledovat konvergenci sít¥. 77 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ 10 Mobilních sít¥ a jejich zabezpe£ení Tato kapitola se zabývá bezpe£nostními problémy mobilních sítí a je zam¥°ena na analýzu bezpe£nostních rizik v rámci systému GSM. Na základ¥ analýzy technické proveditelnosti a stupni rizika takovýchto útoku byly na Kated°e telekomunika£ní techniky VB-Technické univerzity v Ostrav¥ demonstrovány vybrané typy útok· [26]. Historicky lze z vývojového hlediska rozd¥lit mobilní systémy do 4 generací. Mobilní systémy, které pracovaly s analogovým signálem, jsou °azeny do 1. generace. Dal²ím vývojovým krokem jsou pak první digitální systémy 2. generace. V souvislosti s pot°ebou zvládat náro£n¥j²í datové p°enosy v mobilní síti pak vznikají systémy 3. a v sou£asnosti i 4. generace [14]. 1. generace - analogové mobilní systémy 2. generace - GSM 3. generace - UMTS 4. generace - LTE Obecn¥ se v²ak lze v r·zných publikacích setkat i s neociálními mezistupni mezi jednotlivými vý²e popsanými generacemi (nap°. 2.5 generace ozna£ující GPRS, pop°. 3.5 generace pro technologii HSDPA). Stru£n¥ budou v následujících podkapitolách popsány systémy první, t°etí a £tvrté generace. Pro pot°eby praktické £ásti je pak podrobn¥ji popsána funk£nost systému druhé generace GSM vzhledem k praktickému vybavení, na kterém mohly být provedeny experimenty. 10.1 1. generace První p°edch·dci mobilních telefonních systém· za£ali vznikat v pr·b¥hu 70. let 20. století. Ve v¥t²in¥ p°ípad· se jednalo o komer£ní sluºby roz²i°ující moºnosti p°ipojení ke klasické ve°ejné telefonní síti pomocí bezdrátových za°ízení. Mobilní stanice byly v¥t²inou montovány do osobních a nákladních automobil· z d·vodu svých velkých rozm¥r· a nadm¥rné hmotnosti. Systémy 1. generace jsou n¥kdy také nazývány analogovými telekomunika£ní systémy. Mezi nejroz²í°en¥j²í zástupce této generace pat°il systém NMT (Nordic Mobile Telephony) a systémy AMPS a TACS [14]. V t¥chto systémech je obvykle analogový signál modulován na nosné frekvence v rozmezí 250 aº 450 MHz (u NMT 900 pak 900 MHz). Lídrem ve vývoji mobilních sítí 1. generace byly skandinávské zem¥ Norsko, Finsko a védsko, jelikoº se nap°íklad u NMT jednalo o bezplatn¥ p°ístupnou specikaci, do²lo krátce po nasazení do provozu k podstatnému roz²í°ení (v roce 1985 ve Skandinávii 110 tis. uºivatel·) [14]. NMT Bu¬ky systému NMT mají velikost od 2 do 30 km. Men²í bu¬ky se vyuºívají ve m¥stech k navý²ení kapacity sou£asn¥ provád¥ných hovor· [29]. Pro obousm¥rnou komunikaci je u NMT vyuºito pln¥ duplexního provozu, coº znamená, ºe b¥hem hovoru dochází k p°ijímání i vysílání signálu sou£asn¥. Automobilové stanice mají vysílací výkon aº 15 W (NMT-450) resp. 6 W (NMT-900), ru£ní mobilní stanice pak do 1 wattu. Hlavní výhoda NMT oproti p°edchozím komunika£ním systém·m je podpora p°echázení mezi základnovými stanicemi, podpora pro mezinárodní roaming a specikace ú£tování p°ímo ve standardu [29]. 78 NGN PRO VUT A VB-TUO V p·vodní verzi NMT nebylo pouºito ºádné bezpe£nostní kódování p°ená²eného hlasového signálu, coº m¥lo za následek velice jednoduchou moºnost zneuºití pomocí libovolného rádiového p°ijíma£e pracujícího na dané frekvenci. Snaha o zvý²ení bezpe£nosti hovoru vedla k vypu²t¥ní NMT pásem z rozsahu p°ijíma£·[29]. Toto °e²ení je v²ak z pohledu naru²itele sít¥ naprosto banální. Proto do²lo v dal²ích vývojových verzích technické specikace k zavedení metody scramblingu. V analogovém p°enosu se jednalo o úpravu signálu p°ed vlastním vysíláním do nezabezpe£eného kanálu a poté byl na p°ijímacím za°ízení signál reverzn¥ p°eveden zp¥t do p·vodní podoby. Scrambling mohl byt provozován dv¥ma zp·soby - scrambling mezi základnovou a mobilní stanicí nebo scrambling mezi dv¥ma mobilními stanicemi [29]. 10.2 2. generace Sít¥ první generace po svém prvotním rozmachu rychle naráºejí na své hranice zp·sobené analogovou podstatou systému. Bylo pot°eba razantn¥ navý²it kapacitu sít¥, kvalitu a rozsah poskytovaných sluºeb stejn¥ jako sníºit cenu, která by umoºnila masov¥j²í roz²í°ení technologie. Mobilní systémy 2. generace p°echázejí od analogového zpracování signál· k digitálnímu. Nejroz²í°en¥j²ím digitálním systémem 2. generace se celosv¥tov¥ stalo GSM. Mezi dal²í systémy pak pat°í: ADC (IS-54, D-AMPS) - americký standart, který byl zp¥tn¥ kompatibilní s analogovým systémem AMPS [28], JDC - japonský standart nasazený od roku 1991 [28], 10.2.1 Vývoj GSM V pr·b¥hu 80. let dochází p°edev²ím v Evrop¥ k prudkému rozvoji r·znorodých analogových mobilních systém·, coº sebou p°iná²í n¥kolik podstatných problém· - neslu£itelnost jednotlivých systému, které vedou k nepouºitelnosti mobilního za°ízení za hranicemi jednotlivých zemí. Tato rozmanitost m¥la také ekonomické problémy, jelikoº výrobce za°ízení nemohl dodávat z d·vodu kompatibility své výrobky na ostatní trhy ve sjednocující se Evrop¥. Z t¥chto d·vod· byla organizací CEPT (Konference evropských správ a po²t) vytvo°ena v roce 1982 nová standardiza£ní skupina GSM (Groupe Spécial Mobile) [29], jejímº úkolem bylo vytvo°it standarty pro nový digitální systém, který by byl kompatibilní v zemích celé Evropy resp. sv¥ta. Pro vývoj nového systému byly denovány p°edev²ím následující poºadavky [29]: d·raz na nízkou cenu za°ízení a sluºeb kvalitní p°enos lidské °e£i podpora mezinárodního roamingu frekven£ní hospodárnost - maximalizace kapacity sít¥ podpora ISDN sluºeb V roce 1987 byla p°ijata první technická specikace systému GSM. V tomto roce bylo 13 zem¥mi Evropy jednotn¥ p°ijato MoU (Memorandum of Understanding) o vývoji a spolupráci jednotného evropského bu¬kového telefonního systému, díky tomuto rozhodnutí vstoupili do procesu vývoje se svými nan£ními prost°edky operáto°i, coº umoºnilo výrazn¥ zrychlit vývoj [29]. 79 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ V roce 1989 byla správa nad vývojem GSM p°evedena pod ETSI (Evropský telekomunika£ní standardiza£ní institut). V následujícím roce byl ukon£en vývoj primární specikace, která byla publikována jako GSM - Phase 1. N¥keré sou£ásti specikace GSM - Phase 1 [28]: základní hlasové a faxové/datové sluºby mezinárodní roaming p°edávání a blokování hovor· sluºba SMS SIM karta a ²ifrování První hovor v síti GSM byl proveden v roce 1991 mezi soudobým premiérem Finska Harrim Holkerim a starostkou m¥sta Tampere Kaarina Suonio [29].Na základ¥ specikace GSM - Phase 1 vznikají v Evrop¥ první komer£ní sít¥ a byla také uzav°ena první roamingová smlouva mezi Velkou Británií a Finskem. Soub¥ºn¥ se zavád¥ním GSM - Phase 1 do provozu pokra£ovala také práce na dal²ím vývoji standartu GSM. O necelé dva roky pozd¥ji p°i²la specikace GSM Phase 2, která jiº denovala roz²í°ené sluºby, jako je nap°íklad tarikace hovor· na mobilním telefonu dle impuls· sít¥, ale i identikaci volajícího, konferen£ní hovory a dal²í. Zárove¬ pln¥ integrovala dal²í frekvenci 1800 MHz (Digital Cellular System- DCS1800), která se pro systémy na bázi GSM za£ala také pouºívat. V neposlední °ad¥ GSM Phase 2 akceptovala poºadavek na integraci n¥kterých funkcí (zejména kódování °e£i enhanced full rate a half rate), které umoºnily expanzi systému GSM i ve Spojených státech na frekvenci 1900 MHz pod názvem PCS-1900 [28]. N¥které sou£ásti specikace GSM - Phase 2 [28]: GSM 1800 a 1900 MHz identikace volaného a volajícího p°idrºení hovoru a konferen£ní hovory roz²í°ené moºnosti datových sluºeb 10.2.2 Struktura sít¥ GSM Z pohledu architektury m·ºeme GSM sí´ rozd¥lit do 4 základních logických £ástí. Rozd¥lení je znázorn¥no na 10.1. Struktura sít¥ GSM se skládá z t¥chto prvk·: Mobilní stanice (MS) a t°i subsystémy: Subsystém základnových stanic (BSS), Sí´ový spojovací subsystém (NSS), a Opera£ní a podp·rný subsystém (OSS). V levé £ásti obrázku se nachází MS mobilní stanice a dále jsou zde komponenty subsystému základnových stanic BSS: 80 BSS subsystém základnových stanic BSC základnová °ídící jednotka BTS základnová radiostanice NSS sí´ový spojovací subsystém NGN PRO VUT A VB-TUO Obrázek 10.1: Struktura sít¥ GSM MSC úst°edna pro mobilní sít¥ HLR domovský loka£ní registr Následuje sí´ový spojovací subsystém NSS, který se skládá z následujících prvk·: AUC centrum autenti£nosti EIR registr mobilní komunikace VLR náv²t¥vnický loka£ní registr OSS opera£ní a podp·rný subsystém Nakonec v £ásti podp·rného subsystému OSS nalezneme tyto komponenty: OMC provozní a servisní centrum NMC centrum managementu sít¥ ADC administrativní centrum 10.3 Mobilní stanice (MS) MS jsou koncová za°ízení, které slouºí uºivateli pro p°ístup k síti. V sou£asnosti se nej£ast¥ji vyskytují v podob¥ mobilního telefonu, tabletu nebo USB modemu. Dle specikací GSM se mobilní stanicí rozumí jednak vlastní mobilní za°ízení (ME-Mobile Equipment), navíc také p°edplatitelský identika£ní modul SIM (Subscriber Identication Module) - ten umoº¬uje unikátní identikaci uºivatele v rámci celé sít¥ GSM [29]. Mobilní za°ízení (ME) - tvo°eno rádiovým p°ijíma£em/vysíla£em slouºícím ke komunikaci se základnovou stanicí, obvody pro zdrojové a kanálové kódování a dal²í sou£ásti pro 81 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ komunikaci s uºivatelem. Uºivatelské prvky mobilního za°ízení jsou displej, mikrofon, reproduktor pop°. klávesnice. Pro komunikaci s jinými za°ízeními m·ºe obsahovat obvody pro obsluhu dal²ích rozhraní (Bluetooth, NFC apod.). Mobilní za°ízení je identikováno pomocí £ísla IMEI, které je trvale uloºeno v pam¥ti [29]. Karta SIM - je nedílnou sou£ástí MS, která by byla, s výjimkou tís¬ového volání, bez této karty nepouºitelná. V pam¥ti SIM jsou uloºeny její identika£ní údaje, dále uºivatelské £ty°místné identika£ní £íslo PIN (Personal Identication Number) a nem¥nné identika£ní £íslo PUK (Personal Unblocking Key). Úkolem SIM karty je autentizace uºivatele a identikace sluºeb jemu p°ístupných. Karta je p°enosná a lze ji pouºít s libovolným mobilním telefonem [29]. SIM dále uchovává £íslo IMSI slouºící k jednozna£né identikaci uºivatele, údaje pot°ebné k autentizaci MS v·£i síti (klí£ Ki), dále n¥které do£asné údaje klí£ pro ²ifrování komunikace KC, TMSI pro do£asnou identikaci uºivatele, identikátor bu¬ky, £íselný kód oblasti LAI [28, 29]. 10.4 Subsystém základnových stanic (BSS) Jedná se o subsystém, se kterým prost°ednictvím rádiového rozhraní komunikují jednotlivé mobilní stanice. Obvykle se BSS skládá z jedné £i více základnových stanic BTS, které jsou °ízeny jedinou BSC, viz. 10.1. Systém provádí p°ekódování hovorových kanál·, p°id¥lování hovorových kanál· mobilním stanicím (MS), handover a dal²í. Systém GSM je tvo°en typicky bu¬kami o velikosti 1-3 km v pr·m¥ru (v oblastech s nízkým provozem lze vyuºít bu¬ky aº o velikosti 35 km). Bu¬ky jsou slu£ovány do v¥t²ích celk· tzv. svazk·. U systému GSM obvykle obsahuje jeden svazek 9 bun¥k, pouºívají se v²ak i svazky s men²ím po£tem bun¥k. Uvnit° kaºdé bu¬ky je umíst¥na základnová stanice (není-li vyuºito principu sektorizace). P°i sektorizaci dojde k navý²ení kapacity svazku pomocí vyuºití sm¥rových antén, kdy kaºdá vyza°uje v sektoru 120° [28, 29]. Bu¬ková struktura GSM sít¥ umoº¬uje ve srovnání s tradi£ními systémy poskytnout vy²²í kapacitu s vyuºitím minimálních rádiových prost°edk· [29]. Struktura umoº¬uje n¥kolika násobné znovu-vyuºití p°id¥lené rádiové frekvence. Z d·vod· vzájemné interference je pot°eba dodrºet vyuºití rozdílných frekvencí v sousedících bu¬kách. Bu¬ková struktura sít¥ je zobrazena na obr. 10.2. Obrázek 10.2: Bu¬ková struktura GSM 82 NGN PRO VUT A VB-TUO Základnová stanice (BTS) Za°ízení zaji²´ující bezdrátovou komunikaci mezi koncovými za°ízeními (MS) a sítí, modulaci a demodulaci signálu, kódování, opravu chyb, handover mezi sektory a m¥°ení kvality signálu. Skládá se z vysílací a p°ijímací £ásti [29]. Základnová °ídicí jednotka (BSC) stará se o provoz rádiového rozhraní. P°id¥luje a uvol¬uje rádiové kanály pro komunikaci BTS s MS, °ídí handover, frekven£ní p°eskoky. BSC zpravidla odpovídá za °ízení n¥kolika desítek BTS [29]. 10.5 Sí´ový spojovací subsystém (NSS) Sí´ový spojovací subsystém plní v systému GSM p°edev²ím spojovací funkce, obdobn¥ jako je uskute£¬uje klasická telefonní úst°edna. Tuto funkci plní v subsystému NSS mobilní radiotelefonní úst°edna MSC. Jde zde o b¥ºný typ telefonní úst°edny, která je v²ak dopln¥na o dal²í funkce plynoucí z mobility p°epojovaných ú£astnických stanic. Tato úst°edna je nad°azena nad systémem °adi£· BSC a jedna nebo více z nich plní funkci tzv. gateway MSC a umoº¬uje propojení mobilní sít¥ GSM s externími telekomunika£ními sít¥mi. Subsystém NSS dále realizuje celou °adu specických úloh, spojených s mobilitou ú£astník· [29]. Domovský loka£ní registr (HLR) - Tato v podstat¥ databáze slouºí k ukládání ve²kerých údaj· o uºivatelích sít¥ jednotlivého operátora. Obsahuje mimo jiné d·leºitá £ísla IMSI , MSISDN, zp°ístupn¥né sluºby a dále nap°íklad údaje týkající se polohy uºivatele. V síti jednoho operátora je vºdy minimáln¥ jeden HLR, m·ºe jich být i více. Sou£ástí registru HLR je i centrum autenti£nosti AuC (Authentication Centre), coº je chrán¥ná databáze, obsahující klí£e pro ov¥°ování totoºnosti ú£astník·. Toto centrum má dále na starost ²ifrovací klí£, podle kterého se ²ifruje kaºdý ú£astnický signál p°ená²ený rádiovým rozhraním. Tento klí£ je unikátní pro kaºdého ú£astníka a je prom¥nný v £ase [29]. Identika£ní registr stanic (EIR) - Na registr HLR je dále napojen identika£ní registr mobilních stanic EIR. V této databázi jsou uloºena £ísla IMEI mobilních stanic, které jsou autorizovány k pouºití v dané síti, dále £ísla ukradených MS a je zde i seznam stanic, které jsou ozna£eny jako porouchané, p°ípadn¥ nespl¬ující ur£itá poºadovaná specika [29]. Náv²t¥vnický loka£ní registr (VLR) Pro bezproblémovou mobilitu ú£astník· je vyuºíván registr VLR, který p°echodn¥ uchovává a obnovuje data o uºivatelích, v dané chvíli se nacházejících v oblasti p°íslu²né MSC. Obsahuje podobné informace jako HLR , ale pouze do£asn¥, tzn., ºe jakmile ú£astník opustí oblast, data jsou vymazána [29]. Centrum autenti£nosti (AuC) - Obsahuje informace pot°ebné k autentizaci SIM a moºnosti zavedení ²ifrovaného spojení mezi MS a BTS. V mnoha p°ípadech je AuC implementováno jako sou£ást domovského registru. Pro kaºdé uºivatelské £íslo IMSI je obsaºen klí£ Ki a pouºitý ²ifrovací algoritmus A3 a A8. Stejné hodnoty jsou uloºeny i na odpovídající SIM [9, 29]. 10.6 Opera£ní a podp·rný subsystém (OSS) Poslední £ástí GSM architektury je opera£ní a podp·rný subsystém, jehoº sou£ástí je provozní a servisní centrum (OMC), °ídící dohledové centrum (NMC) a administrativní centrum (ADC). Mezi hlavní funkce OSS pat°í kontrola a údrºba NSS a BSS, management a monitoring mobilních stanic v£etn¥ jejich registrace a tarikace [9]. 83 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ 10.7 3. generace Po rozmachu hovorových sluºeb v síti GSM se v 90. letech minulého století za£ala rozvíjet poptávka po datových sluºbách v této síti. N¥kdy jsou jako systémy 2,5. generace prezentovány nadstavby nad GSM sítí umoº¬ující datové p°enosy GPRS, EDGE. Tyto sluºby v²ak poskytují jen omezenou p°enosovou kapacitu a rychlost, a proto bylo pot°eba vytvo°it celý nový systém, který poskytne ²irokopásmový p°ístup k datovým sítím. P°ehled n¥kterých poºadavk· na systémy 3. generace, viz. [28]: Zvý²ení p°enosových rychlostí sou£asných systém· 2. generace na hodnoty aº 2 Mbit/s Lep²í vyuºití rádiových frekvencí (vy²²í spektrální ú£innost modulací, ú£inn¥j²í zdrojové a kanálové kódování) Malé a levné terminály pro r·zné typy aplikací iroké spektrum sluºeb s r·zným stupn¥m kvality 10.7.1 Vývoj UMTS Organizace ITU proto zahájila první p°ípravné kroky pro denování nové sít¥ t°etí generace. Projekt pod názvem IMT-2000 (International Mobile Telecommunications 2000) má své ko°eny uº v roce 1985. íslovka 2000 znamená vyuºití frekvence v oblasti 2000MHz, p°enosovou rychlost 2000 kbps a denici do roku 2000. V roce 1992 pak bylo na mezinárodní konferenci WRC 92 v Malaze rezervováno pásmo 1885-2025 a 2110 a 2200 pro vyuºití v systémech IMT-2000 [14]. V brzké dob¥ do²lo k rozd¥lení vývoje systému 3. generace na dva hlavní sm¥ry UMTS pro Evropu a CDMA2000 pro oblast USA. Vývoj systému UMTS byl p°eveden pod nov¥ vytvo°enou organizaci 3GPP, která publikovala první specikaci v roce 1999. Vlastnosti Release 99, viz. [29]: hovorový kanál 64 kbps paketový p°enos 384 kbps lokaliza£ní sluºby kompatibilita s GSM kvalita hlasového p°enosu Tento standart poloºil základ pro budování UMTS sít¥ v Evrop¥. Do dne²ní doby bylo vydáno n¥kolik dal²ích specikací, které se p°edev²ím v¥nují zkvalit¬ování sluºeb, p°echod jádra systému na protokol IP a navy²ování p°enosové rychlosti a kapacity. Prvního komer£ního nasazení se sí´ UMTS do£kala v roce 2001 v Norsku. Problémem v²ak byla nedostupnost koncových za°ízení, které se postupn¥ dostávaly na trh aº ke konci následujícího roku. 10.7.2 Struktura sít¥ UMTS Systémy 2. generace byly primárn¥ zam¥°eny na p°enos hlasových dat, zatímco UMTS je systém p°iná²ející p°edev²ím ²irokopásmový datový p°ístup [29]. Pro sít¥ 3. generace byla zvolena technologie CDMA (Code Division Multiple Access), coº je p°ístupová metoda kódového d¥lení. Pro UMTS je pouºita její ²irokopásmová varianta W-CDMA (Wideband CDMA). Na rozdíl od TDMA u GSM u CDMA neexistuje ºádné d¥lení na jednotlivé TS a v²ichni uºivatelé pouºívají p°id¥lené frekven£ní pásmo po celou dobu. Aby bylo 84 NGN PRO VUT A VB-TUO umoºn¥no rozpoznání jednotlivých uºivatel· vyuºívajících jedno frekven£ní pásmo sou£asn¥, dochází k p°id¥lení binárního kódu jednotlivým uºivatel·m. Frekven£ní spektrum se skládá z párového pásma (1920-1980 MHz + 2110-2170 MHz) a nepárového pásma (1910-1920 MHz + 2010-2025 MHz), viz. [29]. Podle typu pásma se pouºívají rozdílné metody pro duplexní provoz: FDD (Frequency Division Duplex) pro párové pásmo; TDD (Time Division Duplex) pro pásmo nepárové. Podobn¥ jako u systému GSM lze i UMTS rozd¥lit do n¥kolika základních funk£ních £ástí, toto rozd¥lení popisuje obrázek 10.3. Obrázek 10.3: Architektura systému UMTS MS - Mobilní stanice systému UMTS je obdobou MS v systému GSM, je tvo°eno mobilním za°ízením (ME) a USIM Universal Subscriber Identity Module. USIM p°idává p°edev²ím podporu nových bezpe£nostních prvk· jako je vzájemná autentizace MS a Node B nebo pouºití del²ích ²ifrovacích klí£· [29]. UTRAN - UTRAN je zkratkou pro rádiovou p°ístupovou sí´ pro UMTS (UMTS Terrestrial Radio Access Network). P°edstavuje tu £ást sít¥, která zprost°edkovává rádiový p°enos , °ízení a p°id¥lování rádiových kanál·. Jedná se o obdobu BSS v systému GSM. Podobn¥ jako BSS je i UTRAN sloºena ze dvou základních jednotek [29]. : Node B základnová stanice systému UMTS (obdoba BTS u GSM) RNC (Radio Network Controller) °ídicí jednotka systému UMTS (obdoba BSC u GSM) CSN - (Circuit switched network) je ozna£ení pro p·vodní prvky systému GSM vyuºívané p°edev²ím k uskute£¬ování hovor· pomocí p°epínání okruh·. Tato £ást je dále propojena s ve°ejnou telefonní sítí [29]. . 85 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ PSN - Tato £ást sít¥ vychází z prvk· vyuºitých jiº pro GPRS a slouºí k p°enosu dat prost°ednictvím paketové sít¥ [29]. SGSN - (Serving GPRS Support Node)- prvek °ídící paketový prvek GGSN - (Gateway GPRS Support Node) Rozhraní pro propojení vnit°ní sít¥ operátora s globální sítí v dne²ní dob¥ p°edev²ím sítí Internet. 10.8 4. generace tvrtá generace mobilních telekomunika£ních sítí si klade za úkol obslouºit stále se zvy²ující poºadavky uºivatel· na p°enosovou kapacitu. Systém vedle poskytování klasických hovorových a dal²ích sluºeb známých ze systém· 2. a 3. generace je roz²í°en o vysokorychlostní datový p°ístup, aby bylo moºné vyuºívat sluºeb p°ístupu k Internetu, VoIP, mobilní TV, cloud-computing apod. Pojem 4. generace je pouze komer£ním ozna£ením pro specikaci denovanou ITU-R pod názvem IMT-Advanced (International Mobile Telecommunications). V B°eznu roku 2008 bylo organizací ITU-R p°ijato n¥kolik poºadavk· pro sít¥ IMT-Advanced [11, 27]: P°enosová rychlost 100 Mbit/s pro komunikaci s rychle se pohybujícím za°ízením P°enosová rychlost 1 Gbit/s pro stacionární a pomalu pohybující se za°ízení Vzájemná kompatibilita s ostatními sít¥mi Celosv¥tová pouºitelnost systému kálovatelnost ²í°ky rádiového kanálu podle pot°eby První technologií pln¥ spl¬ující poºadavky pro IMT-Advanced je standart LTE-Advanced schválený v B°eznu 2011. LTE-Advanced navazuje na svého p°edch·dce LTE, který a£koliv je n¥kdy ozna£ován za sí´ 4. generace v materiálech operátor· nespl¬uje poºadavky denované ITU-R. Na vývoji LTE-A se podílela p°edev²ím organizace 3GPP, která také stálá za specikací 3G systému UMTS. N¥které vlastnosti systému LTE-Advanced, viz. [11]: kálovatelnost ²í°ky pásma aº na 100MHz Vyuºití více antén umoº¬ující vícenásobný MIMO (Multiple Input/Multiple Output) p°ístup. Asymetrická ²í°ka pásma pro FDD Automatická kongurace sít¥ Aº 3.3 Gbit/s p°enosová rychlost První LTE-A sít¥ jsou od roku 2013 provozovány v Jiºní Koreji a Rusku. Zatím je na trhu dostupný pouze omezený po£et za°ízení podporujících tuto technologii a výrazný nástup lze o£ekávat aº v následujících letech. 10.9 Zabezpe£ení sít¥ GSM Bezpe£nost sít¥ GSM je postavena na 4 základních bodech [18, 29]: 86 autentizace uºivatele utajení identity uºivatele utajení p°ená²ených dat utajení signalizace NGN PRO VUT A VB-TUO Zaji²t¥ní zabezpe£ení sít¥ má na starost n¥kolik jejích £ástí. Konkrétn¥ se jedná o Subscriber Identity Module (SIM), mobilní za°ízení (MS) a centrum autenti£nosti (AUC). SIM obsahuje mimo jiné IMSI (International Mobile Subscriber Identity), tajný klí£ Ki , dále algoritmus pro generování ²ifrovacího klí£e A8, autentiza£ní algoritmus A3 a osobní identika£ní £íslo PIN. Mobilní stanice - obsahuje ²ifrovací algoritmus A5. AUC - obsahuje databázi s identika£ními a autentiza£ními údaji uºivatel· sít¥. V databázi jsou uloºeny IMSI, TMSI (Temporary Mobile Subscriber Identity), LAI (Location Area Identity) a tajný klí£ Ki , který je unikátní pro kaºdého uºivatele. Z obecného pohledu je nejzraniteln¥j²í bezdrátová £ást sít¥, kde probíhá samotná komunikace mezi MS a BTS, která je ²í°ena volným nezabezpe£eným prost°edím. N¥kterými z metod pro zabezpe£ení p°enosu jsou nap°. p°ela¤ování vysílací frekvence, kanálové kódování, digitální modulace GMSK nebo ov¥°ení ú£astníka. 10.9.1 Autentizace uºivatele Autentizace uºivatele se provádí p°i p°ístupu uºivatele do sít¥. Systém GSM ov¥°í identitu uºivatele pomocí mechanismu challenge-response. BTS odesláním 128 bitového náhodného £ísla RAND vyzve mobilní stanici k výpo£tu ov¥°ené odpov¥di SRES. Hodnota SRES je vypo£tena na základ¥ znalosti Ki a RAND a implementaci algoritmu A3. tzn. SRES = A3(Ki, RAND). MS pak po²le výslednou hodnotu zpátky do sít¥, kde je v registru VLR proveden obdobný výpo£et se stejnými hodnotami. Pokud sí´ dojde ke stejnému výsledku, jako obdrºela od MS, je autentizace úsp¥²ná. Pokud ne, dojde k ukon£ení spojení [18]. Schéma autentizace uºivatele je na obr. 10.4. Obrázek 10.4: Autentizace uºivatele 87 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ 10.9.2 Utajení identity uºivatele Jak bylo popsáno vý²e, £íslo IMSI slouºí k jednozna£né identikaci uºivatele v rámci sít¥ a je uloºeno na SIM kart¥. Aby do²lo ke sníºení rizika zneuºití IMSI zavádí se po autentizaci uºivatele do£asný identikátor TMSI (Temporary Mobile Subscriber Identity). TMSI je do£asn¥ uloºeno na SIM a v registru VLR. TMSI se vztahuje jen k lokalit¥, v níº bylo vydán. V p°ípad¥ p°esunu do jiné lokality je vydáno nové TMSI. Kongurace GSM sít¥ umoº¬uje pr·b¥ºnou zm¥nu TMSI i v p°ípad¥, kdy nedochází k p°echodu mezi lokalitami tento mechanismus posiluje utajení identity uºivatele [18]. 10.9.3 Utajení p°ená²ených dat a signalizace Pr·b¥h ²ifrování v systému GSM je zaloºen na proudové ²if°e A5, kdy je k bitové posloupnosti dat p°i£ítána hodnota ²ifrovací posloupnosti (tzv. keystream). Proces ²ifrování v systému GSM je popsán obrázkem 10.5. V registru HLR (AuC) je vygenerováno náhodné £íslo RAND. Na základ¥ tohoto £ísla je pak s pomocí autentiza£ního klí£e Ki podle ²ifrovacího algoritmu A8 vygenerován ²ifrovací klí£ Kc. Tato trojice (RAND - 128 bit·, SRES - 32 bit· a Kc - 64 bit·) je p°edána do registru VLR, kde je po dobu spojení uchována [26]. BTS pak p°epo²le £íslo RAND mobilní stanici, která na SIM kart¥ obdobným procesem op¥t vygeneruje klí£ Kc. Vstupem pro algoritmus A5 je 64 bitový ²ifrovací klí£, 22 bitové £íslo TDMA rámce a vlastní data ur£ená k ²ifrování. Z d·vodu výpo£etní náro£nosti tohoto algoritmu jiº není uloºen na SIM kart¥, ale je implementován na koncových mobilních za°ízeních. Pokud v pr·b¥hu hovoru dochází k handoveru, tak se ²ifrovací klí£ nem¥ní. Z vý²e zmín¥ného tedy vyplývá, ºe ani p°i ²ifrování nedojde k p°enosu klí£e rádiovým rozhraním a jsou p°ená²ena pouze hodnoty RAND a vlastní ²ifrovaná data [29]. Implementace algoritm· A3 a A8 není závazn¥ specikována a ponechává tak ur£itou volnost domluvy mezi operátorem a výrobcem SIM karet [29] Pro moºnost vyuºití v systému GSM jsou popsány následující typy ²ifrovacího algoritmu A5 : A5/0- ºádné ²ifrování A5/1- proudová ²ifra vyuºívající 64 bitového klí£e A5/2- implementa£ní varianta A5/1 ur£ena pro export mimo zem¥ Evropy a USA, podstatn¥ slab²í zabezpe£ení, umoº¬ující real-time prolomení. V sou£asnosti se tém¥° nepouºívá A5/3- bloková ²ifra nazývaná také KASUMI vyuºívá 128bitového ²ifrovacího klí£e, s 64 bitovým datovým vstupem i výstupem. Jedná se o podstatné zesílení bezpe£nosti, a£koliv se tato ²ifra ukázala jako akademicky prolomitelná. Algoritmus A5/1 je zaloºen na kombinací 3 posuvných registr· s lineární zp¥tnou vazbou (Linear Shift Feedback Register). Délka registr· je 19,22 a 23 bit·. Po£áte£ní stav ²ifry je ur£en ²ifrovacím klí£em Kc a £íslem TDMA rámce. Následn¥ dojde k zahození výstupu pro prvních 100 cykl·. Nyní je algoritmus p°ipraven vytvo°it 114 bitovou výstupní sekvenci ²ifrovaných resp. de²ifrovaných dat [31]. ifrovací algoritmus je gracky znázorn¥n na obrázku 10.6. LSF R 88 NGN PRO VUT A VB-TUO Obrázek 10.5: Autajení p°ená²ených dat Obrázek 10.6: Algoritmus A5/1 89 10 MOBILNÍCH SÍT A JEJICH ZABEZPEENÍ 10.9.4 Zabezpe£ení sít¥ UMTS Zabezpe£ení sítí 3. generace ve velké mí°e vychází z bezpe£nostních prvk· vyuºívaných u sítí p°edchozí generace. P°i tvorb¥ zabezpe£ení pro 3G sít¥ se vývojá°i zam¥°ili p°edev²ím na známé zranitelnosti GSM systému. Jelikoº je sí´ UMTS tvo°ena s ohledem na ²irokopásmový datový p°ístup je pot°eba zohlednit lep²í zabezpe£ení p°ená²ených dat. Architektura zabezpe£ení 3G sítí se skládá z následujících £ástí [21, 31]: Zabezpe£ení p°ístupové sít¥ - Zde je op¥t kladen d·raz na utajení identity uºivatele, autentizaci uºivatele, bezpe£nost a integritu dat. Pro utajení identity je vyuºita do£asná identita, na rozdíl od GSM je kladen d·raz na £ast¥j²í zm¥nu této identity tak, aby uºivatel nemohl být dlouhodob¥ identikován. Pro posílení autentizace bylo zvoleno vzájemné ov¥°ení ú£astníka sít¥. Pro zaji²t¥ní vy²²í bezpe£nosti p°ená²ených dat nejsou dále podporovány ²ifrovací algoritmy A5/1 a A5/2. S tím souvisí vyuºití 128 bit ²ifrovacího klí£e i v rámci SIM. P°edev²ím pro ochranu signaliza£ních dat byl zaveden mechanismus pro kontrolu integrity p°ená²ených zpráv. Tato vlastnost umoº¬uje vºdy zkontrolovat, zda p°ijatá zpráva nebyla zm¥na a pochází z ov¥°eného zdroje. Zabezpe£ení sí´ové domény - Na rozdíl od GSM se specikace UMTS zaobírá zabezpe£ením komunikace uvnit° sít¥ operátora a p°i komunikaci mezi sít¥mi r·zných operátor·. Zabezpe£ení uºivatelské domény - Umoº¬uje zabezpe£it MS proti zneuºití. Stejn¥ jako v GSM je zde vyuºito PIN kódu. Aplika£ní zabezpe£ení Vlastnosti umoº¬ující zabezpe£ení uºivatelských aktivit v rámci sít¥ operátora. Ov¥°itelnost a kongurovatelnost zabezpe£ení Dává moºnost uºivateli ov¥°it si, zda jsou hovory a data p°ená²ena zabezpe£eným rádiovým kanálem, nap°. pomocí indika£ní ikony na MS. 90 NGN PRO VUT A VB-TUO 11 Bezpe£nostní rizika mobilní komunikace Na rizika p°i mobilní komunikaci lze pohlíºet ze dvou stran z pohledu koncového uºivatele a pohledu operátora sít¥. Základním poºadavkem oby£ejného uºivatele je zaplatit pouze za sluºby, které mu byly poskytnuty. Dle architektury GSM sít¥ je za toto odpov¥dná autentizace uºivatele v·£i síti pomocí tajného klí£e dojde-li tedy k úniku tohoto klí£e, m·ºe pak úto£ník provád¥t hovory na ú£et ob¥ti. K dal²ím poºadavk·m zákazníka pat°í zabezpe£ení p°ená²ených dat proti odposlechu. Uº z podstaty bezdrátového provozu vyplývá ve srovnání s metalickým vedením mnohem jednodu²²í p°ístup úto£níka k p°enosovému kanálu. Z tohoto d·vodu je pot°eba p°ená²ena data ²ifrovat dostate£n¥ silným zabezpe£ením, které v²ak nebude naru²ovat provoz sít¥ nap°. nadm¥rným datovým tokem, zvý²enou chybovostí nebo náklady. Dojde-li proto k úniku klí£e pro ²ifrování jsou data libovoln¥ p°ístupná úto£níkovi. Z pohledu operátora mobilní sít¥, jehoº hlavním cílem je nan£ní zisk, je zabezpe£ení stejn¥ d·leºité jako kvalita sluºeb. P°i zneuºití sít¥ m·ºe dojít k p°ímé nan£ní ztrát¥ formou zneuºití jeho sít¥ pro cizí sluºby nebo k nep°ímým ztrátám, kdy dochází k odchodu koncového zákazníka, kterému není poskytnuto bezpe£né zázemí. Z vý²e zmín¥ného vyplývá, ºe hlavním objektem zájmu úto£níka je zisk tajného ²ifrovacího klí£e Ki , který se nachází na SIM kart¥ a AuC . Víme, ºe klí£ Ki se pouºívá jak pro autentizaci uºivatele, tak i pro výpo£et dal²ího klí£e Kc , který dále slouºí k ²ifrování p°ená²ených dat. Pro odposlech hovor· je tedy dosta£ující pouhá znalost klí£e Kc . Detailn¥ji bude tato problematika rozebrána v následujících podkapitolách. 11.1 Klonování SIM karty Z historického pohledu se jednalo o první popsaný zp·sob zneuºití chyb v zabezpe£ení. 13. dubna 1998 byl publikován Ianem Goldbergem (ISAAC Security Research Group) a Marcem Bricenem (SDA - Smartcard Developer Association) £lánek popisující moºnost klonování SIM karty. Za pomocí fyzického p°ístupu k SIM a jednoduché £te£ky se jim poda°ilo získat IMSI a klí£ Ki , který poté nahráli do nové SIM karty a získali tak kopii napadené karty [7]. Standard GSM denuje, ºe pro autentizaci bude vyuºit libovolný algoritmus na základ¥ volby operátora, který v²ak bude odpovídat poºadavk·m na autentizaci denovaných jako A3/8. Jedním z nejroz²í°en¥j²ích autentiza£ních algoritm· je COMP128, podstatným problémem tohoto algoritmu je, ºe byl vyvíjen jako utajený, coº sebou nese problémy ve form¥ nemoºnosti odhalit n¥které skryté problémy, které by byly snadn¥ji odhalitelné v p°ípad¥ vývoje algoritmu v otev°eném formátu s moºností komentá°· ostatních odborník·. Algoritmus COMP128 pracuje s dv¥ma vstupními hodnotami Ki a RAND a jednou výstupní hodnotou. Analýza uniklých informací o algoritmu COMP128 ukázala na nízký rozptyl výstupních hodnot. Podle údaj· ze zprávy je pro získání Ki pot°eba algoritmu p°edloºit cca. 150 tis. poºadavk·. Útok pak probíhá hledáním kolizí mezi výstupními hodnotami tak, ºe jsou zadávány dvojice velice blízkých RAND £ísel m¥ní se pouze jeden nebo dva byty zadávaného £ísla a to tím zp·sobem, ºe hledáme-li 0. a 8. byte klí£e Ki m¥níme pouze 0. a 8. byte RAND, pro hledání 1. a 9. byte m¥níme 1. a 9. byte RAND apod. Je-li výstupem jedné dvojice RAND stejná hodnota, m·ºeme na základ¥ znalosti algoritmu COMP128 dopo£ítat p°íslu²né 2 byty klí£e Ki [7]. Po získání klí£e Ki a IMSI napadené SIM, lze vytvo°it klon karty a dále ji vyuºít pro provád¥ní extra placených hovor·, zneuºití identity apod. A£koliv je tento útok velice jednoduchý na provedení, nelze jej povaºovat za velkou hrozbu v globálním m¥°ítku hned z n¥kolika 91 11 BEZPENOSTNÍ RIZIKA MOBILNÍ KOMUNIKACE d·vod·. Nejprve je pot°eba k provedení útoku získat fyzický p°ístup k SIM na dostate£n¥ dlouhou dobu, pokud se toto úto£níkovi poda°í pak nastupují r·zné ochranné mechanismy nových SIM karet(cca. od roku 2002), omezený po£et dotaz· po p°ekro£ení limitu dojde k zablokování SIM, um¥lé zpomalení výpo£tu odpov¥di coº velice navy²uje dobu provád¥ní útoku a riziko odhalení. Dále je moºno mít v síti p°ihlá²enou práv¥ jednu identickou SIM sou£asn¥, v p°ípad¥ p°ihlá²ení dal²í SIM se stejným IMEI dojde pomocí vnit°ních mechanism· sít¥ k zablokování ú£astníka a nahlá²ení zneuºití [7]. Pokud se v²e zmín¥né úto£níkovi poda°í, stále jde o napadení pouze jediného za°ízení a nejedná se o rozsáhlé zneuºití. 11.2 Jednosm¥rná autentizace V této £ásti se zam¥°íme na dal²í ze známých bezpe£nostních problému systému GSM. Systém GSM je navrºen tak, ºe je ov¥°ována pouze identita ú£astníka v·£i síti, ke které se p°ipojuje a není provád¥na opa£ná autentizace sít¥ v·£i ú£astníkovi tento zp·sob se nazývá jednosm¥rná autentizace a vytvá°í ohromnou skulinu v zabezpe£ení GSM sít¥. Je tak moºno vytvo°it fale²nou základnovou stanici (BTS), která se poté tvá°í jako opravdová BTS operátora, a mohou se k ní p°ipojovat mobilní stanice (MS), aniº by toto odhalili. Na tento problém bylo upozor¬ováno od po£átku GSM systému, ale nebylo to povaºováno za hrozbu z d·vodu velmi vysokých náklad· na po°ízení a provozování fale²né BTS. S nar·stajícím roz²í°ením sít¥ v²ak také dochází k výraznému poklesu náklad· na po°ízení a provoz fale²né základnové stanice. V sou£asnosti jsou pak dostupná softwarov¥ ovládaná rádia, která s vyuºitím voln¥ dostupného softwaru pro zpracování signálu sniºují náklady na tento zp·sob zneuºití na zanedbatelnou £ástku [36]. 11.3 Prolomitelnost algoritmu A5 V kapitole zabývající se zabezpe£ením GSM je zmín¥n utajený vývoj ²ifrovacích algoritm· A5. Díky tomuto nebylo moºno dlouhou dobu získat p°ístup k vlastní implementaci tohoto algoritmu a nebylo tak moºné ov¥°it vlastní bezpe£nost. Po zve°ejn¥ní implementace A5/2 v roce 1999 byla ihned pod vedením Iana Goldberga vypracována analýza upozor¬ující na kritické problémy v zabezpe£ení umoº¬ující real-time prolomení ²ifrování za vyuºití b¥ºného PC. Popis jejich útoku v²ak pracoval se znalostí ne²ifrovaných dat a pro praktickou implementaci nebyl optimální. V roce 2003 byla zve°ejn¥na zpráva popisující prolomení zabezpe£ení pouze na základ¥ znalosti malého mnoºství ²ifrovaných dat. Jejich implementace vychází z vlastnosti GSM systému, kdy jsou £asto odesílány prázdné ²ifrované rámce se známým obsahem dopl¬kové bity. Tento princip umoºnil roz²í°it proveditelnost tohoto útoku následn¥ i na bezpe£n¥j²í ²ifru A5/1 [7, 36]. V kombinaci s moºnosti podvrºení základnové stanice, pak bylo moºné získat klí£ Kc pro komunikaci ²ifrovanou libovolným algoritmem. Úto£ník zachytí výzvu RAND a následnou ²ifrovanou komunikaci. Následn¥ vyuºitím podvrºené BTS vyuºije stejnou hodnotu RAND pro autentizaci v rámci vlastní sít¥ s aplikovaným ²ifrováním A5/2. Po provedení vý²e popsaného útoku tak získá ²ifrovací klí£, který m·ºe následn¥ vyuºít k de²ifrování d°íve zachycených dat a v tomto p°ípad¥ nezáleºí na pouºité ²if°e [36]. 11.4 Absence zabezpe£ení v páte°ní síti Specikace GSM v·bec ne°e²í zabezpe£ení komunikace uvnit° vlastní sít¥ operátora. Signaliza£ní protokol SS7 pouºívaný v páte°ní síti systému neposkytuje dostate£né zabezpe£ení a 92 NGN PRO VUT A VB-TUO autentizaci v rámci vzájemn¥ propojené sít¥ r·zných operátor·. P°i roz²i°ování IP sítí pro propojení jednotlivých prvk· systému GSM je pot°eba brát v potaz také obecné hrozby zneuºití související s globální sítí. V p°ípad¥ proniknutí úto£níka do vnit°ní sít¥ m·ºe podvrhnutím jednoho z prvk· systému získat p°ístup ke kritickým £ástem jako je HLR, VLR pop°. AuC [36]. 93 12 DEMONSTRACE REALIZOVANÝCH ÚTOK 12 Demonstrace realizovaných útok· V této kapitole jsou popsány základní principy n¥kterých útok· vyuºívajících bezpe£nostních chyb systému GSM k neoprávn¥nému zásahu do soukromí uºivatel·. S velkou pravd¥podobností lze p°edpokládat vyuºívání r·zných proprietárních °e²ení na úrovni vládních a bezpe£nostních agentur. V této kapitole jsme se v²ak zam¥°ili p°edev²ím na provedení útok· za vyuºití voln¥ dostupných prost°edk·. 12.1 IMSI catcher pomocí USRP Jiº od roku 1996 jsou dostupná první komer£ní °e²ení IMSI catcher vyvíjených rmou Rhode&Schwarz. Moºnost vyuºití USRP pro provozování IMSI catcher byla popsána Chrisem Pagetem v rámci konference 26C3 a následn¥ prakticky p°edvedena na konferenci DEF CON 30. Srpna 2010, viz. [24]. Vyuºívá programovatelného rádia USRP 1 ve spolupráci s open-source implementací GSM protokolu OpenBTS. Následnou jednoduchou kongurací OpenBTS, kdy jsou nastaveny identika£ní hodnoty MCC a MNC základnové stanice je dosaºeno zprovozn¥ní podvrºené BTS jednoho z lokálních operátor·. Upozornil také na zablokování notikace pouºitého ²ifrování koncovému uºivateli. IMSI catcher je za°ízení slouºící k identikaci uºivatele získáním jeho IMSI. K získání IMSI vyuºívá vytvo°ení fale²né BTS, ke které se následn¥ p°ipojí okolní mobilní stanice a dojde k odeslání IMSI, aby bylo moºno p°ipojené za°ízení identikovat 12.1. Obrázek 12.1: Scéná° útoku - IMSI catcher IMSI catcher vyuºívá vlastnosti GSM sít¥, kdy nedochází k autentizaci BTS v·£i MS, a je tak moºno ji podvrhnout. Pro vytvo°ení IMSI catcheru v rámci na²eho experimentu bylo vyuºito za°ízení USRP spole£n¥ s OpenBTS. Teoretický pr·b¥h útoku je znázorn¥n na obrázku 12.1 je vytvo°ena fale²ná BTS s podvrhnutou identitou, v okamºiku kdy dojde k p°ipojení MS v dosahu fale²né BTS je v rámci procesu identikace MS v·£i BTS zaznamenána hodnota IMSI. 94 NGN PRO VUT A VB-TUO 12.1.1 Instalace a kongurace softwaru Pro instalaci byla zvolena verze OpenBTS 2.8. Software byl kompilován ze zdrojových soubor· [26]. svn co http://wush.net/svn/range/software/public P°ed vlastní kompilací OpenBTS je pot°eba doinstalovat nezbytné závislosti (UHD 003.005.002). wget https://github.com/EttusResearch/UHD-Mirror/archive/release_003_005_002.tar.gz tar xzf release_003_005_002.tar.gz P°ed kompilací UHD je pot°eba nainstalovat dal²í závislosti : sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-cheetah doxygen python-docutils cmake Kompilace UHD : cd release_003_005_002/host mkdir build cd build cmake ../ make make test sudo make install sudo ldconfig Dal²í závislosti OpenBTS : autoconf libtool libosip2-dev libortp-dev libusb-1.0-0-dev g++ sqlite3 libsqlite3-dev erlang build-essential subversion P°ed vlastní kompilací OpenBTS bylo je²t¥ pot°eba doinstalovat knihovnu liba53, která je zahrnuta v balíku OpenBTS. V ko°enovém adresá°i OpenBTS: cd a53/trunk sudo make install Poté je moºno p°istoupit k vlastní instalaci OpenBTS ze zdrojového kódu: cd openbts/trunk autoreconf -i ./configure --with-uhd Make Vytvo°ení symbolického odkazu na aplikaci transceiver: cd apps ln -s ../Transceiver52M/transceiver . V tomto okamºiku bylo moºno p°istoupit k vlastní konguraci OpenBTS pro pouºití jako IMSI catcher. Pro uloºení kongurace je v projektu OpenBTS vyuºita externí SQLite databáze, její inicializaci provedeme následovn¥: sudo mkdir /etc/OpenBTS sudo sqlite3 -init ./apps/OpenBTS.example.sql /etc/OpenBTS/OpenBTS.db ".quit" 95 12 DEMONSTRACE REALIZOVANÝCH ÚTOK 12.1.2 Pr·b¥h útoku Spu²t¥ní OpenBTS : cd apps sudo ./OpenBTS Po úsp¥²ném spu²t¥ní by se m¥la v okn¥ terminálu zobrazit informace o p°ipravenosti systému: system ready use the OpenBTSCLI utility to access CLI P°i pouºití default kongurace je vytvo°ená sí´ identikována jako testovací MCC 001 MNC 01. Je zakázána registrace nových za°ízení. Proto je pot°eba provést kongurace parametr· pro pot°eby IMSI catcheru. V následující tabulce m·ºete vid¥t p°ehled MCC a MNC £eských komer£ních mobilních operátor·. Provozovatel MCC MNC Název T-Mobile Czech Republic O2 Czech republic a.s. Vodafone Czech Republic Mobilkom RD Centre 230 230 230 230 230 01 02 03 04 99 T-Mobile CZ O2 CZ Vodafone U:fon Vodafone / VUT Dále je pot°eba zvolit vhodný kanál ARFCN tak, aby nedocházelo k vzájemnému ru²ení s okolními BTS operátora. Je pot°eba p°ipomenout, ºe obsluhující BTS pomocí kanál· BCCH a informa£ních zpráv zasílá MS seznam okolních BTS na kterých MS následn¥ provádí m¥°ení úrovn¥ signál·, na základ¥ nam¥°ených hodnot m·ºe dojít k reselekci BTS. Provedení kongurace OpenBTS pro provozování IMSI catcher prost°ednictvím konzolového p°ístupu k OpenBTS : config config config config config config config config Control.LUR.OpenRegistration .* // umoºní registraci v²ech za°ízení GSM.Radio.Band 900 // volba GSM pásma 900 GSM.Radio.C0 87 // nastavení ARFCN GSM.Identity.MCC 230 // nastavení MCC operátora O2 GSM.Identity.MNC 02 // nastavení MNC operátora O2 GSM.Identity.ShortName O2-CZ // nastavení názvu sít¥ GSM.Identity.ID 10 // nastavení Cell ID GSM.Identity.LAC 1714 //nastavení LAC Po této konguraci bylo pot°eba restartovat aplikaci OpenBTS, aby do²lo k aplikování nového nastavení. Následující tabulka znázor¬uje výsledky m¥°ení kvality signálu okolních BTS je²t¥ p°ed okamºikem neº do²lo k p°ipojení na BTS s vy²²í kvalitou signálu. Je moºno vid¥t stále stejnou obsluhující BTS s Cell ID 7047, následn¥ v²ak druhá v po°adí je jiº podvrºená BTS v podob¥ IMSI catcheru. Cell ID LAC ARFCN Síla signálu [dBm] 7047 84 -89 96 1713 NGN PRO VUT A VB-TUO 17050 27108 17051 17041 1713 1713 1713 1713 87 46 45 87 -51 -103 -105 -105 Následn¥ dochází k handoveru MS k BTS se siln¥j²ím signálem. P°i testování bylo zji²t¥no, ºe u r·zných mobilních za°ízení dochází k rozdílnému chování v okamºiku, kdy by m¥lo p°ijít k p°epojení na BTS se siln¥j²ím signálem. V¥t²ina star²ích za°ízení se p°ipojovala na OpenBTS tém¥° okamºit¥, po provedení m¥°ení a výpo£tu hodnoty C2. Toto bylo otestováno na telefonech Nokia 3210, Nokia 6230i a LG C3300. V p°ípad¥ nov¥j²ích za°ízení docházelo k rozdílnému chování. Nap°. Samsung Galaxy S2, Apple IPhone 4 se p°ipojili op¥t tém¥° ihned, na rozdíl od za°ízení Gigabyte GSMART Roma R2 nebo Sony Xperia L, kdy pro p°ipojení k BTS bylo pot°eba za°ízení restartovat a vyvolat tak znovu prohledání GSM spektra. Pro zobrazení IMSI mobilních za°ízení obsluhovaných OpenBTS pak slouºí p°íkaz tmsis, který v konzoli vypisuje seznam IMSI a k nim p°i°azeným TMSI. Zachycené IMSI jsou pak zobrazeny v následujícím výpisu: OpenBTS> TMSI 1 3 6 5 4 2 tmsis IMSI 230022901372117 230024100906226 230029101230104 231060900102504 231014451342246 230020701214669 age used 16d 7d 16d 7d 16d 16d 16d 16d 16d 16d 16d 16d Za pouºití voln¥ dostupných nástroj· bylo moºno vytvo°it a úsp¥²n¥ provozovat IMSI catcher. Po prvotní instalaci je moºno IMSI catcher nakongurovat podle aktuálních podmínek a následn¥ spustit v °ádu n¥kolika málo minut. Je pot°eba si uv¥domit, ºe v okamºiku kdy je mobilní za°ízení p°ipojeno k IMSI catcheru nelze na za°ízení p°ijímat a odesílat hovory £i SMS. Aby nedo²lo k prozrazení probíhajícího útoku je pot°eba minimalizovat dobu kdy je IMSI catcher v provozu. Provozování IMSI catcheru je v R i v¥t²in¥ ostatních zemí nelegální. 12.2 Pasivní odposlech pomocí USRP Tento útok byl poprvé prakticky p°edveden v rámci 26. konference 3C Chrisem Pagetem a Karstenem Nohlem 27. 12. 2009 v Berlín¥ [25]. Vlastní útok se skládá ze dvou základních £ástí. První £ástí je pasivní zachycení komunikace mezi BTS a MS pomocí softwarového rádia USRP, druhým krokem pak je získání Kc pro de²ifrování zachycených dat. Pro zachycení komunikace je vyuºit nástroj zaloºený na open-source GNU Radio, umoº¬ující jednoduchou obsluhu za°ízení USRP. Následná interpretace zachyceného signálu vychází z implementace GSM rozhraní v OpenBTS, pro tento úkol byl na této konferenci zve°ejn¥n nástroj Airprobe. Airprobe umoº¬uje zachycení downlink komunikace na jediném rádiovém kanálu bez podpory frekven£ních p°eskok· [17, 25]. Komplexn¥j²ím úkolem pak bylo prolomení ²ifrovacího algoritmu A5/1. Princip prolomení tohoto ²ifrování vychází ze znalosti obsahu n¥kterých ²ifrovaných zpráv. Toto je obdobou prolomení A5/2 a jelikoº se jedná o proudovou ²ifru, lze operací XOR shodné zprávy v ²ifrované a plain-textové podob¥ získat proud bit· (tzv. keystream) pouºitý k jejich za²ifrování [31] . 97 12 DEMONSTRACE REALIZOVANÝCH ÚTOK Pomocí p°edem vypo£tených tabulek pak lze na základ¥ keystreamu získat pouºitý ²ifrovací klí£. Aby byl v²ak tento krok proveditelný je pot°eba získat tento klí£ v rozumném £ase za vyuºití dostupných pam¥´ových prost°edk·. Délka klí£e Kc je 64 bit· a nabývá tedy hodnot z mnoºiny 264 stav·. Pro uloºení v²ech t¥chto stav· do tabulky by bylo pot°eba 64 * 264 bit = 134 217 728 TB pam¥ti. Bylo teda pot°eba p°istoupit k mechanism·m, které umoºní zredukovat pam¥´ovou náro£nost na zvládnutelnou míru. Tímto mechanismem je TMTO (Time-memory trade-o), kdy na úkor navý²ení výpo£etního £asu je dosaºeno niº²ích pam¥´ových nárok· [24, 31] . Celkovou výpo£etní a pam¥´ovou náro£nost bylo moºné výrazn¥ sníºit vyuºitím vlastnosti systému GSM popsaném profesorem Golicem v práci Cryptanalysis of Alleged A5 Stream Cipher, kde popisuje chybu v implementaci ²ifry A5/1, kdy dojde k redukci dosaºitelných stav· na 14% p·vodní teoretické hodnoty 264. Tento problém souvisí s provedením 100 cykl· p°i inicializaci ²ifrovacích registr·. Na základ¥ pokus·, kdy provedl 100 reverzních cykl· na mnoºin¥ 1 milionu stav·, do²el k záv¥ru, ºe v 86% p°ípad· není po£áte£ní stav dosaºitelný [17]. Jednou z metod pro efektivní uloºení p°edem vypo£tených dat je vyuºití tzv. rozli²itelných bod· (Distinguished points), kdy nejsou do výsledné tabulky uloºeny v²echny dvojice po£áte£ních a koncových stav·, ale pouze n¥které spl¬ující p°edem zvolenou podmínku, nap°. mají posledních 16 bit· nulových. Tímto dojde k výraznému sníºení po£tu pot°ebných p°ístup· do tabulky. Aby nedocházelo ve výsledné tabulce k ukládání duplicitních koncových stav·, které by následn¥ zp·sobily zacyklení. Proto byla pro výpo£et následujícího stavu vyuºita mírn¥ odli²ná funkce neº v p°edchozím kroku. Výsledná tabulka se pak nazývá Rainbow table a minimalizuje výskyt redundantních záznam· [31, 36]. Vyuºitím t¥chto technik do²lo ke sníºení pam¥´ové náro£nosti na 2TB p°edvypo£tených tabulek rozd¥lených na 41 £ástí umoº¬ující distribuované výpo£ty tzv. Berlin rainbow tables set s celkovým pokrytím 19,13% moºných stav·. Spole£n¥ s tabulkami byla na konferenci zve°ejn¥na aplikace kraken obstarávající pot°ebné výpo£ty a p°ístup k tabulkám. Vstupní hodnotou pro získání ²ifrovacího klí£e je vloºení XORu ²ifrovaného burstu a známého plain-text ekvivalentu. Pro tuto pot°ebu jsou vyuºity bursty se známým obsahem, které se vyuºívají p°edev²ím jako výpl¬kové v p°ípad¥ kdy, BTS nemá ºádná data k odeslání. Video prezentace a dal²í podrobnosti jsou dostupné na [24]. 12.2.1 Podvrºená BTS a aktivní odposlech Princip aktivního útoku vychází z koncepce IMSI catcheru, kdy je jeho funk£nost roz²í°ená o moºnosti realizace odchozích hovor· a odesílání SMS. Tím, ºe úto£ník má plnou kontrolu nad kongurací BTS, je moºno kompletn¥ vypnout ²ifrování hovorových dat a získat tak k dat·m okamºitý p°ístup. Scéná° útoku je zobrazen na 12.2, je vytvo°ena fale²ná BTS s podvrhnutou identitou, následn¥ dojde k p°epojení MS ob¥ti k fale²né BTS. V okamºiku kdy dojde k odchozímu hovoru je zaznamenáno £íslo volajícího a celý hovor je pomocí Asterisku nahrán a p°esm¥rován pomocí sít¥ VoIP na volanou stanici s podvrºenou identitou volajícího. Jak bylo zmín¥no v úvody této podkapitoly, vytvo°ení fale²né BTS vychází z IMSI catcheru a pro vlastní realizaci bylo také pouºita kombinace softwarového rádia USRP N210 pro rádiovou £ást a OpenBTS pro demodulaci signálu a °ízení základnové stanice. Aby bylo moºno pomocí OpenBTS uskute£¬ovat hovory a odesílat SMS zprávy je pot°eba doinstalovat dal²í sou£ásti OpenBTS: 98 NGN PRO VUT A VB-TUO Obrázek 12.2: Scéná° útoku pomocí fale²né BTS Subscriber registry slouºí k nahrazení funk£nosti HLR v b¥ºné GSM síti a pomocí upraveného SIP registru umoº¬uje uchovávat data o uºivatelích [6], Smqueue server pro zpracování a odesílání SMS zpráv v systému OpenBTS [6], Pobo£ková úst°edna Asterisk slouºí jak k provád¥ní signalizace prost°ednictvím protokolu SIP, tak k °ízení a p°epojování hovor·. Instalace Subscriber registry z balíku OpenBTS : cd subscriberRegistry/trunk/ make cd configFiles/ mkdir -p /var/lib/asterisk/sqlite3dir sqlite3 -init subscriberRegistryInit.sql /var/lib/asterisk/sqlite3dir/sqlite3.db ".quit" sqlite3 -init ../sipauthserve.example.sql /etc/OpenBTS/sipauthserve.db ".quit" Instalace Smqueue: cd smqueue/trunk/ ./autogen.sh autoreconf -i ./configure make make install sqlite3 -init smqueue.example.sql /etc/OpenBTS/smqueue.db ".quit" A nakonec instalace pobo£kové úst°edny Asterisk [33]. Kaºdý ú£astník p°ipojený pomocí OpenBTS je pro pot°eby asterisku identikován jako SIP koncový uºivatel s uºivatelským jménem IMSIxxxxxxxxxxxxxx, kde xxx je IMSI registrované SIM karty o délce 14-15 znak·. IP adresa uºivatele je shodná s IP obsluhující OpenBTS. Samotná OpenBTS je pak v p°ípad¥ vytvo°ení VoIP sít¥ neviditelná, [6]. Nejprve bylo pot°eba podobn¥ jako v p°ípad¥ IMSI catcheru zjistit údaje pro konguraci OpenBTS. Pro vytvo°ení fale²né BTS byla zvolena sí´ operátora O2 a bylo nutné zvolit pot°ebné GSM identika£ní údaje operátora. Výsledná kongurace OpenBTS: config Control.LUR.OpenRegistration .* // umoºní registraci v²ech za°ízení config GSM.Radio.Band 900 // volba GSM pásma 900 99 12 DEMONSTRACE REALIZOVANÝCH ÚTOK config config config config config config GSM.Radio.C0 1 // nastavení ARFCN GSM.Identity.MCC 230 // nastavení MCC operátora O2 GSM.Identity.MNC 02 // nastavení MNC operátora O2 GSM.Identity.ShortName O2-CZ // nastavení názvu sít¥ GSM.Identity.ID 10 // nastavení Cell ID GSM.Identity.LAC 1000 //nastavení LAC Po spu²t¥ní OpenBTS dojde k vytvo°ení fale²né BTS s vý²e uvedenými parametry. Následn¥ dochází k p°ipojení MS ob¥ti k této BTS. P°ipojení MS je moºno kontrolovat pomocí konzolové aplikace OpenBTS p°íkazem tmsis. V p°ípad¥ odchozího hovoru je daný hovor p°esm¥rován pomocí kongurace Asterisku na jeden z pevn¥ denovaných softwarových telefon· ve VoIP sítí vytvo°ené Asteriskem. Toto v laboratorních podmínkách simuluje uskute£n¥ní hovoru pomocí externího poskytovatele VoIP telefonie. Podvrºení identity volajícího a záznam hovoru je proveden pomocí funkcí Asterisku. Nastavení identity volajícího je provedeno pomocí kongurace v souboru extensions.conf. V tomto souboru dochází také k denici nahrávání hovor· do audio stopy v prost°edí asterisku. 12.3 Pasivní odposlech pomocí OsmocomBB P°edchozí útok za vyuºití USRP umoº¬oval zachycení komunikace p°i, které nedochází k frekven£ním p°eskok·m na rádiovém rozhraní. Pro podporu frekven£ních p°eskok· s vyuºitím USRP by bylo pot°eba implementovat tuto funkcionalitu p°ímo do programovatelného pole FPGA. Jako jednodu²²í varianta se ukázalo vyuºití mobilního telefonu s upraveným rmware, který pracuje s jedním fyzickým kanálem. Toto bylo p°edstaveno na konferenci 27C3 (Chaos Computer Conference) v rámci prezentace Karstena Nohla a Sylvaina Munauta [22]. Firmware vyuºitý pro provoz MS byl vytvo°en v rámci projektu OsmocomBB, který se zam¥°uje na open-source implementaci GSM protokolu na stran¥ mobilního za°ízení. Za vyuºití levného mobilního telefonu Motorola a upraveného rmware OsmocomBB p°edstavili moºnost zachycení komunikace v obou sm¥rech MS<->BTS i v p°ípad¥ kdy dojde k zavedení frekven£ních p°eskok·, které primárn¥ slouºí k potla£ení ru²ení. Bylo pot°eba obejít proces de²ifrování signálu, který probíhá na nejniº²í úrovni tak, aby byla dostupná £istá ²ifrovaná data, které je moºno následn¥ vyuºít pro nástroj kraken, p°edstavený v p°edchozí kapitole. Následující krok pro prolomení ²ifrování je totoºný s pr·b¥hem popsaným v p°edchozí £ásti. Podrobn¥j²í informace a video z konference je dostupné z [22]. P°i vyuºití vysíla£e se v²ak úto£ník vºdy vystavuje moºnosti odhalení a pom¥rné snadné lokalizace v p°ípad¥, kdy se na n¥j n¥kdo zam¥°í. V p°ípad¥ pasivního odposlechu komunikace nedochází k ºádnému aktivnímu vysílání ze strany úto£níka, a proto se moºné odhalení v tomto ohledu minimalizuje. V pr·b¥hu roku 2013 se ukázala moºnost vyuºití velice levného za°ízení ur£eného primárn¥ pro p°íjem DVB-T signálu. Tímto krokem do²lo ke sníºení náklad· na provedení pasivního odposlechu na minimální úrove¬ (stovky aº jednotky tisíc K£). 12.3.1 Instalace a kongurace Pro zachycení komunikace byl pouºit nástroj rtl-sdr z balíku Osmocom. P°ed vlastní instalací je pot°eba získat dopl¬kové balíky. sudo apt-get install libusb-1.0-0-dev 100 NGN PRO VUT A VB-TUO Instalace rtl-sdr: git clone git://git.osmocom.org/rtl-sdr.git cd rtl-sdr/ mkdir build cd build cmake ../ make sudo make install sudo ldconfig Levné za°ízení rtl-sdr sebou nese také ur£ité problémy ohledn¥ kvality pouºitého tuneru. Je proto pot°eba provést kalibraci za°ízení jedná se o zji²t¥ní odchylky v reálné frekvenci tuneru a frekvenci, která se zobrazuje uºivateli. Pro ú£el kalibrace byl pouºit nástroj kalibrate-rtl. git clone https://github.com/steve-m/kalibrate-rtl.git cd kalibrate-rtl/ ./bootstrap ./configure make make instar Nyní je pro zji²t¥ní odchylky (oset) pot°eba aplikaci pomocí parametru c poskytnout hodnotu ARFCN jedné z okolních BTS. Pro zji²t¥ní ARFCN okolních BTS je moºno spustit aplikaci s parametrem s GSM900, viz. [23]. Pro p°evod dat získaných pomocí aplikace rtl_sdr do formátu podporovaného aplikací airprobe bylo pouºito jedné z aplikací balík· GNU Radio GRC umoº¬uje vytvá°et pomocí grackého rozhraní spustitelné skripty pro r·zné vyuºití. Návrh diagramu pro vytvo°ení skriptu byl p°evzat z OsmocomSDR [23]. Ukázka diagramu je na obr. 12.3. Obrázek 12.3: GRC schéma pro p°evod zdrojových dat na cle Vyuºití tohoto p°evodu je dáno tím, ºe aplikace airprobe pouºívá pro vstup formát souboru cle s komplexními hodnotami, kdeºto výstupem aplikace rtl-sdr je binární datový soubor. Aby bylo moºno zobrazit získaná data v protokolovém analyzátoru Wireshark vyuºívá airprobe pseudo-záhlaví GSMTAP, které slouºí k zapouzd°ení zpráv systému GSM do UDP paket· [17]. Toto obstarává balík libosmocore. git clone git://git.osmocom.org/libosmocore.git cd libosmocore autoreconf i ./configure make sudo make install sudo ldconfig 101 12 DEMONSTRACE REALIZOVANÝCH ÚTOK Jak jiº bylo n¥kolikrát zmín¥no pro vlastní interpretaci zachycených dat je vyuºit nástroj airprobe. U tohoto balíku jsme p°i instalaci narazili na zna£né mnoºství problému, jednalo se p°edev²ím o problémy s balíky, na kterých je airprobe závislé. Dále pak o problémy s vlastní kompilací zdrojových soubor·. P·vodní balík zve°ejn¥ný autory na webu srlab.de v roce 2009 nebyl nadále udrºován a pro dne²ní pouºití byl nepouºitelný. Proto byla vyuºita modikovaná varianta vytvo°ena uºivatelem ttsou. P°ed vlastní instalací bylo pot°eba p°idat dal²í balíky závislostí. sudo apt-get install gnuradio-dev libboost-all-dev libfftw3-dev swig python-numpy Instalace airprobe: git clone https://github.com/ttsou/airprobe.git cd airprobe/gsm-receiver ./bootstrap ./configure make 12.3.2 Pr·b¥h útoku OpenBTS Tento scéná° byl zvolen z d·vodu ov¥°ení funk£nosti v²ech komponent systému. Bylo totiº moºno vyuºít znalostí o konguraci GSM sít¥. Toto zahrnuje p°edev²ím znalost kanálu ARFCN, na kterém je BTS provozována, dále moºnost získat jednodu²e informace o identikaci uºivatel· v rámci sít¥ (IMSI, TMSI). OpenBTS byla provozována ve stejné laborato°i, kde byl provád¥n také odposlech, coº zajistilo vysokou úrove¬ p°ijímaného signálu a následn¥ také bezproblémovou demodulaci a interpretaci získaných dat. Dal²ím zásadním rozdílem mezi reálnou sítí operátora a vyuºitím OpenBTS byla absence ²ifrování signaliza£ních a komunika£ní kanál· systému GSM. Proto také není v této £ásti °e²en zp·sob získání ²ifrovacího klí£e Kc. Kongurace OpenBTS : config config config config config config config config Control.LUR.OpenRegistration .* // umoºní registraci v²ech za°ízení GSM.Radio.Band 900 // volba GSM pásma 900 GSM.Radio.C0 1 // nastavení ARFCN GSM.Identity.MCC 001 // nastavení testovacího MCC GSM.Identity.MNC 02 // nastavení testovacího MNC GSM.Identity.ShortName OpenBTS // nastavení názvu sít¥ GSM.Identity.ID 10 // nastavení Cell ID GSM.Identity.LAC 1000 //nastavení LAC Na Asterisku je nastaveno p°esm¥rování v²ech hovor· na jedinou koncovou stanici identikovanou pomocí IMSI 230024100906226. Bylo op¥t pot°eba také provést kalibraci DVB-T USB receiveru, pro toto jsem vyuºil aplikaci kalibrate-sdr. Kalibrace byla provedena pomocí testovací OpenBTS na kanálu ARFCN 1 : kal -c 1 Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Exact sample rate is: 270833.002142 Hz kal: Calculating clock frequency offset. Using GSM-900 channel 58 (946.6MHz) average [min, max] (range, stddev) 102 NGN PRO VUT A VB-TUO - 39.908kHz [-39921, -39886] overruns: 0 not found: 0 average absolute error: 42.159 ppm (35, 9.224885) Z vý²e zji²t¥ného je podstatná zejména hodnota -39.908 kHz, která udává absolutní hodnotu odchylky. Relativní odchylka je pak udána jako hodnota 42.159 ppm. Tuto hodnotu je pak nutno ode£íst od hodnoty frekvence p°i zachytávání komunikace. V tomto okamºiku je moºné p°istoupit k zachycení komunikace mezi OpenBTS a MS. rtl_sdr f 935.2M s 1.0e6 data_openbts_arfcn1.bin parametr f ur£uje frekvenci signálu GSM parametr s nastavuje vzorkovací frekvenci 1MHz data_openbts_arfcn1.bin ur£uje název souboru se získanými daty rtl_sdr -f 935.161e6 -s 1.0e6 data\_openbts\_arfcn1.bin Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Exact sample rate is: 1000000.026491 Hz Tuned to 935200000 Hz. Reading samples in async mode... V pr·b¥hu útoku byla odeslána SMS z terminálu OpenBTS na MS identikovanou IMSI 230024100906226. Dále byl proveden telefonní hovor mezi dv¥ma MS p°ipojenými k testovací BTS. Po dokon£ení testovacího hovoru je ukon£eno získávání dat pomocí Ctrl + C. OpenBTS> sendsms 230024100906226 1234 Testovaci SMS zprava odeslana z OpenBTS message submitted for delivery Dal²ím krokem je p°evod získaných dat do formátu cle. V aplikaci GRC byl jako zdrojový soubor zvolen soubor zachycených dat data\_openbts\_arfcn1.bin, jako výstupní soubor pak data\_openbts\_arfcn1.cfile ve sloºce /home/gsmsec/airprobe/gsm-receiver/src/python/ Pro dal²í analýzu dat bude vyuºit skript go.sh z aplikace gsm-reciever v balíku airprobe. Tento skript demoduluje získaná data na základ¥ poskytnuté kongurace a získaný výstup pak odesílá na místní sí´ové rozhraní localhost s dopln¥ným pseudo-záhlavím GSMTAP [17]. go.sh decimation_rate channel_config session_key Parametry skriptu go.sh jsou následující [17]: decimation_rate ur£uje hodnotu pro downsampling, pro kompatibilitu s rtl_sdr je tato hodnota 64 103 12 DEMONSTRACE REALIZOVANÝCH ÚTOK channel_cong umoº¬uje ur£it logický kanál a timeslot pro zpracování, moºné kongurace channel_cong : 0C Kongurace s kombinovaným signaliza£ním kanálem 0B Kongurace s odd¥leným signaliza£ním kanálem 1S Signaliza£ní kanál v timeslotu 1 1-7T P°enosový kanál v timeslotu 1 aº 7 session_key hodnota ²ifrovacího klí£e Kc Dle dokumentace OpenBTS je pouºita varianta s kombinovaným signaliza£ním kanálem, proto jsou zvoleny následující parametry. Pokud není parametr session_key uveden dojde ke zpracování pouze ne²ifrovaných burst·. ./go.sh data_openbts_arfcn1.cfile 64 0C Na obr. 12.4 je moºno vid¥t okamºik kdy dojde k pagingu MS, coº MS oznamuje, ºe má na ur£eném kanálu naslouchat následující signalizaci. Obrázek 12.4: Paging MS Poté je odesláním Immediate Assigment sestaven logický komunika£ní kanál mezi MS a BTS, jehoº prost°ednictvím bude odeslána vlastní SMS.V tomto okamºiku je moºno p°istoupit k p°e£tení odeslané SMS. Obsah SMS je zachycen na obr. 12.5. Po potvrzení odeslání a p°ijetí SMS následuje p°íkaz k uvoln¥ní signaliza£ního kanálu. P°ed získáním hovorových dat je pot°eba provést analýzu signaliza£ního kanálu. Op¥t je stejn¥ jako v p°ípad¥ SMS vyvolán Paging a p°id¥lení signaliza£ního kanálu pomocí Immediate Assigment. V tomto okamºiku MS odesílá poºadavek sluºby (CM Service Request). MS v této zpráv¥ ºádá o sluºbu odchozího hovoru MOC (Mobile originating call) a identikuje se pomocí TMSI. BTS odpovídá pomocí CM Service Accept, ve které sluºbu (v tomto p°ípad¥ MOC) potvrzuje. Následn¥ je MS, ze které je hovor provád¥n pomocí zprávy Assigment Command oznámeno, aby naslouchala p°enosovému kanálu TCH a k n¥mu asociovanému signaliza£nímu kanálu na TS 1. Jelikoº je i volaná MS p°ipojena ke stejné BTS dochází zárove¬ k sestavení p°íchozího hovoru - MTC (Mobile Terminated Call) op¥t je nejprve MS oznámeno pomocí pagingu 104 NGN PRO VUT A VB-TUO Obrázek 12.5: Odeslaná SMS na BCCH, ºe je pot°eba sledovat sdílený signaliza£ní kanál SDCCH. Immediate Assigment pak p°id¥luje volané MS signaliza£ní kanál SDCCH4, subkanál 1, ve kterém následn¥ dojde k sestavení hovoru. BTS dále na p°id¥leném signaliza£ním kanále odesílá zprávu Call Setup obsahující informace o volajícím 12.6. Obrázek 12.6: Call Setup Poté dojde k p°esunu komunikace na hovorový kanál (op¥t pomocí Assigment Command) na TS2. Nyní jsou známy pot°ebné informace k dekódování hovorových dat, viz. níºe. P°ehled p°id¥lených hov. kanál· Identita Kanál (Timeslot) TMSI IMSI 1 230024100906226 TCH/F (1) TCH/F (2) 105 12 DEMONSTRACE REALIZOVANÝCH ÚTOK Airprobe v p°ípad¥ kongurace s hovorovým kanálem ukládá do výstupního souboru získaná hovorová data. Hovor je pak uloºen v audio formátu au.gsm. Pro získaní hovorových dat z TS1 je pouºit následující p°íkaz : ./go.sh data_openbts_arfcn1.cfile 64 1T 0000000000000000 Pro správnou funkci skriptu je pot°eba doplnit ²ifrovací klí£ samými nulami. Výstupem pak je soubor speech.au.gsm. Jelikoº soubor formátu gsm není moºno b¥ºn¥ p°ehrát je pot°eba p°evést získaný soubor pomocí aplikace toast do audio formátu au. toast d speech.au.gsm Získaný soubor byl následn¥ p°ejmenován na mv speech.au call_ts1.au Tento soubor lze následn¥ p°ehrát pomocí konzolové verze p°ehráva£e VLC cvlc call_ts1.au Obdobný proces byl následn¥ proveden i pro TS 2 : ./go.sh data_openbts_arfcn1.cfile 64 2T 0000000000000000 toast d speech.au.gsm mv speech.au call_ts2.au cvlc call_ts2.au P°i poslechu získaných hovor· bylo bohuºel sly²et ru²ení, jelikoº hovorová data jsou vysoce citlivá na chybovost. Toto je jednak zp·sobeno nedokonalostí synchronizace MS a OpenBTS. Dále m·ºe být kvalita zhor²ena ru²ením signál· získaného pomocí DVB-T p°ijíma£e. Jako dal²í krok v pasivním odposlechu je moºné provést zachycení a analýzu datového provozu mezi BTS a MS v reálné sítí GSM provozované lokálním operátorem. P°i reálné útoku by bylo pot°eba nejprve ob¥´ lokalizovat, toto by bylo provedeno pomocí HLR Query. Následn¥ by bylo pot°eba zjistit identitu TMSI ob¥ti útoku. Toto je moºno provést zasíláním naru²ených SMS zpráv tzv. Silent SMS, které jsou doru£eny na cílovou MS, av²ak nejsou z d·vodu po²kození uºivateli zobrazeny. Oba tyto kroky je moºno p°esko£it, pokud se provádí testovací odposlech komunikace MS ve svém vlastnictví (jako v na²em p°ípad¥). Po analýze okolní situace byla jako nejvhodn¥j²í BTS k zachycení provozu zvolena BTS operátora O2 s identikátorem 17051. Analýza byla provedena pomocí aplikace GSM Signal Monitoring na mobilním telefonu s OS Android. Bliº²í popis odposlouchávané BTS lze získat pomocí databáze £eských základnových stanic na webu www.gsmweb.cz a je znázorn¥na v následující tabulce. Informace o BTS s identifikátorem Cell ID 17051 CID LAC ARFCN BSIC Okres 17051 1713 94 45 Ostrava Umíst¥ní Ostrava-Poruba, Pavlouskova 4333/1 Zvolené BTS je provozujícím operátorem p°id¥len frekven£ní kanál ARFCN 94. Toto odpovídá frekvenci 953.8MHz pro downlink a 908.8MHz pro uplink. Pro záznam komunikace byl pouºit nástroj rtl_sdr s následující kongurací : 106 NGN PRO VUT A VB-TUO rtl\_sdr f 953.761e6 s 1e6 data\_gsm_17051.bin Výsledná frekvence f byla op¥t získána ode£tením odchylky za°ízení od reálné frekvence. Komunikace pak byla zaznamenána do souboru data_gsm_17051.bin. Jako vzorkovací frekvence byla zvolena hodnota 1MHz. B¥hem zachytávání komunikace byl proveden telefonní hovor ve sm¥ru od monitorované MS a následn¥ byla na tuto stanici také zaslána SMS zpráva. Po ukon£ení sb¥ru dat bylo pot°eba p°evést soubor data_gsm_17051.bin do formátu cle pomocí aplikace GRC. Výsledný soubor pak byl uloºen pod názvem data_gsm_17051.cle. P°ed dal²í analýzou dat je pot°eba získat hodnotu TMSI ob¥ti. TMSI je identikace MS pro pot°eby sít¥ GSM a proto je tato hodnota pro koncového uºivatele b¥ºným zp·sobem nep°ístupná. Pro zji²t¥ní TMSI bylo proto v laborato°i vyuºito £te£ky SmartCard a aplikace SIMSpyII. Pomocí této aplikace je také moºno zjistit poslední pouºitou hodnotu ²ifrovacího klí£e Kc. Výstup aplikace SIMSpy je zachycen na obr. 12.7 Obrázek 12.7: Získání TMSI a ²ifrovacího klí£e Kc pomocí aplikace SIMSpyII Nyní bylo moºné provést analýzu získaných dat. ./go.sh data\_gsm\_17051.cfile 64 0C Jelikoº se jednalo o reálnou BTS bylo pot°eba zjistit kdy do²lo k Pagingu sledované MS a to proto, ºe poté následuje p°íkaz Immediate Assignment ur£ující následný kanál pro komunikaci. Na následujícím obr. 12.8 je moºné vid¥t Paging Request s TMSI ob¥ti a následný Immediate Assignment. V tomto okamºiku MS za£ne sledovat signaliza£ní kanál SDCCH/8 na TS 1. Dal²ím krokem je tedy analýza tohoto kanálu: ./go.sh data_gsm_17051.cfile 64 1S V¥t²ina komunikace na tomto kanálu je v²ak ²ifrovaná a proto p°i nezadání ²ifrovacího klí£e získáme pouze ne²ifrované informace, jako jsou autentiza£ní poºadavky, Location Update, a 107 12 DEMONSTRACE REALIZOVANÝCH ÚTOK Obrázek 12.8: P°id¥lení signaliza£ního kanálu pro odchozí hovor p°edev²ím zprávy Ciphering Mode Command, které zahajují proces ²ifrování komunikace mezi MS a BTS. V reálném útoku by nyní bylo pot°eba provést prolomení ²ifrovacího klí£e Kc. Jak jiº bylo zmín¥no vý²e, pro testovací ú£ely byl získán ²ifrovací klí£ pomocí aplikace SIMSpy a £te£ky SmartCard. ./go.sh data_gsm_17051.cfile 64 1S 976f2b14c8970800 Analýzou výstupu je moºno odhalit £íslo volajícího 12.9 ve zpráv¥ Call Setup. Obrázek 12.9: íslo volajícího Následuje p°id¥lení hovorového kanálu zprávou Assignment Command, ze které je moºné identikovat TS (2) a konguraci hovorového kanálu. Následn¥ je moºné p°istoupit také k získání vlastních hovorových pomocí následujícího p°íkazu: ./go.sh data_gsm_17051.cfile 64 2T 976f2b14c8970800 Výstupní zvukový soubor je následn¥ konvertován a p°ejmenován. toast d speech.au.gsm mv speech.au call_ts2_gsm_17051.au cvlc call_ts2.au Délka audio souboru odpovídá délce hovoru, nicmén¥ provedené konverzaci nelze rozum¥t. Zachycení SMS pak m¥lo obdobný pr·b¥h jako p°i odposlechu v testovací síti a samotná SMS v£etn¥ odchozího £ísla je moºné vid¥t na obr. 12.10. 108 NGN PRO VUT A VB-TUO Obrázek 12.10: Odeslaná SMS 13 Bezpe£nostní problémy VoIP Drtivá v¥t²ina bezpe£nostních problém· VoIP vzniká z faktu, ºe IP telefonie pracuje na otev°ených systémech, vyuºívá stávající IP sít¥, standardní prvky a známé opera£ní systémy. To znamená, ºe nebezpe£ím jsou v²echny známé problémy z oblasti IP. Lze konstatovat, ºe pokud dokáºe n¥kdo úto£it na £ást sít¥ Internet, tak m·ºe úto£it na VoIP. Bezpe£nostní riziko u protokolu UDP je vy²²í neº u TCP a prakticky ve²kerá koncepce VoIP je postavena na UDP. Z pohledu VoIP m·ºeme bezpe£nost rozd¥lit na zabezpe£ení signalizace a vlastního p°enosu hlasu. Ur£it¥ si dokáºeme p°edstavit útok typu DoS (Denial of Service), nemusí nakonec jít ani o konkrétní útok na n¥který z centrálních logických prvk· VoIP. Dal²ím potencionálním problémem je získání citlivých informací z odchycené signalizace p°i registraci a následné zneuºití, autentizace ²ifrovaným heslem p°i p°ihlá²ení by m¥la být samoz°ejmostí. Nep°ehlédnutelným rizikem VoIP jsou odposlechy, zabezpe£ení médií byla v¥nována p°edchozí kapitola. Pokud se podíváme do historie, tak ochran¥ telekomunikací byla vºdy v¥nována pozornost, spojovací systémy nebyly voln¥ p°ístupné, totéº lze °íci o dokumentaci k nim, kaºdý výrobce si chránil své know-how a oblast spojovacích prvk· se jevila jako uzav°ená. IP telefonie je mnohdy postavena na známých opera£ních systémech a °ada men²ích poskytovatel· IP telefonie pouºívá open-source °e²ení, takºe jsou odborné ve°ejnosti známé i bezpe£nostní problémy. 13.1 Zabezpe£ení signalizace ve standardu H.323 Ve²kerá komunikace v H.323, která se týká signalizace, pouºívá syntaxi ASN.1 (Abstract Syntax Notation) s kódováním PER (Packet encoding Rules), tím je i zaji²t¥no, ºe p°ená²ený kód není voln¥ £itelný bez zp¥tného p°ekladu. A£koliv rozkódování nelze povaºovat za problém a sí´ové analyzátory se s H.323 vypo°ádají, tak binární kód je ne£itelný pro elementární nástroje jako ngrep nebo tcpdump. Oproti SIP protokolu je H.323 komplikovaný a má zcela nov¥ vyvinuté zabezpe£ení, které je popsáno v doporu£ení ITU-T H.235, naproti tomu pro SIP se nic nového netvo°ilo a pouºily se jiº známé nástroje. Standard H.235 byl publikován poprvé v únoru roku 1998 jako specikace bezpe£nosti a ²ifrování ur£ené pro multimediální terminály H.323, lze jej pouºít obecn¥ pro za°ízení vyuºívajících H.245 (media control standard pro vyjednávání parametr· pro média). Poslední úprava zabezpe£ení v H.323 nese ozna£ení H.235.9 a je z roku 2005. 109 13 BEZPENOSTNÍ PROBLÉMY VOIP 13.1.1 Autentizace H.323 terminál· Autentizace terminál· je v H.323 zaloºena na p°edání hesla v poli CryptoToken ve zprávách RAS, m·ºe se ov²em p°edávat i v H.225.0 Q931. ifrování obsahu RTP se °e²í p°edáním klí£· p°es H.245, coº je popsáno jiº ve zmín¥ném doporu£ení H.235. Pro kryptování hesla se pouºívá otisk funkce HMAC-SHA1 nebo MD5. Pro ukázku si uve¤me pole CryptoToken zprávy RRQ (Registration Request). cryptoTokens: 2 items Item 0 Item: cryptoEPPwdHash (0) cryptoEPPwdHash alias: h323-ID (1) h323-ID: 950012315 timeStamp: Feb 26, 2006 15:36:41.000000000 token algorithmOID: 1.2.840.113549.2.5 (md5) paramS hash: 8BB5DFAE1F23EA0AA5C7E73C23B18639 Princip posílání kryptotoken· se ukázal být velmi praktický, k ov¥°ení m·ºe dojít nejen p°i registraci v RRQ, ale i p°i samotném volání a Gatekeeper pro autorizaci provedení volání m·ºe vyºadovat ov¥°ení pole CryptoToken. H.235 denuje následující bezpe£nostní proly: základní bezpe£nostní prol (zabezpe£uje signalizaci), podpisový (zabezpe£uje signalizaci), pouºívá pokro£ilej²í metody zabezpe£ení, hybridní (zabezpe£uje signalizaci), kombinuje základní a podpisový prol, hlasem ²ifrovaný (zabezpe£uje média), pouºívá se v kombinaci s ostatními proly. Obrázek 13.1: Základní bezpe£nostní prol 13.1.2 Bezpe£nostní proly Základní bezpe£nostní prol 13.1 pouºívá pouze symetrické ²ifrování, tzn. ºe ²ifrování se provádí p°es sdílený klí£ (heslo). V¥t²ina koncových za°ízení, která mají podporu H.235, podporují pouze tento prol. Na obrázku je vid¥t, které sluºby jsou tímto prolem poskytovány a jak jsou °e²eny jednotlivé funkce. Podpisový bezpe£nostní prol k ²ifrování údaj· 13.2pouºívá asymetrické ²ifrování a techniky digitálního podpisu. Tento prol je náro£n¥j²í na výkon systému, protoºe se pokaºdé 110 NGN PRO VUT A VB-TUO Obrázek 13.2: Podpisový bezpe£nostní prol. musí generovat digitální podpis na stran¥ odesilatele a poté probíhá jeho ov¥°ení na stran¥ p°íjemce. Hlasem ²ifrovaný bezpe£nostní prol 13.3 m·ºe být pouºit v kombinaci s vý²e uvedenými proly. Generování a distribuce klí£e se v tomto prolu provádí p°es protokol H.245 a vým¥na v protokolu H.225. Proti útok·m typu DoS tento prol denuje protokolem H.235 tzv. anti-spammnig procedury. Vyuºívá algoritm· SHA1, nebo DES. Tento prol také zaru£uje d·v¥rnost p°ená²eného obsahu. Obrázek 13.3: Hlasem ²ifrovaný bezpe£nostní prol. Posledním prolem je hybridní bezpe£nostní prol na obr. 13.4, který kombinuje dva vý²e uvedené proly, konkrétn¥ základní a podpisový bezpe£nostní prol. Digitální podpis je pouºit pouze p°i první vým¥n¥ (handshake), poté je ur£eno tajné heslo. Pro vysv¥tlení si je²t¥ uvedeme ú£el funkcí volání u zmi¬ovaných prol·: RAS (Request, Admission and Status), komunikace s Gatekeeperem, H.225 (jedná se o H.225/Q.931 Call Signaling), signalizace volání, H.245 (Media Control), signalizace pro °ízení a vyjednávaní médií, RTP (Real Time Protocol), p°enos médií. 111 13 BEZPENOSTNÍ PROBLÉMY VOIP Obrázek 13.4: Hybridní bezpe£nostní prol. 13.2 Zabezpe£ení signaliza£ního protokolu SIP SIP (Session Initiation Protocol) je protokolem pro navázání, modikaci a ukon£ení spojení. Základ je popsán v RFC 3261 na který navazuje mnoho roz²í°ení nap°íklad pro IM (Instant Messaging) a prezenci. Principy a problémy popsané dále samoz°ejm¥ platí i pro tyto roz²í°ení. SIP vy²el z HTTP protokolu, je tedy na rozdíl od H.323 textový. Textová podstata dává protokolu lep²í £itelnost a roz²i°itelnost, kterou v²ak také m·ºe vyuºít potencionální pozorovatel nebo úto£ník. 13.2.1 Autentizace v SIP Základním prvkem bezpe£nosti je autentizace, která v SIPu vzhledem tomu, ºe ideovým rodi£em je protokol HTTP, pouºívá schéma HTTP Digest. Ve star²í verzi standartu (RFC 2543) bylo umoºn¥no i schéma HTTP Basic V rámci komunikace se je²t¥ rozli²uje autentizace mezi uºivateli (User-to-User) a mezi proxy serverem a uºivatelem (Proxy-to-User). Vysv¥tleme si pouºití schématu HTTP Digest na p°íkladu registrace. Obrázek 13.5: Autentizace p°i registraci. Za registraci v SIPu je odpov¥dný REGISTRAR Server, který p°ijímá ºádosti o registrace, odpovídá na n¥ a zapisuje do lokaliza£ní databáze kontaktní údaje uºivatele. Nepochybn¥ je ºádoucí, aby se uºivatel p°i registraci autentizoval. P°edpokládejme, ºe uºivatel obdrºel 112 NGN PRO VUT A VB-TUO d·v¥ryhodným zp·sobem uºivatelské jméno a heslo, které si uloºil ve svém IP telefonu. Metoda HTTP Digest spo£ívá v tom, ºe ob¥ strany, jak server tak i klient, mají sdílené tajemství (heslo) a pomocí daných vstupních parametr· je jednosm¥rnou funkcí (MD5) vygenerován otisk (hash). Ha²ovací funkce je jednocestná a bezkolizní. Funkce f : X → Y nazveme bezkolizní, jestliºe je výpo£etn¥ nemoºné nalézt r·zná x, x ∈ X tak, ºe platí f (x) = f (x). Zapsané vyjád°ení prezentuje, ºe neexistují dva stejné výstupy (obrazy) pro r·zné vstupy (vzory) ha²ovací funkce. Pro vyjád°ení jednosm¥rnosti pouºijeme následující denici. Funkci f : X → Y nazveme jednosm¥rnou (jednocestnou), jestliºe z jakékoli hodnoty x ∈ X je snadné vypo£ítat y = f (x), ale pro náhodn¥ vybranou hodnotu y ∈ f (X) je aktuálními výpo£etními prost°edky neproveditelné) najít její vzor x ∈ X tak, aby y = f (x). Slovn¥ vyjád°eno, nedokáºeme z obrazu nalézt vzor, je to p°íliº t¥ºká a výpo£etn¥ nemoºná úloha. Pokud otisk zaslaný SIP klientem bude souhlasit s °et¥zcem, který spo£ítal server, tak autentizace bude úsp¥²ná a kladn¥ tak vy°ízena, získaný otisk vrací klient na server v poloºce response. Výsledný otisk je spo£ítán p°es t°i hashovací funkce, zp·sob výpo£tu a parametry, které do ha²ovací funkce vstupují jsou dle RFC 2069 denovány následovn¥. HA1 = MD5 (username : realm : password) HA2 = MD5 (method : digestURI) response = MD5 (HA1 : nonce : HA1) Roz²í°ení HTTP digest o dal²í zabezpe£ení °e²í RFC 2617, ve kterém se denuje kvalita ochrany qop (Quality of protection), náhodný °et¥zec nonce je generován nejen serverem, ale i klientem jako clientNonce a klient navíc inkrementuje £íta£ nonceCount. Výpo£et poloºky response je tedy dán následovn¥. response = MD5 (HA1 : nonce : nonceCount: clientNonce : qop : HA1) Samoz°ejm¥, ºe i toto roz²í°ení se v SIP signalizaci pouºívá. Na obr. 13.6 byla znázorn¥na vým¥na SIP zpráv p°i registraci s autentizací. ádost REGISTER je odeslána bez autentiza£ních údaj· na SIP Proxy, ta odmítá odpov¥dí 401 Unauthorized, v odpov¥di posílá bliº²í informace k autentizaci, tzn. realm, metodu a nonce, bez pouºití zmi¬ovaného roz²í°ení RFC 2617. Status-Line: SIP/2.0 401 Unauthorized Message Header Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bKd8754z-d8;rport=33209 To: "voznak"<sip:[email protected]>;tag=c10ed4fff3e6fb17efd0bfbdcce87ce2 From: "voznak"<sip:[email protected]>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 1 REGISTER WWW-Authenticate:Digest realm="cesnet.cz",nonce="48ad92c",algorithm=MD5 Server: Sip EXpress router (0.9.6 (i386/linux)) Content-Length: 0 Klient má nyní v²echny poloºky pro výpo£et otisku, pochopiteln¥ zná svou URI a sdílené tajemství password. Klient akceptuje zaslané informace a vypo£te otisk, který za²le v poloºce response ve zpráv¥ REGISTER, tentokrát je úsp¥²n¥ autentizován a jako odpov¥¤ na REGISTER dostává 200 OK, viz. obr. 13.6. 113 13 BEZPENOSTNÍ PROBLÉMY VOIP Obrázek 13.6: Zachycení SIP signalizace p°i volání s autentizací. Request-Line: REGISTER sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bK-d8bc45e75b347-;rport Max-Forwards: 70 Contact: <sip:[email protected]:18188;rinstance=8546638886339213> To: "voznak"<sip:[email protected]> From: "voznak"<sip:[email protected]>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 2 REGISTER Expires: 3600 User-Agent: X-Lite release 1100l stamp 47546 Authorization: Digest username="voznak", realm="cesnet.cz", nonce="48ad92c", uri="sip:cesnet.cz", response="1ca1df39a865353b8703343cbdfbb062", algorithm=MD5 Content-Length: 0 V p°ípad¥, ºe Proxy server pot°ebuje p°ed zpracováním poºadavku uºivatele ov¥°it, ºádá o to v odpov¥di 407 Proxy Authentication Required a v hlavi£ce Proxy-Authenticate je obsaºena výzva. Klient doplní do poºadavku hlavi£ku Proxy-Authorization s pat°i£nými údaji. Nejen HTTP Digest lze pouºít jako bezpe£nostní mechanizmus pro SIP, moºné jsou celkem £ty°i zabezpe£ení signalizace: HTTP Basic Authentication, pouze v zastaralém RFC 2543, HTTP Digest Authentication, nejpouºívan¥j²í uºití pro bezpe£nou autentizaci, Secure Mime, vyuºití pokro£ilej²ích metod ve°ejných klí£· PKI, SIPS URI, pouºití ²ifrovaného protokolu TLS, je z dne²ního pohledu nejbezpe£n¥j²ím °e²ením. HTTP Basic Authentication je prvním mechanizmem, který zaji²´uje autentizaci pomocí sdíleného hesla pro SIP dle RFC 2543. Data nejsou ²ifrovány a není také zaru£ena integrita zprávy, coº je z pohledu dne²ních nárok· na zabezpe£ení prakticky nepouºitelné. Aktuáln¥ pouºívané jádro SIPu dle RFC 3261 neumoº¬uje pouºití tohoto mechanizmu. HTTP Digest Authentication vychází z p°edchozí metody s tím rozdílem, ºe místo p°enosu otev°eného hesla ho ²ifruje pomocí ha²ovací funkce MD5. Tato metoda ov¥°uje autenticitu na základ¥ sdíleného hesla. Obsah zprávy se v²ak nijak ne²ifruje. 114 NGN PRO VUT A VB-TUO Secure MIME (S/MIME) je, jak z názvu vyplývá, zabezpe£ení tzv. MIME (Multipurpose Internet Mail Extension). Konkrétn¥ tato metoda zabezpe£í obsah této zprávy a zaru£í i její integritu. Existuji dva zp·soby ²ifrování obsahu dat MIME. První je application/pkcs7-mime a dokáºe digitáln¥ podepsat i za²ifrovat data. Druhý zp·sob multipart/signed je podobný prvnímu s tím rozdílem, ºe zpráva obsahuje ²ifrovaná i ne²ifrovaná data. K ov¥°ení autentizace se pouºívá architektura ve°ejných klí£· (PKI). Pro utajení obsahu zprávy jsou vyuºity symetrické kryptogracké primitivy (DES, 3DES, AES). Po p°ijetí poºadavku obsahující S/MIME od UAC (User Agent Client) je pot°ebné, aby byl nejprve ov¥°en certikát. UAS (User Agent Server) ov¥°uje certikát s dostupnými ko°enovými certikáty certika£ních autorit. Z pole from SIP hlavi£ky ºádosti je ov¥°eno, zda ten, komu byl certikát vydán, souhlasí s údajem v URI. Pokud je certikát podepsaný sám sebou anebo neznámou certika£ní autoritou, tak není ov¥°en a p°íjemce takovéto ºádosti je dotázán, zda spojení akceptuje a následn¥ je certikát povaºován jako d·v¥ryhodný a je za°azen do adresá°e certikát·. Stejn¥ tak je ov¥°ena i druhá strana spojení, kde se pouºije pole To SIP hlavi£ky. SIPS URI (TLS) vyuºívá architekturu ve°ejných klí£· pro ov¥°ení autentizace. P°i pouºití této metody se m¥ní prex identika£ní hlavi£ky na sips. Aby byla zaru£ená bezpe£ná komunikace, pouºívá tato metoda ²ifrovaný protokol Transport Layer Security (TLS). Tento protokol vyuºívá asymetrické ²ifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a ha²ovací funkce. P°i pouºití této metody je kladena podmínka, ºe protokol TLS je pouºit na celé cest¥ zprávy a pro SIP musí být pouºit protokol TCP. IETF se ov²em zabývá i návrhem SIP DTLS (SIP over Datagram Transport Layer Security), takºe lze o£ekávat, ºe v budoucnu bude moºné pouºití SIPS i nad UDP. 13.3 Systém mezidoménové d·v¥ry Úkolem je zaji²t¥ní oboustranné d·v¥ry, kterou si m·ºeme dle vý²e uvedeného rozd¥lit do t°ech moºností: vkládání ov¥°ené identity, mezidoménová d·v¥ra s pouºitím S/MIME, mezidoménová d·v¥ra s pouºitím TLS 13.3.1 Vkládání ov¥°ené identity Tento zp·sob p°edstavuje exibilní metodu mezidoménové d·v¥ry na protokolu SIP. Tuto metodu si m·ºeme p°edstavit jako federativní systém, coº v praxi znamená, ºe n¥kolik institucí se mezi sebou domluví na zp·sobu vzájemné d·v¥ry a form¥ p°edávání ov¥°ené identity. Pokud bude chtít klient komunikovat s jakýmkoliv subjektem ve federaci, p°ihlásí se ke svému domovskému serveru, kde je prokázána jeho identita a autentiza£ní hlavi£ky této domény jsou nahrazeny denovanou externí identitou. Nyní je volající ov¥°en a od domácí instituce má povolení uskute£nit komunikaci. Volaný ú£astník z federativní instituce ov¥°í platnost identity v poºadavku, který obdrºí od volajícího a povolí spojení. Systém m·ºe samoz°ejm¥ obsahovat dal²í pravidla a dohodnuté konvence, podle kterých se budou jednotlivé instituce zastupující své klienty °ídit. Existuje n¥kolik metod vkládání doménou ov¥°ené identity: Tokeny, autentiza£ní hlavi£ka domény je nahrazena tzv. tokenem (zna£kou), který je vytvo°en na základ¥ p°ijatých údaj· od klienta, který se na tuto doménu p°ihlásil a 115 13 BEZPENOSTNÍ PROBLÉMY VOIP autorizoval. V praxi se pouºívá formát tokenu známý jako AIB (Authenticated Identity Body). Jakmile je token vytvo°en, musí být serverem podepsán. Po podepsání se vkládá do samotné SIP zprávy pomocí t°í zp·sob·. Bu¤ je token vrácen klientovi na schválení a vloºení, nebo je token vloºen do zprávy p°ímo autentiza£ní sluºbou a nebo klient jiº p°edvídá URI, pro kterou bude token dostupný. Podepsání n¥kterých hlavi£ek, je to obdoba tokenu. Nap°íklad p°i pouºití AIB (Authenticated Identity Body) je p°i poºadavku INVITE tato identita uloºena v hlavi£kovém poli From uvnit° message/sip nebo message/sipfrag a podepsána autentiza£ní sluºbou. SAML (Security Assertion Markup Language), ten denuje na XML zaloºený systém pro vytvá°ení a vým¥nu bezpe£nostních informací mezi entitami. Pro vyuºití v SIP musel být vyvinut nový prol SAML. SAML funguje na autorizaci ozna£ované jako Trait-based, uºivatel je oprávn¥n pouºívat n¥které zdroje zaloºené na rolích a vlastnostech. Ov¥°ení identity se pak skládá z potvrzení autoriza£ní sluºby a s vyuºitím SAML prolu. 13.3.2 Mezidoménová d·v¥ra s pouºitím S/MIME S/MIME (Secure / Multipurpose Internet Mail Extensions) je zabezpe£ený MIME a tato metoda poskytuje kryptogracké zabezpe£ovací sluºby pro elektronické zprávy. Pro pouºití S/MIME je nutné získat a nainstalovat certikát pomocí certika£ní autority (CA). V praxi se nejvíce pouºívají soukromé separátní klí£e (certikáty), certikát poté slouºí jako klí£ k za²ifrování SIP zprávy. K ov¥°ení autentizace a vystav¥ní mezidoménové d·v¥ry se pouºívá architektura ve°ejných klí£· (PKI). P°i ²ifrování SIP zprávy S/MIME se pouºívají dva zp·soby, prvním je application/pkcs7-mime, který dokáºe digitáln¥ podepsat a za²ifrovat data, druhým je multipart/signed , ten je podobný prvnímu s tím rozdílem, ºe zpráva obsahuje ²ifrovaná i ne²ifrovaná data. Mezidoménová d·v¥ra s pouºitím S/MIME pracuje na podobném principu jako p°i pouºití TLS. Request-Line: INVITE sip:cesnet.cz SIP/2.0 Via: SIP/2.0/UDP 195.168.1.10:18188;branch=z9hG4bK-d8bc45e75b347-;rport Max-Forwards: 70 Contact: <sip:[email protected]:18188;rinstance=8546638886339213> To: "voznak"<sip:[email protected]> From: "voznak"<sip:[email protected]>;tag=f861ac5a Call-ID: Mzg1M2VlZDRkOWQ5NmJlNzA0MTk1OGNhZDE3MjZiNDg. CSeq: 1 INVITE Content-Type: multipart/signed;protocol=application/pkcs7-signature; micalg=sha1; boundary=boundary42 Content-Length: 568 13.3.3 Mezidoménová d·v¥ra s pouºitím TLS TLS (Transport Layer Security) je protokol umoº¬ující zabezpe£enou komunikaci na Internetu pro sluºby WWW, e-mail a dal²í p°enosy dat. Mezi tyto sluºby samoz°ejm¥ pat°í i VoIP, a TLS protokol se v této sluºb¥ pouºívá p°eváºn¥ k autentizaci a ²ifrování SIP signalizace. TLS vyuºívá infrastruktury ve°ejného klí£e X.509. Pro ov¥°ení autentizace a vytvo°ení d·v¥ry mezi doménami na protokolu SIP s pouºitím TLS se pouºívá certikát X.509 verze 3. TLS se v SIP pouºívá ze dvou hlavních d·vod·: dokáºe identikovat SIP zdroj ve form¥ domény, p°es kterou poté certikát prokazuje své oprávn¥ní, 116 NGN PRO VUT A VB-TUO dokáºe garantovat na transportní vrstv¥, ºe uºivatel, kterým bylo spojení p°es TLS sestaveno, je opravdu tím, za kterého se vydává. Obrázek 13.7: Mezidoménová d·v¥ra. Uºivatel v domén¥ cvut.cz inicializuje spojení odesláním ºádosti INVITE na domovskou SIP Proxy obsluhující doménu cvut.cz, coº je ProxyA. Po nalezení cílové SIP Proxy obsluhující cílovou doménu vsb.cz, coº je ProxyB. P°i nalezení cílové SIP Proxy se uplatní SRV záznamy v DNS, p°ípadn¥ NAPTR, [33]. Oba SIP Proxy servery prezentují své certikáty, aby provedly vzájemnou autentizacii a sestavily spojení. P°i vzniku tohoto spojení °e²í SIP Proxy d·v¥ru certikátu. ProxyA se dozvídá, ºe certikát proxyB je platný pro doménu vsb.cz a pot°ebuje ov¥°it platnost certikátu od proxyB. Certikát bude obsahovat pln¥ kompetentní název hosta [email protected] nebo SIP URI, certikát potvrdí oprávn¥ní proxyB k domén¥ vsb.cz , tzn. identitu sip:vsb.cz jako p°íchozí SIP Proxy (Inbound SIP Proxy). ProxyB p°ijme certikát obsahující jméno [email protected] a musí být z n¥j £itelné, ºe proxyA má funkci SIP odchozího proxy (Outbound SIP Proxy) pro doménu cvut.cz. Zásadní otázkou potom z·stává, kdo certikát vystavil a zda takovému certikátu d·v¥°ujeme. V pracovní skupin¥ ECS byl vybrán TLS protokol jako nejvhodn¥j²í zp·sob zabezpe£ené komunikace mezi SIP Proxy akademických institucí. Adresace bude probíhat jak pomocí URI tak i telefonním £íslem v mezinárodním formátu. Problém sm¥rování byl vy°e²en pomocí ve°ejného a infrastrukturního ENUMu v doménách e164.arpa a nreum.net. P°es záznamy NAPTR a SRV v DNS lze nalézt cílovou Inbound SIP Proxy jakékoliv akademické instituce, která bude mít zájem participovat v této síti. Pokud nebude záznam dosaºitelný p°es ve°ejný ENUM (nap°. neúsp¥²n¥ skon£ily ov¥°ovací provozy na Slovensku, ve výcarsku a Austrálii), tak bude moºné pouºít záznam odkazující na doménu cílového p°íjemce p°es infrastrukturní ENUM nrenum.net. Jako certika£ní autority SIP Proxy budou slouºit organizace provozující výzkumné sít¥ v jednotlivých zemích, aktuáln¥ se °e²í je²t¥ otázka distribuce seznamu ve°ejných klí£· v²ech t¥chto autorit, dosud byla vyzkou²ena validace pouze s lokálním úloºi²t¥m. 117 REFERENCE Reference [1] Gns3 documentation, 2014. URL <http://www.gns3.net/documentation/> . [2] Manual for the INET Framework of OMNeT++, 2014. URL <https://github.com/ inet-framework/inet-doc> . [3] MATLAB SimEvents Model and simulate discrete-event systems, 2014. URL <http: //www.mathworks.com/help/simevents/> . [4] OMNeT++ documentation and tutorials, 2014. documentation> . URL <http://www.omnetpp.org/ [5] S.K. Bose. An Introduction to Queueing Systems. Network and Systems Management. Springer, 2002. ISBN 9780306467349. [6] D. Burgess and S. Harvind. Open BTS Project. Kestrel Signal Processing, California., 2008. [7] I. Goldberg and M. Bricenom. Gsm cloning, 1998. berkeley.edu/isaac/gsm-faq.html> . URL <http://www.isaac.cs. [8] D. Gross, J.F. Shortle, J.M. Thompson, and C.M. Harris. Fundamentals of Queueing Theory. Wiley Series in Probability and Statistics. Wiley, 2013. ISBN 9781118625712. [9] L. Harte. Introduction to global system for mobile communication (GSM): Physical channels, network, and operation. Fuquay-Varina, NC: Althos, 2005. ISBN 1932813047. [10] P. Hebák and J. Kahounová. Po£et pravd¥podobnosti v p°íkladech. Informatorium, 2010. ISBN 9788073330774. [11] E. Holma and A. Toskala. LTE for UMTS - OFDMA and SC-FDMA based radio access. John Wiley. 1st. ed., 2009. ISBN 9780470994016. [12] L. Kadlec. Modelování obsluhových systém· pomocí nástroje octave queueing package. Master's thesis, VB-TU Ostrava, Fakulta elektrotechniky a informatiky, 2014. [13] L. Kleinrock. Queueing Systems: Theory. Number sv. 1 in A Wiley-Interscience publication. Wiley, 1976. ISBN 9780471491101. [14] N. Koke²ová. Principy £inností soudobých mobilních komunika£ních sítí. VUT v Brn¥, BP, 2007. [15] T. Kupec. Modelování mobilních sítí 3. a 4. generace pomocí simula£ních nástroj·. Master's thesis, VB-TU Ostrava, Fakulta elektrotechniky a informatiky, 2012. [16] J. Kvapil. Aplikace sm¥rovacích protokol· v simula£ním prost°edí omnet++. Master's thesis, VB-TU Ostrava, Fakulta elektrotechniky a informatiky, 2014. [17] Security Research Labs. Decrypting gsm phone calls, 2009. URL <https://srlabs.de/ decrypting_gsm/> . 118 NGN PRO VUT A VB-TUO [18] D. Margrave. Gsm security and encryption., george mason university, 2010. URL <http: //www.hackcanada.com/blackcrawl/cell/gsm/gsm-secur/gsm-secur.html> . [19] Moreno Marzolla. A Queueing Package for GNU Octave, 2014. URL <http://www. moreno.marzolla.name/software/queueing/> . [20] K. Molnár. Moderní sí´ové technologie. VUT v Brn¥, 2011. [21] V. Niemi and K. Nyberg. UMTS security. John Wiley., 2003. ISBN 0470847948. [22] K. Nohl and S. Munaut. 27th chaos communication congress: Wideband gsm sning. chaos communication congress, 2010. URL <http://events.ccc.de/congress/2010/ Fahrplan/events/4208.en.html> . [23] Osmo. Osmosdr, 2014. URL <http://sdr.osmocom.org/trac/wiki/rtl-sdr> . [24] C. Paget. Speakers and presentations:defcon 18. defcon, 2010. URL <https://defcon. org/html/links/dc-archives/dc-18-archive.html#Paget2> . [25] C. Paget and K. Nohl. 26th chaos communication congress: Gsm: Srsly, 2009. URL <http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html> . [26] M. Proke² and M. Voz¬ák. Bezpe£nostní problémy GSM. VB-TU Ostrava, DP, 2014. [27] ITU-R M.1645. Recommendation. Framework and overall objectives of the future development of imt-2000 and systems beyond imt-2000., 2003. URL <http://www.itu.int/ dms_pubrec/itu-r/rec/m/R-REC-M.1645-0-200306-I!!PDF-E.pdf> . [28] S. Redl, M. Weber, and M. Oliphant. GSM and Personal Communications Handbook. Artech House, 1998. ISBN 9780890069578. [29] T. Richtr. Technologie pro mobilní telekomunikace, 2001. URL <http://tomas.richtr. cz/mobil/> . [30] Z. Rýzner. Vyuºití teorie hromadné obsluhy p°i návrhu a optimalizaci paketových sítí. VUT v Brn¥, 2011. [31] M. Sedlá°. Time memory trade o útoky v kryptograi. Masarykova Univerzita., 2012. [32] A.S. Sethi and V.Y. Hnatyshin. The Practical OPNET User Guide for Computer Network Simulation. Taylor & Francis, 2012. ISBN 9781439812051. [33] M. Voznak. Voice over IP. VSB-Technical University of Ostrava., 2009. [34] K. Wehrle, M. Günes, and J. Gross. Modeling and Tools for Network Simulation. Springer, 2010. ISBN 9783642123313. [35] C. Welsh. GNS3 Network Simulation Guide. 9781782160816. Packt Publishing, 2013. ISBN [36] P. Yousef. GSM-Security: a Survey and Evaluation of the Current Situation. Linkoping Institute of Technology., 2004. [37] F. Zítek. Ztracený £as: Elementy teorie hromadné obsluhy. Cesta k v¥dení. Academia Praha, 1969. 119 Autor: Katedra: Název: Místo, rok, vydání: Po£et stran: Vydala: Náklad Miroslav Voz¬ák, Libor Michalek Katedra telekomunika£ní techniky Sít¥ nových generací a jejich bezpe£nostní problémy pro integrovanou výuku VUT a VB-TUO Ostrava, 2014, 1. vydání 119 Vysoká ²kola bá¬ská-Technická univerzita Ostrava CD-ROM, 30 ks Neprodejné ISBN 978-80-248-3558-7