Implementarea Rețelelor Ad-Hoc Pe Platforme Android

UNIVERSITATEA “TRANSILVANIA” DIN BRAŞOV DEPARTAMENTUL DE ELECTRONICĂ ŞI CALCULATOARE Programul de studii: Tehnologii şi sisteme de telecomunicaţii

Implementarea rețelelor Ad-Hoc pe platforme Android

Absolvent: TERZA Balázs-László

Indrumător: Şef lucrări dr.ing. SIMON Csaba

BRAŞOV 2015 Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Universitatea Transilvania din Braşov Lucrare de diplomă nr......

Facultatea Inginerie Electrică şi Ştiinţa Calculatoarelor Departamentul Viza facultăţii Electronică şi Calculatoare Programul de studii Anul universitar Tehnologii şi sisteme de telecomunicaţii 2014 - 2015 Candidat Promoţia TERZA Balázs-László 2015 Cadrul didactic îndrumător Ș.l. dr. ing. SIMON Csaba

LUCRARE DE DIPLOMĂ Titlul lucrării: Implementarea reţelelor Ad-Hoc pe platforme Android Problemele principale tratate: 1. Prezentarea generală a sistemului de operare Android 2. Prezentarea modului de comunicatii ad hoc 3. Proiectarea şi dezvoltarea aplicaţiei pentru sistemul Android 4. Testarea şi masurarea parametrilor QoS pe reteaua configurata de absolvent Locul şi durata practicii: Laboratoarele de electronică (112-113) al Universităţii Sapientia, Mai 2014 - Iunie 2015 Bibliografie:

1. Reto Meier: Professional Android 4 Application Development, Wrox, 2012 2. A. Tanenbaum, D.J. Wetherall: Számítógép hálózatok, Panem, 2012

Aspecte particulare:

Primit tema la data de: 15.05.2014

Data predării lucrării: 30.06.2015

Director departament, Cadru didactic îndrumător, Prof. univ. dr. ing. Mihai ROMANCA Ș.l.dr.ing. SIMON Csaba Candidat, TERZA Balázs-László

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

LUCRARE DE DIPLOMĂ – VIZE Data Capitole/ problemele analizate Semnătura cadrului vizei didactic îndrumător

30.05.2014 Discuţie generală despre tema aleasă 30.09.2014 Analizarea sistemelor similare 25.10.2014 Proiectarea sistemului 30.03.2015 Implementarea algoritmilor de comunicaţie 30.05.2015 Pornirea şi diagnostizarea sistemului Recenzarea lucrării scrise, verificarea capitolelor, 25.06.2015 a bibliografiei

APRECIEREA ŞI AVIZUL CADRULUI DIDACTIC ÎNDRUMĂTOR Confirm efectuarea celor 60 de ore de practica pentru realizarea lucrarii de diploma si sunt de acord cu sustinerea lucrarii. Nota acordata de indrumator: ......

Data: ADMIS CADRU DIDACTIC ÎNDRUMĂTOR Ș.l.dr.ing. SIMON Csaba

AVIZUL DIRECTORULUI DE DEPARTAMENT Data: ADMIS pentru DIRECTOR DEPARTAMENT susţinere/ RESPINS Prof. univ. dr. ing. Mihai ROMANCA

SUSŢINEREA LUCRĂRII DE DIPLOMĂ Sesiunea PROMOVAT cu media: Rezultatul susţinerii RESPINS cu refacerea lucrării

RESPINS fără refacerea lucrării

Preşedinte COMISIE

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

UNIVERSITATEA TRANSILVANIA DIN BRAŞOV FACULTATEA INGINERIE ELECTRICĂ ŞI ŞTIINŢA CALCULATOARELOR PROGRAMUL DE STUDII: TEHNOLOGII ŞI SISTEME DE TELECOMUNICAŢII

NUMELE ŞI PRENUMELE: TERZA Balázs-László PROMOŢIA: 2015 SESIUNEA DE DIPLOMĂ IULIE 2015

DENUMIREA LUCRĂRII:Implementarea rețelelor Ad-Hoc pe platforme Android CADRUL DIDACTIC ÎNDRUMĂTOR Coordonator științific: Ș.l.dr.ing. SIMON Csaba

Declarăm pe proprie răspundere că lucrarea de faţă este rezultatul muncii absolventului, pe baza cercetăriilor proprii şi pe baza informaţiilor obţinute din surse care au fost citate şi indicate conform normelor etice, în textul lucrării, în note şi bibliografie. Declarăm că nu s-au folosit în mod tacit sau ilegal munca altora şi că nicio parte din teză/proiect nu încalcă drepturile de proprietate intelectuală ale altcuiva, persoană fizică sau juridică. Declarăm că lucrarea nu a mai fost prezentată sub această formă vreunei instituţii de învăţământ superior în vederea obţinerii unui grad sau titlu ştiinţific ori didactic. În cazul constatării ulterioare a unor declaraţii false, vom suporta rigorile legii.

Data: 06.07.2015

Absolvent TERZA Balázs-László Cadru didactic îndrumător Ș.l.dr.ing.SIMON Csaba

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Extras

Introducere

În zilele noastre, datorită dezvoltării rapide a tehnologieitelefoanele mobile uzuale au procesor multi-core și dispun de mulțisenzori. Aceste dispozitive mobile sunt numite generic „smartphone” sau telefoane inteligente șide obicei oferă funcții avansate cum ar fi e-mail-ul, internetul, touch screen-ul cu rezoluție înaltă, WiFi-ul, browser-ul Web și pe care ruleazăun sistem de operare avansat Android, Symbian, iOS, BlackBerry OS sau Windows Mobile. Cea mai mare răspindire dintre acestea o are sistemul Android, care folosește un kernel Linux. Utilizatorii acestor smartphone-uri de obicei folosesc interfețele radio UMTS/LTE și WiFi pentru transferul datelor. Având în vedere natura acestor dispozitive, sunt ideale pentru a modela noduri de rețele distribuite fără fir. Pentru acest lucru acestea trebuie sa comunice direct între ele, lucru realizabil prin interfețe WiFi configurate în modul ad hoc. În cazul WiFi sistemul Android oferă doar modul de comunicare infraștructura, care necesita existența unui Punct de Acces (Acces Point - AP), deși standardul WiFi definește și modul ad hoc. Totuși, unele modele de smartphone-uri pot fi reconfigurate, activând capabilități ascunse, pentru a suporta modul de comunicații ad hoc. Prezența lucrare propune implementarea unei rețele WiFi ad hoc între smartphone-uri Android și caracterizarea acesteia prin măsurarea parametrilor de calitate (Quality of Service - QoS).

Tema lucrării

Scopul lucrării este realizarea unui nod de rețea de comunicare distribuita, folosind dispozitive Android. În rețeaua distribuită fiecare dispozitiv organizează independent comunicarea, nu are element central. Standardele WiFi au soluții dedicate pentru creare conexiuni distribuite: în mod ad hoc dispozitivele au conexiune directa, ca atare pot servi ca noduri în rețeaua propusa. Având în vedere limitările impuse de sistemul Android (lipsa de suport oficial pentru WiFi în modul ad hoc), prima sarcina a mea a fost alegerea unui dispozitiv prin căruia se poate crea conexiune WiFi în mod ad hoc, configurarea dispozitivului, realizarea comunicației peste conexiunile ad hoc. Apoi a trebuit sa dezvolt un modul software care a realizat expedierea pachetelor la nivelul stratului IP (stratul de rețea ISO-OSI), confering funcționalitatea de rutare nodului respectiv. În final am testat rețeaua

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

distribuită, măsurând parametrii de calitate (QoS). Pentru a putea evalua sistemul, am măsurat aceeași parametri și în cazul conexiunii WiFi în modul infraștructură.

Cerințele proiectului

Sistemul trebuie să îndeplinească următoarele cerințe:

 Alegerea unui dispozitiv, care prevede posibilitatea de a stabili conexiune WiFi ad hoc  Configurarea corectă a dispozitivului selectat  Dezvoltarea unui modul software care a realizat expedierea pachetelor la nivelul stratului IP  Testarea performanței rețelei ad-hoc  Documentarea pașilor făcuti

Selectarea si configurarea dispozitivului

Cerința necesară pentru implementarea sistemului este ca smartphone-ul selectat să conțină cip WiFi, care poate suporta modul ad hoc, și sa existe o varianta de sistem de operare care permite configurarea modului ad-hoc. Pe baza literaturii cercetate am ales smartphone-ul Samsung Nexus S, un dispozitiv dezvoltat de producător în cooperare cu compania Google, dezvoltatorul sistemului Android. Deși în dispozitivul ales, modul ad-hoc nu era susținută de nici o versiune oficială a sistemului de operare, am instalat și configurat componentele software (inclusiv versiunea modificata a sistemului de operare) în asa fel, încât am reușit sa expediez pachete IP în mod ad hoc (direct intre smartphone-uri). Sistemul de operare ales a fost versiunea 11 a distribuției Cyanogenmod, o distribuție renumita pentru bogăția funcțiilor ne-oficiale oferite, tradusă la data de 08. iulie. 2014, fiind o versiune nouă și conținea pachetele necesare. Activarea și controlul modului de comunicare ad hoc am realizat prin schimbarea programului de administrare WiFi a telefonului, care este aplicat de programul open source wpa_supplicant. Distribuția amintita mai sus a fost astfel aleasa, încât a conținut și acest modul software.Am efectuat acești pași pe patru smartphonuri Android, după care configurarea rețelei propriu zisă coincis cu configurarea elementelor unei rețele IP, cu excepția setarea routării, aceasta funcție fiind realizată de modulul software dezvoltată de mine, după cum voi prezenta în capitolul următor..

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Aplicația Android După setarea și configurarea rețelei de test, am avut sarcina de a dezvoltă un modul software care a realizat expedierea pachetelor la nivelul stratului IP. Modulul implementat se poate explica prin diagrama de stare prezentata în Fig. 1. Threadul 1 realizează descoperirea vecinilor, acest proces fiind repetat la fiecare 60 de secunde. Threadul 2 de fapt este o bucla infinita, rolul lui fiind recepționarea mesajelor și procesarea informațiilor. Am definit doua tipuri de mesaje. Mesajul „test” care trebuie expediat la destinație. În cazul în care este recepționat de un nod intermediar este transmis mai departe. Dacă este recepționat de nodul care a inițiat testul, atunci se constata momentul de recepție pentru a furniza întârzierea de transmitere a pachetului. Dacă nu e un mesaj test, mesajul respectiv este afișat pe ecran. se citește mesajul care va fi trimis, apoi se afișează lista vecinilor. În cazul apăsării butonului „send” se poate selecta hopul următor și mesajul se va expediază corespunzător. Butonul „test” inițiază testul: se stochează timpul de pornire și se expediază mesajul de tip test.

Fig. 1. Diagrama de stare a modulului software

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Testarea sistemului Am realizat testarea sistemului prin măsurători. Având în vedere numărul smartphone-urilor, am configurat o rețea cu maxim trei hopuri. Aria de acoperire a unei interfețe WiFi este de aproximativ 25m (vezi Fig. 2), după aceea semnalul este foarte slab. Pentru a măsură acest aspect, am măsurat modificarea puterii semnalului la intervale de 10dBm în funcție de distanță. Ca urmare 3 hopuri acoperă o arie cu rază de 75m, ceea ce întrun mediu indoor deja acoperă multe scenarii (expoziții, simpozioane, birouri, magazine) și ne ajută să evaluam în mod realist sistemul realizat

Fig. 2. –Modificarea puterii semnalului în funcția puterii de recepție

Am măsurat lățimea de banda obținuta între doua noduri care comunica direct (Fig. 3.). Se observa, ca acesta se injumatateste în jurul valorii de -60 - -80 dBm. Ca urmare se poate declara, ca limita de jos a comunicării este de -80dBm, ceea ce rezulta într-o distanță maxima nod-la-nod de 25m

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Fig. 2. – Lațimea de banda obținută în modul ad hoc

În modul infraștructura oricât de departe s-ar situa nodurile care comunica între ele, pachetele sunt trimise prin AP-urile aflate la un singur hop distanța de ele. Ca urmare întârzierea de transfer nu se schimbă atât de drastic, așa cum se vede în Fig. 4. Aceste date sunt mediile întârzierilor măsurate și am observat că aceste valori (mai mari) apar din cauza unor întârzieri neobișnuit de mari.

Întârzirea de transfer a pachetelor în mod infraștructură cu 2 nod 120 102 100 89.4 75.9 80 66.8 61.6 64.7

[msec] 60 p

Tim 40

0 -10 -40 -50 -60 -70 -80 Puterea Semnalului [dBm]

Fig. 4. –Întârziere de transmisie pachete -comunicații în mod infrastructura intre doua noduri

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

În cazul ad hoc, am sumarizat într-un singur grafic toate rezultatele (Fig. 5). Se poate observa, că în fiecare caz, în jurul valorii de -50 dBm și -60dBm valoarea întârzierii suferă o degradare semnificativă. Acesta înseamnă că deși lățimea de banda este încă acceptabilă, în cazul unor aplicații real-time sau senzitive la QoS aria acoperita trebuie micșorată

semnificativ, cu mai mult de 10m.

Fig. 5. –Întârziere de transmisie pachete -comunicații în mod ad hoc intre mai multe noduri Concluzii În cadrul proiectului am realizat o rețea de test pentru ștudierea comunicațiilor distribuite mobile. Am dezvoltat un nod cu interfața WiFi în mod ad hoc pe un sistem de operare Android, inclusiv modulul de software necesar expedierii pachetelor între noduri. Am testat acest sistem, masurând parametrii QoS uzuali care descriu calitatea conexiunii. O parte din rezultatele obtinute în timpul proiectului a fost publicat impreuna cu colegii îndrumatorului [1]. Sistemul poate fi extins pentru a suportă comunicații VoIP.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Abstract

Nowadays, thanks to the rapid development of mobile phones it is no longer rare if your smartphone functions on multi-core processor or if it has a multiplicity of sensors. There is no clear definition for the smartphone. Some definitions describe it as a device that has advanced features such as e-mail, the internet, high-definition touch screen, Wi-Fi, Web browser, and which runs on a complete operating system like Android, Symbian, iOS, BlackBerry OS and Windows Mobile. Most phones are used only for switching their 2G / 3G / 4G on and off in order to call or for data link, however our devices are able to do so much more. With the help of the GPS it can give a three dimensional positioning which shows you your exact position on Earth. The device is able to collect data from its environment and it can be shared easily with other phones with the help of the Wi-Fi, using this as base we can create a distributed sensor network.

The aim of my thesis is to create a distributed data-link layered communication on a network based on Android devices. In the distributed network each device organizes the communication independently; there is no central item. Nowadays, the typical data link layer for the packet-switched local area networks is the Ethernet, in wireless environment IEEE 802.11 Wi-Fi. The Wi-Fi’s standard has a specific solution when it comes to creating a distributed network: in ad hoc mode the devices are directly connected to each other, there is no need for infrastructure, for installed Access Point. However, the Android system does not support this mode, despite the fact that some devices with wireless interfaces would allow such solutions. My tasks are the following: to select a device which has the ability of an ad hoc mode Wi-Fi connection then the proper configuration of the device, and finally over the implementation of ad hoc connections to create a communication network layer on these devices then test their performance and make work documentation.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

TARTALOMJEGYZÉK

1. BEVEZETŐ ...... 14 1.1. Bevezető ...... 14 1.2. A dolgozat témája ...... 14 2. HÁLÓZATI ALKALMAZÁSOK ANDROID PLATFORMON ...... 15 2.1. Android ...... 15 2.1.1. Az Android platform szerkezete ...... 16 2.1.2. Az Andorid-alkalmazás komponensei ...... 17 2.1.3. Android vezeték nélküli interfészei ...... 19 2.2. Vezeték nélküli hálózatok ...... 21 2.2.1. Kliens- és szerverprogramok ...... 22 2.2.2. Vezeték nélküli ad-hoc hálózatok ...... 22 2.2.3. Forgalomirányítás és útvonalfelderítés ad-hoc hálózatokban ...... 23 3. A HÁLÓZATI CSOMÓPONT MEGVALÓSÍTÁSA ...... 25 3.1. Projekt célja ...... 25 3.2. Feladat specifikáció ...... 25 3.3. Eszköz kiválasztása ...... 25 3.4. Eszköz rootolása ...... 26 3.5. Operációs rendszer kiválasztása ...... 29 3.6. Ad-hoc mód engedélyezése ...... 30 3.7. A kommunikációs modul ...... 34 4. AZ AD-HOC SZOFTVER MODUL KEZELÉSE ...... 40 4.1. Telepítési útmutató...... 40 5. A RENDSZER TESZTELÉSE ...... 44 5.1. A rendszer tesztelése 2 csomóponttal ...... 44 5.1.1. Ad-hoc hálózat sávszélessége ...... 44 5.1.2. Jelerősség a távolság függvényében ...... 45 5.1.3. Jitter változásának mérése az adatátviteli sebesség függvényében ...... 46 5.1.4. Jitter változásának mérése a csomagok nagyságának függvényében ...... 48 5.2. Üzenetek késleltetése hozzáférési ponton keresztül ...... 50 5.2.1. Csomagok késésének mérése 2 csomópont esetén ...... 50 5.2.2. Csomagkésleltetés 3 csomópont esetén ...... 52 5.2.3. Csomagkésleltetés 4 csomópont esetén ...... 53 5.3. Csomagkésleltetés ad-hoc hálózatban...... 54

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.3.1. Csomagkésleltetés mérése 2 csomóponttal ...... 54 5.3.2. Csomagkésleltetés mérése 3 csomóponttal ...... 56 5.3.3. Csomagkésleltetés mérése 4 csomóponttal ...... 57 5.4. Mérések összesítése ...... 59 6. ÖSSZEFOGLALÓ ...... 62 6.1. Következtetések ...... 62 6.2. Tovább fejlesztési lehetőségek ...... 62 7. Ábrajegyzék ...... 65

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

1. BEVEZETŐ

1.1. Bevezető

Napjainkban a telefonok rohamos fejlődésének köszönhetően már nem ritka ha okostelefonunk többmagos processzorral és szenzorok sokaságával rendelkezik. Nem létezik egyértelmű meghatározás az okostelefonra. Egyes meghatározások szerint egy olyan eszköz, ami fejlett funkciókat tartalmaz, ilyen például az e-mail,az Internet,a nagy felbontású érintőképernyő, a WiFi, a Web böngésző, és amin teljes értékű operációs rendszere fut: Android, Symbian, iOS, BlackBerry OS és a Windows Mobile[2]. Legtöbben csak a telefonok 2G/3G/4G funkciókat használják ki telefonálás és adatkapcsolat céljából, pedig a készülékünk ennél sokkal többre is alkalmas. A GPS segítségével 3 dimenziós helymeghatározást végezhetünk, ami megadja a pontos helyzetünket a földön. A Készülékünk képes a környezetéből adatokat gyűjteni és ezeket könnyedén WiFi segítségével megosztani más telefonokkal, ezt kihasználva könnyedén kialakíthatunk egy elosztott szenzorhálózatot.

1.2. A dolgozat témája

A szakdolgozatom célja egy adat-kapcsolat rétegbeli elosztott kommunikáció megvalósítása Android eszközökből álló hálózaton. Az elosztott hálózatban minden eszköz önállóan szervezi a kommunikációját, nincs központi elem. Napjainkban a csomagkapcsolt helyi hálózatok jellemző adatkapcsolati rétege az Ethernet, vezetéknélküli környezetben a IEEE 802.11 WiFi. A WiFi szabványnak van dedikált megoldása az elosztottkapcsolatok kialakítására: ad hoc módban az eszközök direkt kapcsolatban állnak egymással, nincs szükség infrastruktúrára, telepített hozzáférési pontra (Access Point). Ugyanakkor az Android rendszer nem támogatja ezt a módot, annak ellenére, hogy egyes eszközök vezetéknélküli interfészei lehetővé tennék ezt a megoldást. Feladatom egy olyan eszköz kiválasztása, amelyen lehetséges az ad hoc módú WiFi kapcsolat kialakítása, az eszköz megfelelő konfigurálása, majd ad hoc kapcsolatok felett hálózati rétegbeli kommunikáció megvalósítása ezeken az eszközökön és a megvalósítás teljesítményének tesztelése, a munka dokumentálása.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

2. HÁLÓZATI ALKALMAZÁSOKANDROID PLATFORMON

A munkám során Android eszközöket kellett hálózatba kapcsolnom. Ebben a fejezetben bevezetést nyújtok az Android platformról, valamint a platform által támogatott vezeték nélküli technológiákról. Szintén ebben a fejezetben tekintem át a vezeték nélküli kommunikációt.

2.1. Android

Az Android operációs rendszer az Open Handset Alliance (OHA)[3]tulajdonában van, amit a Google alapított 2007-ben. Az OHA mögött nem csak a Google áll, hanem több vállalat, akik mind kiveszik a részüket a fejlesztésből. Az OHA ismertebb tagjai:  Készülékgyártók (Sony ,HTC, LG, Samsung)  Félvezető cégek (Intel, Nvidia, ARM, Texas Intrument)  Forgalmazó cégek(Teleca, Borqs)  Szoftverfejlesztő cégek (Google, eBay)  Mobilszolgáltatók(Vodafone, T-Mobile, Sprint Nextel)

Az Android platform napjaink egyik legsikeresebb és legismertebb mobiloperációsrendszere, több mint 900 millió Android-alapú készülék volt aktiválva és ez a szám rohamosan növekedik. A rendszer sikerességének hátterében a látványos felhasználói felület, az egyszerű kezelhetőség, a rendszer nyíltsága és kompatibilitása áll. Sikerességének oka még a fejlett hardverek, amelyeken fut az operációs rendszer:ez egyrészt a többmagos, gyors processzor, és nagyméretű memória, valamint a fejlett vezeték nélküli kapcsolatok. A népszerűségének az egyik fő oka a rengeteg médiareklám, az Android előtt kevés mobil eszközt reklámoztak a rajta futtatott operációs rendszerrel, másik fő oka, hogy a rendszer mögött az nagy “IT-óriás”, a Google áll. Az Android további előnye, hogy rendkívüli egységes és kiválóan működő rendszerképet tükröz a felhasználónak, és elfedi az egyes verziószámokat, valamint a köztük levő különbségeket[4].

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

2.1.1. Az Android platform szerkezete

2.1ábra: Az Android platform szerkezete[5]

Az Android platform rétegesen épül egymásra. A legalsó szinten a Linux kernel fut, aminek a feladata a memóriakezelés, a folyamatok ütemezése és további hardware közeli funkciók megvalósítása. Mivel a telefongyártó cégek ismerik a legjobban a készülékük felépítését, ezért ezeket a részeket ők készítik el.

A kernel szint fölött található a programkönyvtárak, amik hardver-közeli funkciókat valósítanak meg. Ezek a könyvtárak C/C++ nyelven készültek.

A következő réteg az Androidfuttatókörnyezet, amely a Dalvikvirtuális gép[6]futtatásáért felelős. Feladata a Java alkalmazások futtatása. A Dalvik egy bájtkódot

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

futtat. A legfelsőbb rétegben futó alkalmazások is a Dalvik virtuális gépen futnak, ez a megoldás rendkívül biztonságossá teszi, mert egy hibásan megírt alkalmazás futtatása után csak a program saját VM áll le, és nem bénítja meg az egész rendszert. A Linux kernel ezeket a virtuális gépeket (VM) ütemezi.

Alegfelső két rétegben csak Java-alapú kódokat találunk, amelyet a virtuális gép futtat, és ez adja Android az lényegét. AVM teljesen elrejti a Linux fájlrendszerét és csak az Android Runtime által biztosított fájlrendszert láthatjuk. Az Android Runtime két fő részre osztható: az alkalmazás-keretrendszerre (Applicatin Framework) és a rendszeren futó alkalmazásokra (Applications). A keretrendszer feladata hogy kiszolgálja az alkalmazásokat, és biztosítja a hozzáférést az erőforrásokhoz. Az alkalmazás réteg feladta a felhasználó által használt programok kezelése.[4]

2.1.2. Az Andorid-alkalmazás komponensei

Android környezetben egy alkalmazás több különböző komponensekből épülhet fel. Egy alkalmazásnak elég, ha egy komponenst is tartalmaz, és egy komponensből többet is tartalmazhat. Minden alkalmazás komponensek különböző célt szolgálnak, legfontosabb jellemzőjük, hogy egyedi felületet biztosítanak, amelyen a rendszer el tudja indítani őket. Négy fő komponens típust különíthetünk el, amelyek eltérő életciklus modellel rendelkeznek.

Az Android komponenstípusai a következők:

 Activity  Service  ContentProvider  BroadcastReceiver

Az Android Activity a legtöbbször használt alkalmazáskomponens. Saját önálló felülettel rendelkezik, amin keresztül a felhasználó az alkalmazással kommunikál. Egy alkalmazás állhat több activityből, ezeknek mind különböző felülettel rendelkeznek és egymáshoz lazán vannak csatolva. Egy activityvel általában egy funkciót szoktak megvalósítani. Legtöbbször létezik egy fő activity, amely induláskor jelenik meg majd ez az activity valamilyen navigáció segítségével megjeleníthet egy új komponenst. Ha egy új activity elindul, az aktuális activity leáll, és egy verem(Back Stack) tetejére kerül, majd az új activity megkapja a vezérlést.[7]

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

A 2.2 ábra az Android életciklusát szemlélteti:

2.2ábra: Activity-életciklusmodell [8]

Életciklus-(callback) metódusok segítségével valósítja meg az Android rendszer azokat a nagyobb eseményeket, amelyek az activity futása közben bekövetkezhetnek.

A 2.2 ábrán látható metódusok: onCreate: Az alkalmazás indításakor hívódik meg. Létrejön az activity és beállítja a megfelelő állapotokat.Lefutás után a következő metódus az onStart.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

onStart: Szerepe az alkalmazás elindítása. Az onCreate vagy az onRestart után kerül meghívásra. onResume: Meghívódásakor az activity láthatóvá válik, előtérbe kerül és a felhasználó kezelheti a rajta levő vezérlőkkel.

2.1.3. Android vezeték nélküli interfészei

Napjainkban a mobilhálózatok rohamos fejlődésen mennek keresztül. Az androidos készülékek tipikusan rendelkeznek WIFI kommunikációs interfésszel, ennek következtében a nagymennyiségű adatletöltés sem okoz problémát. A legújabb hálózati technológiák gyorsan bekerülnek az új mobileszközökbe. Android platformon nagy szabadságot kapunk a hálózat kialakítása és felügyelete fölött[4]. A WiFi az egyik legjobban elterjedt vezeték nélküli technológia, már az API level 1-ben jelen volt, majd az API level 14-ben jelent meg a WiFIp2p(WiFi peer-to-peer).

Az Androidos készülékek vezeték nélküli interfészén funkcionalitásuk szerint 2fő módon létesíthetünk kapcsolatot:  Infrastrukturális mód Működésekor szükség van egy hozzáférési pontra (Access Point - AP), amihez a kliensek csatlakoznak, ez az AP Infrastruktúra módban működik, rajta keresztül kommunikál minden egyes kliens.

2.3ábra: Infrastrukturális mód

o WiFi A WiFi (IEEE 802.11) az egyik legjobban elterjedt vezeték nélküli technológia, az okostelefonokban mindig szokott lenni WiFi chip.A WiFi eszközök legtöbbje 2.4GHz-en kommunikál. Az okostelefonoka legnagyobb adatátviteli sebesség 54 Mbps és hatótávolsága 50 m. Az Androidban kezdetek óta már az API level 1-ben került bevezetésre az alap változat-

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

o Cella alapú rádiós hálózat Ezen rendszerek lényege, hogy a lefedendő területet úgynevezett „cellákra” osztják, minden egyes cellában egy bázisállomással. A bázisállomásokat általában valamilyen nagy sávszélességű vezetékes hálózat kapcsolja össze egymással, valamint az egyéb kommunikációs rendszerekkel. Alapesetben a rádiós készülék mindig ahhoz a bázisállomáshoz kapcsolódik, amelynek épp a hatókörzetében, a cellájában található. Ide Sorolható az UMTS és a LTE hálózatok. Hatótávolságuk lehet akár 10km Adatátviteli sebessége maximum 150Mbps.

 Direkt kapcsolat Nincs szükség hozzáférési pontra vagy bázisállomásokra, a készülékek közvetlenül egymással kommunikálnak.

2.4ábra: Direkt kapcsolat

o WiFi Direct

Akár 100 méteres hatótávolsággal, illetve akár 250 megabites átviteli sebességet is elérhető. Wi-Fi Direct a biztonságos kommunikáció érdekében WPA2 titkosítási modellt használ

o Bluetooth

A Bluetooth(IEEE 802.15.1) technológia a 2,4 GHz-es ISM (Industrial, Scienic, Medical) frekvenciasávban működő kis hatótávolságú rádiós adatátvitelt valósít meg egy bluetooth adó- adó-vevő chip segítségével, két eltérő frekvencián működve.Ez a protokoll 79 csatornát alakít ki, melyek 1MHz szélesek. A leggyakrabban használt a

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Class 2 (2,5 mW) amely 10 méteren belül látják egymást maximális teljesítménye 4 dBm, sávszélessége 25Mbps.

o NFC

Az NFC(Near Field Communication) technológia vezeték nélküli adatátvitelt biztosít rendkívül rövidtávolságokon (5cm) keresztül, alacsony adatsebességgel (2Mbps).AzAndroidban azNFCképességek API szinten az API level 9-ben kerültek bevezetésre.

Androidban az ad-hoc mód hivatalosan nincs támogatva. Ad-hoc hálózatokban az egyes mobilis csomópontok képesek rögzített infrastruktúra és centralizált adminisztráció nélkül egymással kommunikálni, tehát nincs szükség bázisállomásokra vagy hozzáférési pontokra. Ezen tulajdonságok miatt alkalmazásuk rendkívül széleskörű. Önszerveződő jellegükből adódóan elsősorban olyan helyen alkalmazzák őket, ahol nem cél vagy nem lehetséges infrastruktúrával rendelkező hálózat kiépítése; például katonaság esetében harcmezőn a mobilitás miatt, katasztrófa sújtotta területeken, illetve egyéb nehezen megközelíthető helyeken, ahol egyébként túl költséges lenne egy központosított hálózat kiépítése. Az AP-hiányában a hosztoknak maguknak kell biztosítania olyan szolgáltatásokat, mint például az útválasztás, a címkiosztás vagy a DNS- hez hasonló címfordítás. Az ad-hoc hálózatokban a csomópontok egyenrangúak, melyek vezeték nélküli, rádiófrekvenciás adatkapcsolatokon tartják egymással a kapcsolatot. Ezzel a módszerrel nem csak két, hanem több gépet is hálózatba lehet csatlakoztatni, de egy gép csak akkor tud egy másikkal kapcsolatba lépni, ha hatótávolságon belül van. Ha több eszköz csatlakozik, akkor elérhetőségi tesztet hajtanak végre, ennek eredménye vagy direkt kommunikáció, vagy a route bejegyzés frissítése (ez a bejegyzés tartalmazza, hogy kit milyen útvonalon lehet elérni).

2.2. Vezeték nélküli hálózatok

A vezeték nélküli hálózat lehetővé teszi az emberek számára, hogy vezeték nélkül kommunikálhassanak és különböző alkalmazásokhoz és információkhoz férhessenek

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

hozzá.Mozgási szabadságot biztosít a felhasználó számára, továbbá lehetővé teszi az alkalmazások különböző helyekre vagy a világ bármely pontjába történő kiterjesztését.

A vezeték nélküli kapcsolat többféle módon is létesíthető két vagy több eszköz között, viszont minden technológia alapja közös, mind valamilyen rádiósfrekvencia felhasználásával továbbítják, illetve fogadják az adatokat. Egyetlen kivétel az infravörös mely esetében bizonyos hullámhosszú fény segítségével jön létre a kapcsolat.[9]

2.2.1. Kliens- és szerverprogramok

A kliensprogram egy olyan program, amely szolgáltatást igényel és kap egy másik végrendszeren futó szerverprogramtól[10]. Általában a kliens és szerverprogramok különböző számítógépeken futnak, ezért elosztott alkalmazásnak (distribuited applications) nevezzük. A kliens és szerver alkalmazások üzenetküldéssel tartsák a kapcsolatot egymással. Ma már nem minden osztott alkalmazás áll abból, hogy a kliensprogramok kommunikálnak a szerverprogramokkal, egyre inkább fejlődésben van az egyenrangú (P2P, peer-to-peer) alkalmazások, ahol a felek egyenrangúak, szerverként is és kliensként is tudnak működni. Például az internettelefonok esetében is a két végpont egyenrangú társként működnek, mindkét végpont küld is és fogad is adatokat. Mivel nincs közbeiktatott szerver ezért ezt a felépítést egyenrangú társak közötti architektúrának nevezzük(P2P).

2.2.2. Vezeték nélküli ad-hoc hálózatok

A mobil ad-hoc hálózatok (MANET) olyan lokális adathálózatok, amelyek nem igényelnek kiépített fix infrastruktúrát (drótok, szerverek, routerek, switch-ek, stb.), nem rendelkeznek központi adminisztrációval. Ennek oka, hogy csak így lehet elkerülni a hálózat összeomlását tetszőleges csomópont kiesése esetén. Ugyanis bármely csomópont bármely időpillanatban beléphet a hálózatba, illetve elhagyhatja azt. Mivel az egyes csomópont hatósugara korlátozott, egymás hatósugarán kívül eső eszközök kommunikációjához szükség van közbenső csomópont(ok)ra. Ezek közbenső csomópontok átjátszóként illetve routerként (útvonalválasztóként) működhetnek. Ennélfogva a hálózatot alkotó eszközök nagyobb területen kommunikálhatnak, mint saját hatósugaruk. Minthogy a csomópontok mindegyikében működik az útvonalkereső protokoll, az ad hoc hálózatok képesek kezelni a hálózati topológia változásait és az esetlegesen fellépő csomóponti működési hibákat. Ha például egy csomópont hálózatból történő kilépésének következtében megszakad a kapcsolat, az érintett csomópontok az útvonalkereső protokoll aktivizálásával újra felderítik a lehetséges

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

útvonalakat. Ez a folyamat ugyan valamelyest növeli a csomagkésleltetést, azonban a hálózat működőképessége továbbra is fennmarad. A mobil ad-hoc hálózatokat funkcionalitásuk szerint 3 fő csoportba soroljuk:  Vezeték nélküli testen viselt hálózatok (WBANs -Wireless Body Area Nertworks): Ezt a szabványt az IEEE 802.15.6 munkacsoport felügyeli. Egészségügyi alkalmazásai a legjelentősebbek.

 Vezeték nélküli személyes hálózatok (WPANs -Wireless Personal Area Nertworks): A WPAN technológiák segítségével a felhasználók személyes működési környezetükben (POS) használt eszközei (pl. PDA-k, mobiltelefonok és laptopok) ad hoc vezeték nélküli kommunikációra képesek. A POS betűszó a személy legfeljebb 10 méteres környezetét jelöli. Jelenleg a Bluetooth és az infravörös fény a WPAN két legfontosabb technológiája. A WPAN technológiák fejlesztésének szabványosítására az IEEE megalakította a 802.15 munkacsoportot. Ez a munkacsoport fejleszti a WPAN szabványt a Bluetooth 1.0-s verziójú specifikációja alapján. A szabványtervezet elsődleges célkitűzése a kis komplexitás, a kis áramfelvétel, azegyüttműködési képesség és a 802.11 hálózatokkal való együttélés.  Vezeték nélküli lokális hálózatok (WLAN – Wireless Local Area Networks)

2.2.3. Forgalomirányítás és útvonalfelderítés ad-hoc hálózatokban

Felhasznált irodalom: [11]

Ad-hoc hálózatban nem alapozhatunk a rögzített topológiára, a rögzített és ismert szomszédokra, valamint az IP-címek és fizikai elhelyezkedés közötti rögzített kapcsolatra vonatkozó jól bevált szabályokra. Vezetékes hálózatban a routernek megvan valamely címzett irányába egy érvényes útvonala, amely végtelenségig érvényes marad. Ad-hoc hálózatokban a topológia állandóan változásban lehet, ezért az egyes utak érvényessége is spontán, minden előzetes figyelmeztetés nélkül megváltozhat.

Az útvonalválasztás akkor szükséges, amikor egy csomópont kommunikálni szeretne egy másik csomóponttal. Az útvonalválasztó protokoll feladata az útvonalválasztás végeredményétvisszajutassa a kommunikálni kívánó csomópontnak. Ez az eredmény lehet

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

egy vagy több útvonal a forrás és cél között. Ha nem található útvonal a cél és a forrás között, akkor valamilyen jelző objektum küld vissza. Egy ad-hoc hálózatot bármely pillanatban leírhatunk egy gráf segítségével. Két csomópont akkor van összekötve, ha rádiós úton közvetlenül tudnak kommunikálni egymással. Az útvonalválasztás lehet proaktív és reaktív. Proaktív útvonalválasztás során periodikus üzenetekkel határozzák meg a csomópontok közötti lehetséges útvonalakat. Reaktív útvonalválasztás esetében útvonalválasztás akkor történik, ha arra szükség van, amikor egy csomópont kommunikálni szeretne egy másik csomóponttal. A reaktív protokollok hatékonyabbnak minősülnek, mert nem kell periodikuson felderíteni az útvonalat, elemben a proaktív protokoll gyorsabban reagálnak a csomópontnál történő sok kapcsolatváltozásra. Az útvonalválasztó protokolloknak is létezik két fő csoportja. Az egyikbe atávolsági vektor alapú (distance vector routing) protokollok tartoznak, míg a másikba aforrás alapú (source routing) . A source routing protokollok esetében minden üzenet explicit módon tartalmazza azt az útvonalat, amelyen az üzenetnek haladnia kell. Így az üzenetek hossza a változó hosszúságú útvonalak miatt nem állandó. Például. a DSR, Ariadne, SRP. A tábla alapú protokollok esetében az egyes csomópontok az útvonalinformációkat lokálisan általában táblában tárolják , így az egyes hálózatbeli üzenetek nem tartalmazzák explicit módon az útvonalat amelyen az üzenetnek haladnia kell, hanem minden csomópont lokálisan dönt arról, hogy melyik szomszédja felé kell továbbítani az üzenetet.Például. az AODV, SAODV.

2.5ábra: 3 csomópontú ad-hoc hálózat

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3. A HÁLÓZATI CSOMÓPONT MEGVALÓSÍTÁSA

3.1. Projekt célja

A szakdolgozatom célja egy adat-kapcsolatbeli rétegbeli elosztott kommunikáció megvalósítása Android eszközökből álló hálózaton. Az elosztott hálózatban minden eszköz önállóan szervezi a kommunikációját, nincs központi elem. Napjainkban a csomagkapcsolt helyi hálózatok jellemző adatkapcsolati rétege az Ethernet, vezetéknélküli környezetben a IEEE 802.11 WiFi. A WiFi szabványnak van dedikált megoldása az elosztottkapcsolatok kialakítására: ad hoc módban az eszközök direkt kapcsolatban állnak egymással, nincs szükség infrastruktúrára, telepített hozzáférési pontra (Access Point - AP). Ugyanakkor az Android rendszer nem támogatja ezt a módot, annak ellenére, hogy egyes eszközök vezetéknélküli interfészei lehetővé tennék ezt a megoldást. Feladatom egy olyan eszköz kiválasztása, amelyen lehetséges az ad hoc módú WiFi kapcsolat kialakítása, az eszköz megfelelő konfigurálása, majd ad hoc kapcsolatok felett hálózati rétegbeli kommunikáció megvalósítása ezeken az eszközökön és a megvalósítás teljesítményének tesztelése, a munka dokumentálása. Ebben a fejezetben a mobil csomópont megvalósítását mutatom be, ami az eszköz kiválasztásának, konfigurálásának lépéseit, valamint a kommunikációs modul megvalósítását jelenti.

3.2. Feladat specifikáció

A munkám során elvárás volt az ad hoc képességű WiFi kommunikáció megvalósítása az vezeték nélküli interfészen, azaz ne emuláljam azt például AP-vel való helyettesítéssel. További elvárás volt a mobil csomópontok útválasztóként való működése, ami konkrétan a szomszédok felderítését, valamint a csomag továbbítását jelentette.

A megvalósítás teljesítményével szemben nem volt QoS paraméterekben kifejezett elvárás, a feladatom az volt, hogy a mérhető paraméterek nagyságrendileg az infrastruktúra módú WiFi hálózatokban tapasztaltakkal egyezzenek.

3.3. Eszköz kiválasztása

A rendszer megvalósításához szükséges elvárás, hogy az telefonok rendelkezzenek WiFi chippel, amely támogatja a p2p módot, és ezen felül legyen egy olyan operációs rendszer, amely támogatja az ad-hoc módot. A végül a Samsung Nexus S készüléket választottam. Az

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

ad-hoc módot a készülék hivatalos operációs rendszere közül egyik verzió sem támogatta, viszont a Cyanogenmod cm-10.2.1 verziója igen.

3.4. Eszköz rootolása

Szeretném már az elején kihangsúlyozni, hogy a továbbiakban leírt rootolás vagy operációs rendszer újratelepítését csak saját felelősségre végezze el. A telefon rootolása és új operációs rendszer telepítése a készülék garanciájának elvesztésével jár!

Alapesetben a telefonunk Android operációs rendszerén csak korlátozott felhasználók vagyunk, a rootolás nem más, mint rendszergazdai jogot szerzünk a készülékünkön. Egy átlagos felhasználónak nincs szüksége rendszergazdai jogra, nem kell módosítania a rendszerfájlokat, nem kell a gyári fájlokat, alkalmazásokat letörölnie, és nem kell a processzor órajelét módosítania. A rootjogosultság megszerzése után olyan alkalmazásokat is telepíthetünk, amelyek csak rootolt készüléken hajlandók futni. Egy rootolt készülékre bármikor telepíthetünk új,egyedi ROM-t, ez fontos számunkra a továbbiakban, hogy készülékeink tudjanak ad-hoc hálózatot kialakítani és csatlakozni.

Az általam használt Nexus S készülék rootolásátaz Windows operációs rendszerrel rendelkező számítógép segítségével az alábbi lépések szerint lehet megvalósítani. A készüléket USB kábellel kell a számítógéphez csatlakoztatni, majd telepíteni kell a megfelelő meghajtó programot.Ez legtöbb esetben automatikusan megtörténik, de lehetséges az is hogy manuálisan kell megtegyük. Amennyiben a Windows nem ismeri fel készülékünket le kell tölteni a Google USB meghajtót, majd a Számítógép - jobb klikk - Tulajdonságok – Eszközkezelő menüt kell kiválasztani, majd ajobb az Android 1.0 eszköz legördülő menüjéből az- Illesztőprogram frissítése opciót kell kiválasztani. A megjelenő ablakban az Illesztőprogramok keresése a számítógépen hivatkozást kell választani.Ekkor kell a kicsomagolt USB Driver-t kiválasztani, és Tovább lépni. Ha ez megvan, akkora készüléket kell a Fejlesztői lehetőségek menüpontotaktiválni. Ehhez aBeállítások -> A telefonról menü pontban a „Build szám” opcióra hétszer kell „kattintani”. Ekkor már kiválasztható a Fejlesztői lehetőségek menüpont, ezen belülpedig aktiválni kell a USB hibakeresést és az ADB hálózaton belüli lehetőségeket.

A következő lépés egy megfelelő állapot-visszaállító (recovery) alkalmazás kiválasztása A recovery egy olyan szoftver, ami a kernel után töltődik be és az Android operációs rendszer előtt. Szoftver hiba esetén, amikor a készülékünk nem indul el, ennek segítségével

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

orvosolhatjuk a problémát. Hiba esetén ameddig hozzáférünk a recoveryhez készülékünk “Softbrick” állapotban van. Ha a rendszer nem tud betöltődni és a recovery sem jön elő akkor Bootloop állapotba került.

Én a TWRP-t ( Team Win Recovery Project) választottam, mert grafikus felülettel rendelkezik és az érintő képernyő is működik[12]. Teljes mértékben lekezel minden funkciót, ami számunkra szükséges. Ahhoz, hogy mobileszközünket rootolhassuk, általában szükség van egy alkalmazásra(Nexus Root Toolkit, SuperOneClick, Z4Root, stb.).A választás ebben az esetben a Nexus Root Tolkit 2.0.5 verziója volt[13]. Ez a program automatikusan felismeri a készülékünket és a rajta futó aktuális operációs rendszer, majd letölti a készülék rootolásához szükséges fájlokat köztük a telefonhoz megfelelő TWRP recovery-t is. A program telepítése után rendszergazdai jogosultságunkszerezhetünk a készülékünkön. A program tartalmaz egy teljes funkcionalitású interfészt melyet a3.1 ábra szemléltet.

3.1ábra: Nexus Root Toolkit alkalmazás [13] Először az Unlock, majd a Root gombra kattintva automatikusan rootolódik a készülékünk.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

A root beállítások kezelése veszélyes lehet, ezért megkell védenünk a telefonunkat és a rajta tárolt személyes adatainkat a káros programoktól. Ennek megvédése érdekében fontosnak tartom még a SuperSu nevű alkalmazás telepítését. Ez az alkalmazás menedzseli a különböző alkalmazások számára elérhető jogosultságokat. Telepítéséhez másoljuk a készülék belső memóriájára vagy a hozzá csatolt SD kártyára a programot és kapcsoljuk ki telefonunkat majd Vol+ és Power gombok hosszan tartásával indítsuk el a készülékünket.

3.2ábra: A készülék fastboot menüje Navigáljunk a hangerő fel/le gombok segítségével a RECOVERY menüpontra majd a Power gomb lenyomásával indítsuk el a telepített TWRP recovery-t.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.3ábra: A készülék recovery menüje Majd válasszuk az Installmenüt és keressük meg a tárhelyen a SuperSU.zip állomány és telepítsük. Újraindítás után futtathatjuk is alkalmazásunkat.

3.5. Operációs rendszer kiválasztása

Mivel az Android operációs rendszer a Linux kernelre épít, ezért sokan próbálják testre szabni, és az így elkészített képfájlok (image) nyilvánosan elérhetők. Az egyik széles körben használt, megbízhatóként ismert csoport a Cyanogenmod[14]. Ennek a csoportnak a11es verziójának a 2014 július 08.-án fordított változatát választottam, mert friss kiadás volt és tartalmazta a számomra fontos csomagokat. Ez a csomagolt fájlletölthető a következő URL- ről: [http://download.cyanogenmod.org/get/jenkins/57343/cm-10.2.1-crespo.zip]. Ez a verzió tartalmazza az ad-hoc működési módot és egyszerű telepíteni a készülékünkre. Ennek telepítéséhez csak az SD kártyára vagy a belső tárhelyre kell valahova ráhelyezni ezt a zipállományt. Ezek után kikapcsolni a készüléket, majd a hangerőszabályzó felfele gomb nyomva tartása mellet bekapcsolni a készüléket, ezzel belépve az úgynevezettfastboot módba. Innen a recovery mód választása után Wipe menüpontot kell választanimajd egy húzással felszabadulnak az adatok, a Dalvik , és a cache memóriát, aztánaz Install menüponttal ki kell keresni a tárhelyre másolt zip fájlt, és rövid idő alatt már rendelkezésre is áll a készülék használatra (ld. előző alfejezetet is).

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.6. Ad-hoc mód engedélyezése

Androidban az ad-hoc mód hivatalosan még nincs támogatva, de bárki csinálhat egy olyan Android operációs rendszert, ami engedélyezi az IBSS (Independent Basic Service Set) típusú kapcsolatokat. Ez a telefon WiFi kezelő programjának módosításával lehet elérni amit a /System/bin könyvtárban található wpa_supplicant nevű nyílt forráskódú program végez[15]. Ennek a programnak a módosításához root joggal kell rendelkeznie a felhasználónak, mert alapesetben ez a könyvtár kizárólag olvasási jogosultsággal rendelkezik. Ebben az esetben viszont a keresési eredményben szereplő IBSS hálózatokat normál hálózatként mutatják a rendszer számára. Ha a felhasználó ezt a hálózatot választja ki csatlakozásra, akkor engedélyezi a wpa_supplicantnak hogy IBSS hálózathoz csatlakozzon ad-hoc módban. Egy másik módszer, amit én is alkalmaztam az, hogy olyan dedikált ROMot telepítek a telefonra amiről tudható, hogy támogatja ezt a funkciót. Ha megvan az operációs rendszer telepítése, következő lépés a hálózat kialakítása. A Beállítások -> Wi-Fi menüpontban be kell kapcsolni a készülék wireless chipjét, majd a Hálózat hozzáadása (általában egy + ikon jelzi ) lehetőséget kell választani.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.4ábra: Ad-hoc hálózat létrehozása Mivel ad-hoc hálózatban nincsAP az IP címeket statikusan kell megadnunk.

A jelerősség mérésére a Wifi Analyzer alkalmazást használtam, ami a telefon számára elérhető WiFi hálózatok jelerősséget méri decibelben és ábrázolja grafikusan.[16] AWiFi eszközök(802.11g/n) 2.4 GHz-es frekvencián kommunikálnak, ettől térhetünk el, ha különböző csatornákat választunk. Két csatorna között 5 MHz a különbség.Az alkalmazás segítségével nyomon tudjuk követni a környezetünkben észlelhető WiFi hálózatokat erősségét és hogy melyik csatornában van. A 3.5 ábrán látható hogy létrejött a hálózat a 2412 MHz frekvencián amire más IBSS hálózatot támogató készülékekről lehet csatlakozni. [17]A grafikonon a vízszintes tengelyen a csatornák száma, a függőleges tengelyen a jelerősség látható. Megfigyelhető továbbá, hogy az adhoc nevű hálózat nincs egyetlen hálózattal sem átfedésben, tehát nem fogja befolyásolni az 5.fejezetben végrehajtott méréseket.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.5ábra: Jelerősség grafikus ábrázolása [17] A tesztek során 4 készülék állt rendelkezésemre melyek a következő IP címekkel működtek:  192.168.1.2 – A csomópont  192.168.1.3 – B csomópont  192.168.1.7 – C csomópont  192.168.1.10 – D csomópont

A 3.6 ábrákon látható,hogy egy másik telefonon megjelenik a létrehozott hálózat és lehet csatlakozni hozzá csak statikusan bekell állítsunk magunknak egy C osztályú IP címet. Majd ha mindent beállítottunk a kapcsolódás gombhoz érve csatakozik az ad-hoc nevű IBSS hálózatunkhoz. Mivel statikusan konfiguráljuk az IP címeket, vigyázni kell hogy két készüléknek ne adjuk ugyanazt az IP címet!

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.6ábra: A létrejött IBSS hálózat

3.7ábra: Csatlakozás a létrejött IBSS hálózathoz

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.7. A kommunikációs modul

Az alkalmazásom feladata ad-hoc kapcsolatok felett hálózati rétegbeli kommunikáció megvalósítása ezeken az eszközökön. Mivel az Android eszközök nem támogatják az ad-hoc módot, ezért a megvalósított és megfelelően konfigurált ad-hoc hálózat esetében sem sikerült megoldani, hogy két végpont egy harmadik eszközön keresztül adatokat cseréljen az adatkapcsolati rétegben. Amíg Linux operációs rendszerben lehetőség van routerként üzemeltetni egy számítógépet (pl. Linux laptopokat WiFi interfésszel)[18], ezek a módszerek nem vezettek eredményre az általam konfigurált hálózatban.

Továbbá alkalmazásomnakfel kell derítse és tárolnia a hálózatban levő aktív eszközöket. Mivel mobilis eszközökről van szó, időközönként frissíteni kell a tárolt adatokat, hogy mindig érvényes információnk legyen. Az itt felsorolt okok miatt terveznem kellett egy olyan szoftvermodult, amely a fenti funkciókat képes nyújtani.

Az Android alkalmazás fejlesztéséhezEclipse fejlesztőkörnyezetet használtam[19]. Az Eclipse közkedvelt fejlesztőkörnyezet Java-, Java EE, C++ és egyéb projektek fejlesztéséhez, számos pluginnal kiegészíthető így a fejlesztők rugalmasan testre szabhatják. A 3.8 ábrán látható az alkalmazás osztálydiagramja.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.8ábra: A szoftver osztálydiagramja Az Ad-Hoc nevű alkalmazás 2 fő activityből áll. Az első activity (MainActivity) (3.8 ábra) az alkalmazás indításakor kerül előtérbe. 5 fő komponenst találunk rajta, az első egy

TextView, ami segítségével megjeleníthető az eszközünk IP címe, ami a WifiManagerosztály

.getConnectionInfo(); metódusa térít vissza.[20] Az IP cím lekérése után a hálózatban levő csomópontok felderítése következik, amit a discoverNeighborNodes(); metódus végez. A metódus hívásakor töröljük a Nodes lista tartalmát. Mivel tudjuk, hogy C osztályú IP címünk van, a teszthálózatban engedélyezett IP címeket lekérdezzük ping paranccsal és az elérhető csomópontokat hozzáadjuk a listánkhoz. A méréseim során C osztályú IP címet használtam, és legfennebb 10 csomópontra terveztem (a munkám során tényleges maximális csomópontszám 5 volt), így konkrétan 10 ping üzenetet küldtem ki az 192.168.1.1-től 192.168.1.10-ig címekre. AzupdateTimerThread() metódus minden percben meghívja discoverNeighborNodes(); metódust ,így frissül az elérhető csomópontok listája.

A második fő komponens egy editText, a harmadik a Send gomb. A Send gomb lenyomására az editText típusú mezőből kiolvassa a beírt szöveget és a string típusú msg változóba kerül.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Ez a string bekerül egy intent-objektum extrák mezőjébe, az intent meghívásakor elindul a második activity, és az elküldeni kívánt üzenet átadódik. A ListViewActivity Nodes lista tartalmát jeleníti meg, ami az eszközök számára elérhető csomópontokat tartalmazza. Acél csomópont kiválasztása után létrejön egy UDP socket majd kiolvassuk az intent extrák mezőjében levő üzenetet és elküldi az üzenetet.

Mivel ad-hoc osztott alkalmazásról van szó minden készülék egyben kliens és szerver is, tehát kell tudjon adatokat küldeni és adatokat fogadni. Az adatok fogadása főszálon nem lehetséges mert nem lehet tudni mikor fogunk adatot kapni és a DatagramSocket receive metódusa blokkolásos függvény, ezért egy szállat kell létrehozni ami végtelen ciklusban hallgatózik a 11111-es porton. Ez valósítja meg a MyDatagrammReceiver szál. Mikor üzenet érkezik az adatot a feladó IP címével együtt megjelenik a MainActivity ReceivedtextView mezőjében.

Az alkalmazás a 192.168.1.2 (A csomópont) esetén kiegészült egy teszt funkcióval, ami több csomópont esetén alkalmazható. A MainActivity tartalmaz egy Test nevű gombot. A Teszt gomb lenyomására létrejön egy UDP socket, ami 64 bájtot küld ki a 192.168.1.3 IP címre (–B csomópont). Küldéskor a startTime long típusú váltózóba lekéri a rendszer aktuális idejét. A csomag visszaérkezésekor ismét lekéri az aktuális időt, majd a kettő különbségéből megkapjuk az oda-vissza út idejét. Ez az időt kiírja a ReceivedtextView mezőbe, illetve LogCat ablakba amit debugolás közben olvashatunk le az Eclipse programból. 2 csomópont esetén ha teszt üzenetről van szó a B változatlanul visszaküldi, ha 3 csomópontról beszélünk akkor továbbítja C-nek (192.168.1.7), illetve ha C már megkapta és visszaküldte B továbbítja A-nak. Amint a 3.9 ábrán látható, 4 csomópont esetében az A és B csomópont feladata nem változik a C nem küldi vissza B-nek hanem továbbítja D-nek majd a D küldi vissza a C-nek , a C a B-nek és a B az A-nak. Fontos hogy az IP címek mindig a 3.6 fejezetben tárgyaltak legyenek. Ez a folyamat látható a szekvencia diagramon (3.9 ábra)

A 3.10 ábrán az alkalmazás állapot diagramja látható. Az szál 1 ágon a szomszédok felderítésének megvalósítása látható, ez a folyamat minden percben automatikusan meghívódik. A szál 2 tulajdonképpen egy végtelen hurok, feladata a beérkező üzenetek fogadása és az adatok feldolgozása. Két lehetséges üzenettípus van, az egyik a teszt típusú, ha nem ő volt a teszt üzenet kezdeményezője akkor továbbítja a következő csomópontnak, ha ő volt a feladó akkor lekéri az aktuális időt, majd kivonja a küldéskor lekért időt és kiszámolja

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

az eltelt időt és megjeleníti a felhasználónak . Ha nem teszt üzenetről van szó akkorcsak megjeleníti. A send gomb megnyomására beolvassa egy változóba az elküldeni kívánt üzenetet, majd megjelenik a szomszédok listája, a kiválasztott elemhez érve elküldi az üzenetet. A teszt gombhoz érve ami csak az A csomópontnak érhető el az alkalmazás létrehoz egy 64 bájtos teszt üzenetet és kiküldi a B csomópontnak, majd visszatér a MainActivitybe.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.9 ábra: A szoftver teszt funkciójának szekvencia diagramja

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

3.10 ábra: A szoftver állapotdiagramja

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

4. AZ AD-HOC SZOFTVER MODUL KEZELÉSE

4.1. Telepítési útmutató

4.1ábra: USB-háttértár

Érintsük meg az USB-tár bekapcsolása gombot, másoljuk át a letöltött Ad-Hoc.apk állományt a készülék belső memóriájába, majd az USB-tár kikapcsolása gomb érintése után biztonságosan eltávolíthatjuk a készüléket. Keressük meg a fájlkezelőben az Ad-Hoc.apk állományt majd érintésre elindul a telepítő.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

4.2ábra: Ad-Hoc.apk telepítése A telepítő alkalmazás kilistázza az általunk telepíteni kívánt alkalmazás hozzáférési jogosultságait:

 Hálózati kapcsolatok megtekintése  Teljes hálózati hozzáférés  Wi-Fi kapcsolatok megtekintése

A telepítés gombhoz érve elkezdődik a telepítés és rövid időn belül elkészül.

4.1. Felhasználói útmutató

Az alkalmazás sikeres telepítése után indíthatjuk a programot. Az első felhasználói felület első sorában megjelenik az készülékünk IP címe. A második sorban egy szerkeszthető szövegmező kapott helyet, ide kell beírni az elküldésre szánt üzenetet (4.3 ábra).

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

4.3ábra: Ad-Hoc alkalmazás A Send gombhoz érve előjön egy lista, ami tartalmazza azon hálózatban levő készülékek elérhetőségét ami a készülék hatósugarában van. Ez a lista tartalmazza a szomszéd csomópontok IP címét és Port számát. A kiválasztott csomóponthoz érve elküldi a beírt szöveget.

4.4ábra: A hálózatban levő csomópontok A 4.5 ábrán látható hogy az elküldött üzenet a küldő címével megjelent a cél csomópontnál.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

4.5ábra: A célba ért üzenet

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5. A RENDSZER TESZTELÉSE

Feladatom megvizsgálni az ad-hoc módú eszköz-eszköz közti kommunikációt Android eszközök hálózatán. Ennek érdekében rejtett képességeket kihasználva konfiguráltam az eszközöket és megvalósítottam azokat a szoftver modulokat amelyek képesek ez a kommunikációt támogatni. Ebben a fejezetben a mérés alapú tesztek eredményeit mutatom be. Méréseimben a késleltetésre, késleltetés ingadozásra, csomagvesztésre összpontosítottam. Azért választottam ezeket a paramétereket, mert ezek hatnak direkt a QoE-re (Minőségi tapasztalat, Quality of Expeience), ezek fontosak a felhasználói élmény szempontjából. Méréseim a QoE-re próbál mérőszámot adni, a hálózat paramétereire alapozva. Az 5.1 alfejezetben független mérőprogramot használtam, az IPerf-et[21]. Majd az 5.2 és 5.3 alfejezetben az általam készített alkalmazás segítségével végig mértem a fizikailag rendelkezésemre álló maximális számú csomóponttal konfigurálható teszthálózatot. Ezzel a megoldással tudtam 2,3 és 4 csomóponton keresztül menő kommunikációt vizsgálni. Ezeket a méréseket elvégeztem infrastruktúra módban is az összehasonlítás kedvéért (5.2 alfejezet). Ad-hoc módban végzett méréseimet az 5.3 alfejezet tartalmazza. A mérések összehasonlító értékelését az 5.4 alfejezet tartalmazza.

5.1. A rendszer tesztelése 2 csomóponttal

5.1.1. Ad-hoc hálózat sávszélessége

Az adatátviteli sebességet az IPerf nevű alkalmazás segítségével mértem, amely egy TCP és UDP sávszélesség teljesítmény mérésére kifejlesztett szoftver[21]. A mérést 2 Nexus S készülék segítségével végeztem el. A 2 eszköz között kiépítettem egy Ad hoc hálózatot ebből az egyiket (A node) Servernek konfiguráltam (-s –p 12000 paranccsal) a másikat kliensnek ( -c ”Server Ip címe” –p 12000 –t 60 –i 1 ). Ez azt jelenti hogy 0-60 másodpercig minden másodpercen elküld egy csomagot a szervernek, méri az adat átviteli sebességet majd a végen átlagot számol. A mérést megismételtem -10dB-ként -10dB-től -90dB-ig. Az eredményt az 5.2 táblázat szemlélteti.

5.1 ábra: Két csomópontos teszteset

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Jelerősség Idő Adatmennyiség Átlag Sebesség [dBm] [Sec] [Mbytes] [Mbits/sec] -10 0.0-60.1 256 35.7 -20 0.0-60.2 276 38.4 -30 0.0-60.0 270 37.8 -40 0.0-60.1 269 37.5 -50 0.0-60.1 272 38.0 -60 0.0-60.2 260 36.3 -70 0.0-60.1 153 21.3 -80 0.0-60.1 98.9 13.8 -90 0.0-61.1 20.6 2.83

5.2 táblázat: Ad-hoc hálózat sávszélesség mérésének mérési eredménye

Sávszélesség 45

40 38.4 37.8 37.5 38 35 35.7 36.3

[Mbps] 30

20 21.3

15 13.8

10 Adatátviteli Sebesség Sebesség Adatátviteli 5 2.83 0 -10 -20 -30 -40 -50 -60 -70 -80 -90 Jelerősség [dBm] 5.3 ábra:Ad-hoc hálózat sávszélessége A teszt elvégezése után arra a következtetésre jutottam, hogy -60dBm jelerősségig 35.7 és 38.4 Mbit/sec intervallum között mozog, majd -60dBm-től kezd csökkeni.

5.1.2. Jelerősség a távolság függvényében

Ebben a tesztben két készüléket különböző távolságokra helyeztem egymástól, direkt rálátásra voltak egymással. A két készülék közti távolságot változtattam és figyeltem a jel erősségének a változását a WiFi Analyzer nevű alkalmazással. Eredményeimet az5.4 táblázat foglalja össze:

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Távolság Jelerősség [m] [dBm] 0.5 -39 1 -45 2 -48 4 -64 8 -68 16 -70 24 -81 32 -89 5.4 táblázat: Jel erőssége a távolság függvényében mérés eredménye

A Jel erősségének változása a távolság függvényében 0 -10 0.5 1 2 4 8 16 24 32 -20 -30 -39 -45

-40 -48 [dBm] -50 -64 -60 -68 -70

Jelerősség Jelerősség -70 -81 -80 -89 -90 -100 Távolság [m]

5.5ábra: Jel erőssége a távolság függvényében

5.1.3. Jitter változásának mérése az adatátviteli sebesség függvényében

Ebben a tesztben a jitter változását mértem a sávszélesség módosításával -10dbm jelerősségnél, 10 mbit/másodperctől 40mbit/másodpercig 5mbit/másodpercenként. Továbbá mértem az összes átküldött datagrammot és az elveszett datagrammokat.

A méréshez az Iperf nevű alkalmazást használtam, a következő paraméterekkel:

Server oldal: -s -u -i 1  -s : jelenti, hogy szervernek konfiguráltuk készülékünket

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

 -u : jelenti,hogy UDP protokolt szeretnénk használni  -i 1: beállítja az időközt másodpercben ameddig ismételje a mérést. Kliens oldal: -c “Server IP címe” –u –b “ 10m”  -c: beállítja az eszközt kliensnek, majd utána következik a szerver IP címe  -b: segítségével beállíthatjuk a sávszélességet, hogy kliensünk milyen gyorsan küldje az üzeneteket.

Tesztemben a –b paraméter értéket változtattam és figyeltem a jitter változását.

A 5.6 táblázat szemlélteti a mérés eredményeit.

BW Jitter Lost Datagrams Total Datagrams Total Datagrams/ [mbit/sec] [msec] Lost Databrams [%] 10 0.588 0 8282 0 15 0.294 0 12705 0 20 0.166 1 16865 0.01 25 0.352 0 20949 0 30 0.482 0 25323 0 35 0.225 0 29622 0 40 0.388 11 33631 0.03 5.6 táblázat: Ad-hoc hálózat jitter és adatvesztés mérés eredménye sávszélesség függvényében

Jitter 0.7 0.588 0.6 0.482 0.5 0.388 0.4 0.352

[msec] 0.294

ő ő 0.3

Id 0.225 0.2 0.166

0.1

0 10 15 20 25 30 35 40 Sávszélesség [Mbps] 5.7ábra: Ad-hoc hálózat Jitter

A számításokból kiderült, hogy az átlag jitter 0.356429 [msec] csomagvesztés nagyon kevésszer fordult elő.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.1.4. Jitter változásának mérése a csomagok nagyságának függvényében

Ezt a tesztet 4 különböző jelerősségnél: -20dBm , -40dBm , -60dBm , -80dBm jelerősségeknél minden jelerősségnél 2 különböző nagyságú datagrammokra: 8kByte, 16kByte, 32kByte. A mérést a lehető legnagyobb sávszélességen 40mbit/másodpercen végeztem.Amikor 32KB adatot akarunk küldeni, akkor azokat 23 darab 1.5KB-os csomagokra bontva tudjuk csak megtenni. Emiatt gyors egymásutánban, egy börsztben kell kiküldeni 23 csomagot, utána meg egy hosszú szünet következik a következő 23 csomagos börsztig. Ez a nagy, egyszerre indított börszt okozza a kiugró adatvesztést és nem az egyenletesen eloszló forgalmi terhelésre jellemző körülmények. Ehhez a teszthez is az Iperf nevű alkalmazást használtam, a következő paraméterekkel:

Server oldal: -s -u –l “ ” –w “ ” –i 1  -s, -u, -i 1: lásd előző teszt.  -l :Az írási és olvasási buffer hossza. Alapértelmezetten 8 KB TCP-n, 1470 bájt UDP-n.  -w: Beállítsa a buffer hosszát.  Kliens oldal: -c “Server IP címe” –u –b 40m –l „ ” –w „ ”

Datagramm length Jitter BW Transfer Lost Total Total/Lost [kByte] [ms] [Mbits/sec] [Mbyte] [%] -20 dBm 8k 1.141 31.5 37.8 1256 6069 21 -20 dBm 16k 0.777 33.1 39.6 480 3014 16 -20 dBm 32k 2.336 26.8 32.1 486 1512 32 -40 dBm 8k 0.542 33 39.6 1002 6076 16 -40 dBm 16k 0.748 34.2 41 397 3020 13 -40 dBm 32k 1.267 36.9 43.9 115 1520 7.6 -60 dBm 8k 1.51 30.6 37.3 1295 6075 21 -60 dBm 16k 1.255 28.6 34.3 827 3023 27 -60 dBm 32k 2.237 36.6 43.8 112 1515 7.4 -80 dBm 8k 15.134 3.09 3.88 5483 5980 92 -80 dBm 16k 58.061 2.26 2.75 2825 3001 94 -80 dBm 32k 69.573 0.999 1.22 1464 1503 97 5.8táblázat: Ad-hoc hálózat jitter és adatvesztés mérés eredménye csomagok nagysága függvényében

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

80 Jitter 69.573 70

58.061 60

Jiter [msec] Jiter 30

20 15.134

10 1.141 0.777 2.336 0.542 0.748 1.267 1.51 1.255 2.237 0 8k 16k 32k 8k 16k 32k 8k 16k 32k 8k 16k 32k 20 20 20 40 40 40 60 60 60 80 80 80 dBm dBm dBm dBm dBm dBm dBm dBm dBm dBm dBm dBm Jitter [ms] 1.141 0.777 2.336 0.542 0.748 1.267 1.51 1.255 2.237 15.13 58.06 69.57 5.9ábra: Jitter változása a csomagok nagysága és a jelerősség függvényében

Jitter 2.5 2 1.5 1 0.5 0

8k 16k 32k 8k 16k 32k 8k 16k 32k Jitter [msec] Jitter 20 20 20 40 40 40 60 60 60 dBm dBm dBm dBm dBm dBm dBm dBm dBm Jitter [ms] 1.141 0.777 2.336 0.542 0.748 1.267 1.51 1.255 2.237

5.10ábra: Jitter változása 20dBm-től 60dBm-ig

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Összes és Elveszett Datagramok 7000 6069 6076 6075 5980 6000 5483 5000 Elveszett datagramm 4000 3014 3020 3023 28253001 3000

Datagrams 2000 1256 1512 1520 1295 1515 14641503 1002 827 Osszes 480 486 397 datagramm 1000 115 112 0 8k 16k 32k 8k 16k 32k 8k 16k 32k 8k 16k 32k

5.11ábra: Őszes és elveszett datagrammok

5.2. Üzenetek késleltetése hozzáférési ponton keresztül

Az előző tesztekben a készülékek direkt kapcsolatban álltak egymással, a hálózatban nem volt hozzáférési pont (Access Point). A következő tesztekben a hálózat annyiban különbözik, hogy a készülékek nem közvetlenül egymással, hanem egy bázisállomáson keresztül (AP) kommunikálnak. A hozzáférési pont amihez a készülékek csatlakoztak egy TP-LINK TL-WR941ND típusú wireless router volt.

5.2.1. Csomagok késésének mérése 2 csomópont esetén

A tesztet az általam készített alkalmazás segítségével végeztem. Az A csomópont feladata egy teszt üzenet átalakítása byte tömbé, a rendszertől lekérni az aktuális időt milliszekundumban a következő metódussal : startTime = System.currentTimeMillis();, elküldeni a B csomópontnak, majd várni hogy érkezzen vissza. A B csomópont feladata az ,hogy figyelje a beérkező üzeneteket és abban az esetben ha teszt üzenetet kap változatlanul visszaküldi a feladó IP címére ez esetben a 192.168.1.2 címre. Amikor az A megkapja a visszaküldött üzenetet lekéri az aktuális idő a rendszertől (endTime), majd kivonja a két értéket egymásból és megkapja az oda-vissza eltelt időt. Ez a megoldás hasonló az Internet Control Message Protocol (ICMP) ping parancsához ami a megfelelő viszhangválasz- üzenetek fogadását jeleníti meg az oda-vissza út idejével együtt . Ezt a tesztet tízszer végeztem el -10dBm,-40dBm,-50dBm,-60dBm,-70dBm,-80 dBm jelerősségeknél , majd a végén átlagot számoltam.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

A csomópontok statikus IP címmel csatlakoztak a hozzáférési ponthoz, az 5.12ábraszerint.

5.12ábra: 2 csomópont + hozzáférési pont A5.13 táblázatbanláthatóak a mérés eredményei:

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 61.6 3 155 -40 66.8 9 127 -50 64.7 4 148 -60 75.9 10 193 -70 89.4 7 316 -80 102 10 314

5.13 táblázat: 2 csomópont + hozzáférési pont mérés eredménye

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Késleltetés 2 csomóponttal hozzáférési ponton keresztül 120 102 100 89.4 75.9 80 66.8 61.6 64.7

[msec] Idő 40

0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm] 5.14 ábra: Késleltetés 2 csomópont +AP 5.2.2. Csomagkésleltetés 3 csomópont esetén

Ez a teszt az általam készített alkalmazással készült. Az A csomópont feladata megegyezik az 5.2.1 fejezetben tárgyalt esettel. A B csomópont figyeli a bejövő üzeneteket és ha teszt üzenettel találkozik akinek a feladója a 192.168.1.2, akkor változatlanul továbbítja a C csomópontnak azaz a 192.168.1.7 IP címre. A C csomópont is figyeli a bejövő üzeneteket és ha megkapta a továbbított üzenetet akkor változatlanul visszaküldi a B csomópontnak és a B továbbítja vissza a feladónak. Ez a folyamatot szemlélteti az 5.15 ábra. Az A csomópont ebben az esetben is küldéskor és érkezéskor is lekérte a rendszertől az aktuális időt és a két értékből kiszámolta az eltelt időt.

5.15ábra: 3 csomópont + hozzáférési pont

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 313 78 544 -40 318 48 615 -50 311 30 516 -60 261 79 475 -70 350 44 1232 -80 299.7 36 635

5.16 táblázat: 3 csomópont + hozzáférési pont mérés eredménye

Késleltetés 3 csomóponttal hozzáférési ponton keresztül

400 350.5 318.4 350 313.3 311.6 299.7 300 261.9 250

200 [msec]

150 Idő 100 50 0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm]

5.17 ábra Késleltetés 3 csomópont +AP 5.2.3. Csomagkésleltetés4 csomópont esetén

5.18ábra: 4 csomópont + hozzáférési pont

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 336.6 80 595 -40 552.6 139 1173 -50 753 45 1535 -60 584 184 1103 -70 739 179 1154 -80 1061.6 394 3015

5.19táblázat: 4 csomópont + hozzáférési pont mérés eredménye

Késleltetés 4 csomóponttal hozzáférési ponton keresztül 1200 1061.6

1000

753 739.4 800 552.6 584.3

600

[msec] ő

Id 336.6 400

200

0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm] 5.20 ábra: Késleltetés 4 csomópont + AP

5.3. Csomagkésleltetés ad-hoc hálózatban

Az 5.2 fejezetben megvalósított tesztekben a készülékek hozzáférési ponton kommunikáltak. A következő tesztekben a hálózat annyiban különbözik, hogy a készülékek nem hozzáférési ponton keresztül hanem közvetlenül egymással kommunikálnak.

5.3.1. Csomagkésleltetés mérése 2 csomóponttal

Mivel alkalmazásom kommunikációja socketek segítségével van megvalósítva, a szoftver ad-hoc típusú hálózatokban is módosítás nélkül megfelelően működik. A teszt az 5.2.1fejezetben tárgyaltak alapján volt megvalósítva.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.21ábra : 2 csomópontú ad-hoc hálózat

Az 5.22 táblázat szemlélteti a mérés eredményeit.

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 6.1 3 10 -40 14.8 6 27 -50 20.2 5 33 -60 23.6 10 45 -70 37.7 18 83 -80 45.1 20 73

5.22táblázat: 2 csomópontú ad-hoc hálózat mérés eredménye

Késleltetés 2 csomóponton keresztül 50 45.1 45 37.7 40 35 30 23.6

25 20.2 [msec] 20 14.8 Idő 15 10 6.1 5 0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm]

5.23ábra: Késleltetés 2 csomóponton keresztül

A mérés során csomagvesztést nem tapasztaltam, a telefonok közvetlenül ráláttak egymásra. A teszt elvégzése során arra a következtetésre jutottam, hogy -60 dBm-től kezdve meredeken kezd nőni az késleltetés.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.3.2. Csomagkésleltetésmérése 3 csomóponttal

Az előző tesztben az ad-hoc hálózat viselkedését vizsgáltam 2 csomópont esetén. Továbbiakban vizsgálom a hálózatot 3, illetve 4 csomópontra. Linux operációs rendszerben lehetőség van routerként üzemeltetni egy számítógépet (pl. Linux laptopokat WiFi interfésszel). Nexus S készülékeken nem minősült megfelelőnek ez a megoldás, ezért szükséges volt egy alkalmazás készítése, amely értelmezi a fogadott üzeneteket és továbbítja a megfelelő címzetthez. Ez a tesztis az általam készített alkalmazással készült,az 5.2.2 fejezetben tárgyaltak alapján van megvalósítva. A kiépített hálózatot a5.24 ábra szemlélteti.

5.24ábra : 3 csomópontú ad-hoc hálózat

Az 5.25táblázatban látható a mérés eredményei

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 16 7 33 -40 23.9 8 53 -50 165.9 81 247 -60 184.8 85 341 -70 185.2 157 268 -80 181.4 157 227

5.25táblázat: 3 csomópontú ad-hoc hálózat mérés eredménye

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Késleltetés 3 csomóponton keresztül 100 92.4 92.6 90.7 90 82.95 80 70 60

50 [msec]

ő ő 40 Id 30 11.95 20 8 10 0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm]

5.26ábra :Késleltetés 3 csomóponton keresztül

5.3.3. Csomagkésleltetésmérése 4 csomóponttal

Ez a teszt mérésének módszere hasonlóképen történt az 5.2.2 fejezetben leírtakhoz. A kiépített hálózatot a5.27 ábra szemlélteti.

5.27ábra : 4 csomópontú ad-hoc hálózat

Jelerősség Átlag késleltetés Min Max [dBm] [msec] [msec] [msec] -10 27.3 15 44 -40 81.1 12 146 -50 197.8 135 301 -60 201.1 156 292 -70 192.7 170 263 -80 201.9 171 268

5.28táblázat: 4 csomópontú ad-hoc hálózat mérés eredménye

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Késleltetés 4 csomopónton keresztül 120 100.55 100.95 98.9 96.35 100

60 [msec] 40.55 Idő 40 13.65 20

0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm]

5.29ábra: Késleltetés 4 csomóponton keresztül

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.4. Mérések összesítése

Késleltetés ad-hoc módban 250 197.8 201.1 192.7 201.9 184.8 185.2 200 169.9 181.4

150

[msec] 81.1

100 Idő

27.3 45.1 23.9 37.7 50 16 20.2 23.6 6.1 14.8 0 -10 -40 -50 -60 -70 -80 Jelerősség [dBm]

2 Csomópont 3 Csomópont 4 Csomópont

5.30 ábra: Késleltetési értékek összesítése ad hoc módú kommunikáció esetén

Az 5.30 ábra összesíti a 2, 3 illetve 4 csomópontú ad-hoc hálózatban fellépő adatok késését. A diagramon látható, hogy 2 csomópont esetén a jelerősség függvényében az adatok késése szinte lineárisan nő. A 3 és 4 csomópontú hálózatok esetében -40dBm és -50dBm között figyelhetünk meg nagy váltózást, nagyságrendekkel megnő az üzenetek késleltetése. Majd -50dBm után már nem észlelhető nagy ingadozás.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Késleltetés infrastruktúra módban 1200 1061.6

1000

800 753 739.4

584.3

600 552.6

[msec] Idő

400 336.6 350.5 313.3 318.4 311.6 299.7 261.9

200 89.4 102 61.6 66.8 64.7 75.9

0 -10 -40 -50 -60 -70 -80

2 Csomópont 3 CsomópontJelerősség [dBm]4 Csomópont

5.31ábra: Késleltetési értékek összesítése infrastruktúra módú kommunikáció esetén

Az 5.30 ábra összesíti a 2, 3 illetve 4 csomópontú infrastruktúra hálózatban fellépő adatok késését. A diagramon látható, hogy 2 csomópont esetén -50dBm jelerőségig nem észlelhető ingadozás, utána kezd emelkedni. 3 csomópont esetén nem tapasztaltam jelentős változást a jelerősség függvényében. 4 csomópont esetén -40dBm jelerősségtől már jelentősen nő az adatok késleltetésének ideje. -80 dBm jelerősségnél már 1 másodperc a késleltetés.

A mérések során arra a következtetésre jutottam, hogy az ad-hoc hálózat késleltetés szempontjából jobbnak minősül, mint az infrastruktúra mód. Jó jelerősségnél ad-hoc módban nagyon kicsi a késleltetés 2, 3 illetve 4 csomópont esetén is. Összehasonlítva az infrastruktúra móddal sokkal kisebb a késleltetés bármilyen jelerősségnél. Ennek az az oka, hogy ad hoc módban csak a minimális utat kell bejárja a csomag, míg infrastruktúra módban minden esetben le és fell kell küldeni a köztes csomópont és az AP között (lásd pl. az 5.18 ábrát). Amennyiben csak az a cél, hogy a két végpont közti kommunikációt hasonlítsuk össze, anélkül, hogy figyelembe vegyük a köztes lépéseket, akkor az infrastruktúra mód mindig a 2 csomópontos esetet fogja megvalósítani, az eredmények ugyanazok lesznek, mint azt az 5.13. és 5.14 ábrákon bemutattam. Természetesen ebben az esetben le kell mondani az ad hoc

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

módban elérhető rugalmasságról. Fontos megjegyezni, hogy ebben az esetben a nagyságrenddel rosszabb késleltetési átlag értéket a maximális késleltetést szenvedő csomagok okozzák, míg a minimális késleltetési érték jobb, mint például a 4 csomópontos ad hoc kommunikációnak. Ennek az az oka, hogy a mobil csomópontok közel lévén egymáshoz zavarják a kommunikációt, a csatornán bitvesztést okoznak és alsó rétegekben újra kell azokat küldeni.

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

6. ÖSSZEFOGLALÓ

6.1. Következtetések

Dolgozatom célja volt ad-hoc hálózatot implementálni Android platformon annak ellenére, hogy egyik hivatalos Android operációs rendszer sem támogatja ezt a funkciót.

A projekt elején a kitűzött feladatokat elvégeztem, a 3.2 alfejezetekben megfogalmazott elvárásokat teljesítettem.

 Kiválasztottam egy olyan eszközt, amelyen lehetséges az ad hoc módú WiFi kapcsolat kialakítása  Megfelelően konfiguráltam a kiválasztott eszközt  Megvalósítottam az ad-hoc kapcsolatok felett hálózati rétegbeli kommunikációt  Saját alkalmazással megvalósítottam az eszközök közötti adattovábbítást  Teszteltem a kiépített ad-hoc hálózat teljesítményét, a megvalósított szoftvermodul képes a WiFi infrastruktúra módban mért értékekhez nagyságrendben hasonlítható (vagy jobb) paramétereket elérni  A diplomamunkám elkészítése során elért egyes eredményeket a konzulensemmel és kollégáival közösen írt cikkben publikáltam [1] 

6.2. Tovább fejlesztési lehetőségek

Az Android alkalmazás továbbfejlesztési lehetősége alatt értem egy útvonalválasztó protokoll implementálását. Ez nagy segítséget nyújtana ha több csomópont van a hálózatban.Mivel mobilis eszközökről van szó a topológia állandó változásban lehet, ezért könnyen megeshet, hogy egy csomópontot csak egy másik csomóponton keresztül érünk el. Ezzel a megoldással könnyen kiterjeszthetjük a hálózatunk hatósugarát.

Megoldható lenne ad-hoc kapcsolatok felett hangot továbbítani, ezzel egy Voice over IP , Internet Protokoll feletti hangátvitelt megvalósítani az eszközök között. Továbbá megvalósítható lenne még az egyik készülék kamerájának video anyagát valós időben küldeni egy másik készülékre. Ez alkalmazható lenne távirányítós kisautók vagy esetleg drónok vezérlésénél

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

Irodalmjegyzék

[1] „ZS. Zalatnay, Cs. Simon, M. Malios, B. Terza "Managing streaming services in a distribuited testbed" The 5th International Conference on Recent Achievements in Mechatronics, Automation, Computer Science and Robotics, MACRO 2015, Targu Mures, Romania 2015”.

[2] C. Janssen, „What is a Smartphone? - Definition from Techopedia,” [Online]. http://www.techopedia.com/definition/2977/smartphone.

[3] „Open Handset Alliance szervezet honlapja,” [Online]. http://www.openhandsetalliance.com/android_overview.html. [Hozzáférés dátuma: 23 június 2015].

[4] F. M. F. B. K. I. Ekler Péter, "Android-alapú szoftverfejlesztés", Budapest: Szak, 2012.

[5] „EazyTutz Android programozói blog,” [Online]. http://www.eazytutz.com/android/android-architecture/. [Hozzáférés dátuma: 24 június 2015].

[6] „Dalvik bytecode | Android Open Source Project,” [Online]. https://source.android.com/devices/tech/dalvik/dalvik-bytecode.html#design. [Hozzáférés dátuma: 24 június 2015].

[7] „Activities | Android Developers,” [Online]. http://developer.android.com/guide/components/activities.html. [Hozzáférés dátuma: 1 5 2015].

[8] „Activity | Android Developers,” [Online]. http://developer.android.com/reference/android/app/Activity.html.

[9] „Vezetéknélküli hálózatok biztonsági kérdései | Tudományos dolgozat,” [Online]. https://dea.lib.unideb.hu/dea/bitstream/handle/2437/3133/Szakdolgozat.pdf?sequence=1 . [Hozzáférés dátuma: 2015].

[10] K. W. R. James F. Kurose, "Számítógéphálózatok működése", Budapest: Panem Könyvkiadó Kft., 2009.

[11] A. S. Tanenbaum, "Számítógéphálózatok", 2004 szerk., Budapest: Panem Könyvkiadó, 2004.

[12] „TeamWin - TWRP fejlesztői honlapja,” [Online]. https://twrp.me/. [Hozzáférés dátuma: 10 április 2015].

[13] „Nexus Root Toolkit v2.0.5 | WugFresh,” [Online]. http://www.wugfresh.com/nrt/. [Hozzáférés dátuma: 12 május 2015].

[14] „CyanogenMod | Android Community Operating System Hivatalos honlapja,” [Online].

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

http://www.cyanogenmod.org/. [Hozzáférés dátuma: 4 augusztus 2014].

[15] „WPA supplicant fejlesztői honlapja,” [Online]. http://linux.die.net/man/8/wpa_supplicant.

[16] „Wifi Analyzer – Android-alkalmazások a Google Playen,” Farproc, [Online]. https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer&hl=hu.

[17] „Wifi Analyzer,” Farproc, [Online]. https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer.

[18] „Tecmint-Linux Howto's Guide,” [Online]. http://www.tecmint.com/setup-linux-as- router/.

[19] „The Eclipse Foundation open source community website,” [Online]. https://eclipse.org/.

[20] „Android Developers-WifiManager,” [Online]. http://developer.android.com/reference/android/net/wifi/WifiManager.html.

[21] „Iperf - The TCP/UDP Bandwidth Measurement Tool,” [Online]. https://iperf.fr/. [Hozzáférés dátuma: 2 június 2015].

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

7. Ábrajegyzék

2.1 ábra: Az Android platform szerkezete [5] ...... 16 2.2 ábra: Activity-életciklusmodell [8] ...... 18 2.3 ábra : Infrastrukturális mód ...... 19 2.4 ábra: Direkt kapcsolat ...... 20 2.5 ábra: 3 csomópontú ad-hoc hálózat ...... 24 3.1 ábra: Nexus Root Toolkit alkalmazás [13] ...... 27 3.2 ábra: A készülék fastboot menüje ...... 28 3.3 ábra: A készülék recovery menüje ...... 29 3.4 ábra: Ad-hoc hálózat létrehozása ...... 31 3.5 ábra: Jelerősség grafikus ábrázolása [17] ...... 32 3.6 ábra: A létrejött IBSS hálózat ...... 33 3.7 ábra: Csatlakozás a létrejött IBSS hálózathoz ...... 33 3.8 ábra: A szoftver osztálydiagramja ...... 35 3.9 ábra: A szoftver teszt funkciójának szekvencia diagramja ...... 38 3.10 ábra: A szoftver állapotdiagramja ...... 39 4.1 ábra: USB-háttértár ...... 40 4.2 ábra: Ad-Hoc.apk telepítése ...... 41 4.3 ábra: Ad-Hoc alkalmazás ...... 42 4.4 ábra: A hálózatban levő csomópontok ...... 42 4.5 ábra: A célba ért üzenet ...... 43 5.1 ábra: Két csomópontos teszteset ...... 44 5.2 táblázat: Ad-hoc hálózat sávszélesség mérésének mérési eredménye ...... 45 5.3 ábra: Ad-hoc hálózat sávszélessége ...... 45 5.4 táblázat: Jel erőssége a távolság függvényében mérés eredménye ...... 46 5.5 ábra: Jel erőssége a távolság függvényében ...... 46 5.6 táblázat: Ad-hoc hálózat jitter és adatvesztés mérés eredménye sávszélesség függvényében ...... 47 5.7 ábra: Ad-hoc hálózat Jitter ...... 47 5.8 táblázat: Ad-hoc hálózat jitter és adatvesztés mérés eredménye csomagok nagysága függvényében ...... 48 5.9 ábra: Jitter változása a csomagok nagysága és a jelerősség függvényében ...... 49 5.10 ábra: Jitter változása 20dBm-től 60dBm-ig ...... 49 5.11 ábra: Őszes és elveszett datagrammok ...... 50 5.12 ábra: 2 csomópont + hozzáférési pont ...... 51 5.13 táblázat: 2 csomópont + hozzáférési pont mérés eredménye ...... 51 5.14 ábra: Késleltetés 2 csomópont +AP ...... 52 5.15 ábra: 3 csomópont + hozzáférési pont ...... 52 5.16 táblázat: 3 csomópont + hozzáférési pont mérés eredménye ...... 53 5.17 ábra Késleltetés 3 csomópont +AP ...... 53 5.18 ábra: 4 csomópont + hozzáférési pont ...... 53 5.19 táblázat: 4 csomópont + hozzáférési pont mérés eredménye ...... 54

Universitatea Transilvania din Braşov Tehnologii şi Sisteme de Telecomunicaţii Facultatea de Inginerie Electrică şi Ştiinţa Calculatoarelor 2015

5.20 ábra: Késleltetés 4 csomópont + AP ...... 54 5.21 ábra : 2 csomópontú ad-hoc hálózat ...... 55 5.22 táblázat: 2 csomópontú ad-hoc hálózat mérés eredménye ...... 55 5.23 ábra: Késleltetés 2 csomóponton keresztül ...... 55 5.24 ábra : 3 csomópontú ad-hoc hálózat ...... 56 5.25 táblázat: 3 csomópontú ad-hoc hálózat mérés eredménye ...... 56 5.26 ábra : Késleltetés 3 csomóponton keresztül ...... 57 5.27 ábra : 4 csomópontú ad-hoc hálózat ...... 57 5.28 táblázat: 4 csomópontú ad-hoc hálózat mérés eredménye ...... 57 5.29 ábra: Késleltetés 4 csomóponton keresztül ...... 58 5.30 ábra: Késleltetési értékek összesítése ad hoc módú kommunikáció esetén ...... 59 5.31 ábra: Késleltetési értékek összesítése infrastruktúra módú kommunikáció esetén...... 60