Development of a Mobile Application for Real-Time Cognitive Wireless Network Planning

Transcriptie

1 Development of a Mobile Application for Real-Time Cognitive Wireless Network Planning Roel Mangelschots Supervisors: Prof. dr. ir. Wout Joseph, Prof. dr. ir. Luc Martens Counsellors: Dr. ir. David Plets, Dr. ir. Toon De Pessemier, Kris Vanhecke Master's dissertation submitted in order to obtain the academic degree of Master of Science in de ingenieurswetenschappen: computerwetenschappen Department of Information Technology Chairman: Prof. dr. ir. Daniël De Zutter Faculty of Engineering and Architecture Academic year

2

3 Development of a Mobile Application for Real-Time Cognitive Wireless Network Planning Roel Mangelschots Supervisors: Prof. dr. ir. Wout Joseph, Prof. dr. ir. Luc Martens Counsellors: Dr. ir. David Plets, Dr. ir. Toon De Pessemier, Kris Vanhecke Master's dissertation submitted in order to obtain the academic degree of Master of Science in de ingenieurswetenschappen: computerwetenschappen Department of Information Technology Chairman: Prof. dr. ir. Daniël De Zutter Faculty of Engineering and Architecture Academic year

4 Word of Thanks First of all, I would like to thank David Plets, Kris Vanhecke and Quentin Braet for their support and supervision of this research. They gave me the freedom to find my own course, and their extensive knowledge about the subject made it possible for me to get insight to the network planning technologies. The continuous advice they offered me made it possible to keep thinking with the right objective in mind, and certainly helped the progression of this dissertation. Secondly, I very much like to thank the WiCa research group for the feedback and giving me the opportunity to do a PhD in their department in the coming years. Finally, I thank everyone around me that has supported my academic trajectory. A special thanks is in order for my parents and sister, for their ongoing support, and allowing me to make measurements in their homes for this research. Roel Mangelschots, May 2014 Roel Mangelschots, May 2014 i

5 Usage Permission The author gives permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation. Roel Mangelschots, May 2014 ii

6 Development of a Mobile Application for Real-Time Cognitive Wireless Network Planning by Roel Mangelschots Dissertation submitted for obtaining the degree of Master of Science in Computer Science Engineering Academic year Ghent University Faculty of Engineering and Architecture Department Wireless & Cable Head of the Department: prof. dr. ir. Luc Martens Supervisors: prof. dr. ir. Wout Joseph, prof. dr. ir. Luc Martens Associate supervisors: dr. ir. David Plets, dr. ir. Toon De Pessemier, Kris Vanhecke, Quentin Braet Summary In this article, a mobile application is presented which lets users plan wireless networks using various path loss models and can improve the results returned by these models by performing measurements with the device. To evaluate to what extent one can improve the path loss results and how many measurements are required to efficiently improve them, tests have been performed. Very promising results were obtained for the three different monitored environments when fitting the model results by a single shift and fitting the models themselves by fitting multiple variables. Samenvatting Dit artikel behandelt een mobiele applicatie die gebruikers in staat stelt om draadloze netwerken te plannen, gebruikmakend van verschillende padverliesmodellen waarvan de resultaten verbeterd kunnen worden door metingen te doen met het mobiele toestel. Om te bepalen tot in hoeverre deze padverlies resultaten kunnen verbeteren en hoeveel metingen nodig zijn om deze efficient te verbeteren, zijn verschillende tests uitgevoerd. Veelbelovende resultaten werden behaald voor de drie testomgevingen wanneer de modelresultaten gefit worden met een shift alsook wanneer de modellen zelf gefit werden door meerdere variabelen aan te passen. Keywords: mobile application, path loss, network planning Trefwoorden: mobiele applicatie, padverlies, netwerkplanning iii

7 Development of a Mobile Application for Real-Time Cognitive Wireless Network Planning Roel Mangelschots Supervisor(s): Prof. dr. ir. Wout Joseph, Prof. dr. ir. Luc Martens Abstract In this article, a mobile application is presented which lets users plan wireless networks using various path loss models and can improve the results returned by these models by performing measurements with the device. To evaluate to what extent one can improve the path loss results and how many measurements are required to efficiently improve them, tests have been performed. Very promising results were obtained for the three different monitored environments when fitting the model results by a single shift and fitting the models themselves by fitting multiple variables. Keywords mobile application, path loss, network planning I. INTRODUCTION AS we advance further in the digital era, more and more electronics become mobile. These mobile devices often need a way to communicate with other devices. Due to an immense amount of types of mobile applications, wireless connections are everywhere in our daily lives. Wireless networks often require a stable connection for continuous transmission, a certain throughput to support larger amounts of traffic and maximum delay for fast responsiveness. Trying to satisfy these constraints in an environment, often leads to a sub-optimal usage of available network resources (e.g. capacity). In this study, a mobile application serving as a portable network planning tool is developed. It strives to return the best possible results on a floor plan of an environment using several types of algorithms and real-time measurements by the device. The main goal was to determine to what extent it is possible to improve existing network planning algorithms using measurements performed on a mobile device. This optimized network planning will be performed on the mobile device itself, therefore an Android app is developed in which floor plans can be drawn, on which a network planning model is performed. These models will be improved by the application using the device s measurements. This app can be of use for firms or private individuals that install wireless networks. A. WHIPP Tool II. SYSTEM DESCRIPTION The WiCa (Wireless & Cable) research group of Ghent university developed the WHIPP (WiCa Heuristic Indoor Propagation Prediction) tool to calculate path loss, optimize exposure and to predict and optimize coverage of indoor wireless networks. This tool is however not fit for mobile devices. It makes use of a web service (described in WSDL 1 ) which was developed by WiCa and applies five different path loss models to floor plans. 1 The first is the free-space model [1] which makes use of the Friis transmission equation [2] and assumes there are no obstacles in the direct path from transmitter to receiver. The second model is the TGn IEEE indoor model [3] and consists of two formulas. One for distances smaller than and one for distances greater than a certain break-point distance. The one-slope model [1] is an extension on the free-space model and can adjusted to account for obstacles in the environment. The multiwall model [1] extends this one-slope model and includes the penetration loss of the traversed types of walls. The last model is the SIDP (simple indoor dominant path) model [4] which not only considers the direct ray, but also many other possible signal paths leading to the receiver. B. Typical User Scenario A typical user scenario for the application is as follows. First the user draws a floor plan. Then, parameters like the path loss model to use and the receiver specifications are set. Subsequently, the desired prediction tool is selected (e.g. coverage prediction, optimal access point placement, etc.). As a fourth step, the results which can be graphically displayed are checked. As a last step, the user can attempt to improve the results by performing signal strength measurements with the mobile device as the web service results are adjusted to those measurements. C. General Design The Android platform provides a range of build-in design patterns making apps behave in a consistent, predictable fashion [5]. These patterns are applied as it was deemed necessary and appropriate. As major design pattern of the application, MVC (model-view-controller [6]) was chosen. Models contain what to render, views determine how to render and the controllers react on user input or events. In Android, the Activity instances deliver both view and controller functionality and are thus implemented for both purposes. The components of which the application exists are POJOs (which contain actual data), models (performing actions on the POJOs) and the views and controllers (taking care of the communication with the user). D. Libraries Two external libraries are used. This first one is afiledialog, which is an Android library for browsing files. File browsing is a must when the user should be able to manage (load and save) data of the application, like floor plans and results. The second library is a SOAP parser, specifically designed for Android, called ksoap2-android. It is lightweight, efficient and is used to communicate with the WiCa web service.

8 III. APPLICATION DESIGN When designing the application, issues and trade-off considerations appeared. Some are specific for the mobile application and others are in common with the WHIPP tool. A. Requirement differences compared to WHIPP Tool A first consideration which does not appear for the WHIPP tool is the way the user can draw a floor plan. This includes zooming, dragging and the actual drawing of the floor plan. For zooming and dragging, two fingers are used, and in the case of single-touch devices, buttons and scroll bars are provided. Drawing is performed by using only one finger. As long as the user has his finger on the screen, the object is not yet placed, but a preview at a small distance left above the finger is shown so it is clear where the object will be placed once the finger is lifted. Horizontal and vertical scrolling (or dragging) at the same time is not supported by default in Android. This required a custom view implementation. As there is no graphical interface foreseen in the Android SDK for file browsing purposes, the external library afiledialog was used. As the application is required to use and produce floor plan files with the same structure that is used in other WiCa software, the data structures represented in the files are not the same as the self-created ones. Therefore it is not possible to have easily automated conversions from and to the desired XML structure. For conversion, separate methods are implemented for each file type. Performance issues appeared when the GUI (graphical user interface) was developed. The cause was a very hierarchic structure of the layout. This was detected by the Android Hierarchy Viewer. The problem was solved by flattening the hierarchy and making the views more independent of scaling updates. A minimal supported Android version had to be set. To support as many devices as possible, Android API level 8 was picked. B. Similar requirements to WHIPP Tool There is a need for the walls (and windows and doors) to connect precisely in order for the web service to detect the distinct rooms. We do not want to burden the user with exact drawing, thus a complex system was engineered to simplify the drawing of usable floor plans. In a drawing application, functionality to undo and redo actions is indispensable. The choice was made to save the complete floor plan states in an undo and redo stack. In software with a GUI, issues with multithreading ofter arise. In Android, the UI thread is the main thread. Different threads need to be used for CPU intensive operations since a nonresponsive GUI needs to be avoided. ASyncTask objects were chosen to be used as they are specifically developed to solve these kind of issues. Depending on how large the floor plan is, many location specific results can be returned by the algorithms of the web service. When drawing them separately, high CPU usage and lag was observed. The solution was to store the results as a bitmap where one pixel for each ten square centimeter is provided. When drawing the results, a scaled up version of this bitmap is used. IV. TESTING For testing the network planning model improvement possibilities for Android devices, signal strength measurements were taken in three different indoor environments. The same measuring procedure was used for each measurement. First, The location on the floor plan where the measurement takes place is selected on the device. Then, the amount of measurement samples to be take is set to five. The device is held at the same location and height during the measurements. Subsequently, the average result at each location is stored. Finally, the results are saved in XML (Extensible Markup Language) format, to be parsed and processed by Excel for statistics. The first environment is a detached residential house in Turnhout. The second is an old townhouse in Bruges. The third and last is the third floor of Complex Zuiderpoort in Ghent. An example of a drawn floor plan in the application is shown in Figure 1 for Turnhout. The black dots are the locations where measurements were done. At the first two environments, the complete floor was used for measurements, and at the third environment, the hallway and toilets were used. Fig. 1. Monitored floor plan of the house in Turnhout A. Result Improvement Based on Fitted Shift Firstly, the maximum improvement of the results returned each algorithm in each test environment is investigated. We define improvement as decrease in MSE (mean squared error) [7]. The maximum improvement is defined as the MSE when shifting is done based on all measurements. The shift is equal to the average deviation. The error reductions (or result improvements) of the four used path loss models for each environment are shown in Table I. Except for two results (Ghent TGn and Ghent multiwall) very large improvements can be achieved. Ghent TGn already has accurate results without the shift and Ghent multiwall should not be used for this type of floor plan as it performs badly at specific locations unreachable by direct ray. Next, we test how many locations should be measured to efficiently improve results. Random generated subsets of the total set of measurements are used. The accumulated improvements for different subset sizes, which are the MSE decrease percentages towards the above obtained minimal MSE, are set out in Table II. If the two previously described situations (Ghent TGn

9 TABLE I THE OBTAINED ERROR REDUCTIONS (ER) FOR TURNHOUT (T), BRUGES (B) AND GHENT (G). sidp tgn free-space multiwall ER T (%) ER B (%) ER G (%) TABLE II THE ACCUMULATED IMPROVEMENTS OBTAINED FOR TURNHOUT (T), BRUGES (B) AND GHENT (G) FOR DIFFERENT AMOUNTS OF MEASUREMENTS. amount of measurements T SIDP (%) T TGn (%) T Free-space (%) T Multiwall (%) B SIDP (%) B TGn (%) B Free-space (%) B Multiwall (%) G SIDP (%) G TGn (%) G Free-space (%) G Multiwall (%) and Ghent multiwall) can be detected, three measurements produce an average accumulated improvement of percent for the other situations. When five measurement were done, even in the two less performing cases an improvement is achieved. Instead of adding random measurements to the subsets, the subsets will consist of measurements done in separate rooms. In Ghent, the hallway spans 90 percent of the area, so it is excluded from this test. When comparing these two methods, no pattern was found. Therefore, we can assume random measurements (but fairly spread) are as good as measuring in different rooms. B. Result Improvement Based on Multiple Parameters We also can adjust multiple variables of the path loss models to try and decrease the MSE even more. Table III contains the resulting MSE, taking into account all measurements. When comparing MSE results, we notice the free-space model is only improving slightly. This means there is not a lot of difference in using average error to shift compared to minimizing the MSE. By adding the slope as variable in the One-slope model, a big improvement is obtained. An even bigger improvement is achieved by the multiwall model as the MSE values often more than halve compared to the two other models. It also has a large improvement when comparing to the shifted multiwall model with default values. TABLE III MSE OF RESULTS WITH FITTED VARIABLES FOR TURNHOUT (T), BRUGES (B) AND GHENT (G) Free-space One-slope Multiwall T shift T multivar B shift B multivar G shift G multivar A. Conclusion V. CONCLUSION AND FUTURE WORK In this dissertation, a mobile Android application for real-time cognitive wireless network planning is developed to study the possible impact of the usage of a mobile device to improve path loss models. To enable future improvement and expansion of this application, attention was given to modifiability and usability. Possible result improvements of up to 94 percent with an average of 70 percent were observed when shifting model results based on average deviation of measurements. The impact of the amount of measurements on the improvement of the results was investigated. When omitting two cases, the average improvement is percent at three measurements. If such situations can be detected, three measurements are sufficient to significantly improve path loss model results. If not, five measurements or more can be required for boost model results. No significant increase or decrease in model performance was observed when adding measurements room per room. When fitting multiple variables of models, a significant positive impact was observed. This gives an incentive for further research. VI. FUTURE WORK It can be interesting to study the performance relations between network planning models. For instance, in case a certain algorithm performs badly or well in a given situation, other algorithms can be advised or avoided. The floor plan can also be analyzed to detect which path loss models will perform. A further study is required to find the relations between floor plan properties and model performance. This way, advise can be given even before a model is applied. As shown in this article, model result fitting for multiple variables can give big opportunities. To determine if multivariable fitting is also viable for a small amount of measurements, further research needs to be done. This type of fitting is a more complex optimization problem that needs an advanced algorithm (like GRG2 in Excel) for solving. Data of the resulting fit, like model parameters, model result accuracy, access point product details and mobile device, can be stored locally or sent to the web service to improve future model predictions. and to gain useful statistics. If this functionality would be implemented, useful statistics could be gained

10 and other possible future work can be dis- covered. REFERENCES [1] Saunders SR., Antennas and Propagation for Wireless Communication Systems, John Wiley & Sons Ltd, [2] Harald Trap Friis, Friis transmission equation, wikipedia.org/wiki/friis_transmission_equation, 2014, [Online; accessed 24-May-2014]. [3] Vinko Erceg, Laurent Schumacher, et al., Ieee p wireless lans. tgn channel models, doc.: IEEE /940r4, [4] David Plets et al., Coverage prediction and optimization algorithms for indoor environments, EURASIP Journal on Wireless Communications and Networking, vol. 2012, no. 123, [5] Open Handset Alliance, Android design patterns, developer.android.com/design/patterns/index.html, 2014, [Online; accessed 24-May-2014]. [6] Robert Eckstein, Java se application design with mvc, index html, 2007, [Online; accessed 24-May-2014]. [7] Mean squared error, squared_error, [Online; accessed 24-May-2014].

11 Ontwikkeling van een Mobiele Applicatie voor Real-Time Cognitieve Draadloze Netwerkplanning Roel Mangelschots Supervisor(s): Prof. dr. ir. Wout Joseph, Prof. dr. ir. Luc Martens Abstract Dit artikel behandelt een mobiele applicatie die gebruikers in staat stelt om draadloze netwerken te plannen, gebruikmakend van verschillende padverliesmodellen waarvan de resultaten verbeterd kunnen worden door metingen te doen met het mobiele toestel. Om te bepalen tot in hoeverre deze padverlies resultaten kunnen verbeteren en hoeveel metingen nodig zijn om deze efficient te verbeteren, zijn verschillende tests uitgevoerd. Veelbelovende resultaten werden behaald voor de drie testomgevingen wanneer de modelresultaten gefit worden met een shift alsook wanneer de modellen zelf gefit werden door meerdere variabelen aan te passen. Trefwoorden mobiele applicatie, padverlies, netwerkplanning I. INTRODUCTIE ELEKTRONISCHE apparaten worden steeds meer mobiel. Deze mobiele toestellen hebben vaak een manier nodig om met de buitenwereld te communiceren. Door een immens aantal verschillende types van mobiele toepassingen, verschijnen draadloze verbindingen overal in ons dagelijks leven. Draadloze netwerken vereisen vaak een stabiele verbinding voor continue transmissie, een bepaalde doorvoersnelheid om grotere hoeveelheden verkeer te ondersteunen en een maximale vertraging voor snelle reacties. Wanneer men tracht te beantwoorden aan deze vereisten, resulteert dit vaak in een suboptimaal gebruik van netwerk resources (bv. capaciteit). In deze studie wordt een mobiele applicatie, die dient als draagbare netwerk planning tool, ontwikkeld. Het tracht de best mogelijke resultaten weer te geven op een grondplan gebruikmakend van verschillende types algoritmen en real-time metingen van het toestel. De voornaamste doelstelling is om te bepalen tot in hoeverre het mogelijk is om bestaande netwerkplanning modellen te verbeteren door gebruik te maken van werkelijke metingen. Dit optimaliserend proces zal uitgevoerd worden op het toestel zelf. Hiervoor is een Android app ontwikkeld waarin een grondplan getekend kan worden waarop een netwerkplanning model toegepast wordt. Deze modellen zullen verbeterd worden door de resultaten die teruggegeven worden door de modellen aan te passen aan de metingen. Deze applicatie kan interessant zijn voor bedrijven en particulieren die draadloze netwerken installeren. A. WHIPP Tool II. SYSTEM BESCHRIJVING De WiCa (Wireless & Cable) onderzoeksgroep van iminds UGent heeft de WHIPP (WiCa Heuristic Indoor Propagation Prediction) tool gemaakt op pathloss the berekenen, blootstelling te optimaliseren en om de coverage van indoor draadloze netwerken te optimaliseren. Deze tool is echter niet geschikt voor mobiele toestellen. Het maakt gebruik van een web service (beschreven in WSDL 1 ) die ook ontwikkeld is door WiCa en past vijf verschillende netwerkplanning modellen toe op grondplannen. Het eerste model is het free-space model [1] welke gebruik maakt van de Friis transmission equation [2] en er vanuit gaat dat er geen obstakels zijn in het directe pad van zender naar ontvanger. Het tweede model is het TGn IEEE indoor model [3] en bestaat uit twee formules. De eerste voor afstanden kleiner dan een zekere break-point afstand en de tweede voor grotere afstanden dan deze. Het one-slope model [1] is een uitbreiding van het free-space model en kan aangepast worden om rekening te houden met mogelijke obstakels in de omgeving. Het multiwall model [1] breidt dan weer het one-slope model uit. Het maakt gebruik van het penetratieverlies van de muren welke doorkruist worden door het direct signaal. Het laaste model is het SIDP (simple indoor dominant path) model [4]. Deze betrekt niet enkel het directe pad, maar overweegt ook vele andere mogelijke signaal paden die naar de ontvanger leiden. B. Typisch gebruikersscenario Een typische gebruikersscenario gaat als volgt. Eerst tekent de gebruiker een grondplan in de applicatie. Vervolgens worden parameters ingesteld zoals het te gebruiken padverlies model. Daarna wordt de gewenste prediction tool geselecteerd (bv. pathloss berekenen, berekenen coverage, etc.). Als vierde stap kan de gebruiker de verschillende resultaten grafisch weergeven. In de laatste stap kan de gebruiker de geretourneerde resultaten proberen te verbeteren door signaalsterktes te meten met het mobiele toestel waarbij de resultaten zich automatisch aanpassen. C. Algemeen Design Het Android platform voorziet een reeks van ingebouwde design patterns [5] zodat apps zich gedragen op een consistente, voorspelbare manier. Deze patterns zijn toegepast waar het nodig leek. Als voornaamste design pattern van de applicatie is MVC (model-view-controller [6]) gekozen. Modellen bevatten wat er weergeven moet worden, views bepalen hoe er weergegeven moet worden en de controllers reageren op user input of gebeurtenissen. In Android zorgen de Activity instanties zowel voor view als controller functionaliteit en zijn dus geïmplementeerd voor beide doelen. De componenten waaruit de applicatie bestaat zijn POJO s (bevatten de data), modellen (doen bewerkingen op de POJO s) en de views en controllers (zorgen voor communicatie met de gebruiker). 1

12 D. Libraries Twee externe libraries zijn gebruikt. De eerste is afiledialog, een Android library om te browsen naar bestanden. De mogelijkheid om te browsen is een vereiste aangezien de gebruiker de data uit de applicatie, zoals grondplannen en resultaten, moet kunnen opslaan en inladen. De tweede library is een SOAP parser genaamd ksoap2-android, specifiek ontworpen voor Android. De library is lightweight en efficiënt. Deze zal gebruikt worden om met de WiCa web service te communiceren. III. APPLICATION ONTWERP Wanneer een applicatie werd ontworpen doken verschillende overwegingen op. Sommige zijn specifiek voor de mobiele applicatie terwijl andere gelijkaardig zijn aan deze van de WHIPP tool. A. Verschil in vereisten WHIPP Tool Een eerste overweging is de manier waarop gebruikers een grondplan moeten tekenen. Dit houdt in- en uitzoomen, verslepen en het werkelijke tekenen van het grondplan in. Voor het zoomen en verslepen worden twee vingers gebruikt, en in het geval van single-touch toestellen zijn knoppen en scrollbars voorzien. Het tekenen gebeurt met een enkele vinger. Zolang de gebruiker deze vinger op het scherm heeft staan is het object nog niet getekend, maar een preview zal afgebeeld worden links boven de vinger zodat het duidelijk is waar het object werkelijk geplaatst zal worden eens de vinger wordt opgeheven. Horizontaal en verticiaal scrollen (of slepen) tegelijkertijd is standaard niet ondersteund in Android. Bijgevolg moest er voor deze funcitonaliteit een custom view gemaakt worden. Aangezien er geen grafische interface is voorzien in de Android SDK om te browsen voor files, was de externe library afiledialog gebruikt. Aangezien de applicatie grondplan bestanden met dezelfde structuur moet kunnen gebruiken en maken, komen de datastructuren van de applicatie niet overeen met deze van de bestanden. Daarom is het niet mogelijk om gemakkelijk geautomatiseerde conversies te doen van en naar de gewenste XML structuur. Voor elk bestandstype is er een verschillende functie ontwikkeld. Performantie problemen doken op wanneer de GUI (graphical user interface) werd ontwikkeld. De oorzaak was een erg hiërarchische structuur van de layout. Dit was gedetecteerd door de Android Hierachy Viewer. Het probleem werd volledig opgelost door de hiërarchie in te krimpen en de views meer onafhankelijk te maken van schalingen. Een minimaal ondersteunde Android versie moest bepaald worden. Om zoveel mogelijk toestellen te ondersteunen is er voor Android API level 8 gekozen. B. Gelijkaardige vereisten WHIPP Tool Muren, ramen en deuren moeten correct aansluiten zodat de web service de individuele kamers kan detecteren. We willen de gebruiker niet lastigvallen om dit exact te tekenen. Hiervoor is een complex systeem ontworpen dat het tekenproces van bruikbare grondplannen simpel maakt op touchscreen. In een tekenapplicatie is er ook undo en redo functionaliteit nodig. De keuze is gemaakt om volledige grondplantoestanden op te slaan in een undo en redo stack. Bij software met een GUI duiken vaak problemen op met multithreading. In Android is de UI thread de main thread. Andere threads moeten gebruikt worden voor CPU intensieve operaties aangezien een niet-reagerende GUI vermeden dient te worden. ASyncTask objecten werden gekozen om hiervoor een oplossing te bieden aangezien deze specifiek gemaakt zijn om dergelijke problemen op te lossen. Wanneer het grondplan groot is zal de web service erg veel locatiespecifieke resultaten teruggeven. Wanneer ze apart getekend werden, deed zich een hoog CPU gebruik en lag voor. De oplossing was om de resultaten als bitmap op te slaan waarbij een enkele pixel voor elke tien vierkante centimeter voorzien wordt. Wanneer de resultaten nu getekend worden, wordt een opgeschaalde versie van deze bitmap gebruikt. IV. TESTS Om te testen tot in hoeverre het mogelijk is de resultaten van de netwerkplanning modellen te verbeteren, werden metingen gedaan in drie verschillende indoor omgevingen. Dezelfde procedure werd steeds gevolgd. Eerst wordt de locatie op het grondplan waar de meting zich plaats vindt aangeduid. Vervolgens wordt het aantal samples dat genomen moet worden ingesteld op vijf. Het toestel wordt op dezelfde plaats gehouden tijdens de metingen. Daarna wordt de gemiddelde signaalsterkte op die locatie opgeslagen. Tenslotte worden de resultaten opgeslagen in een XML formaat waarna het verwerkt wordt door Excel voor statistieken. De eerste omgeving is een alleenstaand huis in Turnhout. Het tweede is een oud rijhuis in Brugge. De derde en laatste omgeving is de derde verdieping van het Zuiderpoort Complex in Gent. Een voorbeeld van een in de applicatie getekend grondplan wordt getoond in Figure 1 voor Turnhout. De zwarte cirkels zijn de locaties waar metingen plaatsvonden. Bij de eerste twee omgevingen werd de hele verdieping gebruikt voor metingen, en bij de derde omgeving werden enkel metingen gedaan in de gang en de toiletten. Fig. 1. Grondplan met metingen van het huis in Turnhout A. Resultaatverbetering gebaseerd op fitted shift Als eerste test werd de maximale verbetering van resultaten die gegenereerd werden door de modellen onderzocht. We definiëren verbetering als vermindering van MSE (mean squared

13 TABLE I DE VERKREGEN FOUTVERMINDERINGEN (FV) VOOR TURNHOUT (T), BRUGGE (B) AND GENT (G). sidp tgn free-space multiwall FV T (%) FV B (%) FV G (%) TABLE II DE GEACCUMULEERDE VERBETERINGEN VERKREGEN VOOR TURNHOUT (T), BRUGGE (B) EN GENT (G) VOOR VERSCHILLENDE AANTALLEN METINGEN. aantal metingen T SIDP (%) T TGn (%) T Free-space (%) T Multiwall (%) B SIDP (%) B TGn (%) B Free-space (%) B Multiwall (%) G SIDP (%) G TGn (%) G Free-space (%) G Multiwall (%) error) [7]. We definiëren maximale verbetering als de MSE wanneer shifting is gedaan gebruikmakend van alle metingen. De shift is hier gelijk aan de gemiddelde afwijking. De foutverminderingen (of resultaatverbeteringen) zijn gegeven in Table I. Uitgezonderd twee resultaten (Gent TGn en Gent multiwall), zijn er erg grote verbeteringen mogelijk. Bij Gent TGn is dit te wijten aan dat het al accurate resultaten gaf zonder de shift. Gent multiwall zou voor dit type grondplan niet gebruikt mogen worden omdat het slechte resultaten geeft op specifieke plaatsen welke onbereikbaar zijn als men enkel het directe pad volgt. Vervolgens testen we hoeveel meetlocaties nodig zijn om de resultaten efficiënt te verbeteren. Random gegenereerde subsets van de totale set van metingen worden gebruikt voor statistieken. De geaccumuleerde verbeteringen voor de verschillende subset groottes, welke de MSE verminderingspercentages is met betrekking tot de in het hierboven verkregen minimale MSE, zijn uitgesteld in Table II. Indien de in de zopas omschreven situaties (Gent TGn en Gent multiwall) kunnen gedetecteerd worden, leveren drie metingen een gemiddelde geaccumuleerde verbetering van percent voor de overige gevallen. Wanneer vijf metingen gedaan werden, krijgen we zelfs in de minder presterende gevallen een verbetering. In plaats van random metingen in de subsets te steken, bekijken we nu de impact wanneer er steeds metingen van andere kamers toegevoegd worden. Aangezien in Gent de gang 90 percent van de totale meetoppervlakte overspant, zal deze omgeving niet gebruikt worden voor deze test. Wanneer deze twee methodes vergeleken werden, werd er geen patroon ont- TABLE III MSE VAN DE RESULTATEN MET GEFITTE VARIABELEN VOOR TURNHOUT (T), BRUGGE (B) AND GENT (G) Free-space One-slope Multiwall T shift T multivar B shift B multivar G shift G multivar dekt. Hierdoor kunnen we aannemen dat random metingen even goede resultaten opleveren dan metingen in aparte kamers. B. Resultaatverbetering gebaseerd op meerdere parameters We kunnen ook verschillende variabelen van de padverliesmodellen gaan aanpassen om de MSE nog meer proberen te verbeteren. De resulterende MSE s waarbij alle metingen gebruikt werden staan in Table III. We zien maar een kleine verbetering bij het free-space. Dit betekent dat er niet veel verschil is tussen een shift gebruiken gebaseerd op gemiddelde afwijking en gebaseerd op de minimalisatie van de MSE. Door de slope als variabele in het one-slope model toe te voegen is een grote verbetering verkregen. Een nog grotere verbetering is verkregen door het multiwall model aangezien de MSE waardes vaak meer dan halveren in vergelijking met de andere modellen. Ook wanneer men vergelijkt met het shifted multiwall model vinden zich grote verbeteringen plaats. V. CONCLUSIE Een mobiele Android applicatie voor real-time cognitieve wireless netwerkplanning is ontwikkeld om de impact te onderzoeken van het gebruik van een mobiel toestel om padverliesmodellen te verbeteren. Om toekomstige verbeteringen en uitbreidingen van de applicatie te ondersteunen, is er aandacht besteed aan modifiability en usability. Mogelijke resultaatverbetering tot 94 percent met een gemiddelde van 70 percent zijn vastgesteld wanneer de modelresultaten worden geshift op basis van de gemiddelde afwijking van metingen. De impact van het aantal metingen op de verbetering van de resultaten was onderzocht. Wanneer twee speciale gevallen worden weggelaten, is de gemiddelde verbetering percent voor slechts drie metingen. Indien zulke speciale gevallen gedetecteerd kunnen worden voldoen drie metingen dus om de resultaten significant te verbeteren. Indien niet, leverden vijf metingen zelfs in de slechtste gevallen een verbetering op. Geen significante stijging of daling van verbetering werd vastgesteld wanneer metingen gelijkmatig per kamer geselecteerd werden. Wanneer we meerdere variabelen van modellen gaan fitten en de MSE minimaliseren, is er een significant positieve impact opgemerkt. Dit geeft een aanzet naar verder onderzoek. VI. TOEKOMSTIG WERK Het kan interessant zijn om de performantie relatie tussen verschillende netwerkplanning modellen te onderzoeken. Zo kun-

14 nen, indien een bepaald model goed of slecht presteert, andere modellen geadviseerd of vermeden worden. Het grondplan kan ook geanalyseerd worden om te detecteren welk padverlies model het beste resultaat zal teruggeven. Een verdere studie is nodig om deze relatie tussen grondplan eigenschappen en model performantie te vinden. Op deze manier zou advies zelfs al gegeven kunnen worden alvorens een model toe te passen. Zoals aangetoond in deze studie, heeft het fitten van meerdere modelvariabelen veel potentieel. Om te bepalen of multivariable fitting ook goede resultaten oplevert voor een klein aantal metingen, is verder onderzoek nodig. Dit type van fitting is een complexer optimalisatieprobleem dat een geavanceerde algoritme (zoals GRG2 in Excel) nodig heeft. Data van de resulterende fit zoals model parameters, nauwkeurigheid van modelresultaten en eigenschappen van access points en mobiele toestellen, kunnen lokaal opgeslagen worden of naar de webservice gestuurd worden om toekomstige modelvoorspellingen te verbeteren. Indien deze functionaliteit geïmplementeerd wordt, zou dit kunnen resulteren in nuttige statistieken zodat meer toekomstig werk wordt ontdekt. REFERENTIES [1] Saunders SR., Antennas and Propagation for Wireless Communication Systems, John Wiley & Sons Ltd, [2] Harald Trap Friis, Friis transmission equation, wikipedia.org/wiki/friis_transmission_equation, 2014, [Online; accessed 24-May-2014]. [3] Vinko Erceg, Laurent Schumacher, et al., Ieee p wireless lans. tgn channel models, doc.: IEEE /940r4, [4] David Plets et al., Coverage prediction and optimization algorithms for indoor environments, EURASIP Journal on Wireless Communications and Networking, vol. 2012, no. 123, [5] Open Handset Alliance, Android design patterns, developer.android.com/design/patterns/index.html, 2014, [Online; accessed 24-May-2014]. [6] Robert Eckstein, Java se application design with mvc, index html, 2007, [Online; accessed 24-May-2014]. [7] Mean squared error, squared_error, [Online; accessed 24-May-2014].

15 Contents 1 Introduction Problem statement Outline Extensive system description WHIPP Tool Web service Typical User Scenario General Design Components POJOs Models Views and controllers Libraries afiledialog KSoap2Parser Application Design Requirement Differences Compared to WHIPP Tool Mobile Device Drawing Operations Horizontal and Vertical Scrolling File Browsing XML Structure Performance Issues Android Version Complex Wall Drawing Undo and Redo Multithreading Draw Results xii

16 4 Testing Test Environments Turnhout Bruges Ghent Measurements and Deductions Result Improvement Based on Fitted Shift Result Improvement Based on Multiple Parameters Conclusion and Future Work Conclusion Future Work Model Advise Multivariable Fitting Store Data A DVD 42 A.1 Contents Bibliografie 44 xiii

17 List of Figures 2.1 Drawing a floor plan Setting the parameters Selecting and running a prediction tool Viewing the results Improving the results by measurements The Back button in Android Possible display styles of the view for a door Import background The afiledialog library GUI Zoom buttons in the application Illustration drag and zoom Illustration of drawing overlapping walls Illustration of drawing a wall near an edge of another wall Indoor picture of the environment in Turnhout Monitored floor plan in Turnhout Indoor picture of the environment in Bruges Monitored floor plan in Bruges Indoor picture of the environment in Ghent Monitored floor plan in Ghent Improvement by automatic shift based on all measurements Comparison between random and room measurement addition xiv

18 Abbreviations API BSSID CPU DOM GUI GRG2 IEEE INTEC MSE POJO RX SOAP SIDP TGn UI UTP W3C WHIPP WiCa WSDL XML Application Programming Interface Basic service set identification Central Processing Unit Document Object Model Graphical User Interface Generalized Reduced Gradient Institute of Electrical and Electronics Engineers Department of Information Technology of UGent mean squared error Plain Old Java Object Receive Simple Object Access Protocol Simple Indoor Dominant Path Task Group N User Interface Unshielded twisted pair World Wide Web Consortium WiCa Heuristic Indoor Propagation Prediction Wireless & Cable Web Service Definition Language Extensible Markup Language xv

19 Chapter 1 Introduction 1.1 Problem statement As we advance further in the digital era, more and more electronics become mobile. These mobile devices often need a way to communicate with other devices. Not only mobile phones, laptops, airplay speakers and other sort of consumer electronics, but also industrial tools, various sort, etc. Wireless connections are everywhere in our daily lives. Wireless networks often require a stable connection for continuous transmission, a certain throughput to support larger amounts of traffic and maximum delay for fast responsiveness. Trying to satisfy these constraints in an environment, often leads to a sub-optimal usage of available network resources (e.g. capacity). In this dissertation, a mobile application serving as a portable network planning tool is developed. It strives to return the best possible results on a floor plan of an environment using several types of algorithms and real-time measurements by the device. The main goal of this thesis is to determine to what extent it is possible to improve existing network planning algorithms using measurements performed on a mobile device. This optimized network planning will be performed on the mobile device itself, therefore an Android app is developed in which floor plans can be drawn, on which a network planning model is performed. These models will be improved by the application using the device s measurements. This app can be of use for firms or private individuals that install wireless networks. 1.2 Outline The outline of this thesis is as follows. In Chapter 2 an extensive description of the Android application is given. Design considerations are stated alongside their elaborated 1

20 solutions in Chapter 3. Chapter 4 presents the measurement setup and results of various environments. Conclusions are drawn and possible future work is proposed in Chapter 5. 2

21 Chapter 2 Extensive system description In this chapter, an extensive description of the mobile application is elaborated. Usability as well as modifiability are prioritized as quality attributes for the developed software. This ensures the ability to expand the functionality of the tool with little effort. Since no similar tool exists thus far, there are opportunities to market the application. First of all, the WHIPP tool of the WiCa research group of INTEC will be addressed in Section 2.1. Section 2.2 describes a typical user scenario to show what this application should be capable of and to clarify how and where this tool can be useful in practice. Next, the general design will be presented in Section 2.3. In Section 2.4, the most important components of the code structure will be explained. In the last section of this chapter, Section 2.5, the two used Android libraries are discussed. 2.1 WHIPP Tool The WiCa research group of Ghent university developed a tool to calculate path loss, optimize exposure and to predict and optimize coverage of indoor wireless networks. It is available by web browser and is developed in Adobe Flash. As Apple s ios does not support Adobe Flash and Adobe has cut support for Flash in Android Jelly Bean (API level 16) and beyond, the tool is not fit for mobile devices. Even if the Flash is available on the mobile device, the GUI of the WHIPP tool has not been developed with the mindset of possible mobile usage, resulting in inconvenient touchscreen actions. In case the user wants to use both the mobile applications and the WHIPP tool, it would be smart for their layouts to be similar. Hence, the appearance of the WHIPP tool was used as a model for the mobile app. The same icons and navigation type was used. This will significantly decrease the learning curve for the second application if one of both is already mastered. 3

22 2.1.1 Web service The WHIPP tool makes use of a web service, also developed by WiCa, which applies network planning algorithms on inputted indoor environments. It makes use of five different prediction algorithms (Free-space, TGn IEEE Indoor, One-slope, Multiwall, SIDP) which will be explained further on in this chapter. The web service is described in WSDL 1 with its associated XML Schemas 2,3. It can return multiple results: Data at locations: Download speed Upload speed Path loss Electric field Absorption Receive power Transmit power Benchmarks Diffuse power Optimized plan... Requests and responses are communicated by the SOAP protocol. This web service will be used in the mobile application. Free-space The free-space path loss model [7] presumes there are no obstacles in the line-of-sight path from transmitter to receiver and makes use of the Friis transmission equation [5] to get a specific formula for 2.4 GHz WiFi access points. Equation 2.1 contains the resulting formula where P L 0 is the path loss at distance d 0 and d is the distance between transmitter and receiver. As default values, the web service uses 40 as P L 0 for a distance of one meter. ( ) d P L = P L log 10 (2.1) d

23 TGn IEEE Indoor The TGn IEEE indoor model [4] consists of the free-space path loss model up a certain distance and a slope of 3.5 for distances larger than that break-point distance. This gives Equation 2.2. The default values in the web service for P L 0 and d 0 are the same as for free-space. P L F S in the equation is the path loss when applying the free space model. ( P L F S = P L log 10 P L = ( d P L F S + 35 log 10 d 0 ) ) d d 0 for d d 0 for d > d 0 (2.2) One-slope The one-slope model [7] is an extension on the free-space model where the slope of the distance part of the formula is variable. This different slope can be useful to account for objects and other obstacles in the environment. Equation 2.3 is the used one-slope formula where n is the path loss exponent. The default values the web service uses are 2.85 for n, 27 for P L 0 and 1 for d 0, which are based on measurements performed by WiCa at Complex Zuiderpoort. P L = P L n log 10 ( d d 0 ) (2.3) Multiwall An extension on the one-slope model is the multiwall model [7]. It takes the walls that are passed by the signal from transmitter to receiver into account. The penetration losses of the types of walls supported by the application are given in Table 2.1. The formula of this model is given in equation 2.4. L Wi stands for penetration loss (L) of all walls traversed along the signal s path, i = 1,..., W T, where W T is the total amount of passed walls and i is the index. Table 2.1: Wall penetration loss values for different types of walls (in db) Material Thin Thick Brick Layered drywall Concrete Glass 2 4 Wood 6 10 Metal

24 P L = P L n log 10 ( d d 0 ) + i L Wi (2.4) SIDP The simple indoor dominant path model [6] combines semi-empirical models that only consider the direct ray between transmitter and receiver and ray-tracing models that investigate many possible signal paths leading to the receiver. The path loss of each signal is calculated by the formula in equation 2.5 which takes into account the distance along the ray s path (distance loss), the corresponding wall losses, and the propagation direction changes along the dominant path (interaction loss). This interaction loss is an additional part compared to the multiwall model s formula, where L Bj is the loss caused by propagation direction change j with j = 1,..., BT where BT is the total number of times the propagation path changes its direction. The same wall penetration losses are used as in the multiwall model (see Table 2.1). ( ) d P L = P L n log 10 + L Wi d } {{ 0 } i } {{ } distance loss cumulated wall loss + j L Bj } {{ } interaction loss (2.5) 2.2 Typical User Scenario 1. Draw floorplan (Figure 2.1) The different types of objects to draw and other drawing functions are on the right side of the screen. The user draws a floor plan on the design area on the left. 2. Set parameters (Figure 2.2) In the second tab, several types of parameters are set. The configured parameters of the receivers are shown at the right. 3. Select prediction tool (Figure 2.3) The required prediction tool is selected and initiated. invoked. The web service will be 4. Check results (Figure 2.4) Results will be displayed graphically. At the right side of the screen, a legend is shown to clarify all visual data. Different types of results (like pathloss, download speed, etc.) can be chosen to be displayed. 5. Improve results (Figure 2.5) By doing actual measurements with the device, the results that are returned by the 6

25 web service can be improved. The shown results on the floor plan are updated with the adjusted values. Figure 2.1: Drawing a floor plan 2.3 General Design The Android platform provides a range of build-in design patterns making apps behave in a consistent, predictable fashion[2]. As this app is mainly developed for tablet usage, much data and functionality is displayed at the same time while still being very accessible to the user. To have all components of the layout well-arranged, a multi-pane layout 4 was used which contains the navigation hierarchy. All levels of the hierarchy are displayed at the same time. Such hierarchical structure is typical for Android applications 5. The top level views of this hierarchy are the numbered buttons describing the first four steps of the typical user scenario of Section 2.2. The second level of views are the buttons located at the right side of the screen, under the top hierarchy level buttons. These contain specific information on what action can be done with them. The deepest level contains the details of the action which often can be edited

26 Figure 2.2: Setting the parameters Figure 2.3: Selecting and running a prediction tool 8

27 Figure 2.4: Viewing the results Figure 2.5: Improving the results by measurements 9

28 The system Back button (see Figure 2.6) is used to close pop-up windows, and thus functions as a cancel button. When being in the main application and no pop-up dialogs are shown, the Back button exits the application. This is a typical navigation element of an Android app 6. Figure 2.6: The Back button in Android As major design pattern of the app, MVC[3] was chosen. Models contain what to render, views determine how to render and the controllers react on user input or events. There are two models implemented which are located in the model package. The classes representing the models extend the Observable class as they need to be observed by the views. Activities and their Views act as both view and controller and therefore implement the Observer interface. These classes are located in the layout package Components Basic Android coding knowledge is required to understand this section POJOs Floor plan A FloorPlan object contains all data contained in the floor plan. There are several types of objects that can be placed on a floor plan. There are walls, access points, data activities, connection points, and access point measurements. The java classes representing these object types will need to extend the abstract class which is called FloorPlanObject. The FloorPlanObject has a Point variable which represents the location of the object on the floor plan. It also contains an enum which depicts the type of object and should be set in the constructor of extending classes. It has an abstract method, called getpartialdeepcopy(), which should return a deep copy of the object with only the static characteristics of it (i.e. without location data), mainly used to get a fresh similar instance after adding it to the floor plan. It also has two methods for acquiring its state and usually overridden by extending classes. The method iscomplete() returns whether

29 the object is ready to be added to the floor plan, and thus misses no required data. The method candraw() returns whether the instance has sufficient data to be drawn on the floor plan. Its usage will become clear with an example. A wall can be partially drawn when one of its two locations is set (the position of a wall is defined by two locations), but it needs two locations to be complete. An abstract method, called drawoncanvas(), is provided to make the object draw itself on a Canvas that belongs to the DrawingView discussed in Section To know where should be drawn exactly, location transformation is performed by the DrawingModel (see Section 2.4.2) instance, passed as an argument for the method. The FloorPlan object itself contains four lists. The first list contains instances of Wall objects. The Wall class extends FloorPlanObject and is representing any type of object that has a start and end point, including windows, doors and actual walls. The type of Wall is defined by the WallType enum. The wall also has a thickness and is made from a certain material, both stored in variables. Connection points are located in the second list. The ConnectionPoint class can represent locations for access to both data, such as UTP wall outlets, and electricity. The third list holds access points (AccessPoint class). An access point has various properties, e.g. what network it is on, frequency, height,... It also has an optional RealAccessPoint variable, so it can be linked with an actual access point to compare measurements with algorithm results (see Section 2.4.1). The last list contains data activities, required at certain locations. Certain rooms may need to have a connection strong enough to play HD video while others should not have any coverage for security reasons. Deus objects Deus objects are used for communication between the web service, which is explained in section 2.1.1, and the application. Firstly, there is the DeusRequest class, containing the input for the web service. Any type of request to the web service can be represented by it. DeusResult on the other hand, represents whatever is returned by the service. As results need to be displayed on the floor plan, a drawresult() method is implemented and has a result type as parameter to indicate which one of the returned results needs to be drawn. When there are location-specific results, they are stored in CSVResult objects. One CSVResult instance is required for each location. Measurements The ApMeasurement class is provided for measurement storage. It extends FloorPlanObject because measurements must be able to be rendered on the floor plan. It holds the signal strength and the amount of samples it is based on. In order to measure, one must 11

30 first link the appropriate access points of the floor plan with actual access points detected by the device. This ensures that correct signals are sampled. Real access points are stored in the RealAccessPoint class and are uniquely identified by their BSSID. The class WifiManager of the Android s android.net.wifi package is used for the measurements. First, a BroadcastReceiver is registered with the current Context, which will be notified when the device finished a scan for WiFi signals. When this notification takes place, the getscanresults() method of the WifiManager will be called and returns a list of ScanResults. Each ScanResult instance represents a signal. Out of these ScanResult instances, the concerning signal is retrieved and the signal strength contained in the level variable is stored. Calling the WifiManager s startscan() method makes the device start a scan for WiFi connections Models Floor plan model The first model (FloorPlanModel class) is the one holding the floor plan, its change history (for undo and redo functionality) and any info displayable on it. This other info includes measurements and the result of the web service. Because no more than one instance needs to be used, it is implemented as a singleton. The model has the following functionality: Get and set the data it holds. Add FloorPlanObject instances (see Section 3.2 for adding Wall objects in particular). Remove FloorPlanObject instances. Get closest FloorPlanObject to location for selection and removal. Get closest Wall object to location for snapping. Undo and redo logic, also discussed in Section 3.3. Drawing model The DrawingModel class is responsible for what actually should be displayed and where. Several sorts of data are managed by this model: Dimensions of the drawing area. Properties of the grid. 12

31 Which part of the total drawing area is shown. The state of the drawing area (idle, place, selection, edit, remove). Which FloorPlanObject is currently being addressed. The last touched location. Background image and its scale. One of its key functionalities is transforming locations on the floor plan to coordinates on screen and vice versa. The drawing model uses the floor plan model to get FloorPlanObject objects dependent on the touch location and can add completed FloorPlanObject instances to it Views and controllers Drawing view The most important view for floor plan design is the DrawingView class. It observes both the FloorPlanModel and the DrawingModel as their updates require the view to be redrawn. It can display all floor plan objects, measurements and results on the floor plan as well as what the user is drawing currently. It can also show a background image (see Section 2.4.3) and a grid to improve accuracy. Details on how the designing itself takes place can be found in Section Also included in the view, are tools to easily navigate the plan by both single- and multi-touch touchscreen (e.g. scroll bars, multitouch zooming and dragging). Design views The views containing the possible properties of objects we can draw on a floor plan in order to design it, are located in the design package. They can be used to display and edit the addressed object. Wall, AccessPoint, ConnectionPoint and DataActivity objects can all be represented by their respective views to set, change or show their properties. These types of view usage are shown in Figure 2.7 in case of a door. For controller functionality of the MVC pattern, the ontouchevent method of View is overridden. For the view part, the ondraw() method is overridden to draw on the screen. Import image An image can be set as background of the drawing area. This is useful when a digital ground plan is available, so accurate floor plan designs can be made. In case a ground 13

32 (b) Menu to edit properties of a door (a) Menu to adjust properties of the door to be drawn (c) Menu displaying properties of a door Figure 2.7: Possible display styles of the view for a door 14

33 plan is hung up against a wall or a paper version is available, it is easy to take a picture of it with the device itself and import it to the application. In Figure 2.8, a ground plan of the third floor of Complex Zuiderpoort is being imported. In (a), a line was drawn and we set the length of the line to be five meters in real life. The application shows the scaling that will be done. The scale represents the amount of pixels per centimeter. The result of the import is shown in (b) where a few walls are drawn on top of it already. 2.5 Libraries afiledialog To be able to browse for files in Android, the open source library afiledialog was used. As there are little libraries available with this functionality, afiledialog seemed the best documented and most mature. It is licensed under LGPL 3 and is compatible with Android It is easy to use and to extend. It can be used as an Activity or a Dialog. The latter was picked for the application as it appears more integrated into the application and reduces complexity. Displayed files and folders can be filtered which is useful in our application for only displaying appropriate file types (i.e. images and XML files). It also has a GUI to let the user create a new file. It does not actually create the new file, but returns the file name to the application so it can be handled manually in a different thread. This feature is used whenever applicable. The library has a user guide in English, French and Spanish. Developer guides are available in English and Spanish. The code of the library is structured using the design patterns embedded in the Android API and can easily be internationalized by making use of the internationalization mechanisms provided by the Android SDK. Figure 2.9 is a screenshot of afiledialog in action in the application KSoap2Parser In order to read the data returned by the web service and send messages to it, a SOAP parser is required. The ksoap2-android library seemed to be the ideal client library for this purpose. It is lightweight, efficient and specifically made for usage on the Android platform. The library is open source and licensed under MIT. Being actively maintained, any bugs that might show up in the future are very likely to be fixed. There are many tutorials and helpful resources to be found on their wiki page hosted by Google. 15

34 (a) Importing a ground plan image as background (b) Drawing on top of the background Figure 2.8: Illustration of how ground plan images are imported and used. 16

35 Figure 2.9: The afiledialog library GUI. 17

36 Chapter 3 Application Design When designing the application, issues and trade-off considerations appeared. This includes code-specific as well as general development issues. Some are specific for the mobile application and others are in common with the WHIPP tool. 3.1 Requirement Differences Compared to WHIPP Tool Mobile Device Drawing Operations As the Android application should allow the user to draw a floor plan, a user-friendly drawing functionality is required. Because mobile devices almost never have other input possibilities than a touchscreen (i.e. there is no mouse), it should be straight-forward to draw the floor plan as well as moving its view (i.e. zooming and shifting). An additional issue would be to make it as easy as possible both for single- as multi-touch devices. For the drawing part, objects need to be divided into two categories. The first category has two location points to define its position on the floor plan (e.g. walls, doors, windows). The second category only has one such location point (e.g. access points, data activities, connection points, measurements). All objects will be drawn with single touch functionality. When the user touches the screen, a location left above the touch location will be marked as the current position to draw. As long as the user keeps touching the screen, this current draw position can be changed by moving on the touchscreen. When the screen is no longer touched (i.e. finger or pen is lifted), the object will be drawn at the last touched location. If the object is of the second category, this is all what needs to be done to draw it. In case the object is of the first category, the user has follow the same procedure again. When the user is touching the screen to draw the second location point, the connection line in between the two points will be drawn as well. 18

37 As for the zooming and shifting functionality, a difference was made between single and multi-touch devices. For zooming, single-touch users can use the zoom buttons at the top menu bar (Figure 3.1). This will zoom in/out with the focus on the center of the drawing part of the screen. For shifting purposes, scroll bars have been implemented. These scroll bars needed to be custom made as the scrolling functionality also needed to be custom made (see Section 3.1.2). Multi-touch devices have the extra functionality to zoom and shift by using 2 fingers on the drawing canvas. When two fingers start touching, all drawing activities (caused by touching with one finger first) are canceled. When moving the 2 fingers on the touchscreen, the zooming degree will be linear with the difference in distance between fingers. Shifting is based on the smallest x and y coordinate the fingers are located at. Figure 3.2 contains an example of dragging and zooming. Figure 3.1: Zoom buttons in the application Horizontal and Vertical Scrolling In the part of the application where the floor plan is drawn on the screen by the user, both horizontal and vertical scrolling should be possible at the same time. This is required in order to significantly simplify drawing with multi-touch. This is however not available as a GUI component in Android by default. Therefore, it was necessary to implement a custom view which allowed this behavior. The result is contained in the DrawingView class which processes the touches on the screen and displays the changes in visible elements File Browsing In the application, different types of files need to be opened and saved. Examples of types of files to be opened are images of floor plans and the floor plans themselves. Files that are to be saved are floor plans, screenshots, measurements, and all kinds of results that are generated by the algorithms. As there currently are no standard features in Android to browse for files, four possible solutions were considered: 1. No file browsing; only let user select and save files in a dedicated application folder. 2. Develop a custom file browser. 3. Let the browsing be handled by third-party apps. 19

38 Figure 3.2: Illustration of how to do dragging and zooming. The green arrows depict where the fingers of the user are touching the screen. 20

39 4. Use a file browsing library. The first option implies that users always has to move external files to the correct folder in order to open it with the application. It can also cause confusion about the exact location of the files when they are required for usage in other software. The second option would be a very user-friendly solution as it can modified exactly to any needs. However, there are certain risks that go hand in hand with this choice. It is very work-intensive to implement the GUI as well as the functionality and to handle everything that can go wrong in an appropriate manner. Option number three means that the device needs to have file browsing software installed to select files for our application to open or save. This requirement is rather undesirable. The last option is chosen as the best option. A reliable externally developed library is preferred over option two. The Android library afiledialog is chosen to be the file browser of the application. See Section for detailed information about afiledialog XML Structure As the application is required to use and produce floor plan files with the same structure that is used in other WiCa software, the data structures represented in the files are not the same as the self-created ones. Therefore it is not possible to have easily automated conversions from and to the desired XML structure. All data classes that need to be able to transform to XML implement the XMLTransformable interface and require implementing its toxml() method in which the required data is formatted and returned in an Element object of the W3C DOM package. To transform XML to the data objects, seperate methods are implemented for each file type and are located in the XMLIO class Performance Issues The GUI of the application is rather big and contains a lot of functionality on a single screen. This is to limit the amount of actions needed to be performed by the user. As the user interface kept expanding, slow responsiveness of the screen occurred. The cause was found using Android Hierarchy Viewer. The quite hierarchic structure of the layout resulted in slow loading and updating of several views. The solution of this problem was flattening the hierarchy and making the views more independent of scaling updates. After the restructuring, no lag or delay of any kind was perceived anymore. 21

40 3.1.6 Android Version Because we want to maximize the amount of devices compatible with the application, we want to pick an Android version with the lowest possible version as the newer version are backward compatible. The used library afiledialog (see Section 2.5.1) requires a minimum API level of 8 (Android 2.2 Froyo). Devices starting from API level 8 have access to Google Play, formerly Android Market. This means all possible users are reachable by solely publishing it on Google Play. 3.2 Complex Wall Drawing There is a need for the walls (and windows and doors) to connect precisely in order for the web service to detect the distinct rooms. We do not want to burden the user with exact drawing, thus a system was engineered to simplify the drawing of usable floor plans. To select the locations where the edges of a new wall have to be, two ways of drawing are made possible. The first is the option Snap to grid. The background of the floor plan is a grid with spacing of 50 centimeters. Enabling this options will the currently drawing edge to snap to the closest grid, or to a wall if it is even closer. The other possible option is Snap to walls. In this mode, only snapping to walls will occur if drawing close enough to it. The snapping itself is not sufficient to provide an acceptable level of user-friendliness. In case walls are overlapping, they should be split in two at the intersection point (e.g. Figure 3.3). Also, if a wall is near the edge of another wall, this edge should be used for the wall (e.g. Figure 3.4). For this functionality, an algorithm for adding new walls (Algorithm 1) is elaborated. For each already existing wall (line 2), save the wall s edge locations (line 6) if they can be perpendicularly projected on the new wall (line 5) and are 40cm or less away from it (line 5). If no edges of the current wall are added and it gets intersected by the new wall (line 9), split the current wall in two separate walls (line 10) and save the intersection location (line 11). After iterating all walls, sort the list of saved locations by distance to the first edge of the new wall (line 14). Next, add new walls with the same properties of the new wall using the sorted locations (line 15). Finally, remove duplicate walls, if any (line 16). 22

41 Figure 3.3: Illustration of drawing overlapping walls. Figure 3.4: Illustration of drawing a wall near an edge of another wall. The brown colored wall is drawn after the red colored wall. 23

42 Algorithm 1 Add wall algorithm 1: procedure AddWall(newW all, walllist) 2: for all wall walllist do 3: for all location wall do 4: if isp erpendicularlyp rojectable(location, neww all) 5: && distance(location, neww all) < 40 then 6: locations location 7: end if 8: end for 9: if nolocationsadded && isintersectedbyw all(wall, neww all) then 10: splitw all(wall) 11: locations intersectionlocation 12: end if 13: end for 14: locations.sortbydistance(neww all) 15: addw alls(locations, neww all) 16: removeduplicatew alls 17: end procedure 3.3 Undo and Redo In a drawing application, functionality to undo and redo actions is indispensable. Certainly needed components are an undo stack, containing the data to return to past state, and a redo stack, containing data to return to a previously undone state. When invoking an undo, the undo stack is popped, and the element is pushed to the redo stack. Vice versa when invoking a redo. Of course, the redo stack is cleared when a new action is taken. There are two possible manners to actually implement this. The first possibility is storing the actions themselves in the stacks. When undoing, the inverse action should be performed. This would make undoing the placement of a wall (see Section 3.2) extremely complicated since it involves merging walls. The second manner is saving the complete states in the stacks. A state contains all elements of the floor plan. This solution requires more storage since much duplicate data is stored. Performance on the other hand is expected to be much better than the complex inversions proposed in the first possibility. Considering the data overhead is not large enough to be worried about, and the low complexity, the second option is implemented. 3.4 Multithreading In software with a GUI, issues with multithreading often arise. In Android, the UI thread is the main thread. Different threads need to be used for CPU intensive operations since 24

43 a non responsive GUI needs to be avoided. Because ASyncTasks operate in a thread separate from the UI thread, they are used in the application to perform background operations. The only tasks that can take a long time are the ones involving I/O. We use two types of I/O operations. The first is file reading and writing. The application can read and write plain text, xml and images. The other type is communication with the web service described in Section The duration of both the operations depend on the amount of data that needs to be processed and to what extent this data needs to be transformed. All ASyncTask instances are managed by the ASyncIOTaskManager which can provide a progress dialog to the UI. An implementation of the OnAsyncT askcompletelistener T interface will be notified when the task is complete, and it will be passed the result of the task. 3.5 Draw Results Depending on how large the floor plan is, many location specific results can be returned by the algorithms of the web service. When drawing them separately, high CPU usage and lag was observed. For this reason, a different approach was vital. Now, one pixel for each ten square centimeter is provided. The results for the complete ground plan are provided by small bitmaps whereas each bitmap represents one result type (i.e. download speed, RX power,... ). No lag presented itself after this adjustment. 25

44 Chapter 4 Testing For testing the network planning model improvement possibilities for Android devices, signal strength measurements were taken in three different indoor environments. All measurements were done using the same Android device (Sony Xperia Tablet Z) with the application described in Chapter 2 (see Section for the measurement implementation). During each measurement, the tablet was held horizontally, facing the access point at a height of approximately one meter. The measurement procedure was as follows: 1. Select the location on the floor plan where the measurement needs to be taken. 2. Set amount of measurements to be taken at the location to Hold the device at the same location and height during the measurements. 4. Store the average result at each location. 5. Save the results in XML format, to be parsed and processed by Excel for statistics. 4.1 Test Environments Turnhout The first set of measurements was taken in a detached residential house in Turnhout (Figure 4.1). It has three floors including the attic. All measurements took place on the first floor. The walls of this residence are brick and all doors are made of wood. As can be seen in Figure 4.2, every single room was used and measurement locations are fairly spread out. The residence is little furnished and the access point was placed in the bottom right location on the floor plan. The used access point was a DLink dir-615 (hardware version H2, firmware version 8.02) which has two antennas and a transmit power of 13 26

45 dbm. The TX power of the router is an estimation based on online searching as the actual value could not be found in any documentation nor settings. The surface on which the monitoring took place is square meters. Since 112 locations were measured, the number of measurements per square meters is Data per room can be found in Table 4.1. All rooms have at least 1.2 measurements per square meter. Figure 4.1: Indoor picture of the environment in Turnhout Table 4.1: Properties of the monitored rooms in Turnhout. surface(m 2 ) #measurements #measurements/m 2 Room Room Room Room Room Total Bruges The second set of measurements was taken in an old townhouse in Bruges (Figure 4.3). It has a total of four floors including the basement. The measurements were taken on the ground floor. All rooms were included in the measurements except for the stairs leading to the basement as can be seen in the top center of Figure 4.4. It has brick walls and the doors are from glass or wood. The residence is averagely furnished, meaning it has 27

46 Figure 4.2: Monitored floor plan of the house in Turnhout several objects that can possibly block signals (e.g. piano, metal music stand, high filled bookcases). A DLink dir-600 access point (firmware DD-WRT v24-sp2) was placed on top of a sofa at a height of one meter. It has one antenna and a transmit power of 8 dbm. The surface of this floor is square meters where 96 measurements were done. This results in measurements per meter. As in Turnhout, the rooms also have at least 1.2 measurements per square meter. More detailed information can be found in Table 4.2. Table 4.2: Properties of the monitored rooms in Bruges. surface(m 2 ) #measurements #measurements/m 2 Room Room Room Room Room Total Ghent The third and final set of measurements was taken in Complex Zuiderpoort in Ghent (Figure 4.5). As can be seen in Figure 4.6, most walls are layered drywall and concrete except for some metal in the center and glass at the sides of the floor plan. The metal walls represent the elevators. The third floor was used for the measurements. As students and employees are working in all of the rooms, only the hallways and toilets were used for measurements. The rooms were slightly furnished while the hallway is as good as clear of objects. The same access point as in Bruges was set up here. The two rooms and the 28

47 Figure 4.3: Indoor picture of the environment in Bruges Figure 4.4: Monitored floor plan of the house in Bruges 29

48 hallway have a surface of square meters and have 272 measured locations in total. This makes a measurement density of measurements per square meter. The details per room are located in Table 4.3. Figure 4.5: Indoor picture of the environment in Ghent Table 4.3: Properties of the monitored rooms in Ghent. surface(m 2 ) #measurements #measurements/m 2 Room Room Room Total Measurements and Deductions In this section, two different methods with the purpose of improving the results of the algorithms will be tested Result Improvement Based on Fitted Shift Maximum Improvement Firstly, the maximum improvement of the results returned each algorithm in each test environment is investigated. We define improvement as decrease in MSE (mean squared 30

49 Figure 4.6: Monitored floor plan of Complex Zuiderpoort in Ghent error[1]). The MSE when shifting is done based on all measurements will be called the maximum improvement. We add the average deviation of the difference between result and measurement to the result. This will make the average deviation between the new results and the measurements zero. The impact of adjusting the results will be evaluated by the change in MSE because it incorporates both variance and bias. Since only a shift is applied, the standard deviation will always be the same before and after the shift. At every monitored environment and for each algorithm using default values statistics are calculated. This includes the average error, the average deviation, the standard deviation, the average error after shift and the error reduction. The results for Turnhout are displayed in Table 4.4, for Bruges in Table 4.5 and for Ghent in Table 4.6. Figure 4.7 shows how the results of the SIDP model are shifted for the house in Turnhout. Table 4.4: Algorithm comparison statistics of Turnhout. sidp tgn free-space multiwall MSE (dbm) avg. dev. (dbm) std. dev. (dbm) MSE shift (dbm) error reduction (%) We notice large error reductions (and thus result improvements) for almost every algorithm at every environment. The observed improvement rates in Turnhout vary between 47 and 73 percent. In Bruges, this is between 82 and 94 percent. The environment in Ghent produces good results for the SIDP and Free-space algorithms as their improvements are over 62 percent. The TGn algorithm in Ghent shows almost no improvement 31

50 Figure 4.7: Improvement by automatic shift based on all measurements for Turnhout shown in the application. The top image shows the received power predictions of SIDP. The bottom image shows the shifted results. 32