Optimering af dataoverførsler på mobile enheder

Optimering af dataoverførsler på mobile enheder Hovedopgave Master i IT Jan Kølbæk (19900183) og Steen Voersaa (20097675) Vejleder: Niels Olof Bouvin 14. juni 2012 1

Indholdsfortegnelse Optimering af dataoverførsler på mobile enheder Hovedopgave Master i IT Indholdsfortegnelse 1. Motivation 1.1 Indsamling af positionsdata 1.2 Udfordringer 1.3 Opsummering 2. Hypotese og problemformulering 2.1 Direkte indsamling 2.2 Mellemlag 2.3 Hypoteser 2.4 Afgrænsning 3. Metode 4. Baggrund og relateret arbejde 4.1 3G netværk 4.2 RRC state machine 4.3 Overgange i RRC tilstande 4.4 Tail effekt og trade-off 4.5 Udledning af state machine 4.6 Relateret arbejde 4.6.1 TailEnder 4.6.2 TOP (Tail Optimization Protocol) 4.6.3 Bartendr 4.6.4 Andre bidrag 5. Værktøjer 5.1 ARO 5.2 PowerTutor 5.3 Præcision og begrænsninger 6. Analyse og design 6.1 Analyse 6.1.1 Teknologier 6.1.2 WebSockets 6.2 Design 6.3 Implementation 6.3.1 AJAX web applikation 6.3.2 WebSockets applikation (version 1) 6.3.3 WebSockets applikation (version 2) 6.3.5 Native Android-JSON Applikation 6.3.6 Jetty Webserver og MySql setup på Linux Ubuntu server 7. Resultater 7.1 Udførelse af eksperimenter 7.1.1 Test setup 7.1.2 Udførelse af test 7.2 Direkte indsamling af data 7.2.3 Målinger med ARO 7.2.3.1 Opsætning af ARO 2

7.2.3.2 Resultater fra native app 7.2.3.3 Resultater fra AJAX applikation 7.2.3.4 Resultater fra WebSockets applikation 7.2.3.5 Sammenligning 7.2.4 Målinger med PowerTutor 7.2.4.1 Opsætning af PowerTutor 7.2.4.2 Resultater fra native app 7.2.4.3 Resultater fra AJAX applikation 7.2.4.4 Resultater fra WebSockets applikation 7.2.4.5 Sammenligning 7.2.5 Konklusion og best practices 7.3 Intelligent mellemlag 7.3.1 Målinger 7.3.2 Konklusion 8. Konklusion 9. Referencer 3

Denne hovedopgave på Master i IT uddannelsen ved Aarhus Universitet omhandler problemstillinger omkring energiforbruget i forbindelse med dataoverførsler på mobile enheder. 1. Motivation Indenfor de seneste år har teknologien omkring smartphones udviklet sig drastisk, samtidigt med, at udbredelsen af disse mobile enheder er eskaleret. Dermed har der åbnet sig en helt ny verden af muligheder indenfor applikations- og softwareudvikling, som samtidig også stiller helt nye krav til udviklerne, da der er mange nye problemstillinger indenfor mobile computing, som ikke eksisterer ved traditionel applikationsudvikling på web platformen. F.eks. er batteriforbrug pludselig en faktor, som har stor betydning. Og netværkstraffik har også typisk mere bevågenhed på en mobil platform end på en stationær, pga. af betaling for dataforbrug og varierende netværkskvalitet. 1.1 Indsamling af positionsdata Da smartphones har indbygget GPS giver det nye muligheder for at indsamle data omkring brugernes position. Ved hjælp af løbende indsamling over et tidsrum, så kan der analyseres på brugernes bevægelsesmønstre indenfor et givent geografisk område, eller også kan brugernes positioner monitoreres. Der er mange anvendelsesområder for denne type dataindsamling omkring positioner. F.eks. indenfor trafiksektoren, hvor der er mulighed for at analysere, hvilke ruter bilisterne benytter sig af for at komme fra et sted til et andet, samtidig med, at tidsforbruget også kan medregnes og køer på vejene kan identificeres. Dette åbner op for mulighed for at lave intelligente applikationer, som kan vejlede bilisterne i den mest optimale rute til deres destination. Eller evt. foreslå alternative transportsmuligheder. Indenfor detailhandlen er der i forvejen meget fokus på at få forbrugerne til at tage en vej gennem butikken, som optimerer chancerne for impulskøb. Her kunne indsamling af data omkring forbrugernes aktuelle rute gennem butikkerne bidrage væsentligt til analyser på dette område. I forbindelse med transportplanlægning og -afvikling findes der allerede idag mange systemer, hvor lastbilernes positioner løbende tilbagemeldes til et centralt system, sådan at det er muligt at lave opfølgninger på forsinkelser, anløbstider og meget andet relevant. Med brug af smartphones som teknologi, så åbnes der op for billigere og mere avancerede frontend applikationer, som kan bidrage med øget forretningsværdi. Så hvis indsamling af positionsdata kan foregå på en relativ nem og billig måde, så vil der potentielt være mange anvendelsesmuligheder for dette. 1.2 Udfordringer Hvis der skal etableres indsamling af positionsdata i større stil, så kræver det, at brugerne ikke oplever gener eller irritationsmomenter i denne forbindelse, da de ellers nemt vil vælge ikke at deltage i indsamlingen. Samtidigt er energiforbrug generelt en vigtig faktor i verdenen idag, så jo mindre energi, der generelt set bruges på indsamlingen af data, desto bedre er den totale økonomi i løsningerne både ud fra en samfundsøkonomisk og en privatøkonomisk betragtning. Batteriforbruget i forbindelse med indsamling og overførsel af data er derfor en megen vigtig parameter, da det både har indflydelse på energiforbruget og også samtidigt på brugerens oplevelse ved at bruge applikationen. Netværksforbruget har på tilsvarende vis også betydning, da netværkstraffik også koster både penge og ressourcer, specielt på mobile netværk. 4

I modsætning til disse målsætninger om at begrænse brugernes ressourceforbrug, så er der forskellige krav fra modtagerne af data til hyppighed af måling af positionsdata, samt hvor hurtigt, at data bliver tilgængelige i backend. I nogle sammenhænge er der krav om meget hyppige indrapporteringer i realtid (f.eks. monitorering af traffikkøer og ruteafvikling), mens det i andre sammenhænge kan være tilstrækkeligt, at data blot indsamles lokalt og så indrapporteres samlet på et senere tidspunkt (f.eks. når data skal bruges til at analysere bevægelses- og brugsmønstre). 1.3 Opsummering Ovennævnte trade-off mellem ressourceforbrug og realtidsopdatering kan nemt blive en vigtig beslutningsparameter, når en aktuel applikation skal designes og implementeres ud fra et givent ønske om dataindsamling. Så derfor vil vi i dette projekt forsøge at belyse og analysere forskellige metoder til indsamling af positionsdata fra mobile enheder, sådan at vi bliver istand til at komme med en fornuftig vejledning til, hvordan dataindsamlingen kan foregå på den mest økonomiske måde ud fra forskellige krav til opdateringsfrekvenser. 5

2. Hypotese og problemformulering Vi vil analysere mulighederne for at optimere en løbende indsamling af positionsdata fra mobile enheder ved at undersøge forskellige teknikker, som kan løse denne problemstilling. 2.1 Direkte indsamling Der udarbejdes tre forskellige måder at håndtere problemstillingen på, som anvender forskellige teknologier: Native app, som med fast interval sender positionsdata til backend via HTTP protokollen Web app, som via standard AJAX teknikker sender positionsdata til backend med et fast interval. Web app, som udnytter WebSockets protokollen til at holde en permanent connection åben til backend, hvor der så med et fast interval sendes positionsdata igennem. Med disse tre opstillinger er vi i stand til både at sammenligne performance af en native app mod web apps og også sammenligne omkostningerne ved at holde en konstant forbindelse åben til backend i forhold til at connecte hver gang, der skal sendes data. 2.2 Mellemlag Udover førnævnte forholdsvis direkte måder at håndtere dataindsamlingen på, så vil vi også udarbejde et intelligent mellemlag, som via forskellige heuristikker skal forsøge at optimere selve forsendelsen af data fra klienten til backend. Ved at udnytte mulighederne for local storage af data på klienten, så kan data pakkes i større klumper og sendes med større intervaller imellem hver forsendelse. Dette giver også bedre muligheder for at udnytte forskellige metoder til at komprimere de datapakker, som sendes. Endvidere kan der tages hensyn til batteriniveau, kvalitet af netværksforbindelse og andre relevante parametre, når der skal vælges, hvilket mønster, som skal bruges til at sende data med. F.eks. kunne vælges kun at sende data, når man er på en WiFi connection for at spare på datatrafik over mobile netværk. 2.3 Hypoteser Ud fra ovennævnte beskrivelser af direkte indsamlingsmetoder og mellemlag, sammenholdt med diskussionen under det tidligere afsnit omkring udfordringer, så kan vi opstille disse hypoteser omkring løbende indsamling af positionsdata fra mobile enheder, som vi vil forsøge at verificere i dette projekt: 1. Ved at undersøge og sammenligne de skitserede metoder til direkte indsamling af data, så kan vi opstille en vægtet prioritering af hvilke metoder, som performer bedst mht. til batteri- og netværksforbrug under hensyntagen til forskellige krav om realtidsopdatering af data. 2. Det er muligt at udarbejde et intelligent mellemlag til forsendelse af data, som kan reducere batteri- og netværksforbruget ved at følge fastlagte mønstre ud fra forskellige heuristikker 6

2.4 Afgrænsning Følgende afgrænsninger er identificeret for at kunne holde et fornuftigt fokus i projektet: Den native app udvikles kun til Googles Android styresystem. Der laves ikke tilsvarende apps til iphone og Windows Phone for at sammenligne resultaterne. Der testes og indsamles kun data fra enkelte specifikke mobile enheder med Android styresystem. Der forsøges ikke at ramme et bredt og dækkende udvalg af kendte enheder. Både backend og apps udarbejdes kun til et prototype niveau, som er tilstrækkeligt til at muliggøre de opstillede tests og dataindsamlinger. Fastlæggelse af brugerens position kan gøres på forskellige måder af den mobile enhed. Der er forskel i ressourceforbruget og præcisionen for disse forskellige fremgangsmåder. Vi forventer ikke at arbejde meget med optimering af denne parameter, men vælge en fast metode for at kunne fokusere på selve dataindsamlingsproblemstillingen. 7

3. Metode Vi vil arbejde ud fra en agil og scrum-baseret proces, hvor vi løbende vil tilpasse arbejdet ud fra de delkonklusioner, erfaringer og refleksioner, som vi gør os undervejs. Hermed sikres, at vi bevarer fokus på de vigtige områder af problemstillingerne, da vi konstant vurderer vores prioriteringer. Overordnet set vil vi udføre disse opgaver: Fremfinde relevant litteratur og baggrundsartikler omkring dataindsamling fra mobile enheder, sådan at vi kan præsentere emnet på fornuftig vis. Udvikle en simpel backend, som kan modtage positionsdata via både HTTP og WebSockets protokoller og gemme disse data i en relationel database. Udvikle de tidligere beskrevne applikationer til direkte dataindsamling. Udvikle et mellemlag, som kan bruges til at optimere dataoverførsel og ressourceforbrug gennem forskellige teknikker og logikker. Opstille kvantitative tests for forskelligt ressourceforbrug (batteri og netværk), som har statistisk gyldighed til at kunne give resultater, som kan bruges til en fornuftig konklusion på de sammenligninger og hypoteser, som vi skal afprøve. Udføre de opstillede tests og bruge de indsamlede data til analyse og konklusion. 8

4. Baggrund og relateret arbejde I dette afsnit præsenteres teori og resultater fra litteraturen omkring energiforbrug i forbindelse med dataoverførsler på mobile enheder. Under relateret arbejde præsenteres andre tilgangsvinkler til problemstillingen omkring optimering af energiforbrug på mobile enheder. Teorien i sektion 4.1 til 4.5 er gengivet ud fra [5], som har en meget grundig gennemgang af allokeringen af radio resourcer i 3G netværk. Det er samme undersøgelser og teori, som også danner basis i [6] og [7]. 4.1 3G netværk Sammenlignet med WiFi, så opererer 3G netværk under større radio resource begrænsninger. For at udnytte de begrænsede resourcer optimalt, så arbejder 3G netværk, som f.eks. det udbredte UMTS (Universal Mobile Telecommunications System) netværk, med en radio resource control (RRC) state machine, som bestemmer radio resource brugen og dermed har stor indflydelse på enhedens energiforbrug og brugeroplevelse. I front af UMTS netværket er der Radio Network Controllers (RNC) enheder, som kontrollerer en samling af base stations (antenner), som de mobile enheder forbinder sig til. I RNC enheden er implementeret logik, som håndterer funktioner såsom skedulering af pakker, radio resource kontrol og handover kontrol. Det er dermed RNC enheden, som styrer RRC state machine på den enkelte mobile enhed, når enheden er forbundet til UMTS netværket. 4.2 RRC state machine I RRC protokollen er der en state machine tilknyttet hver enkelt mobile enhed. Denne state machine har typisk tre tilstande, som enheden kan befinde sig i. Nedenstående figur 4.1, som er taget fra [7] side 323, illustrerer disse tilstande og flowet imellem dem. Figur 4.1 RRC State Machine fra [7] side 323 De tre tilstande har disse karakteristika: IDLE. Det er default tilstanden, når en mobil enhed tændes. Enheden har endnu ikke oprettet 9

en RRC forbindelse til en RNC enhed, så der er ingen radio resource allokeret, og enheden kan ikke overføre eller modtage data. CELL_DCH. Der er etableret en RRC forbindelse og enheden har typisk fået allokeret dedikerede kanaler til download og upload. Denne tilstand tillader enheden at udnytte radio resourcerne fuldt ud til overførsel af data. I denne tilstand kan enheden tilgå HSDPA/HSUPA (High Speed Downlink/Uplink Packet Access) muligheder, hvis infrastrukturen tillader det. CELL_FACH. Der er etableret en RRC forbindelse, men enheden har ikke fået allokeret en dedikeret kanal til overførsel af data. Istedet må enheden nøjes med at benytte delte kanaler med lave hastigheder, som typisk er mindre end 15 kbps. FACH tilstanden er designet til applikationer, som kræver en meget lav overførselshastighed for data. Denne tilstand bruger væsentligt mindre radio resourcer end DCH tilstanden. RRC tilstanden har stor indflydelse på enhedens energiforbrug. I IDLE bruges så godt som ingen energi fra radio interfacet, mens DCH forbruger 50% til 100% mere radio energi end FACH. Energiforbruget er rimeligt stabilt i den enkelte tilstand uafhængigt af hastigheden på dataoverførslen. Endvidere bliver RRC tilstanden vedligeholdt både på den mobile enhed og på RNC enheden. De to enheder er altid synkroniseret via kontrol kanaler, undtaget i forbigående eller fejlbehæftede situationer. 4.3 Overgange i RRC tilstande Overgange mellem de forskellige RRC tilstande styres af logikken i RRC state machine. Hvis enheden er i IDLE tilstand, så udløses en forfremmelse til FACH eller DCH af brugeraktivitet, som kræver dataoverførsel. Forfremmelse fra FACH til DCH sker, når Radio Link Controller (RLC) buffer størrelsen (data, som ligger i kø for at blive overført) overstiger et fastsat niveau. Degradering fra DCH til FACH eller FACH til IDLE sker på baggrund af to forskellige timers, som er styret af RNC enheden. Disse timers sørger for, at efter et givent tidsrum uden radio aktivitet, så degraderes tilstanden. Ved fornyet aktivitet indenfor timer intervallet, så resettes intervallet til det fastlagte antal sekunder, så hvis der er fortsat radio aktivitet med en frekvens, som er mindre end dette antal sekunder, så kan tilstanden forblive i f.eks. DCH i lang tid. Forfremmelser er dyrere end degraderinger. Specielt er der forbundet en lang ramp up latency med forfremmelser på op til 2 sekunder, hvor der sendes kontrol beskeder mellem den mobile enhed og RNC enheden. Stor brug af forfremmelser øger arbejdsbyrden for RNC enhederne og forringer brugeroplevelsen pga. forsinkelser, specielt for korte dataoverførsler. 4.4 Tail effekt og trade-off Som det fremgår af 4.3, så forbliver den mobile enhed i DCH eller FACH tilstanden i et stykke tid efter afsendelsen af data, også selvom der ikke umiddelbart afsendes yderligere data. Dette kaldes tail effekt, hvis der ikke kommer yderligere afsendelse af data i denne state, og betyder, at der forbruges høj radio resource energi i dette tidsrum, selvom enheden faktisk ikke bruger radio kommunikation. Så f.eks. hyppige afsendelser eller modtagelser af små mængder data kan forbruge meget mere energi, end det umiddelbart forventes. En formindskelse af tail tiden vil nedsætte energiforbruget på den mobile enhed. Men vil samtidig forøge antallet af tilstandsovergange, sådan at brugeroplevelsen formindskes (via ventetid på handshake mellem den mobile enhed og RNC enheden) og arbejdsbyrden for RNC enheden forøges. Tilsvarende vil en forøgelse af tail tiden forøge energiforbruget på den mobile enhed, men vil forbedre brugeroplevelsen og formindske arbejdsbyrden på RNC enheden. Varigheden af tail tiden er fastsat af den enkelte netværksudbyder. Og er sikkert valgt ud fra 10

overvejelser omkring dette trade-off mellem energiforbrug og brugeroplevelse. 4.5 Udledning af state machine Nedenstående tabel i figur 4.2, som er taget fra [5] side 139, viser udledte parametre omkring RRC state machine og energiforbrug for to store netværksudbydere foretaget i november 2009. Figur 4.2 Udledte RRC parametre fra [5] side 139 Tallene er udledt ved eksperimenter på mobile enheder, som er baseret på algoritmer til at beregne værdierne ud fra data fra telefonen (tcpdump traces). Efterfølgende er tallene så verificeret via direkte målinger på den mobile enhed med specielt måleudstyr (voltmeter m.m.), som bekræftede gyldigheden. Som det fremgår af tabellen, så er implementeringen af RRC state machine foretaget forskelligt for de to udbydere. 4.6 Relateret arbejde Her præsenteres andre tilgangsvinkler til at minimere energiforbruget ved brug af 3G netværk for mobile enheder. 4.6.1 TailEnder I [2] foretages først undersøgelser og målinger af energiforbruget i forbindelse med at overføre data over henholdsvis 3G, GSM og WiFi netværk. For 3G netværk opstilles den samme RRC state machine, som er beskrevet i de foregående sektioner. Målingerne viser, at op til 60% af energiforbruget er spildt i DCH state (tail effekt), efter at selve dataoverførslerne er afsluttet. Samtidigt viser målingerne, at for WiFi, så er der et forholdsvist stort overhead forbundet med at oprette forbindelsen, mens dataoverførslerne herefter er væsentligt mere effektive end ved 3G for alle data størrelser. På baggrund af de fundne resultater, så opstilles en protokol (TailEnder), som kan minimere energiforbruget for 3G netværk. Udgangspunktet for protokollen er, at mange af de 11

applikationer, som afvikles på mobile enheder kan inddeles i to kategorier: 1) applikationer, som kan tåle forsinkelser, og 2) applikationer, som kan drage fordel af prefetching. Typiske eksempler på applikationer, som kan tåle en mindre forsinkelse er e-mail, feeds og software opdateringer. Prefetching kan typisk gavne applikationer, som web browsing og søgning. Teknikken til at optimere de applikationer, som kan tåle en forsinkelse, er at skedulere dataoverførslerne, sådan at den totale tid i DCH state formindskes. Hermed formindskes tail effekten og det samlede energiforbrug. Der opstilles en algoritme, som kan håndtere denne skedulering ud fra faste max deadlines for de enkelte requests for dataoverførsel. Ved prefetching bestemmes på heuristisk vis det optimale antal dokumenter at prefetche (f.eks. 10 dokumenter ved search). Ideen er, at den ekstra energi, som er forbundet med at prefetche dokumenter, som brugeren måske ikke vælger at åbne, bliver opvejet af den større besparelse som indtræffer, når brugeren vælger at følge et link til et af dokumenterne, som er prefetchet. I dette tilfælde spares hele tail effekten, da der ikke er brug for en ny dataoverførsel. Og da energiforbruget ved selve dataoverførslen er væsentligt mindre end tail effekten, så kan det gennemsnitlige energiforbrug faktisk minimeres med denne teknik. Besparelsen er beregnet på baggrund af statistik fra Microsoft omkring brugeradfærd i forbindelse med søgning. Ud fra en modelbaseret simulering påvises, at TailEnder kan give besparelser mellem 35% og 52% for givne applikationstyper. TailEnder protokollen er naturligt egnet til at blive implementeret i styresystemet på mobile enheder, da der skal optimeres datatrafik fra flere applikationer. Ved at stille et simpelt API til rådighed, hvor applikationer kunne angive deres tolerance for forsinkelser, så ville det være simpelt for applikatoner at udnytte protokollen. 4.6.2 TOP (Tail Optimization Protocol) I [6] arbejdes som ved TailEnder også med at udvikle en protokol, som kan ligge mellem applikationerne og nerværkslaget. TOP gør brug af en teknik, som kaldes Fast Dormancy. Denne teknik gør det muligt for den mobile enhed at sende et signal til det mobile netværk, sådan at netværket med det samme lukker for alle radio resourcer. Hermed kan tail effekten undgås. Fast Dormancy er indbygget i den fleste moderne smartphones, mens netværksunderstøttelsen varierer fra udbyder til udbyder. For at kunne udnytte Fast Dormancy optimalt, så kræver TOP, at den enkelte applikation sender det forventede interval inden næste dataoverførsel til TOP, når en dataoverførsel er slut. Ud fra en algoritme sørger TOP så for at beregne, hvornår det er optimalt at sende en Fast Dormancy besked til netværket, ud fra de til enhver tid modtagne intervaller fra alle aktive applikationer. Eksperimentelle resultater baseret på rigtige traces viser, at ved en fornuftig præcision under forudsigelsen af intervallet til næste dataoverførsel, så kan TOP gennemsnitligt spare omkring 15% på energiforbruget ved at reducere tail tidsrummet med 60%. For specifikke applikationer, såsom multimedie streaming, så kan der opnås væsentligt større besparelser på op imod 60% af energiforbruget. For at kunne implementere TOP i praksis, så kræves det, at applikationerne på fornuftig vis kan estimere intervallet til næste dataoverførsel. For mange applikationer er dette nok ikke realistisk, samtidigt med, at det stiller større krav til udviklerne af applikationerne. Og samtidigt er det et krav, at Fast Dormancy bliver implementeret på mobile enheder og netværk. 4.6.3 Bartendr I [8] arbejdes med udgangspunkt i signalstyrken. Det påvises empirisk, at energiforbruget for 12

radioen i en mobil enhed afhænger direkte af signalstyrken, og at overførselshastigheden også afhænger direkte af signalstyrken. Det kan koste seks gange så meget energi per bit at kommunikere, når signalet er svagt, som når signalet er stærkt. Med baggrund i dette resultat, så udarbejdes Bartendr, som er et system til at minimere energiforbruget ved at skedulere kommunikation i perioder med stærkt signal. Bartendr bruger tidligere gemte tracks med signalstyrke langs ruter, som brugeren ofte benytter, til at forudsige den aktuelle og den fremtidige signalstyrke. Herved undgås at bruge energi til at bestemme signalstyrken. Ud fra disse forudsigelser opstilles algoritmer, som bestemmer skeduleringen af kommunikationen, sådan at der såvidt muligt overføres data, når signalet er stærkt. For applikationer, som kan tåle forsinkelse (f.eks. sync af email), så bruges en algoritme, som forsøger at finde intervaller, hvor signalstyrken er større end en given tærskel. Disse intervaller udnyttes så til kommunikation. For applikationer, som streamer dataoverførsel, så bruges en algoritme, som benytter sig af dynamisk programmering til at finde det optimale skema for dataoverførslerne. Denne algoritme tager også hensyn til tail effekten ved brug af radio resourcer på 3G netværk. Bartendr evalueres ved omfangsrige simulationer baseret på målinger af signalstyrke og overførsler, som er dannet ved rigtige kørsler langs bestemte ruter i Bangalore og Washington. Disse simulationer viser energibesparelser på op til 10% for sync applikationer, mens der ved streaming applikationer kan spares op til 60%. De praktiske muligheder for anvendelse er sandsynligvis begrænset, da det kræver, at brugerne bevæger sig langs de samme ruter ofte, før systemet giver nogen gevinst. 4.6.4 Andre bidrag I [3] undersøges og analyseres aktuel trafik fra en brugerskare med mobile enheder. Der opstilles brugsmønstre, samtidigt med at der kommes med flere forslag til optimering af datatrafikken. F.eks. at en reduktion af sleep timers, som er tiden, hvor enheden forbliver i DCH state, inden der skiftes til IDLE, vil kunne reducere energiforbruget med 35% ud fra den aktuelt analyserede trafik. I [4] foretages en dybdegående analyse af mange forskellige faktorer, som har indflydelse på performance af applikationer på mobile enheder. Ud fra disse analyser peges på områder, hvor netværksudbydere, smartphone fabrikanter og applikationsudviklere kan foretage optimeringer af de nuværende tilstande. Ved dynamisk at skifte mellem 3G netværk og åbne WiFi netværk, ud fra opstillede kriterier, så påvises i [1], at brugen af 3G netværk kan reduceres med 45% indenfor en forsinkelsestolerance på 60 sekunder. Resultatet er opnået gennem simulationer på aktuelle traces målt i tre større amerikanske byer. Da antallet af åbne WiFi netværk i større byer sandsynligvis vil forøges i fremtiden, så kan der være fornuftige perspektiver i denne tilgangsvinkel. 13

5. Værktøjer Fuldstændig præcis måling af energiforbrug på en mobil enhed kræver brug af specielt måleudstyr, såsom voltmeter m.m. [9]. Samtidigt skal der analyseres indsamlede data fra enheden (tcpdump traces), sådan at energiforbruget kan allokeres til de forskellige applikationer, som kører på enheden på testtidspunktet. Da dette er yderst besværligt og tidskrævende, så har vi istedet valgt at indsamle data ved hjælp af to værktøjer, som udleder energiforbruget ud fra algoritmer, profilering og antagelser, samtidigt med, at allokeringen af energiforbruget til de forskellige applikationer er indbygget. Af samme grund har det heller ikke været muligt for os at indbygge målinger af energiforbruget direkte i vores applikationer. Nedenfor beskrives de to værktøjer, som vi har brugt til indsamlingen af data: 5.1 ARO ARO (Application Resource Optimizer) er et værktøj, som er udviklet af AT&T og stillet gratis til rådighed gennem deres developer program [10]. Det er baseret på teorien, som er beskrevet i [7]. Ud fra teorien omkring RRC state machine og de forskellige radio tilstande, så opstilles en algoritme, som ud fra opsamlede data traces fra en smartphone kan identificere, hvilke tilstande, som RRC state machine har været i undervejs i trace forløbet. Denne algoritme er nødvendig, da der ikke er noget interface tilgængeligt på smartphones, som kan give denne information direkte. Ved validering af algoritmen mod en sideløbende fysisk måling på smartphonen og en udledning af tilstande ud fra disse målinger, så opnås solide resultater. Ovenpå denne teknik til udledning af RRC tilstande, så er bygget et analyseværktøj, som ud fra de opsamlede data traces kan analysere både energiforbruget og årsager til forbruget. Dette sker ved at kigge på både HTTP og TCP trafik, samtidig med at der undersøges for mindre dataoverførsler for om muligt at identificere flaskehalse såsom periodiske overførsler. Ved brug af analyseværktøjet dannes en detaljeret rapport, som påpeger mulige forbedringer til designet af applikationen, samtidigt med, at der vises statistik for energiforbrug, dataoverførsel og en del andet. ARO er desværre ikke tilgængeligt til fysisk installation på egne mobile enheder, da applikationen kræver root access på enheden. Og hvis man rooter sin enhed, så mister man garantien fra udbyderen, så derfor har AT&T (som jo er udbyder) valgt ikke at lægge applikationen ud til almindelig download. Så derfor er vores brug begrænset til, at værktøjet kan afvikles sammen med den emulator, som følger med Android SDK et fra Google. Fra ARO programmet kan startes en opsamling af et data trace fra emulatoren. Herefter afvikles applikationen på emulatoren, hvorefter data tracet kan overføres til ARO værktøjet, hvor der via analysedelen dannes en rapport pga. af tracet. Så der mangler de fysiske varianser fra et aktuelt device, men det er muligt at indlæse de RRC state machine parametre, som man ønsker at bruge til analysen af data tracet. 5.2 PowerTutor PowerTutor er en app, som kan downloades fra Android Market [11] og installeres på en aktuel Android enhed. Den er baseret på teorien, som er beskrevet i [9]. Der opstilles og udledes energi modeller for aktuelle smartphones ved fysisk at måle energiforbruget (vha. voltmeter), mens forskellige komponenter på enheden undersøges. Mens en komponent (CPU, LCD, GPS, WiFi, Radio, Audio) undersøges, så holdes alle andre komponenter fast i samme tilstand. Ud fra forskellige observationer og antagelser udarbejdes så en model, hvorved energiforbruget kan bestemmes ud fra den aktivitet, som udføres. Ved 14

undersøgelse af energiforbruget ved radio resourcer, så er anvendt samme teori og antagelser omkring state machine og tilstande, som er beskrevet i afsnit 4. Efterfølgende er så udført validering af modellen ved at afvikle forskellige applikationer på enheden og så sammenligne de aktuelle fysiske målinger af energiforbruget med de værdier, som modellen har udledt. Denne validering har vist meget lave afvigelser mellem de målte og de udledte værdier, specielt ved målinger over længere tid (under 0,8 % gennemsnitlig afvigelse med et max på 2,5 %). Der er udarbejdet modeller for forskellige smartphones, hvilket gav det resultat, at der er meget små afvigelser mellem forskellige smartphones af samme model, mens afvigelserne er store imellem smartphones af forskellige modeller. Som et alternativ til at udlede energimodellen ud fra fysiske målinger med voltmeter, så er der dannet energimodeller ud fra målinger med den indbyggede batterispændings sensor. Modellerne omkring de enkelte komponenter er udarbejdet på samme måde som i den første version med fysiske målinger. Herefter er spændingsmålingerne omsat til energiforbrug ud fra kendskab til batteriets afladningsmønster. Dette kræver, at udarbejdelsen af modellen kører over et længere tidsrum, da der skal opnås kendskab til batteriets afladningsmønster. Ved valideringen af den batteribaserede model, så er opnået en max afvigelse på 4,1 % ved målinger over længere tid. Den batteribaserede energimodel har dannet baggrund for udarbejdelsen af den app, som er lagt ud til fri benyttelse på Android Market. Gennem et pænt interface vises energiforbrug for de forskellige applikationer, som kørte på smartphonen i måletidsrummet. Energiforbruget er delt ud på de forskellige komponenter i energimodellen. Den store fordel ved denne app er, at man fuldstændig slipper for at bruge fysisk måleudstyr. Dette koster så lidt kompensation i form af manglende præcision i målingerne, men de generelle trends og variationer i energiforbruget vil stadigvæk træde frem. For interesserede, så er source koden til app en tilgængelig på GitHub [12]. 5.3 Præcision og begrænsninger Begge de ovenfor beskrevne værktøjer til indsamling af data omkring energiforbrug har visse begrænsninger omkring præcisionen af målingerne. For begge gælder, at der mangler profilering af værktøjet ud fra de aktuelle smartphones, som vi bruger til målingerne. For ARO gælder, at de aktuelle RRC state machine parametre ikke kendes, men istedet indlæses med nogle standardværdier. For PowerTutor gælder, at der mangler dannelse af en energímodel og batterimodel ud fra de aktuelle smartphones. Istedet bruges standardværdier, som er dannet ved profilering af andre smartphones. Vi mener, at denne manglende præcision kan forsvares, da vi ikke er specielt interesserede i værdien af det aktuelle energiforbrug, men istedet er tilfredse med en relativ værdi, som vi kan sammenligne med målinger, hvor vi ændrer på opsætningen af vores testapplikation. Så derfor vil de angivne Joule værdier for vores målinger ikke nødvendigvis være de aktuelt korrekte, men istedet svare til værdier, som ville være opnået med samme opsætning af applikationen på en anden smartphone. Men da målingerne stadigvæk vil være konsistente ud fra applikationsopsætningen, da de er baseret på de opsamlede data traces, så kan de bruges til at sammenligne det relative energiforbrug for de forskellige applikationsopsætninger. 15

6. Analyse og design For at verificere vores opstillede hypoteser, så har vi udviklet tre applikationer til afvikling på Android smartphones. Samtidig har vi implementeret en backend til at modtage data fra applikationerne på en webserver. I dette afsnit beskrives vores analyse af problemstillingerne fulgt af en gennemgang af designet og implementeringen af løsningerne. 6.1 Analyse Som beskrevet i afsnit 5, så gav artiklerne [7] og [9] hurtigt det svar, at vi skulle bruge de to beskrevne værktøjer, ARO og PowerTutor, til at foretage vores målinger af energiforbrug med. Hermed blev det også klart, at vi ikke kunne indbygge afviklingen af vores test og opsamlingen af målingerne i selve applikationerne, men istedet var nødt til at afvikle applikationerne og foretage målingerne af energiforbruget manuelt. Derfor var det vigtigt at designe applikationerne således, at det blev nemmest muligt at afvikle vores tests. Det har vi gjort ved at lave forskellige felter til indtastningen af opsætningerne for den enkelte test, sådan at vi nemt har kunnet variere de parametre, som vi skulle teste på. 6.1.1 Teknologier Det har hovedsageligt været kendte teknologier, som vi skulle bruge til at implementere vores løsninger med. Den eneste undtagelse er WebSockets, som er beskrevet nærmere i næste sektion. Derudover er vi rimeligt fortrolige med Java, JavaScript og HTML, så vi var fortrøstningsfulde med at skulle udvikle AJAX og Android applikationer, selvom vi ingen tidligere erfaring havde med Android udvikling. Der er store mængder materiale omkring Andriod udvikling tilgængeligt på webben, så det er hurtigt at komme igang med den første prototype. 6.1.2 WebSockets I analysefasen valgte vi at kigge en del på WebSockets teknologien, da vi ikke var så fortrolige med denne relativt nye teknologi og derfor havde brug for mere viden. Samtidig skulle vi også afklare, hvordan vi i praksis kunne implementere en backend server, som gav mulighed for at benytte WebSockets protokollen. På server siden forsøgte vi først at bruge Apache Tomcat, som ikke umiddelbart kan håndtere WebSockets protokollen. Selvom vi fandt flere indlæg i forskellige forums omkring at udvide serveren til WebSockets, så var ingen af forslagene anvendelige i praksis. Derfor blev konklusionen efter at have læst forskellige folks erfaringer med WebSockets servere, at de bedste alternativer på java siden er Jetty og jwebsocket, mens node.js er et rigtig godt alternativ med server-side JavaScript. Jetty serveren så umiddelbart mest genkendelig ud for os, så den valgte vi at bruge. For at synliggøre den store forskel WebSockets tilbyder, ikke mindst på kommunikation med mobile enheder, så beskriver vi, hvad en WebSockets forbindelse er, og sammenligner den med den traditionelle request/response model, som traditionelt benyttes i HTTP protokollen. Beskrivelsen og sammenligningen er baseret på artiklen i [14], som også indeholder yderligere information omkring WebSockets. En WebSockets forbindelse er en fuld-duplex forbindelse mellem en webbrowser og en webserver. Dette betyder ganske enkelt, at efter en forbindelse er etableret, så forbliver den åben, så længe hverken klienten eller serveren eksplicit lukker forbindelsen. Med en fuld-duplex forbindelse er kommunikationen mellem serveren og klienten 2-vejs, og det er muligt at sende 16

og modtage på en og samme tid. Før Websockets har andre metoder, så som polling, long polling, og streaming, været relevante, men alle med seriøse drawbacks med hensyn til scaling og latency. Enten er det for kostbart (i form af bytes) at opretholde en live forbindelse til et stort antal klienter (scaling), eller også er forsinkelsen af dataudveksling for stor (latency). Her følger et kort og konkret ekspempel på den enorme forskel mellem polling metoder og websocket metoden. Når en forbindelse oprettes fra en klient browser til en server starter klienten med at sende header information til serveren med diverse data. Hvilke data der bliver sendt er ikke vores primære focus i dette eksempel, men det er mængden af data i headeren derimod. Et eksempel på en HTTP request header: Og på tilbagevejen, fra serveren til klienten, kunne en HTTP response header se sådan ud: Hvis vi tæller det samlede antal karakterer i de ovenstående to headers, så lander vi på 871 17

karakterer. Og dette inkluderer ingen applikationsdata. Med WebSockets åbnes en forbindelse til serveren, hvorefter små frames med applikationsdata leveres til eller fra serveren med en header på kun 2 bytes. Ved mange forsendelser af data, så kan forskellen mellem 2 bytes og 871 bytes hurtigt blive signifikant. Og hvis der er tale om et setup, hvor mange klienter er connected til serveren, så bliver forskellen rigtig stor. Samtidig med, at WebSockets muliggør størrere integration mellem klient og server, da der kan initieres dataoverførsel fra begge enheder, hvilket åbner op for at udnytte teknologien i mange nye applikations- og forretningsdomæner. 6.2 Design Vi har valgt et klassisk 3-lags design af vores system med en relationel database i bunden, en Java webserver i midten til at afvikle web applikationer og modtage data, og endelig tre forskellige klienter til at sende data til serveren. Med hensyn til design og organisation af programmeringskoden, så har vi valgt at følge modelview-controller (MVC) mønstret. Den klare separation af de tre kodelag gør videre udvikling og vedligehold nemmere, og betyder endvidere, at den generelle kodeorganisation bliver lettere. Samtidigt er Android SDK et som udgangspunkt sat op til, at man skal bruge MVC, når man udvikler native apps. Så derfor var det meget oplagt at bruge dette mønster. I vores implementation er modellen den record, som gemmes i databasen på vores backend, mens vi har forskellige views i de tre applikationer til at indtaste parametre med. Controlleren er så den logik i applikationen, som håndterer timingen og al kommunikation med serveren, efter at testen er startet. Vi har valgt at lægge al logik på dette niveau, da det er klienten, som skal styre al indsamlingen og afsendelsen af data med de ønskede intervaller. Dette betyder også, at vores servlet på serveren egentlig kun fungerer som et transportlag, som sørger for at gemme de tilsendte data ned i den relationelle database. Der er ingen egentlig logik indbygget her udover kendskab til modellen. Som beskrevet i sektion 6.1.2 omkring analyse, så har vi valgt en Jetty server som vores webserver. Vores umiddelbare preference var ellers at bruge Apache Tomcat serveren og dermed udnytte den viden, vi har tilkæmpet os på tidligere fagpakker på AU. Men dette kunne desværre ikke lade sig gøre. Vi valgte at bruge en Java webserver (istedet for alternativet node.js og JavaScript), da vi så trods alt kunne udnytte nogle af vores tidligere erfaringer, hvor vi har benyttet Java og servlet teknologi på serversiden. Persistence af lokationsdata fra Jetty serveren foregår igennem Java objekter, som direkte reflekterer tabeller i den relationelle database. Som relationel database har vi valgt MySQL, da det er en solid og fornuftig open-source database, som vi har gode erfaringer med fra tidligere brug. Ud fra vores opstillede hypoteser, så består klientdelen af vores system af tre forskelliger applikationer. En native app til afvikling på Android styresystemet og to web-applikationer, som kan tilgås via browseren på en smartphone, og som ved hjælp af henholdsvis AJAX teknologi og WebSockets protokollen, kan indsamle lokationsdata og sende disse data ind til serveren. Den native app er kodet i Java via Android SDK et, mens de to web-applikationer hovedsageligt er implementeret via JavaScript, da både AJAX og WebSockets naturligt håndteres af JavaScript. Det endelige visuelle design af vores webapplikation såvel som vores native Android applikation er blevet re-designet et par gange, hvilket er beskrevet i flere detaljer i den følgende sektion. 18

6.3 Implementation For at sammenligne energiforbruget ved direkte indsamling af data fra en native app med energiforbruget ved en webapp har vi udviklet tre testapplikationer. Teknologier som er brugt i vores løsninger er: HTML5, CSS, jquery, jquery Mobile, JavaScript, Jetty webserver, Eclipse IDE, Java, XML, MySql database, PhoneGap, Android programmerings platformen, Sqlite og Websocket teknologi. I det efterfølgende beskrives implementeringsforløbet og udviklingen af vores applikationer, og vi demonstrerer samtidigt, hvor og hvordan de forskellige teknologier er brugt. Figur 6.1 AJAX web applikation Figur 6.2 WebSockets applikation Figur 6.3 Native Android app 6.3.1 AJAX web applikation Vores Ajaxtester web applikation er bygget med jquery Mobile og består af en enkelt web side. jquery Mobile er et framework, som er udviklet til at gøre webudvikling til mobile enheder nemmere og mere optimalt med hensyn til dataoverførsel og UI design. Det er lykkedes os at lære en hel del omkring frameworket, og vi er begge opsat på at bruge det igen til fremtidige opgaver. På app en kan man indtaste testens varighed og antal sekunder mellem hver dataoverførsel til serveren (se figur 6.1). Når brugeren trykker på Send knappen, så bruges JavaScript funktionerne settimeout() og setinterval() til at afvikle AJAX kald til serveren med det angivne interval: 19

Mens testen kører, bruges javascript frameworket jquery til at håndtere AJAX kaldene. På den måde sikrer vi os cross-browser funktionalitet og nem implementering. Lokationsdata overføres i JSON format: På Jetty serveren modtages lokationsdataene af en servlet, hvor vi først renser data for potentielle karakterer, som kan bruges til SQL-injection og dernæst instantierer en GeoPositionEntity model, som gemmer dataene i MySQL databasen. Til sidst returneres et JSONObject til klienten: 6.3.2 WebSockets applikation (version 1) Vores HTML5 WebSocketst tester front-end er kodet på samme måde som vores AJAX webapplikation beskrevet i 6.3.1, altså med jquery Mobile. Det samme gælder for håndtering af testvarighed og timingen of kommunikationen med serveren. 20

Selve kommunikationen med serveren er der, hvor koden er forskellig. Vi begynder med at klienten starter etableringen af en WebSockets forbindelse til serveren, hvorefter vi definerer tre callback metoder specificeret i WebSockets API et: onopen, onmessage, og onclose: På klient siden startes kommunikationen til Jetty serveren som sagt med, at der etableres en WebSockets forbindelse. På web serveren er WebSockets teknologien implementeret på en sådan måde, at den er integreret ind i Jettys HTTP server. HTTP serveren lytter som normalt efter kommunikation fra klienter, og hvis det er nødvendigt, så opgraderer Jetty forbindelsen til en WebSockets forbindelse. Et hurtigt kig i FireBug viser denne succesfulde opgradering: På server siden håndteres alle forbindelser af en servlet. Denne servlet står for opkobling 21

(handshake), administration af klienter, og persistence af lokationsdata. WebSockets protokollen definerer opkoblingen til serveren som en slags HTTP handshake. Dette gør det muligt for en standard webserver at fortolke/håndtere opkoblingen og skifte til WebSockets protokollen, hvis klienten ønsker at åbne en fuld-duplex WebSockets forbindelse til serveren. Med hver ny forbindelse som ønskes, laves et nyt GpsLocationWebsocket object. Vi gemmer så denne nye forbindelse i en collection (Set), så vi kan finde den frem senere, hvis vi skulle være interesseret i at sende en besked ud til samtlige brugere, som er forbundet. WebSocket klassen er en intern klasse, hvor vi definerer de tre nødvendige WebSockets metoder på server siden: Vi sætter også alle forbindelsernes maxidletime til 2 minutter, dobbelt så lang tid som den længste idle tid vi bruger i vores målinger (1 minut). Det viste sig desværre, at Androids browser ikke har WebSockets teknologien indbygget endnu, så version 1 af vores WebSockets Tester applikation fungerede ikke i denne browser. Vi testede også vores applikation på Opera Mini og Firefox til Android, men heller ikke nogen af disse mobile browsere har indbygget understøttelse for WebSockets teknologien endnu. Så for at kunne udføre vores test med WebSockets teknologien var vi nødt til at prøve en anden tilgangsvinkel, som er beskrevet i næste sektion. 22

6.3.3 WebSockets applikation (version 2) Version 2 af vores WebSockets applikation er en native Android app, som er bygget med Eclipse ved hjælp af PhoneGap. På grund af, at vi ikke havde nogen erfaring med at bygge Android applikationer før denne fagpakke, så var PhoneGap et naturligt udviklingsframework for os, da PhoneGap gør det muligt at bruge webteknologier til at bygge native Android applikationer (og også native applikationer til alle andre mobile platforme). Så med PhoneGap integreret i Eclipse begyndte vi at prøve os frem med nogle forskellige tutorials. Version 2 af WebSockets applikationen er bygget op omkring Androids WebView object og Androids Activity object. Desuden bruger vi et lille 3rd-parti API med PhoneGap-optimerede klasser fra Strumsoft, da PhoneGap ikke har indbygget support for Websocket teknologien endnu. En PhoneGap applikation bruger som UI en HTML fil, og i vores tilfælde er det index.html. Index filen bliver aktiveret fra et Activity object af Android frameworket når programmet åbnes af Android styresystemet. Selve brugerfladen er programmeret ud fra samme fremgangsmåde som beskrevet ovenfor i 6.3.2 (version 1), og den er illustreret i figur 6.2. Årsagen til at version 2 virker på Android er, at den nye version ikke er afhængig af Androids interne web browser. Som beskrevet tidligere, så starter klienten etableringen af en WebSockets forbindelse til serveren, men i stedet for at overlade denne server-opkobling til web browseren, så overlades den istedet til Strumsofts klasse WebSocketFactory. Efter et nyt WebSocket object er instantieret, og forbindelsen til serveren er klar, så returnes WebSockets forbindelsen til JavaScript. Herefter bruger vi forbindelsen til at sende lokationsdata til serveren i fuld-duplex. På serveren sker tilkoblingen, administrationen af forbindelser, og behandlingen af data med en Servlet, på samme vis som beskrevet i 6.3.2 (version 1). På grund af, at Websocket teknologien er ny og derfor ikke integreret i Andoid platformen endnu, så har udviklingsforløbet af denne applikation været meget krævende både med hensyn til tid og tålmodighed. Med det sagt, så ser vi også helt klart et kæmpe potentiale i denne teknologi, og vi har allerede et nyt projekt planlagt, som gør brug af Websockets. 6.3.5 Native Android-JSON Applikation Vejen til vores første ægte Android app, som ikke var bygget med PhoneGap, var længere end vi havde regnet med. Den kan deles op i flere faser: Opsætning af udviklingsmiljø, læse, studere og følge mange online tutorials, få overblik over hvilken funktionalitet Android API et stiller til rådighed, som vi kunne bruge, og hvordan man får adgang til disse, og endelig selve udviklingen af app en. Vi vil nu beskrive udviklingforløbet af selve Android app en. Alle Android applikationer har som minimum en activity klasse, som er associeret med 23

et layout (skærm). Den første version af vores app er bygget op omkring to activity klasser og to layout. Hoved funktionaliteten i app en er kodet i AndroidJsonActivity klassen og består af opsætning af brugerflade, håndtering af diverse brugerflade-events, såsom knapper og spinner, opsætning af loop og administration af tråd til afvikling og overholdelse af brugerens indtastede testspecifikationer, opsætning af HTTP forbindelse og overførsel af data til Jetty webserveren. Hoved funktionaliteten i UrlActivity klassen er at opsætte brugerfladen til skærm 2 og tilføre nye server-url er til den interne Sqlite database. Vi har efterfølgende valgt ikke at overføre funktionaliteten fra UrlActivity klassen til version 2 af vores app, fordi den er overfødig i forhold til det endelig mål med vores app. Version 1 er en god start på en app, fordi den gav os erfaring med app udvikling til Android og dens interne database, men den har især et problem, som vi følte, at vi var nødt til at løse, før vi kunne kalde det en rigtig Android app. Problemet er, at når vi kører en test, så låses brugerfladen. Og efter en del efterforskning og test stod det klart, at vores test-loop skulle omkodes, da det kører i den samme tråd som brugerfladen. Så vi tog hul på version 2. Version 1 app en og muligheden for at gemme URL s er illustreret i figur 6.4 og 6.5. Figur 6.4 Native Android app version 1 Figur 6.5 Native Android app version 1 Version 2, og den nuværende udgave af vores Android App, er som sagt bygget op omkring AndroidJson aktiviteten og en enkelt skærm (se figur 6.3). Funktionaliteten i denne activity klasse er dog blevet kraftigt udvidet og modificeret i forhold til version 1. Vi starter med at opsætte brugerfladen, som i en Android App er bygget op i en XML fil, hvor man definerer hvilke UI-elementer, som man vil bruge, og layoutet af disse. I toppen af vores brugerflade har vi placeret en progressbar, som det nu er mulig at opdatere, fordi vi bruger 24

separate tråde til henholdsvis kørsel af selve testen og til brugerfladen. Dernæst instantierer/ specificeres to BroadcastReceivers og en LocationListener: [Receivers og listeners i Activity] Det sidste skridt er at registrerere ovenstående hos Andoid styresystemet så vi får opdateringer om status ændringer fra telefonens GPS, batteri/energi level og netværkstype. Hvis vi modtager opdaterede statusdata fra Android systemet, så opdateres brugerfladen i den øverste halvdel af skærmen. Den nederste halvdel af skærmen er hvor brugeren indtaster testvarighed og de to intervaller, hvormed data ønskes gemt i henholdsvis telefonens egen database, og hvor ofte disse data skal overføres til webserverens database. Når testen starter, så indlæses de indtastede parametre fra brugerfladen, og et baggrundsjob sættes op til at køre vores test-loop: 25

Som det kan ses i koden, så bruger vi i version 2 en AsyncTask, som gør det lettere at arbejde med tråde og opdatere brugerfladen med indbyggede metoder. Denne konstruktion har vist sig at være den helt rigtige løsning til vores brugsscenarie. Hvis ingen GPS lokationsdata er tilrådighed, så informeres brugeren med en Toast besked om, at simuleret lokationsdata bliver brugt i stedet. Det næste vi gør, når selve loopet kører, er at gemme lokationsdatane i telefonens Sqlite database. [Kode fra Activity] [Kode fra model hvor data gemmes til lokal db] Efter dataene er gemt i telefonens database tages der stilling til, om det er tid til at overføre data til webserveren endnu. Hvis dette er tilfældet, så hentes al lokationsdata fra telefonens database og overførslen til webserveren startes. Data bliver overført i JSON format: [Kode fra loop i activity] 26

[Kode fra LocationData model viser dataafhentning fra android db og formatering af JSON string til overførsel til webserveren ] Vi har bygget endnu et abstraktionslag, en utility (RequestUtil), som vi bruger til koden til kommunikation med webserveren. Vi begynder med at sætte en HTTP Post request op, og dernæst laves en ArrayList, hvor et namevaluepair bliver sammensat, og hvor valuen er JSON arrayet med alle lokationerne, som ikke tidligere er blevet overført til webserveren. [Kode fra RequestUtil kommunikaiton med webserveren] 27

På webserveren modtages data af en servlet, som gemmer den i en MySQL database: Efter denne action opdateres brugerfladens progressbar, og en ny iteration af testloopet startes, med mindre testvarigheden er udløbet. Inden vi afslutter denne sektion er det vigtigt at inkludere en smule omkring datamodellen i Android app en. Datamodellen består af 3 klasser: LocationData.java, UrlData.java og DatabaseHelper.java. Det er alt, som er nødvendigt i denne version af app en. LocationData.java og UrlData.java reflekterer deres respektive tabeller i Sqlite databasen: 28

Og DatabaseHelper.java er en slags utility- eller hjælpeklasse, som bruges til at sætte en Sqlite database op. I denne klasse definerer vi altså alle de detaljer, som er nødvendige for at Android kan lave den nye database med de ønskede tabeller. Vi definerer også versioneringen af app en i DatabaseHelper filen, da dette gør fremtidige opgraderinger lettere: [Kodefragment fra DatabaseHelper klassen] Ovenstående er er det mest relevante i Android app en. Herudover er der naturligvis en hel del opsætning og housekeeping, som vi ikke har inkluderet her i rapporten. Det kunne for eksempel være selve opsætning af UI-elementer, diverse events, og un registrering af diverse receivers, m.m. 6.3.6 Jetty Webserver og MySql setup på Linux Ubuntu server Vi har brugt version 8 af Jetty serveren som webserver, som sammen med MySQL er installeret på en Linux Ubuntu server. Installering og implementering af vores test applikationer på webserveren var umiddelbart ikke vanskelig, men integrering af applikation specifik logning, datasource opsætning og installering på en Linux server var ikke trivielt for nogen af os. Vi brugte betragtelig tid på at få Jetty, MySql, 29

Log4J, og Linux Ubuntu til at spille sammen. Vores server applikation er bygget op efter model-view-controller modellen. Sourcekoden er organizeret i forskellige packages, alt efter de enkelte filers/klassers formål. Databasemodelen på serveren er yderst simpel. Den består af en enkelt GeoPositionEntity klasse, som extender ActiveRecord klassen. Denne entity reflekterer geo_positions tabellen i database: 30

7. Resultater For de tre direkte indsamlingsmetoder har vi opstillet tests, sådan at vi kan måle batteriforbrug som funktion af indsamlingsfrekvens (tidsrum imellem hver positionsmåling og afsendelse af denne). For mellemlaget har vi opstillet tests, hvor vi kan måle resultatet af at opsamle data med et kort interval, og derefter sende dem til serveren med et væsentligt længere interval. 7.1 Udførelse af eksperimenter Nedenfor er beskrevet, hvordan vi i praksis har udført vores eksperimenter og indsamlet målingerne. 7.1.1 Test setup Vi har brugt de to værktøjer, ARO og PowerTutor, som er beskrevet i sektion 5. Ved måling med ARO er vores applikationer afviklet på en pc med den emulator, som følger med Android SDK, mens applikationerne er afviklet på en Android smartphone ved målinger med PowerTutor. Der er brugt en HTC Desire med Android version 2.3.7 installeret til målingerne. Alle målingerne med smartphone er foretaget fra den samme lokation for at holde signalstyrken så fast som muligt. I alle applikationer bruges ikke den aktuelle position, men istedet sendes en fast hard-coded værdi for at gøre målingerne uafhængige af energiforbruget til at fremfinde den aktuelle position fra GPS eller anden vis. Varigheden af hver test har vi sat til 120 sekunder. Inden starten foretog vi en del testmålinger med andre varigheder, og disse målinger viste, at det overordnede mønster var det samme for alle de varigheder, som vi forsøgte os med. Dog kunne den initielle opstart af radio resourcen (IDLE til DCH state) vægte forholdsvis meget ved alt for korte varigheder, specielt ved lave frekvenser for dataoverførslerne. Da vores primære udgangspunkt har været at undersøge længerevarende indsamlinger af positionsdata har vi derfor valgt en varighed, som er lang nok til, at den initielle opstart ikke vægter nævneværdigt, men samtidig en varighed, som gør det praktisk muligt at foretage målingerne. Der er foretaget målinger for frekvenser mellem 2 og 20 sekunder. Og derefter kun målinger for frekvenser på 30 og 60 sekunder. Det skyldes, at det mest interessante interval er 2 til 20 sekunder, mens målingerne herefter følger et trivielt mønster, som gør, at målingerne for 30 og 60 sekunder er reprænsentative nok til at illustrere mønsteret. 7.1.2 Udførelse af test Den praktiske udførelse af testene og indsamling af måleresultater viste sig at være en meget tidskrævende proces, da ingen af de anvendte værktøjer giver muligheder for automatisering af tests. Så hver eneste måling er resultatet af en manuel afvikling af applikationen efter først at have igangsat en ny måling i værktøjsapplikationen. Og efter afvikling af applikationen i 120 sekunder, så er målingen afsluttet i værktøjsapplikationen, og resultatet registreret i et regneark. Specielt ARO involverer mange manuelle steps, da data collectoren først skal registreres på Android emulatoren, hvorefter tracet skal hentes fra emulatoren efter afvikling af applikationen og endelig skal tracet så loades i data analyzeren til sidst. Alle steps kan udføres vha. af knapper i AROs Java program, men der er stadigvæk noget ventetid involveret efter hvert tryk. Målingerne med PowerTutor følger et mere kontinuerligt flow uden ventetider, men stadigvæk med skift mellem applikation og værktøj. Men som beskrevet i afsnit 5 og i [9], så er det ikke umiddelbart muligt på en simpel måde at udlede energiforbruget, så derfor har vi ikke kunnet indbygge målingerne direkte i vores 31

applikationer, hvilket ellers ville have kunnet gjort indsamlingen af måleresultater væsentligt nemmere og mindre tidskrævende. 7.2 Direkte indsamling af data I denne sektion beskrives vores undersøgelse af energiforbruget i forbindelse med direkte indsamling af data. 7.2.3 Målinger med ARO I figur 7.1 er vist energiforbrug som funktion af frekvensen mellem dataoverførslerne. Der er plottet middelværdierne ind med angivelse af standardafvigelsen. Der er foretaget 3 målinger for hver frekvens. Det lave antal målinger bunder i, at der kun har været en megen minimal afvigelse mellem resultaterne, hvilket skyldes, at ARO kører på en emulator og bruger en fast algoritme og model til at beregne energiforbruget. Derfor har målingerne primært fungeret som kontrol for, at det er den rigtige test, som er udført. Bemærk, at kurverne for Native app og WebSockets er sammenfaldende fra en frekvens på 17 sekunder og fremefter, da alle måleresultaterne i dette interval er fuldstændigt ens for de to applikationer. Figur 7.1 Målinger med ARO 32

7.2.3.1 Opsætning af ARO I ARO burde det i princippet være muligt at stille på en mængde relevante parametre, som styrer den algoritme, som bruges til at beregne energiforbruget ud fra de traces, som er hentet fra emulatorens afvikling af applikationen. Det er angivet i user guiden, og der er en funktionen til at opsætte parametrene. I praksis er det desværre kun muligt at indlæse forskellige prædefinerede profiler, da funktionen til manuelt at ændre på parametrene ikke gemmer ændringerne. Alle de prædefinerede profiler har de samme værdier for de timers, som styrer overgangen mellem de forskellige RRC states, svarende til værdier fra AT&T netværket. De prædefinerede profiler adskiller sig kun på de parametre, som relaterer sig til energiforbruget i de forskellige states. Så derfor fremkommer præcist samme mønster i energiforbruget som funktionen af frekvensen for alle de prædefinerede profiler, bare med forskelligt niveau på kurverne. Det er lidt uheldigt, at det ikke er muligt at stille på parametrene, da det kunne være meget interessant at se og sammenligne kurverne for forskellige opsætninger af timers. Aktuelt er timerne sat til, at der skiftes fra DCH til FACH efter 4 sekunder, mens der skiftes fra FACH til IDLE efter 10 sekunder. 7.2.3.2 Resultater fra native app De ovennævnte timer værdier afspejler sig i resultaterne for den native app. Ved 2 og 3 sekunders frekvenser er RRC i DCH state hele tiden, da timeren aldrig når at skifte fra DCH til FACH, da timeren er sat til 4 sekunder. Derfor er resultaterne ens og energiforbruget højest for disse to frekvenser. Ved en frekvens på 4 sekunder, så når timeren at skifte ned fra DCH til FACH state efter de to første dataoverførsler (fordi vores app har en lille forsinkelse, så den aktuelt sender med 4.1 eller 4.2 sekunders frekvens. Så ret beset, så burde en frekvens på 4 sekunder også give samme resultat som 2 og 3 sekunder, mens ændringen først indtræffer ved en frekvens på 5 sekunder). Herefter sender app en så datapakker af så lille størrelse, at RRC bliver i FACH state resten af forløbet. Timeren når aldrig at skifte fra FACH til IDLE, da denne timer er sat til 10 sekunder. De samme forhold gør sig gældende for alle frekvenser fra 4 til 9 sekunder, så derfor er energiforbruget ens for disse frekvenser. Dette mønster er illustreret i figur 7.2, hvor frekvensen er 5 sekunder. Figuren er taget fra den grafiske præsentation af traces i ARO programmet. I figuren (og alle efterfølgende lignende figurer) er RRC state illustreret i den nederste række, hvor rød angiver skift fra IDLE til DCH state, gul er DCH state, grøn er FACH state, mens der ingen søjle er, hvis state er IDLE. Hvis søjlen er skraveret, så er der tale om en tail. Dataoverførslerne er markeret ved de lodrette streger ovenfor state angivelsen, mens tiden er angivet i sekunder på aksen forneden. Optagelsen af tracet startes inden app en startes, så derfor sker den første dataoverførsel i dette tilfælde først ca. 8 sekunder inde i tracet. Figur 7.2 Native app med frekvens på 5 sekunder Ved en frekvens på 10 sekunder, så når timeren at skifte fra FACH til IDLE efter hver anden dataoverførsel (igen kommer skiftet allerede ved 10 sekunders frekvens istedet for først ved 11 33

sekunders frekvens pga. app ens lille forsinkelse). Det betyder så, at RRC skal skifte fra IDLE til DCH hver anden gang, der foretages en dataoverførsel, hvilket forklarer, at energiforbruget faktisk er større ved en frekvens på 10 sekunder end ved frekvenser på 4 til 9 sekunder. Dette mønster er illustreret i figur 7.3. Det samme mønster er gældende for alle frekvenser fra 10 til 15 sekunder, dog sådan at tiden i IDLE state hele tiden øges, hvilket forklarer, at energiforbruget er støt aftagende. Figur 7.3 Native app med frekvens på 10 sekunder Ved en frekvens på 16 sekunder er intervallet så stort, at der aldrig overføres data i FACH state, så derfor er FACH tail konstant på 10 sekunder. Det indebærer så, at alle dataoverførsler kræver en overgang fra IDLE til DCH, hvilket gør, at energiforbruget stiger signifikant i forhold til en frekvens på 15 sekunder, hvor hver anden dataoverførsel kunne foregå i FACH state. Dette mønster er illustreret i figur 7.4. Eneste variation ved en forøgelse af frekvensen er herefter, at tiden i IDLE state forøges, og derfor falder energiforbruget jævnt ved en forøgelse af frekvensen. Figur 7.4 Native app med frekvens på 16 sekunder Så kurven for den native app følger ikke et trivielt lineært mønster, men har mange interessante variationer, som er forklaret via overgange mellem de forskellige RRC states og illustreret i figurerne ovenfor. 7.2.3.3 Resultater fra AJAX applikation For AJAX applikationen gælder ligesom ved native app, at ved frekvenser på 2 til 4 sekunder, så er RRC i DCH state hele tiden, hvilket betyder, at energiforbruget er på et konstant højt niveau. Niveauet er det samme som for native app. Ved en frekvens på 5 sekunder, så sørger timeren for, at der ligesom ved native app skiftes fra DCH til FACH state efter de to første dataoverførsler. Men modsat den native app, så forbliver RRC ikke i FACH state resten af tiden, da den datamængde, som overføres er større end den grænseværdi, som trigger, at der skiftes fra FACH til DCH state. Det betyder, der skiftes fra FACH til DCH state ved hver anden dataoverførsel. Efter at der skiftet til DCH, så bliver den umiddelbart efterfølgende dataoverførsel sendt i DCH tail. Dette mønster er illustreret i figur 7.5. Vi har ikke nogen underbygget forklaring på, at datamængden er større, når browseren sender data, end når den native app sender data. Men vi forventer, at det skyldes, at browseren sender en del flere HTTP headers med i hver request til serveren end den native app gør. Men datamængden for AJAX applikationen ligger og balancerer lige omkring den grænse, som 34

er sat i opsætningen i ARO. Figur 7.5 AJAX med frekvens på 5 sekunder Ved frekvenser fra 6 til 15 sekunder, så følges det samme mønster som ved en frekvens på 5 sekunder. Dog er intervallet nu så stort, at DCH tail ikke kan udnyttes ved hver anden dataoverførsel, så alle dataoverførsler trigger et skift fra FACH til DCH state. Dette er illustreret i figur 7.6. Da tiden i FACH tilstanden øges, så falder energiforbruget ved større frekvens. Forskellen mellem energiforbruget i AJAX og den native app skyldes fortsat, at den native app forbliver i FACH ved forsendelse af data i denne tilstand, modsat AJAX, som skifter op til DCH hver gang. Figur 7.6 AJAX med frekvens på 6 sekunder Fra en frekvens på 16 sekunder, så kommer et nyt mønster i spil. Ca. 7 sekunder efter hver dataoverførsel, så sender browseren en request til webserveren for at lukke forbindelsen. Der sendes ingen data i denne forbindelse, men requesten sørger stadigvæk for, at RRC forbliver i FACH tilstand i lidt længere tid istedet for at skifte til IDLE tilstand efter 10 sekunder, da FACH timeren resettes til 10 sekunder ved requesten. Dette mønster er illustreret i figur 7.7, hvor de lodrette blå streger er ovennævnte requests for at lukke forbindelsen.. Dette mønster fortsætter, når frekvensen øges. Dog med den ændring, at når frekvensen kommer op på 17 sekunder, så er intervallet så stort, at RRC når at komme i IDLE state efter FACH state. Så derfor falder energiforbruget løbende, når frekvensen stiger. Figur 7.7 AJAX med frekvens på 17 sekunder Kurven for AJAX applikationen følger et mere fast aftagende mønster end kurven for den native app. Men der er stadigvæk variationer i hældningen på kurven, som er forklaret bl.a. via den ekstra request for at lukke forbindelsen. 7.2.3.4 Resultater fra WebSockets applikation 35

WebSockets applikationen følger langt hen af vejen mønsteret for den native app. Dette er også forventeligt, da datamængden og mønsteret i dataoverførslerne er næsten ens. Der er dog nogle forskelle, som beskrives under gennemgangen af intervallerne. Ved frekvenser fra 2 til 10 sekunder, så er energiforbruget konstant. Det skyldes, at RRC kun bliver i DCH state indtil timer værdien på 4 sekunder er nået. Herefter foregår resten af overførslerne i FACH state. Datamængden ved WebSockets applikationen er mindre end ved den native app. Hvilket skyldes, at forbindelsen er konstant åben, så det er kun data, som sendes frem og tilbage uden store headere til at åbne forbindelsen (som beskrevet i 6.1.2, så sendes faktisk kun en lille header på 2 bytes ved hver dataoverførsel). Den meget lave datamængde gør, at selvom dataoverførslen foregår i DCH state, så trigger det ikke en reset af DCH timeren, som der ellers normalt foregår i denne state ved en dataoverførsel. Så derfor skiftes der til FACH state efter 4 sekunder, også ved helt korte frekvenser på 2 og 3 sekunder. I modsætning til den native app, hvor DCH timeren resettes og DCH state forbliver aktiv hele forløbet ved disse frekvenser. Dette er illustreret i figur 7.8. Figur 7.8 WebSockets med frekvens på 2 sekunder Ved en frekvens på 11 sekunder, så når timeren at skifte fra FACH til IDLE state, hvilket betyder, at RRC skal skifte fra IDLE til DCH ved hver anden dataoverførsel. Det er samme mønster, som indtræffer i den native app ved 10 sekunder (indtræffer tidligere i den native app pga. den indbyggede lille forsinkelse), og som gør, at det samlede energiforbrug stiger i forhold til de kortere frekvenser. Mønsteret er illustreret i figur 7.3 fra gennemgangen af den native app. Og igen ved en frekvens på 16 sekunder sker der en forøgelse af energiforbruget ligesom ved den native app. Også her skyldes forøgelsen, at intervallet bliver så stort, at der aldrig overføres data i FACH state, hvilket betyder, at alle dataoverførsler kræver et skift fra IDLE til DCH state, hvilket giver en væsentligt forøgelse af det samlede energiforbrug. Dette mønster er illustreret i figur 7.4 fra gennemgangen af den native app. Fra en frekvens på 17 sekunder og fremefter er målingerne fuldstændigt sammenfaldende med målingerne for den native app, og forklaringen på den aftagende kurve er ligesom ved den native app, at tiden i IDLE state herfra forøges, når intervallet mellem dataoverførslerne forøges. Så kurven for WebSockets applikationen kan forklares ud fra de samme overgange mellem RRC states, som kurven for den native app. Dog med den væsentlige forskel for de lave frekvenser på 2 og 3 sekunder, som er forklaret ovenfor, og som giver en betragteligt besparelse i energiforbruget for disse frekvenser i forhold til de to andre applikationer. 7.2.3.5 Sammenligning I de foregående tre sektioner er målingerne med ARO blevet grundigt gennemgået. For AJAX applikationen er tendensen, at når man kommer ud over en frekvens på 4 sekunder, så falder energiforbruget konstant indtil en frekvens på 10 sekunder. Herefter er faldet indtil en frekvens på 17 sekunder meget lille, hvorefter besparelsen ved at øge frekvensen stiger markant. For den native app er kurven noget mere kompliceret og viser mange af de ting, som er gennemgået under teorien i sektion 4, hvilket gør resultaterne teoretisk interessante. Det 36