Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Bakalářská práce

Databázový systém na sběr a archivaci dat o kvalitě mikrovlnných páteřních spojů GSM sítě Miroslav Lhoťan

Vedoucí práce: Ing. Alexandru Moucha Ph.D.

8. května 2013

Poděkování V první řadě bych chtěl svému vedoucímu panu Ing. Alexandru Mouchovi, Ph.D. za příkladné vedení a ochotu pomoci ve všech ohledech s prací souvisejících. Dále poděkování směřuji k panu Dobroslavu Tyrkasovi ze společnosti Ericsson, který mi velmi pomohl při prvním kontaktu s technologií MINI-LINK, a k pánům Ing. Jiřímu Vondráčkovi a Ing. Pavlu Kubíkovi ze společnosti T-Mobile, za jejich ochotu a pomoc při testování a nasazování aplikace do provozu. Velké poděkování samozřejmě patří i Ing. Vojtěchu Barešovi, Ph.D. a Ing. Martinu Fenclovi za to, že s celým projektem přišli.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 8. května 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Miroslav Lhoťan. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Lhoťan, Miroslav. Databázový systém na sběr a archivaci dat o kvalitě mikrovlnných páteřních spojů GSM sítě. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract This bachelor thesis deals with design and implementation of an application serving for collection of data about signal strengths in GSM network. Data are obtained via SNMP protocol from MINI-LINK devices made by Ericsson. Application is a support for a research being realized at Faculty of Civil Engineering CTU in Prague. Subject of this research is measurement and localization of a rain in the environment. Keywords precipitation, measurement, SNMP, MINI-LINK, database

ix

Abstrakt Tato práce se zabývá návrhem a implementací aplikace pro sběr dat o síle vysílaných a přijímaných signálů v GSM síti. Data se získávají pomocí protokolu SNMP a to ze zařízení MINI-LINK vyráběných společností Ericsson. Aplikace slouží jako podpora výzkumu na Fakultě Stavební ČVUT v Praze, který se zabývá měřením a lokalizací srážek v terénu na základě útlumu signálu. Klíčová slova srážky, měření, SNMP, MINI-LINK, databáze

x

Obsah Úvod

1

1 Vymezení cílů a požadavky 1.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Obecné požadavky . . . . . . . . . . . . . . . . . . . . . . .

3 3 4

2 Použité technologie 2.1 Jazyk implementace 2.2 Protokol SNMP . . . 2.3 Ericsson MINI-LINK 2.4 PostgreSQL . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5 5 5 9 12

3 Návrh 13 3.1 Databázové schéma . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Realizace 4.1 Knihovna SNMP4J . . . . . . . . . . . . . . . . 4.2 PostgreSQL JDBC . . . . . . . . . . . . . . . . 4.3 Databáze . . . . . . . . . . . . . . . . . . . . . 4.4 Balíček cz.cvut.lhotamir.mwlcollection.server . . 4.5 Balíček cz.cvut.lhotamir.mwlcollection.messages 4.6 Balíček cz.cvut.lhotamir.mwlcollection.client . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 20 20 21 26 27

5 Testování 29 5.1 Vývoj a prvotní testování . . . . . . . . . . . . . . . . . . . . 29 5.2 Testování v laboratoři operátora . . . . . . . . . . . . . . . . 30 xi

5.3

Testování v reálné síti

. . . . . . . . . . . . . . . . . . . . .

30

Závěr

33

Literatura

35

A Seznam použitých zkratek

37

B Tabulka hodnot PDU typů

39

C Návod k instalaci a použití aplikace 41 C.1 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C.2 Obsluha serverové části . . . . . . . . . . . . . . . . . . . . . 42 C.3 Obsluha vzdáleného ovládání . . . . . . . . . . . . . . . . . . 43 D Obsah přiloženého CD

45

xii

Seznam obrázků 2.1 2.2 2.3

Struktura SNMP zprávy. . . . . . . . . . . . . . . . . . . . . . . Struktura PDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . Ericsson MINI-LINK . . . . . . . . . . . . . . . . . . . . . . . .

7 9 10

3.1 3.2 3.3

Doménové schéma databáze . . . . . . . . . . . . . . . . . . . . Model požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . Případy užití . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 15 17

4.1 4.2

Schéma databáze . . . . . . . . . . . . . . . . . . . . . . . . . . Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . . . . .

21 28

5.1

Ukázka nasbíraných dat . . . . . . . . . . . . . . . . . . . . . .

31

xiii

Seznam tabulek 2.1 2.2

Struktura SNMP zprávy . . . . . . . . . . . . . . . . . . . . . . Struktura PDU . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

8 9

Úvod V dnešní době je již celkem velká část světa pokrytá sítí GSM. To znamená, že infrastruktura s tímto spojená je velmi rozsáhlá a komplikovaná. Nabízí se tedy otázka, jak tato již existující a fungující zařízení využít jiným a kreativním způsobem. Jedním z možných využití by mohlo být měření a lokalizace srážek. Mikrovlnné páteřní spoje se k tomu jeví jako vhodné z několika důvodů. Kromě toho, že celá infrastruktura je již vybudovaná, je to například fakt, že spoje probíhají v poměrně nízké výšce nad zemí a vzhledem ke své délce lépe postihují plošný charakter srážek. Takový výzkum právě probíhá na Fakultě stavební ČVUT v Praze a cílem této práce je vytvoření systému, který by sbíral data potřebná k vytvoření a kalibraci matematických modelů spojených s tímto výzkumem. V tuto chvíli je po systému požadováno aby data pouze sbíral a nijak je zatím nevyhodnocoval. Tato data budou totiž porovnávána se skutečně naměřenými srážkami v daných oblastech tak budou vytvořeny již zmíněné rovnice a modely.

1

Kapitola

Vymezení cílů a požadavky

1.1

Cíl práce

Cílem této práce je vytvoření aplikace, která bude s vysokou frekvencí získávat data o signálu na páteřních spojích GSM sítě. Tato data budou použita pro výzkum na Fakultě stavební ČVUT v Praze, jak již bylo zmíněno v úvodu. Aplikace bude uchovávat dva typy dat. První jsou samotná data ze spojů, tedy hodnota síly přijatého signálu, hodnota síly vysílaného signálu, frekvence signálu spoje a čas, ve kterém byla tato data naměřena. Druhým typem jsou data potřebná pro samotný chod aplikace. Jsou to tedy údaje o samotných spojích, uzlech sítě a údaje nutné pro přístup k nim. Tato data budou uložena ve standardní SQL databázi, se kterou bude hlavní program komunikovat.

Komunikace se samotnými zařízeními v síti bude probíhat pomocí protokolu SNMP. Bude tedy třeba zjistit, jakou verzi protokolu SNMP zařízení v síti podporují, v jakém formátu nám potřebné hodnoty zařízení poskytnou a kde se v rámci protokolu vůbec nacházejí. Také bude třeba otestovat, s jak rychlou odezvou nám budou zařízení odpovídat a s jakou přesností. Vzhledem k tomu, že v tuto chvíli je v České republice v provozu řádově tisíce takových spojů, bude nutné zjistit, s jak dlouhou odezvou budou vzdálená zařízení odpovídat a jaké maximální frekvence dotazování bude možné dosáhnout. 3

1

1. Vymezení cílů a požadavky

1.2 1.2.1

Obecné požadavky Nalezení přístupu k požadovaným hodnotám

V prvé řadě bude třeba zjistit, kde a v jakém formátu se požadovaná data v rámci zařízení nacházejí. Potřebné jsou konkrétně hodnoty o síle vysílaného a přijímaného signálu a frekvence spoje. S tím bude nápomocen přímo výrobce zařízení MINI-LINK společnost Ericsson. Dále bude třeba navrhnout systém pro ukládání veškerých nasbíraných dat. Důležité je také, aby data o síle signálu byla časově synchronizovaná, tedy aby měření přijatého a vysílaného signálu probíhalo pokud možno v jednom okamžiku.

1.2.2

Portabilita

Vzhledem k tomu, že není možné přesně říct, na jakém operačním systému aplikace ve výsledku poběží, je třeba ji vyvinout tak, aby byla platformně nezávislá a dala se použít na co nejširším spektru operačních systémů, aniž by muselo docházet k nějakým dodatečným úpravám.

1.2.3

Spolehlivost

Aplikace bude spuštěna dlouhodobě, a to s nepříliš častými zásahy uživatele. Bude tedy důležité aby byla odolná vůči různým neočekávaným vlivům, jako jsou například výpadky sítě. Nezbytné je také zajistit, aby provoz aplikace nijak neomezoval ani neohrožoval běžný provoz v síti.

1.2.4

Rozšířitelnost

Aplikace by měla být použitelná pro různě velké množiny sledovaných spojů a měla by umožňovat tuto množinu dynamicky měnit. Aplikace tedy bude získávat informace o sledované síti z externí databáze. Samozřejmě bude nutné zjistit, jaké informace budou pro identifikaci zařízení a spojů v síti potřebné.

1.2.5

Snadnost použití

Vzhledem k tomu, že tato aplikace slouží jako podpora již běžícího výzkumu, je žádoucí, aby její nasazení a následné používání a správa bylo co nejjednodušší. Součástí této práce bude také příručka pro instalaci a obsluhu aplikace.

4

Kapitola

Použité technologie 2.1

Jazyk implementace

Jako hlavní jazyk implementace byla již v samotném počátku zvolena Java verze 1.6, a to z několika důvodů. Hlavním důvodem je multiplatformnost. Na začátku práce totiž vůbec nebylo jisté, na jakém operačním systému aplikace nakonec poběží (prvotní vývoj a testování například probíhal na MS Windows). Další výhodou je i dobrá možnost komunikace s databázovými stroji a komfort při práci se síťovou komunikací. V neposlední řadě je to i autorova osobní preference.[3] Jako důvod proti zvolení tohoto jazyka se nabízí velmi často uváděný nižší výkon například oproti C++. Tento argument zde ovšem není příliš na místě, neboť v programu se nenachází žádné algoritmicky složité řešení, které by vyžadovalo složitou optimalizaci. Rovněž musíme vzít v úvahu fakt, že program většinu času svého běhu stráví čekáním na odpověď ze zařízení v síti. To budou podle našich očekávání desítky až stovky milisekund, což nemůže volba jazyka (ani nic jiného) ovlivnit.

2.2 2.2.1

Protokol SNMP Základní popis

SNMP neboli Simple Network Management Protocol je, jak již jeho název napovídá, protokol pro správu sítí a síťových zařízení. Velmi zjednodušeně lze říci, že slouží pro čtení nebo případně zápis různých hodnot do a ze zařízení. V současnosti protokol SNMP existuje ve třech, respektive čtyřech verzích. Jsou to: SNMPv1, SNMPv2, SNMPv2c a SNMPv3. V našem pří5

2

2. Použité technologie padě používáme verzi 3. Tato verze poskytuje jak autentizaci uživatelským jménem a heslem, tak šifrování, které ovšem nepoužíváme. Z hlediska architektury je protokol SNMP rozdělen na několik částí. Jako první uvedu takzvané SNMP agenty. SNMP agenti jsou programy běžící na jednotlivých síťových zařízeních, které získávají hodnoty přímo ze zařízení a odpovídají na příchozí požadavky. Agent tedy zná vnitřní strukturu zařízení a informace z něj překládá do formy definované protokolem. Na druhé straně stojí SNMP manager. Ten již o vnitřní struktuře zařízení nic neví a pouze zpracovává data, o která požádal a následně obdržel ze SNMP agentů. Aplikace, která je předmětem této práce, je tedy SNMP managerem. Aby manager věděl, jaká data může od agenta požadovat, mají oba k dispozici MIB databázi. MIB je zkratka z Management Information Base a jedná se o stromově řazenou databázi objektů, k nimž může SNMP agent přistupovat. K hodnotám, které jsou uloženy v listech stromu se přistupuje pomocí identifikátoru, jenž může vypadat takto: .1.3.6.1.2.1.31.1.1.1.1.2129920257 Tyto identifikátory se nazývají OID – Object Identifier. Tento konkrétní OID nám například vrátí řetězec s názvem rozhraní v MIB stromu označeného číslem 2129920257. Jednotlivá čísla oddělená tečkami, totiž určují do jaké části podstromu se má při vyhledávání pokračovat. Kromě řetězců můžeme získat hodnoty čítačů, IP adresy nebo jiné číselné hodnoty.[2]

2.2.2

SNMP Operace

Protokol SNMP podporuje ve své třetí verzi 7 základních operací respektive příkazů. Jsou to tyto: GET – Příkaz GET je odesílán SNMP managerem. Je doprovázen jedním nebo několika OID, které určují jaké hodnoty manager po agentovi požaduje. GET NEXT – Je podobný jako GET, v odpovědi však agent vrací objekt bezprostředně následující objektu, který určuje OID odeslané v příkazu. GET BULK – Kromě toho, že obsahuje OID, obsahuje i údaj o požadovaném počtu opakování. Agent pak v odpovědi odešle požadovaný počet objektů bezprostředně navazujících na OID dané v požadavku. 6

2.2. Protokol SNMP SET – Opak příkazu GET, říká agentovi aby na zařízení nastavil hodnotu objektu určeného OID na hodnotu poskytnutou v příkazu. V praxi se příliš nepoužívá, většina zařízení umožňuje z bezpečnostních důvodů pouze čtení. TRAP – Je odesílán agentem jako upozornění, že hodnota nějakého objektu přesáhla nastavenou kritickou mez. INFORM – Funguje podobně jako TRAP, pouze od managera navíc vyžaduje potvrzení že zprávu přijal. RESPONSE – Odpověď agenta na nějakou GET operaci.

2.2.3

Struktura SNMP požadavku

SNMP komunikuje většinou na portu 161 protokolem UDP. Port ani protokol ovšem nejsou nijak závazné, je tedy možné komunikovat pomocí protokolu TCP a číslo portu závisí čistě na uživatelském nastavení. Protokol TCP však vzhledem k povaze SNMP není příliš vhodný a i my se budeme držet protokolu UDP. SNMP požadavek má tedy, po vypuštění UDP hlaviček, takovouto strukturu.

SNMP v3 Message Message Version Number

Message Identifier

Maximum Message Size

Message Flags

Message Message Security Security Model Parameters

Scoped PDU

Obrázek 2.1: Struktura SNMP zprávy. Nyní si přiblížíme prvních šest položek zprávy. V nich jsou uloženy důležité informace o samotném požadavku, a poskytují SNMP agentovi informace o tom, v jakým způsobem má managerovi na jeho požadavek odpovídat. Při přijetí požadavku totiž agent netuší jakou verzí protokolu s ním manager komunikuje. To zjistí až po přečtení první položky z požadavku a podle toho se může dále zařídit. Tu nejdůležitější část, tedy PDU které obsahuje veškerá data si pak rozebereme zvlášť a podrobněji.[7]

7

2. Použité technologie Název pole Message Version Number Message Identifier

Typ Integer

Délka 4 bajty

Popis Číslo verze SNMP protokolu, v našem případě se zde nachází číslo 3.

Integer

4 bajty

Maximum Message Size Message Flags

Integer

4 bajty

Octet String

1 bajt

Integer

4 bajty

–

proměnná

–

proměnná

Číslo sloužící k identifikaci SNMPv3 zprávy a ke spárování požadavku a odpovědi. Maximální velikost zprávy, kterou odesilatel může přijmout. Minimální hodnota tohoto pole je 484. Sada příznaků ovlivňujících další zpracování požadavku. Jedná se například o indikaci použití autentizace či šifrování. Číselná hodnota určující jaký bezpečnostní model je použit. Pro výchozí model SNMPv3 založený na uživatelích je zde hodnota 3. Parametry doplňující použitý bezpečnostní model. Jejich obsah je popsán v RFC 3414. Zde jsou uloženy identifikátory objektů, jejichž hodnoty manager na agentovi požaduje. Bude podrobněji rozebráno v další části.

Message Security Model Message Security Parameters Scoped PDU

Tabulka 2.1: Struktura SNMP zprávy

2.2.4

Struktura Scoped PDU

Nyní si rozebereme strukturu Scoped PDU, neboli Scoped Protocol Data Unit. Zde jsou uloženy identifikátory OID objektů, jejichž hodnotu manager na agentovi požaduje. Jako scoped se označuje proto, že z bezpečnostních důvodů se požadavek zpracovává v kontextu určitého rámce (scope – rámec či rozsah). Po položkách určujících kontext již následuje samotné PDU.[6]

8

2.3. Ericsson MINI-LINK

SNMP v3 Scoped PDU Context Engine ID

Context Name

PDU Type

Request ID

Error Status

Error Index

Variable Bindings

Obrázek 2.2: Struktura PDU. Název pole Context Engine ID Context Name PDU Type

Typ Octet String

Délka proměnná

Octet String

proměnná

Integer

4 bajty

Request ID

Integer

4 bajty

Error Status

Integer

4 bajty

Error Index

Integer

4 bajty

–

proměnná

Variable Bindings

Popis Určuje jaká konkrétní aplikace bude na straně agenta PDU zpracovávat. Identifikátor specifikující jeden konkrétní kontext spojený s PDU. Číslo určující typ požadavku. Jednotlivé hodnoty jsou upřesněny v tabulce uvedné v dodatku B. Číslo, které je použito pro spárování požadavku a odpovědi. Je vygenerováno zařízením odesílajícím požadavek. Číselná hodnota použitá v ResponsePDU upřesňující nastalou chybu. Těchto statusů je celkem 19 a nebudou blíže specifikovány. Pokud je Error Status v odpovědi nenulový, obsahuje tato položka ukazatel na objekt, který chybu způsobil. Množina dvojic OID–hodnota. Pokud jde o požadavek, nikoli o odpověď, je hodnota prázdná.

Tabulka 2.2: Struktura PDU

2.3

Ericsson MINI-LINK

MINI-LINK je zařízení pro tvorbu mikrovlnných spojů vyráběné společností Ericsson, jehož prostřednictvím je realizována naprostá většina spojů v námi sledované síti. Toto zařízení umožňuje jak spojování paketových sítí pomocí nativního Ethernetu, tak přenos pomocí starší technologie TDM, respektive PDH. Zařízení pracuje v rozsahu frekvencí 6 až 42 GHz a umožňuje přenosovou rychlost až 1 GBit/s. Toto přenosové pásmo lze libovolným 9

2. Použité technologie poměrem rozdělit právě mezi Ethernetový provoz a PDH.[1] Zjednodušeně řečeno, celé zařízení funguje jako router. Směruje tedy provoz mezi svými jednotlivými rozhraními, což může být jak mikrovlnný spoj, tak například metalická či optická síť. Takových rozhraní může být, jak vidíme na obrázku v případě Traffic Nodu (TN), až 19. Na druhou stranu Compact Node (CN) je menší a hodí se jako koncové zařízení nebo pro jednoduché spoje.

Obrázek 2.3: Ericsson MINI-LINK To, co nás ovšem zajímá nejvíce, je způsob jakým MINI-LINK řídí sílu vysílaného signálu. Toto řízení může pracovat ve dvou režimech. Prvním je režim RTPC. V tomto základním režimu se jednoduše nastaví požadovaná síla vysílání, a to s přesností na jednotky decibelů. Druhý režim s názvem ATPC je již sofistikovanější. Na obou koncích spoje se nastaví požadovaná úroveň přijímaného signálu a maximální úroveň síly vysílání. Zařízení již potom automaticky koriguje sílu vysílaného signálu tak, aby na druhé straně spoje byla stále udržována nastavená úroveň příjmu. Pokud se tedy podmínky přenosu například vlivem počasí zhorší, je síla vysílání zvýšena. Potom co se podmínky opět zlepší, vrátí se vše na původní úroveň. S řízením výkonu souvisí také možnost použití tzv. fallback (záložní či záchranné) funkce. Tato funkce spočívá v tom, že po uplynutí určité, předem nastavené doby, kdy zařízení vysílalo maximální nastavenou silou, přejde ATPC do fallback režimu. V tomto režimu je síla vysílání snížena na nastavenou fallback úroveň a je odeslána varovná zpráva. Fallback režim je zrušen pokud je režim řízení změněn na RTPC, nebo je odstraněna případná 10

2.3. Ericsson MINI-LINK závada a je obnoven ATPC režim. Fallback time-out, tedy doba po které systém přechází do fallback režimu, lze nastavit v rozmezí 1 až 60 minut, a to s přesností na jednu minutu.[12] Naprostá většina zařízení v námi sledované síti pracuje v režimu ATPC. Našemu pozorování to ovšem nijak nebrání, neboť hlavním objektem našeho zájmu je útlum signálu na spoji. Jediným rozdílem je skutečnost, že vlivem počasí se bude měnit hlavně úroveň vysílaného signálu a nikoliv úroveň signálu přijímaného, jak by mohlo být očekáváno. Co se týče získání požadovaných hodnot, byla výrobcem zařízení poskytnuta celá MIB databáze pro zařízení MINI-LINK. Pomocí MIB prohlížeče[10] není poté problém zjistit, v jakých částech stromu se požadované hodnoty nachází a získat tak jejich číselné identifikátory OID, které budou použity v SNMP dotazech. OID podstromu pro hodnoty síly vysílaného signálu: 1.3.6.1.4.1.193.81.3.4.3.1.3.1.1. OID podstromu pro hodnoty síly přijatého signálu: 1.3.6.1.4.1.193.81.3.4.3.1.3.1.10. OID podstromu pro frekvenci spoje: 1.3.6.1.4.1.193.81.3.4.3.1.2.1.1. V každém z těchto podstromů se pak nacházejí konkrétní hodnoty příslušející k jednotlivým anténám připojeným k zařízení. Ty jsou odlišeny číselným identifikátorem označujícím jednotlivé listy stromu. Nacházejí se zde dokonce hodnoty, které patří k anténám na protější straně spoje. To je velmi výhodné, protože jediným SNMP dotazem bude možné získat všechny potřebné hodnoty o aktuálním stavu spoje. Nyní zbývá přiřadit jednotlivé hodnoty příslušným spojům. Ze samotného čísla určujícího list MIB stromu to totiž není zjevné. Je tedy nutné nalézt způsob, jak pro konkrétní spoj zjistit poslední část OID pro jeho hodnoty. Dalším zkoumáním MIB databáze bylo zjištěno, že stejné číselné identifikátory se vyskytují v části stromu obsahující názvy jednotlivých rozhraní. Názvy rozhraní jsou řetězce v takovémto formátu: 1/X.1/1 pro výchozí část spoje a FX/1.1/1 pro rozhraní na vzdáleném konci spoje, kde X je číslo odpovídající číslu slotu, ve kterém je příslušný modem umístěn. Číslo slotu již není problém zjistit z aplikace pro správu MINI-LINK zařízení, kterou má operátor k dispozici. Způsob získání konkrétních OID bude blíže popsán v části 4.4.1. 11

2. Použité technologie

2.4

PostgreSQL

PostgreSQL je open-source objektově relační databázový stroj, který je vyvíjen už více než 15 let. Běží na všech významných operačních systémech a obsahuje plnou podporu pohledů, cizích klíčů, pohledů, triggerů a vložených procedur. Podporuje rovněž naprostou většinu datových typů daných standardem SQL 2008 a splňuje taktéž kritéria ACID. Z hlediska výkonu nijak nezaostává za komerčními produkty. [4] Tento databázový stroj byl pro práci vybrán zejména díky své otevřenosti, bohaté dokumentaci a dostatečně snadnému nasazení a následnému používání. Použita je konkrétně verze 9.2.1, která byla vydána 24. září 2012. Pro správu databáze je používán zejména grafický nástroj pgAdmin III.[9]

12

Kapitola

Návrh 3.1

Databázové schéma

Jako první bylo vytvořeno doménové schéma databáze, do které se budou ukládat jak naměřená data, tak data potřebná pro provoz aplikace (tzv. metadata). To jsou například IP adresy jednotlivých uzlových zařízení nebo identifikátory pro přečtení konkrétních hodnot právě pomocí SNMP. Celé schéma obsahuje 3 entity. Jsou to: Node, Link a Record. Entita Node obsahuje údaje o uzlech, Link údaje o spojích, které jsou přiřazeny k jednotlivým uzlům a konečně Record obsahuje již naměřená data. Toto rozvržení víceméně odpovídá organizaci v dohledové databázi operátora, kde jsou uloženy jednotlivé lokality a spoje lokality spojující. Na jednotlivé entity se postupně podíváme podrobněji.

3.1.1

Entita Node

Jak již bylo řečeno, entita Node obsahuje informace o jednotlivých uzlech sítě. Prvním z těchto údajů je IP adresa, přes kterou se do uzlu přistupuje. Právě na tuto adresu se bude odesílat SNMP požadavek, pokud budeme právě požadovat hodnoty ze spojů, které z tohoto uzlu vycházejí. Jako další je zde uvedeno jméno uzlu, které je představováno řetězcem. Ve skutečnosti zde bude uložen alfanumerický identifikátor, který ve svém dohledovém systému používá operátor sítě. Jako poslední zde máme zeměpisnou polohu uzlu. Ta bude v budoucnosti využívána pro lokalizaci srážek. 13

3

3. Návrh

Obrázek 3.1: Doménové schéma databáze

3.1.2

Entita Link

Další entitou v pořadí je entita Link. V této entitě budou uloženy tři důležité údaje. Zřejmě tím úplně nejdůležitějším je název rozhraní, do kterého je příslušný modem s anténou připojen. Pokud tento název budeme znát, není už problém odhalit identifikátory RxOID a TxOID. Tyto dva identifikátory nám již poskytnou přímý přístup ke konkrétním hodnotám, které nás budou zajímat. Toho docílíme jednoduše tak, že RxOID, respektive TxOID, jednoduše připojíme za OID označující MIB podstrom, ve kterém jsou umístěny údaje o síle signálu, případně frekvenci. Vzhledem k tomu, že jeden obousměrný spoj jsou ve skutečnosti dva spoje na různých frekvencích, bude každý směr spoje v entitě uložen zvlášť. Při procházení seznamu uzlů se budou vždy zpracovávat spoje, které z aktuálního uzlu vycházejí. V databázi pak nebude problém vždy oba směry spárovat.

3.1.3

Entita Record

Poslední entitou v databázi je Record. Zde jsou již konečně uloženy jednotlivé stavy tak, jak byly přečteny ze zařízení. Jedná se vždy o čtveřici 14

3.2. Aplikace datum + čas, síla vysílání, síla přijatého signálu na druhé straně spoje a frekvence. Tato entita bude obsahovat opravdu velké množství záznamů, bude tedy vhodné nad tabulkou, která z entity vznikne, vytvořit nějaké indexy.

3.2

Aplikace

Obrázek 3.2: Model požadavků

3.2.1

Funkční požadavky

3.2.1.1

Export dat z databáze

Přímo v aplikaci bude možné exportovat do textového souboru data uložená v databázi, a to jak jednotlivé záznamy o síle signálu, tak i data o jednotlivých uzlech a spojích. Při exportu jednotlivých záznamů bude možné určit požadovaný spoj a časový interval, který uživatele zajímá. 3.2.1.2

Přidání nových uzlů do systému

Pomocí konfiguračního souboru bude možné přidat do systému nové spoje. Uživatel formou tohoto souboru poskytne aplikaci potřebné informace o nově přidávaných uzlech, tedy IP adresu zařízení představujícího uzel, jeho zeměpisnou polohu a název, kterým se tento uzel bude dále identifikovat. 15

3. Návrh 3.2.1.3

Přidání nových spojů do systému

Podobně jako v předchozím případě budou prostřednictvím textového konfiguračního souboru přidávány nové spoje pro sbírání dat. Pro každý směr nového spoje je třeba poskytnout tyto údaje: název uzlu, ze kterého vychází, ve kterém končí a názvy rozhraní pro tyto uzly.

3.2.2

Nefunkční požadavky

3.2.2.1

Řádkové rozhraní pro server

Toto rozhraní bude spouštěno spolu se serverovou částí aplikace. Ovládat se bude pomocí textových příkazů, které budou realizovat všechny navržené případy užití. 3.2.2.2

Grafické uživatelské rozhraní pro klienta

V tomto grafickém rozhraní bude možné vykonávat všechny operace potřebné pro provoz a správu aplikace. Klientské rozhraní se bude k serverové části aplikace připojovat přes síťové rozhraní, bude tedy možné systém ovládat i vzdáleně.

3.2.3

Případy užití

3.2.3.1

Spuštění nebo zastavení sběru dat

1. Uživatel zadá příkaz pro spuštění/zastavení sběru. 2. Aplikace ověří, zda je již sběr dat spuštěn 3. Pokud není, je sběr zahájen/ukončen 4. Uživatel je informován, zda byl sběr spuštěn/ukončen či nikoliv 3.2.3.2

Přidání uzlů nebo spojů do systému

1. Uživatel zadá příkaz, pro přidání nových spojů či uzlů 2. Uživatel specifikuje soubor, ze kterého se příslušné informace budou načítat 3. Aplikace načte data ze souboru 4. Pokud jsou přidávány spoje, aplikace se spojí se zařízením a získá číselné identifikátory pro jednotlivá rozhraní 16

3.2. Aplikace 5. Aplikace zapíše nové informace do databáze

Obrázek 3.3: Případy užití

3.2.3.3

Export dat z databáze

1. Uživatel určí, zda chce exportovat data o uzlech, spojích či záznamy o signálu 2. Pokud se jedná o záznamy, uživatel specifikuje konkrétní spoj a časový interval 3. Uživatel určí soubor, do kterého se budou data exportovat 4. Aplikace exportuje vyžádaná data

17

Kapitola

4

Realizace 4.1

Knihovna SNMP4J

Pro práci s protokolem SNMP je v této aplikaci využito již hotové knihovny. Bylo by samozřejmě možné požadavky skládat, odesílat a poté přijímat ručně. Ovšem vzhledem k tomu, že námi zkoumaná zařízení komunikují třetí verzí protokolu SNMP, která již obsahuje jistou úroveň zabezpečení, bylo by to, jak jsme viděli v části 2.2 velmi složité. Proto bude raději využito služeb nějaké knihovny. Při hledání vhodné knihovny jsem narazil na knihovny dvě. Jako první jsem objevil JAVA SNMP API od firmy iReasoning. Tato knihovna je ovšem dostupná pouze pod komerční licencí a zřejmě již není dále vyvíjena. Navíc jsem k ní nebylo k dispozici dostatečné množství dokumentace. Další knihovnou, kterou jsem objevil, je knihovna SNMP4J. Tato knihovna je dostupná pod licencí Apache 2.0 a je možné k ní získat obsáhlou dokumentaci, a to včetně kompletních zdrojových kódů. Také jsem našel dostatek příkladů použití této knihovny, což mi velmi pomohlo k pochopení jak tuto knihovnu používat. Pro realizaci aplikace bude tedy použita knihovna SNMP4J. Knihovna SNMP4J vychází z knihovny SNMP++, která je určena pro jazyk C++. Obsahuje funkce jak pro implementaci SNMP managerů, tak i pro implementaci SNMP agentů. V současné verzi 2.2.0, která byla vydána 19.3.2013, je již vestavěná podpora pro nejobvyklejší způsoby šifrování (DES, 3DES, AES 128. . . ) a autentizace (MD5, SHA). Rovněž již v základní konfiguraci umožňuje komunikaci pomocí TCP, UDP a dokonce TLS. Další způsoby komunikace je možné přidat pomocí zásuvných modulů.[11] 19

4. Realizace

4.2

PostgreSQL JDBC

Jako JDBC je označována skupina rozhraní a tříd umožňující připojení Java aplikací k relačním databazím (např. MySQL, PostgreSQL, Oracle. . . ). JDBC vytváří vrstvu mezi samotnou aplikací a databází, která na jedné straně poskytuje unifikované rozhraní, jež je na straně druhé přeloženo do formy nativní pro databázi. V tomto případě je použito PostgreSQL JDBC ve verzi 9.1-901 doporučené pro použití s JDK 1.6.[5] Základem každého JDBC jsou třídy Connection a Statement. Třída Connection představuje, jak název napovídá, připojení k databázovému stroji. Ve chvíli, kdy je spojení navázáno, lze pomocí instance třídy Connection vytvářet instance třídy Statement nebo její potomky. To jsou třídy představující konkrétní SQL dotazy či DML operace. Asi nejpoužívanějším typem statementu je třída PreparedStatement, ta umožňuje požadovanou operaci připravit na straně serveru, a pak pouze odesílat jednotlivé hodnoty, které se do příkazu dosadí. Tento postup výrazně urychluje například vkládání většího množství řádků do tabulek nebo opakující se dotazy lišící se pouze konkrétními hodnotami.

4.3

Databáze

Návrh databáze, který byl uveden v sekci 3.1 a který byl vytvořen pomocí nástroje Enterprise Architect[8], byl stejným nástrojem převeden do formy DDL skriptu. Tento skript obsahuje příkazy nutné k vytvoření tabulek tak, jak byly navrženy. U sloupců nodeid a linkid je v tomto skriptu uveden typ serial. Použití tohoto typu zajistí automatické vytvoření sekvence, která bude automaticky číslovat nově přidávané uzly a spoje. Do skriptu byla rovněž dodatečně přidána dvě další integritní omezení (constrainty). Prvním je omezení na tabulce Node, které zajišťuje unikátnost názvu u všech uzlů. To je důležité, neboť právě pomocí názvů uzlů jsou do systému přidávány nové spoje. Druhým omezením je omezení na unikátnost dvojice fromNodeID,toNodeID. Mezi dvěma uzly totiž může vést právě jeden spoj v daném směru. Nad sloupcem time v tabulce Record byl rovněž vytvořen index typu B Tree. Tento index výrazně urychlí vyhledávání požadovaných časových intervalů v tabulce. V databázi jsou dále vytvořeni dva noví uživatelé a jedna uživatelská role. Uživatelé jsou nazvání gsm a gsmapp, role je nazvána gsmgroup. Uživatel gsm je vlastníkem databáze. Aplikace však do databáze přistupuje prostřednictvím uživatele gsmapp, kterému je přidělena právě role gsmgroup. Tato role má pouze omezená práva t.j. pouze čtení a zápis do tabulek. 20

4.4. Balíček cz.cvut.lhotamir.mwlcollection.server

Obrázek 4.1: Schéma databáze

4.4

Balíček cz.cvut.lhotamir.mwlcollection.server

Tento balíček obsahuje třídy realizující hlavní část aplikace. Nacházejí se zde třídy, které tvoří jak hlavní funkcionalitu aplikace, tedy rozesílání SNMP dotazů na jednotlivá zařízení v síti, tak rozhraní pro ovládání aplikace. Nyní budou postupně přiblíženy jednotlivé třídy.

4.4.1

Třída MWLCollection

Třída MWLCollection obsahuje jádro aplikace. Obsahuje metody pro přidávání nových uzlů a spojů do databáze a také hlavní metodu run, ve které je realizováno samotné dotazování na jednotlivé hodnoty. 21

4. Realizace Metoda addNodes, přidává do databáze nové uzly. Potřebné informace aplikaci poskytuje uživatel pomocí textového souboru, jehož každý řádek obsahuje tyto hodnoty: IP adresa uzlového zařízení, zeměpisná šířka, zeměpisná délka a název uzlu. Jednotlivé hodnoty jsou odděleny středníky. Soubor se záznamy pro nové uzly může vypadat například takto. 10.230.79.65;50.068972;14.453361;10283A 10.230.79.93;50.037489;14.484764;10333A 10.230.80.245;50.040371;14.496461;12209A Jak již bylo řečeno v sekci 3.1.1, název uzlu je identifikátor používaný operátorem pro označení lokality, ve které je zařízení umístěno. V tomto případě je tento identifikátor doplněn ještě písmenem. V některých lokalitách je totiž umístěno více zařízení s různými IP adresami a různými spoji a tato zařízení je potřeba nějak rozlišit. Kromě uvedených čtyř údajů je novému uzlu v databázi pomocí sekvence automaticky přidělen číselný identifikátor. Ten slouží pro identifikaci uzlu v rámci databáze. Pokud jsou již v databázi uloženy nějaké uzly, je možné začít přidávat i spoje. To se děje pomocí metody addLinks. Metoda addLinks funguje podobně jako metoda addNodes. Rovněž načítá data z textového souboru, který v tomto případě obsahuje tyto hodnoty: název výchozího uzlu, název cílového uzlu, název rozhraní na výchozím uzlu a název rozhraní na cílovém uzlu. Například tedy: 10283A;12299B;1/2.1/1;F2/1.1/1 12299B;10283A;1/16.1/1;F16/1.1/1 10333A;12299B;1/2.1/1;F2/1.1/1 Název rozhraní je důležitý z následujícího důvodu. Je to totiž v rámci celého MIB stromu zřejmě jediné spojení mezi identifikátory, které jsou potřebné pro přístup k jednotlivým hodnotám, a informacemi dostupnými ze stávajícího dohledového systému operátora. Při přidávání spojů je tedy pro každý uzel stažen seznam jeho rozhraní. Toto stažení je již realizováno protokolem SNMP a ve výsledku tedy dostaneme seznam Variable Bindings. Ten si můžeme zjednodušeně představit takto: ... ... ... ... ... ... 22

.ifName.2146697473 .ifName.2146705665 .ifName.2147352832 .ifName.2129920257 .ifName.2147352833

1/2.1/1 1/2/1 1/2/2A F2/1.1/1 1/2/2B

4.4. Balíček cz.cvut.lhotamir.mwlcollection.server ... .ifName.2147352834 1/2/2C ... Nás zajímá hlavně poslední část OID. V tomto seznamu je třeba najít názvy rozhraní příslušných přidávaných spojů a získat právě poslední část OID. Pokud tedy přidáváme spoj, jehož rozhraní mají názvy 1/2.1/1 a F2/1.1/1, odpovídají jim čísla 2146697473 pro blízký konec a 2129920257 pro vzdálený konec spoje. Budeme-li tedy chtít získat sílu vysílání daného spoje, k OID podstromu obsahujícího údaje o síle vysílání připojíme právě číslo 2146697473. Po získání těchto identifikátorů jsou podle svých názvů v databázi nalezeny identifikátory uzlů, mezi kterými spoj probíhá. Ty slouží jako cizí klíče do tabulky uzlů. V tuto chvíli jsou už k dispozici všechny potřebné údaje pro uložení spoje do databáze, kam je zapsána následující pětice hodnot: název lokálního rozhraní, číselný identifikátor lokálního rozhraní, číselný identifikátor vzdáleného rozhraní, id výchozího uzlu a id vzdáleného uzlu. V databázi je novému spoji přidělen číselný identifikátor stejně, jako je tomu při přidávání uzlu. Poslední důležitou metodou je metoda run, která je spouštěna jako samostatné vlákno. Zde již odehrává samotné dotazování na jednotlivé hodnoty. Při spuštění metody jsou nejdříve z databáze načtena veškerá data o uzlech a spojích. Nejprve jsou z databáze načteny všechny záznamy o uzlech a pomocí těchto informací je vytvořen seznam objektů třídy Node. Po vytvoření seznamu uzlů je pro každý tento objekt přečten seznam spojů z něj vycházejících a tyto spoje jsou jako objekty typu Link vloženy do seznamu uvnitř objektu představujícího příslušný uzel. Poté je seznam uzlů sekvenčně procházen a je volána metoda třídy Node s názvem getValues a v případě, že je nastavena nenulová délka prodlevy, je vlákno na tuto dobu uspáno. Vlákno může být uspáváno proto, že pokud je v databázi málo spojů, bylo by zbytečné dotazovat se jednoho uzlu několikrát za sekundu.

4.4.2

Třída Node

Třída Node reprezentuje síťový uzel, ze kterého vycházejí jednotlivé spoje a odpovídá databázové entitě Node. Každá instance třídy Node obsahuje seznam spojů, které z daného uzlu vycházejí. Při vytváření nové instance třídy Node, je inicializována členská proměnná target, což je instance třídy UserTarget, která je jednou ze tříd knihovny SNMP4J. Tato třída představuje cíl, na který je odesílán SNMP požadavek, v tomto případě je tímto cílem právě uzel. Pro všechny spoje v seznamu je tedy target stejný. Po vytvoření nové 23

4. Realizace instance je proměnné target nastavena adresa, počet případných opakování, timeout, verze protokolu, úroveň zabezpečení a uživatel pro přihlášení. Při procházení seznamu uzlů v metodě run se u každého uzlu volá metoda getValues. V této metodě je další cyklus, který prochází právě seznam spojů z uzlu vycházejících. Pro každý spoj jsou pomocí getterů zjištěny hodnoty TxOID (síla vysílaného signálu) a RxOID (síla přijatého signálu). Poté je vytvořena nová instance třídy ScopedPDU. To je opět třída z knihovny SNMP4J, která odpovídá Scoped PDU danému popisem protokolu. Do nového PDU jsou postupně přidány nové Variable Bindings pro požadované hodnoty. OID potřebné pro vytvoření Variable Binding vzniknou připojením připojením proměnných RxOID a TxOID za konstanty určující OID příslušného MIB podstromu. Poté je typ PDU nastaven na GET a požadavek je připraven k odeslání. Po odeslání požadavku a přijetí odpovědi (opět ve formě PDU), jsou z přijatých Variable Bindings získány jednotlivé hodnoty, které jsou pomocí instance třídy PreparedStatement zapsány do databáze. Pokud dojde k nějaké chybě (paket se na své cestě ztratí apod.) a odpověď nedorazí v požadované době, vzniká výjimka, která je okamžitě odchycena, a cyklus pokračuje zpracováním dalšího spoje.

4.4.3

Třída Link

Třída Link reprezentuje jeden směr reálného spoje tak, jak je uložen v databázi. Kromě konstruktoru a getterů neobsahuje již žádné jiné metody.

4.4.4

Třída Console

Toto je jedna z tříd, které obsahují metodu main. Metoda main třídy Console obsluhuje ovládání aplikace přes příkazový řádek a spouští dohledové vlákno, se kterým poté komunikuje a může tak ovládat vlákno provádějící SNMP dotazování. Dohledové vlákno je popsáno v sekci 4.4.5. Jednotlivé příkazy, kterými lze aplikaci ovládat budou popsány v dodatku C. Příkazy zadané uživatelem jsou předány právě instanci třídy SurveillanceThread, která je dále předá objektu realizujícímu sběr dat.

4.4.5

Třída SurveillanceThread

Třída SurveillanceThread implementuje rozhraní Runnable, třída tedy představuje samostatné vlákno. Toto dohledové vlákno má za úkol dvě činnosti. První činností je uchovávání odkazu na instanci třídy MWLCollection a případné vytváření nových instancí této třídy. Druhou činností je naslouchání na zadaném portu a spouštění vláken pro ovládání aplikace po síti. Tato 24

4.4. Balíček cz.cvut.lhotamir.mwlcollection.server třída tedy vytváří jakési rozhraní mezi uživateli a třídou MWLCollection. Je totiž nutné udržet konzistenci mezi uživatelem, který aplikaci ovládá lokálně a uživatelem přistupujícím po síti. Všichni zúčastnění musí vždy přistupovat ke stejné instanci MWLCollection, k instanci třídy MWLCollection přistupují tedy výhradně prostřednictvím této třídy. Pokud tedy po síti dorazí příkaz pro zastavení sběru dat, je pomocí metody stopCollection zastaveno vlákno třídy MWLCollection a poté je vytvořena nová instance pro sběr dat.

4.4.6

Třída Control

Třída Control rovněž představuje samostatné vlákno, které je spuštěno ve chvíli, kdy dohledové vlákno naváže spojení se vzdáleným klientem. Toto vlákno poté přijímá příkazy, které předává dohledovému vláknu a odesílá odpovědi zpět klientovi.

4.4.7

Třída DataReader

Tato třída slouží pro přístup k datům uložených v databázi. Obsahuje metody umožňující číst data ze všech tří tabulek v databázi. Pokud chceme číst data přímo v serverové části aplikace, postupuje se následujícím způsobem. Pomocí bezparametrického konstruktoru je vytvořena instance třídy DataReader a je navázáno spojení s databází. Poté je zavolána příslušná metoda vzniklého objektu, v závislosti na tom jaká data jsou požadována je to metoda readNodes, readLinks nebo readRecords. Tato metoda zjistí, zda je požadován výstup do souboru, či na standardní výstup, a v případě že jsou požadovány jednotlivé záznamy požádá metoda o identifikaci spoje a určení časového intervalu. Poté je spuštěna další metoda, tentokrát nazvaná getNodes, getLinks či getRecords. Tato metoda vykoná příslušný SQL dotaz a zapíše výsledek tohoto dotazu do souboru nebo na standardní výstup. Poté uzavře spojení s databází a skončí. V případě, kdy jsou data požadována vzdáleným klientem, je postup poněkud odlišný. V tomto případě je použit konstruktor a všechny potřebné hodnoty (název souboru, identifikace spoje. . . ) jsou instanci předány jako jeho parametry. Poté není ale použita metoda read. . . , ale rovnou metoda get. . . . Jako parametr je jí předán odkaz na stream realizující síťové spojení (v přechozím připadě je předána hodnota null). Tento odkaz je v metodě použit místo odkazu na soubor. Díky tomu může být tělo metody stejné jako v předchozím případě, i když se zde zapisuje do síťového streamu, nikoliv do souboru. Data jsou jsou exportována v takovýchto formátech: 25

4. Realizace Uzly: id uzlu;název uzlu;ip adresa;zem. šířka;zem. délka Spoje: id spoje;název poč. uzlu;název kon. uzlu Záznamy: čas;název poč. uzlu;název kon. uzlu;síla vys. sig.;síla přij. sig.

4.5

Balíček cz.cvut.lhotamir.mwlcollection.messages

Tento balíček obsahuje třídy představující zprávy, jejichž prostřednictvím komunikuje server a klient pro jeho vzdálené ovládání. Všechny tyto třídy jsou celkem jednoduché, slouží vždy pouze pro přenos několika málo parametrů. Základní třídou je třída Message, která implementuje rozhraní Serializable a jejíž kód má hodnotu 0. Ostatní třídy jsou jejími potomky a liší se právě hodnotou kódu. Pokud tedy chceme odeslat například zprávu pro zjištění stavu sběru dat, do výstupního proudu síťového spojení pošleme objekt třídy StateMessage. Na druhé straně je ovšem zpráva přijata jako objekt třídy Message a právě podle kódu je poté zjištěno, jaká konkrétní zpráva byla obdržena a jaký příkaz tedy představuje. Pokud zpráva obsahuje nějaké další hodnoty, je poté přetypována aby mohly být tyto hodnoty získány. Nyní bude uveden výčet všech typů zpráv spolu s jejich číselnými kódy a jejich stručný popis. Message – Kód 0, základní třída StartMessage – Kód 1, odesílána pro spuštění sběru dat StopMessage – Kód 2, zastavuje sběr dat StartSuccessMessage – Kód 3, odpověď při úspešném spuštění sběru StartFailMessage – Kód 4, odpověď pokud sběr nebyl spuštěn (již běží) StopSuccessMessage – Kód 5, odpověď při úspěšném zastavení sběru 26

4.6. Balíček cz.cvut.lhotamir.mwlcollection.client StopFailMessage – Kód 6, odpověď při neúspěšném zastavení sběru (sběr nebyl dosud spuštěn) ServerStopMessage – Kód 8, příkaz pro zastavení sběru dat a ukončení serveru StateMessage – Kód 9, slouží jako dotaz na stav sběru dat, jako odpověď se vrací s příznakem zda sběr běží a kdy byl případně spuštěn ReadNodesMessage – Kód 10, slouží pro vyžádání seznamu uzlů uložených v databázi AddNodesMessage – Kód 11, oznamuje serveru že bude zahájen přenos souboru s novými uzly AddLinksMessage – Kód 12, oznamuje serveru že bude zahájen přenos souboru s novými spoji ReadLinksMessage – Kód 13, slouží k vyžádání seznamu spojů z databáze ReadRecordsMessage – Kód 14, vyžádá z databáze jednotlivé záznamy, obsahuje informace o požadovaném spoji a časovém intervalu ClientQuitMessage – Kód -1, oznamuje serveru že se klient ukončuje, a server tak může ukončit vlákno obsluhující jeho požadavky

4.6

Balíček cz.cvut.lhotamir.mwlcollection.client

Tento balíček obsahuje třídy realizující klienta určeného pro vzdálené ovládání serveru. K dispozici je jak klient řádkový tak klient grafický. Klient se serverem komunikuje pomocí zpráv, které byly popsány v předchozí části.

4.6.1

Třída Client

Tato třída představuje řádkového klienta. Ten je velmi jednoduchý, pouze odesílá příslušné zprávy v závislosti na vstupu od uživatele a přijímá odpovědi na ně. Řádkový klient neumožňuje všechny operace jako server, podporuje pouze příkazy pro spuštění a zastavení sběru dat, dotaz na aktuální stav sběru a ukončení serveru. 27

4. Realizace

4.6.2

Třída GUIClient

Zde je realizováno grafické uživatelské rozhraní. Toto rozhraní se připojuje pomocí protokolu TCP k serveru jako klient, podporuje ovšem všechny operace jako server. Je tedy možné přidávat nové uzly a spoje do databáze, číst z databáze data a samozřejmě spouštět a zastavovat sběr dat.

Obrázek 4.2: Uživatelské rozhraní

28

Kapitola

Testování 5.1

Vývoj a prvotní testování

Pro začátek vývoje a prvotní testování byl společností T-Mobile zapůjčen jeden celý spoj. Konkrétně dvě jednotky MINI-LINK CN-510, dvě antény, útlumový člen, vlnovod a napájecí zdroje. Není totiž možné použít skutečné mikrovlnné spojení, neboť v tomto frekvenčním pásmu je třeba povolení Českého telekomunikačního úřadu. Obě antény byly tedy přes útlumový člen spojeny kabelem a signál tedy nebyl šířen vzduchem. Dále byly obě jednotky připojeny přes svá síťová rozhraní k počítači poskytnutému vedoucím práce. Celý tento spoj byl umístěn v místnosti E228 v budově Fakulty elektrotechnické na Karlově náměstí. Do připojeného počítače byl zřízen vzdálený přístup a velká část vývoje probíhala přímo na něm. Na tomto spoji bylo vytvořeno a otestováno jádro třídy MWLCollection, tedy samotné vytváření, odesílání a přijímání SNMP požadavků a ukládání získaných hodnot do databáze. Rovněž byla zjišťována rychlost odezvy na SNMP požadavky. V tomto případě se jednalo řádově o desítky milisekund. V reálné síti bude odezva ovšem s největší pravděpodobností pomalejší a se vzdáleností spojů bude dále růst. V tomto stádiu bylo rovněž přidáno brzdění hlavního cyklu procházejícího seznam uzlů. Při takto nízkém počtu uzlů a spojů je pak frekvence požadavků zbytečně vysoká, a vytěžuje jak zařízení, tak počítač na kterém aplikace běží. Rovněž byly navrženy a implementovány metody pro přidávání nových uzlů a spojů do databáze. Nebylo však možné je důkladněji otestovat, protože nebylo k dispozici větší množství spojů. Z hlediska spolehlivosti se již od samého počátku nevyskytovaly problémy. Sběr dat běžel bez přestávky více než týden bez pádu a nedocházelo ani k memory leakům. Rovněž bylo testována reakce aplikace na ztrátu spo29

5

5. Testování jení se zařízením. Tento test byl realizován tak, že byla během sbírání dat deaktivována síťová rozhraní počítače. Aplikace vždy zareagovala tak jak měla, tedy vypsala, že vypršel čas pro provedení operace a pokračovala ve sběru dat dále. Nic tedy nebránilo tomu aby mohla být aplikace otestována na větší síti.

5.2

Testování v laboratoři operátora

Dalším krokem testování bylo spuštění aplikace v laboratoři přímo v sídle operátora sítě, společnosti T-Mobile. Zde byly k dispozici 3 spoje rovněž vedené prostřednictvím kabelů, ovšem opatřené útlumovými členy s nastavitelným útlumem. Tyto nové uzly a spoje byly do systému úspěšně přidány pomocí konfiguračních souborů. Hlavním cílem tohoto testování bylo ovšem zjistit jak rychle zařízení reaguje na změnu útlumu. Sběr dat byl spuštěn po dobu asi čtyř hodin a po tuto bylo zaznamenáváno, jak byl měněn útlum mezi anténami. Pomocí tohoto měření bylo zjištěno, že změna se na zařízení projeví zhruba během 2-5 sekund v závislosti na tom, jak byla změna rychlá. Nemá tedy velký smysl sbírat data v intervalu kratším než 2 sekundy. Během tohoto testování byl na sledovaných spojích rovněž pomocí speciálního testeru simulován datový provoz. Zjištěno bylo, že na kvalitu datového provozu nemá sběr dat v tomto rozsahu žádný vliv. Sběr dat negativně neovlivnil ani rychlost odezvy dohledového systému.

5.3

Testování v reálné síti

Po otestování aplikace v laboratoři bylo možné přikročit k testování v reálné síti. Nyní byla aplikace nasazena na jeden počítač v dohledovém centru operátora, který nám byl vyhrazen. Tento počítač byl z bezpečnostních důvodů připojen pouze do dohledové sítě, nikoliv do internetu. Nebylo tudíž bohužel možné použít část aplikace určenou pro vzdálené ovládání serveru a nebylo možné ani vzdáleně stahovat data, která bylo tedy nutné vyzvedávat osobně. Pro pilotní provoz bylo vybráno 6 spojů v lokalitě pražských Roztyl, které vycházejí ze zařízení umístěných přímo v budově operátora. Nové uzly a spoje byly opět přidány pomocí konfiguračních souborů. Při přidávání nových spojů ovšem došlo k problému. Původně byl při přidávání nových spojů seznam názvu rozhraní stahován pomocí SNMP operace GET BULK. Některá zařízení ovšem obsahují větší počet různých modemů a jiných komponent a tedy i seznam rozhraní je velmi velký. Operace GET BULK funguje 30

5.3. Testování v reálné síti tak, že data, která se do jednoho datagramu již nevejdou, jednoduše ořízne a v odpovědi již nedorazí. Pro některé spoje tedy nebyl nalezen OID identifikátor a aplikace nesbírala správná data. Stahování seznamu rozhraní bylo tedy přepracováno tak, že se jednotlivé záznamy stahují po jednom. Pak je jisté že jsou staženy skutečně všechny. Celá tato operace se provádí pro každý nový spoj pouze jednou, samotný sběr nijak nezpomaluje. V tuto chvíli bylo vlákno sbírající data ještě dodatečně zpomalováno. Sběr na těchto spojích byl zahájen 22. února 2013. K 23. dubnu 2013 bylo získáno zhruba 20 milionů jednotlivých záznamů. Tohoto dne bylo rovněž přidáno dalších 17 nových spojů, tentokrát v oblasti Letňan. Při tomto množství spojů se již ukázalo jako zbytečné sběr dodatečně brzdit, nyní trvá projití všech uzlů v seznamu průměrně 4 až 6 sekund. 54 53 52 51 A [dB]

50 49 48 47 46 45 44 00:00 06:00 12:00 18:00 00:00 06:00 12:00 18:00 00:00 06:00 12:00 18:00 00:00 Čas [hodiny:minuty]

Obrázek 5.1: Ukázka nasbíraných dat Na obrázku 5.1 je pro ilustraci nasbíraných dat vynesen graf útlumu pro oba směry jednoho spoje (v grafu jsou směry barevně odlišeny). Útlum je definován jako rozdíl síly signálu vysílaného, a síly signálu, který je zachycen na druhém konci spoje, tedy: A[dB] = Ptrans. [dB] − Prec. [dB] Čím vyšší je tedy tento rozdíl, tím vyšší je útlum signálu na spoji.

31

5. Testování Data uvedená v grafu byla nasbírána během 11. 12. a 13. dubna 2013 na spoji vedoucím mezi budovou T-Mobile na Roztylech a výškovou budovou na rohu ulic Želetavské a U Pomníku. Jak je vidět, dne 12. dubna došlo ke znatelnému zvýšení tohoto rozdílu. To znamená že došlo ke zhoršení přenosových podmínek, je tedy možné, že došlo v tomto období ke srážkám.

32

Závěr V této chvíli je aplikace již víceméně připravena pro použití. Pokud jí jsou formou konfiguračních souborů poskytnuty potřebné informace, je schopna pracovat v jakékoliv síti se zařízeními Ericsson MINI-LINK a sbírat z nich data. Do budoucna se však nabízí otázka jak sběr dat urychlit, neboť se při větším množství spojů v databázi zhorší časové rozlišení záznamů pro jeden konkrétní spoj. Nabízí se tedy sběr dat distribuovat mezi více počítačů (třeba i virtuálních). Toto řešení by dokonce ani nevyžadovalo žádné programové úpravy. Možné by samozřejmě bylo paralelizovat sběr v rámci aplikace, to už by ovšem jisté úpravy vyžadovalo. Jako autor práce jsem velmi rád že jsem si tuto práci zvolil. Jednak jsem se detailněji seznámil s protokolem SNMP, ale hlavně jsem měl možnost pracovat se skutečnou a v praxi velmi používanou technologií MINI-LINK o jejímž fungování jsem také získal jistý přehled. Rovněž jsem velmi rád že jsem se mohl zúčastnit většího projektu s kolegy z Fakulty stavební se kterými byla výborná spolupráce, která bude doufám nadále pokračovat.

33

Literatura [1] MINI-LINK - Ericsson [online]. [cit: 2013-04-02]. Dostupné z: http: //www.mini-link.cz/mini-link.aspx [2] Simple Networking Management Protocol [online]. [cit: 2013-03-28]. Dostupné z: http://docwiki.cisco.com/wiki/Simple_Network_ Management_Protocol [3] Java JDK 1.6 [software]. [cit: 2013-04-28]. Dostupné z: http://www. java.com/ [4] PostgreSQL 9.1 [software]. [cit: 2013-04-28]. Dostupné z: http://www. pgadmin.org/ [5] PostgreSQL JDBC [software]. [cit: 2013-04-28]. Dostupné z: http:// jdbc.postgresql.org/ [6] The TCP/IP Guide - SNMP Version 2 (SNMPv2) Message Formats [online]. Září 2005, [cit: 2013-03-28]. Dostupné z: http://www. tcpipguide.com/free/t_SNMPVersion2SNMPv2MessageFormats-5. htm [7] The TCP/IP Guide - SNMP Version 3 (SNMPv3) Message Format [online]. Září 2005, [cit: 2013-03-28]. Dostupné z: http://www. tcpipguide.com/free/t_SNMPVersion3SNMPv3MessageFormat.htm [8] Enterprise Architect 9.0 [software]. c2008, [cit: 2013-05-02]. Dostupné z: http://www.sparxsystems.com.au/products/ea/index.html [9] pgAdmin III 1.16.0 [software]. c2012, [cit: 2013-03-30]. Dostupné z: http://www.snmp4j.org/ 35

Literatura [10] MG-SOFT MIB Browser Professional Edition [software]. c2013, [cit: 2013-05-02]. Dostupné z: http://www.mg-soft.si/mgMibBrowserPE. html?p1=products&p2=mgProductsNMA-SNMP [11] SNMP4J - Free Open Source SNMP API for Java [software]. c2013, [cit: 2013-03-30]. Dostupné z: http://www.snmp4j.org/ [12] Ericsson AB: MINI-LINK TN R5 ETSI Technical Description. 2012.

36

Příloha

Seznam použitých zkratek

GUI Graphical user interface SNMP Simple Network Management Protocol MIB Management Information Base UDP User Datagram Protocol OID Object Identifier TDM Time Division Multiplex – časový multiplex PDH Plesiochronní digitální hierarchie RTPC Remote Transmit Power Control ATPC Automatic Transmit Power Control JDBC Java Database Connectivity DDL Data Definition Language

37

A

Příloha

Tabulka hodnot PDU typů PDU Type Hodnota 0 1 2 3 4 5 6 7 8

39

Typ PDU GET GET NEXT RESPONSE SET SNMPv1 TRAP GET BULK INFORM TRAP REPORT

B

Příloha

Návod k instalaci a použití aplikace C.1

Instalace

Pro úspěšnou instalaci a provoz je třeba mít: • Java JRE verze alespoň 1.6 • PostgreSQL databáze verze alespoň 9.1 • Balíček se samotnou aplikací a podpůrné knihovny (SNMP4J a PostgreSQL JDBC) • Přístup do sítě se zařízeními Ericsson MINI-LINK Postup instalace: 1. Nainstalujte PostgreSQL a nastavte tak, aby naslouchal na portu 5432 2. Jako uživatel postgres se připojte do databáze a spusťte dávkový soubor create_script.sql 3. Nyní je aplikace připravena ke spuštění

41

C

C. Návod k instalaci a použití aplikace

C.2

Obsluha serverové části

Spuštění serveru – Server spustíme z konzole tímto příkazem, kde „cesta“ je cesta k souboru MWLCollection.jar java -cp "cesta" cz.cvut.lhotamir.mwlcollection.server.Console port Při spouštění je možné jako parametr zadat číslo portu, na kterém bude server naslouchat. Pokud parametr nezadáme bude server naslouchat na portu 3999. Přidání uzlů – Pro přidání uzlů zadáme příkaz add nodes následovaný cestou k příslušnému konfiguračnímu souboru. Je možné použít i relativní cestu. Konfigurační soubor je textový soubor v takovémto formátu, kde každý řádek představuje jeden nový uzel. Jednotlivé položky na řádku jsou odděleny středníky. IP adresa

Zem. šířka

Zem. délka

Název uzlu

Například: 10.230.79.93;50.037489;14.484764;10333A 10.230.80.245;50.040371;14.496461;12209A ... Přidání spojů – Spoje se přidávají podobně jako uzly příkazem add links. Pozor, každý směr spoje se přidává zvlášť! Soubor s novými spoji má takovýto formát. Název výchozího uzlu

Název koncového uzlu

Název výchozího rozhraní

Název koncového rozhraní

Například: 10283A;12299B;1/2.1/1;F2/1.1/1 12299B;10283A;1/16.1/1;F16/1.1/1 ... Spuštění sběru – Sběr dat se spouští příkazem start. 42

C.3. Obsluha vzdáleného ovládání Zastavení sběru – Sběr dat zastavíme příkazem stop. Zjištění stavu – Příkaz state zjistí zda sběr dat běží. Pokud běží, vypíše kdy byl sběr spuštěn. Export uzlů z databáze – Uzly exportujeme z databáze příkazem read nodes. Aplikace si poté vyžádá cestu k výstupnímu souboru. Pokud jako cestu zadáme pomlčku, provede se výstup na standardní výstup. Export spojů z databáze – Příkaz read links funguje stejně jako příkaz předchozí Export záznamů z databáze – Příkaz read records je podobný jako dva předchozí příkazy. Od uživatele si navíc vyžádá určení požadovaného spoje a časového intervalu. Ukončení serveru – Server se ukončuje příkazem stop server. Pokud v tuto chvíli běží sběr, je bezpečně zastaven a celý server se poté ukončí.

C.3

Obsluha vzdáleného ovládání

C.3.1

Řádkový klient

Spuštění řádkového klienta – Klienta spustíme obdobným příkazem jako server. java -cp "cesta" cz.cvut.lhotamir.mwlcollection.client.Client Po spuštění zadáme IP adresu počítače na kterém běží server a port na kterém server naslouchá. Další příkazy – Řádkový klient podporuje příkazy start, stop, state a stop server, které fungují stejně jako v případě serveru.

C.3.2

Grafický klient

Grafický klient podporuje stejné příkazy jako serverová část aplikace. Spuštění grafického klienta – Klienta spustíme následujícím příkazem: java -cp "cesta" cz.cvut.lhotamir.mwlcollection.client.GUIClient 43

C. Návod k instalaci a použití aplikace Připojení k serveru – V nabídce File se nachází položka Connect, která představuje příkaz pro připojení k serveru. Po zvolení této položky, se objeví dialogové okno, do kterého zadáme IP adresu a port, na kterém server naslouchá. Přidání uzlů nebo spojů – V nabídce Edit zvolíme příkaz Add Nodes, respektive Add Links podle toho, které položky chceme přidat. Po zvolení příkazu zvolíme konfigurační soubor ve stejném formátu jako u přidávání přes server. Další příkazy – Zbytek příkazů najdeme po levé straně hlavní obrazovky. Fungují stejně jako v případě serveru.

44

Příloha

Obsah přiloženého CD

readme.txt ................................ stručný popis obsahu CD dist....................adresář se spustitelnou formou implementace lib.............................adresář s potřebnými knihovnami doc ..................................................... javadoc src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce BP_Lhotan_Miroslav_2013.pdf ....... text práce ve formátu PDF 45

D