Sít¥ nových generací a jejich bezpe£nostní problémy pro

Transkript

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.
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)
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
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)
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
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
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 NEJASTJÍCH ROZDLENÍ
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)
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.
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.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)
E(X) =
∞
X
k=1
k
1
m+1
=
m
2
(2.11)
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)
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)
St°ední hodnota normálního rozd¥lení je:
(2.17)
E(X) = µ.
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)
E(X) =
k
.
λ
(2.23)
D(X) =
k
.
λ2
(2.24)
Speciálním p°ípadem Erlangova rozd¥lení pro k = 1je rozd¥lení exponenciální.
11
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)
E(X) =
a+b
.
2
(2.26)
(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)
Z
Γ(α) =
∞
e−x xα−1 dx.
0
Pro α = n se dá indukcí odvodit, ºe Γ(n) = (n − 1)!
12
(2.29)
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¥óvé
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É ETZCE, 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)
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
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¥óvý.
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
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¥óvost (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
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
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¥óvosti. 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óvá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
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
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
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
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)
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
λ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)
5 GNS3
5.1 Úvod
Open-source program GNS3 (Graphical Network Simulator) umoº¬uje emulaci komplexních
síóvý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íóvé 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íóvý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íóvých komponent. Ovládání síóvý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íóvý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íóvá 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íóvý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íóvou 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íóvé komunikace prost°ednictvím síóvé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
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
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íóvá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
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íóvý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
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
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
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íóvou
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íóvé provozu a
rezervace p°enosové rychlosti pro jednotlivé sluºby.
RA(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)#class-map DATA
RC(config)#class-map VOICE
RC(config-cmap)#match access-group 101
RC(config)#class-map VIDEO
RC(config)#class-map DATA
34
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)#class DATA
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)#class DATA
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íóvá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
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)#exit
RA(config)#interface serial 0/0
RA(config-if)#exit
RB(config)#interface serial 0/0
RB(config-if)#exit
RB(config)#interface serial 0/1
RC(config)#interface fastEthernet 0/0
RC(config-if)#exit
RC(config)#interface serial 0/0
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
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íóvé 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
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
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.2.2 e²ení
[U, R, Q, X, p0, pm] = qsmm1 (lambda, mu, m)
lambda (λ) - intenzita poºadavk· (λ ≥ 0).
mu (µ) - intenzita obsluhy (µ > λ).
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 .
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
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í
B = erlangb (A, M)
A - nabízené zatíºení, denované jako A = µλ , kde λ je intenzita p°íchod· a µ je intenzita
obsluhy kaºdého uºivatele.
45
M - po£et identických linek v OS (m ≥ 1).
B - pravd¥podobnost, ºe budou v²echny linky obsazeny
Bylo zvoleno:
λ=60
µ=10
m=10
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í
C = erlangc (A, M)
46
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
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í
B = engset (A, M, N)
N - kone£ný po£et p°íchozích poºadavk·
47
B - pravd¥podobnost, ºe budou v²echny linky obsazeny
Bylo zvoleno:

λ=60
µ=10
M=100
N=200
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
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óvání jednotlivých síóvý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íóvý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
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
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
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
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
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
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
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íóvé 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
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íóvý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;
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]; }
H1: StandardHost {gates: ethg[1]; }
SW1: 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='R1 R2' 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] <-->
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íóvý 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"
**.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 >

68
<Area id="0.0.0.0">
<AddressRange address="H1" mask="H1" status="Advertise" />
<AddressRange address="R1>R2" mask="R1>R2" status="Advertise"
</Area>
/>
/>
/>
/>
/>
/>

<Router name="R1" RFC1583Compatible="true">
<PointToPointInterface ifName="eth1" areaID="0.0.0.0" interfaceOutputCost="1" />
<BroadcastInterface ifName="eth0" areaID="0.0.0.0"
interfaceOutputCost="2" routerPriority="2" />
</Router>
</Router>
</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
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
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íóvý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]; }
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íóvý 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
**.udpApp[0].startTime = 4s
**.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£·.
<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>
<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">
</Router>
<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">
</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"/> 
</AS>
<AS id="65248">
<Router interAddr="10.10.10.2"/> 
</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íóvých prvk·.
<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'
<interface hosts='RB' names='ppp0' address='10.10.10.2'
<interface hosts='RB' names='eth0' address='10.10.10.9'
<interface hosts='R1' names='eth0' address='10.10.10.6'
netmask='255.255.255.0' metric='1'/>
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
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
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
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
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
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
Základnová stanice (BTS) Za°ízení zaji²újí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íóvý spojovací subsystém (NSS)
Síóvý 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.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
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
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
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.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
Obrázek 10.5: Autajení p°ená²ených dat
Obrázek 10.6: Algoritmus A5/1
89
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íóvé 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
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
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
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.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
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
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¥óvý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¥óvou 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¥óvých
nárok· [24, 31] .
Celkovou výpo£etní a pam¥óvou 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¥óvé 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
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
config
config
config
config
config
config
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¥
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
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
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.Identity.MCC 001 // nastavení testovacího MCC
GSM.Identity.MNC 02 // nastavení testovacího MNC
GSM.Identity.ShortName OpenBTS // nastavení názvu sít¥
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
- 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íóvé 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
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
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
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
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
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
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.
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
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íóvé 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
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
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
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
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]>
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
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
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]>
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
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
[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
CD-ROM, 30 ks
Neprodejné
ISBN 978-80-248-3558-7

Sít¥ nových generací a jejich bezpe£nostní problémy pro

Transkript

Podobné dokumenty

Úvod - Ivan Nagy

"O zemi, starých naukách, úctě a souvztažnosti DOBA KDY ZEMĚ

UV ZAŘÍZENÍ obecné informace