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 enhederHovedopgave Master i ITIndholdsfortegnelse1. Motivation

1.1 Indsamling af positionsdata1.2 Udfordringer1.3 Opsummering

2. Hypotese og problemformulering2.1 Direkte indsamling2.2 Mellemlag2.3 Hypoteser2.4 Afgrænsning

3. Metode4. Baggrund og relateret arbejde

4.1 3G netværk4.2 RRC state machine4.3 Overgange i RRC tilstande4.4 Tail effekt og trade-off4.5 Udledning af state machine4.6 Relateret arbejde

4.6.1 TailEnder4.6.2 TOP (Tail Optimization Protocol)4.6.3 Bartendr4.6.4 Andre bidrag

5. Værktøjer5.1 ARO5.2 PowerTutor5.3 Præcision og begrænsninger

6. Analyse og design6.1 Analyse

6.1.1 Teknologier6.1.2 WebSockets

6.2 Design6.3 Implementation

6.3.1 AJAX web applikation6.3.2 WebSockets applikation (version 1)6.3.3 WebSockets applikation (version 2)6.3.5 Native Android-JSON Applikation6.3.6 Jetty Webserver og MySql setup på Linux—Ubuntu server

7. Resultater7.1 Udførelse af eksperimenter

7.1.1 Test setup7.1.2 Udførelse af test

7.2 Direkte indsamling af data7.2.3 Målinger med ARO

7.2.3.1 Opsætning af ARO

2

7.2.3.2 Resultater fra native app7.2.3.3 Resultater fra AJAX applikation7.2.3.4 Resultater fra WebSockets applikation7.2.3.5 Sammenligning

7.2.4 Målinger med PowerTutor7.2.4.1 Opsætning af PowerTutor7.2.4.2 Resultater fra native app7.2.4.3 Resultater fra AJAX applikation7.2.4.4 Resultater fra WebSockets applikation7.2.4.5 Sammenligning

7.2.5 Konklusion og best practices7.3 Intelligent mellemlag

7.3.1 Målinger7.3.2 Konklusion

8. Konklusion9. 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. MotivationIndenfor 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 positionsdataDa 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 UdfordringerHvis 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 OpsummeringOvennæ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 problemformuleringVi 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 indsamlingDer 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 MellemlagUdover 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 HypoteserUd 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ænsningFø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. MetodeVi 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 arbejdeI 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ærkSammenlignet 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 machineI 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 tilstandeOvergange 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-offSom 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 machineNedenstå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 arbejdeHer præsenteres andre tilgangsvinkler til at minimere energiforbruget ved brug af 3G netværk for mobile enheder.

4.6.1 TailEnderI [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 BartendrI [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 bidragI [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øjerFuldstæ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 AROARO (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 PowerTutorPowerTutor 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ænsningerBegge 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 designFor 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 AnalyseSom 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 TeknologierDet 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 WebSocketsI 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 DesignVi 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 model-view-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 ImplementationFor 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 applikationVores 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 ApplikationVejen 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 test-specifikationer, 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 serverVi 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. ResultaterFor 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 eksperimenterNedenfor er beskrevet, hvordan vi i praksis har udført vores eksperimenter og indsamlet målingerne.

7.1.1 Test setupVi 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 testDen 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 dataI denne sektion beskrives vores undersøgelse af energiforbruget i forbindelse med direkte indsamling af data.

7.2.3 Målinger med AROI 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 AROI 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 appDe 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 applikationFor 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 SammenligningI 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

skal understreges, at denne kurve er noget mere afhængig af de parametre for timere og grænseværdier, som er sat op for RRC states af den enkelte udbyder end kurven for AJAX applikationen. Det er interessant, at hvis man kan holde datamængden under grænseværdien for skiftet fra FACH til DCH tilstand, så er der meget energi at spare, når man kommer ud over timer værdien for skift fra DCH til FACH. Ellers er tendensen, at man skal ud over en frekvens på 20 sekunder, før den store besparelse kommer. Ihvertfald hvis man går ud over de helt korte frekvenser, som kun kører i DCH state.For WebSockets applikationen er betragtningerne de samme som for den native app. Dog med den væsentlige forskel, at der er en stor besparelse for de helt korte frekvenser, hvor den meget lave datamængde gør, at der allerede her skiftes til FACH state.Kurverne giver ikke noget helt entydigt svar på, hvilken applikation, der generelt er bedst til at formindske energiforbruget. WebSockets er bedst på de helt korte intervaller, mens native app og WebSockets er ens og bedre end AJAX på mellem intervallerne. Og AJAX er så endelig bedst på intevaller på knap 20 sekunder og fremefter. Dog konvergerer alle applikationer mod den samme værdi, når intervallet bliver rigtig stort.

7.2.4 Målinger med PowerTutorI figur 7.9 er vist energiforbrug som funktion af frekvensen mellem dataoverførslerne. Der er plottet middelværdierne ind med angivelse af standardafvigelsen. Der er foretaget 5 målinger for hver frekvens. Standardafvigelserne er væsentligt større end for målingerne med ARO, hviket skyldes den større usikkerhed ved målinger på et rigtigt device. Samtidigt er ændringerne i værdierne for energiforbruget også væsentligt større for målingerne med PowerTutor. Ud fra disse målinger er der meget mere energi at spare ved at indsamle data med store intervaller imellem, end det fremgår ved målingerne med ARO.

37

Figur 7.9 Målinger med PowerTutor

7.2.4.1 Opsætning af PowerTutorPowerTutor er som udgangspunkt ikke kalibreret til den smartphone model, hvor målingerne er udført. Det gør, at det angivne energiforbrug ikke nødvendigvis er korrekt, da der bruges en standard energimodel, som sandsynligvis afviger fra den aktuelle energimodel i smartphonen. Men da det er variationen i målingerne, som vi er interesserede i, så betyder størrelsen af værdierne ikke så meget.Vi har taget energiforbruget som summen af de værdier, som PowerTutor angiver for 3G og CPU forbrug. Og vi har valgt at se bort fra de værdier, som PowerTutor angiver for OLED forbrug.

7.2.4.2 Resultater fra native appKurven følger et mønster, som undervejs viser karakteristika fra teorien og fra erfaringerne fra målingerne med ARO. Men kurven har også samtidig momenter, som ikke kan forklares direkte ud fra teorien.Ved skift fra en frekvens på 9 sekunder til en frekvens på 10 sekunder, så sker der et kraftigt fald i energiforbruget. Det kunne svare til, at en timer værdi blev overskredet, sådan at RRC skifter fra FACH state til IDLE state. Det passer også med, at værdierne for frekvenser på 7 og 8 sekunder er de samme som værdien for 9 sekunder, hvilket tyder på en konstant RRC state. Samtidigt indikerer det jævne fald mellem frekvenser på 10 og 15 sekunder også, at mængden

38

af tid, hvor RRC befinder sig i en lav state, f.eks. FACH eller IDLE, hele tiden forøges, hvilket også passer med formodningen om, at en timer værdi er overskredet ved skift af frekvens fra 9 til 10 sekunder.Det konstante fald mellem frekvenser på 2 og 7 sekunder passer dog ikke helt overens med teorien, da der burde startes med nogle værdier, som var ens, da det ville svare til en start i en konstant DCH state. Denne start med konstante værdier observeres både med AJAX og WebSockets applikationerne, så den mest logiske forklaring på afvigelsen er, at der er andre ting, som spiller ind og influerer på PowerTutors beregninger for de mindste frekvenser.Fra frekvenser på 11 sekunder og fremefter falder energiforbruget rimeligt jævnt, hvilket svarer til, at RRC er i IDLE tilstand i stadigt stigende tidsintervaller.

7.2.4.3 Resultater fra AJAX applikationKurven for AJAX applikationen ser ud til at starte med en konstant DCH state for frekvenser mellem 2 og 6 sekunder. Det efterfølgende fald svarer så til, at der skiftes til FACH state i gradvist voksende tidsintervaller.Og ved i området med frekvenser på 10 og 11 sekunder, så sker der et stort fald i energiforbruget, hvilket understøtter antagelsen fra den native app om, at her overskrides en timer værdi, sådan at RRC skifter fra FACH til IDLE.Og endelig afsluttes med en forholdsvist jævnt aftagende kurve, ligesom ved den native app.

7.2.4.4 Resultater fra WebSockets applikationKurven for WebSocket applikationen stemmer faktisk bedst overens med teorien og erfaringerne fra ARO. Der startes med et konstant interval, som kan forklares med, at der er en konstant DCH state for frekvenser fra 2 til 4 sekunder. Herefter følger et jævnt fald, som svarer til, at der skiftes til FACH state i gradvist voksende intervaller. Ved en frekvens på 11 sekunder mellem dataoverførslerne, så kommer et drastisk fald i energiforbruget, hvilket svarer til den allerede omtalte overskridelse af timer værdien, sådan RRC nu skifter fra FACH til IDLE.Afslutningen på kurven følger det samme mønster, som beskrevet under native app og AJAX.

7.2.4.5 SammenligningResultaterne fra PowerTutor kan langt hen ad vejen forklares ud fra teoretiske overvejelser. Samtidigt giver de et mere entydigt billede af, hvilken applikation, som performer bedst mht. energiforbrug, end resultaterne fra målingerne med ARO. Ved frekvenser mellem 3 og 12 sekunder, så er den native app solidt bedre end både AJAX og WebSockets applikationen. Størst ved en frekvens på 10 sekunder, hvor besparelsen er over 35%.Ved frekvenser mellem 12 og 14 sekunder er energiforbruget næsten ens for native app og AJAX, mens WebSockets ligger langt over. Fra frekvenser på 15 sekunder fremkommer igen større forskel. Ved en frekvens på 60 sekunder er forskellen igen højt oppe på 33% mellem native og AJAX, mens WebSocket ligger lidt bedre her.Så ud fra målingerne med PowerTutor er konklusionen klart, at det er bedst at benytte sig af en native app til indsamling af data.Vi er dog lidt forundret over, at WebSockets applikationen klarer sig så dårligt i målingerne med PowerTutor. WebSockets applikationen sender mindre datamængder, da forbindelsen mellem serveren og klienten forbliver åben, og der derfor ikke er behov for at sende requests og headers for at åbne en forbindelse ved hver dataoverførsel. Den mindre datamængde sammenholdt med erfaringerne fra ARO målingerne gjorde, at vi forventede, at WebSockets ville klare sig på niveau med eller bedre end den native app. Men det er som vist ikke tilfældet i målingerne med PowerTutor.

7.2.5 Konklusion og best practicesFor direkte indsamling af data viser resultaterne fra målingerne med ARO og PowerTutor, at der

39

bør benyttes en native app til at indsamle positionsdata med. Ved målingerne med PowerTutor er konklusionen helt klar, mens billedet er lidt mere nuanceret ved målingerne med ARO, hvor WebSockets fremstår som det bedste generelle valg. Men ved målingerne ved PowerTutor ligger WebSockets konstant dårligere end den native app, så vores konklusion er, at native app er det bedste generelle valg, da den store forskel i ARO målingerne mellem WebSockets og native app ligger ved de korte frekvenser på 2 og 3 sekunder. Ved de andre frekvenser er forskellen mellem energiforbruget for de to applikationer relativt lille eller ikke eksisterende.Så undtagelsen fra reglen om at bruge en native app er, hvis man entydigt går efter at indsamle data med en meget kort frekvens på f.eks. 2 sekunder. Så giver det mening at bruge WebSockets eller AJAX, da native app og AJAX har ens resultater i både ARO og PowerTutor for denne frekvens, mens resultaterne for WebSockets ligger minimalt over resultaterne for de to andre applikationer i PowerTutor, mens WebSockets til gengæld har en besparelse i energiforbruget på 35% i målingerne fra ARO på denne frekvens. Et lidt mere nuanceret syn viser dog, at der er andre scenarioer, hvor en AJAX applikation har sin berettigelse. Ved frekvenser på f.eks. 30 eller 60 sekunder, så er besparelsen i joule ikke så stor i PowerTutor målingerne, mens ARO faktisk fremstiller AJAX med lavest energiforbrug her. Så ved store intervaller mellem dataoverførslerne, så kan man med fordel overveje en AJAX løsning. Det vil typisk være endog væsentligt hurtigere og billigere at udvikle en AJAX løsning, specielt hvis man ønsker at udbrede sin applikation til mange typer smartphones, da man ved en native app så skal udvikle og vedligeholde forskellige applikationer til hver type (f.eks. iPhone, Android, Windows Phone og Blackberry) i hvert sit programmeringssprog og -miljø. Ud fra betragtninger i samme spor, så er WebSockets måske nok endnu ikke helt moden som generel teknologi til at bruge på smartphones, da mobile browsere enten ikke (Android) eller kun delvist (iOS) understøtter WebSockets protokollen [13]. Så man er nødt til at bruge specielle teknikker og samtidig pakke sin webapp ind i en native app (via f.eks. PhoneGap) for at bruge protokollen. Dette er ikke helt tilfredsstillende. Samtidigt understøtter gængse webservere, som f.eks. Apache Tomcat, endnu ikke umiddelbart at fungere som en WebSockets server. Så derfor er man nødt til at bruge mindre udbredte webservere som Jetty eller node.js for at kunne implementere sin backend til indsamlingen af data, hvilket også kan være en stor forhindring i en eksisterende infrastruktur.Vi er dog overbevist om, at inden for et kort tidsperspektiv, så vil WebSockets være en naturlig og fuldt implementeret del af alle browsere og understøttet af gængse webservere, da perspektiverne og mulighederne ved brug af protokollen er utallige. Når protokollen er understøttet af mobile browsere, så er det lige så nemt at lave en WebSockets applikation, som at lave en AJAX application, og så er Websockets at foretrække i de fleste tilfælde ud fra vores resultater. Specielt hvis man også tager netværksforbrug med i betragtning, da WebSockets sender færre data frem og tilbage over nettet, jvf. vores betragtninger under 6.1.2. Samtidigt betyder de færre data, at webserveren bliver mindre belastet, specielt hvis der er rigtigt mange samtidige brugere. Selvom målingerne med native app fra PowerTutor ikke helt understøtter det, så er både observationen og teorien, at så længe frekvensen er mindre end timer værdien for skiftet mellem DCH og FACH state, så er energiforbruget konstant. Så hvis man har brug for hyppige indsamlinger af data, så er der sandsynligvis ikke større forskel på at vælge en frekvens på 4 sekunder i forhold til en frekvens på 2 sekunder. Dette er også understøttet af de oplysninger omkring timer værdier, som fremgår af nogle af artiklerne i referencelisten. Så derfor kan man ved meget små frekvenser vælge den frekvens, som passer bedst til den ønskede strategi for indsamlingen af data.Ved frekvenser i mellemintervallet (5 - 19 sekunder), så afhænger besparelsen i energiforbruget

40

meget af timer- og grænseværdier for den enkelte udbyder. Så hvis man har mulighed for det, så er det bedst at vælge en frekvens på 20 sekunder. Men gode besparelser kan absolut også opnås med mindre frekvenser, da man altid vil ramme en vis del af udbyderne. Ud fra ovenstående betragtninger kan vi opstille disse best practices omkring valg af strategi, når man skal udvikle en applikation til at indsamle positionsdata direkte.

● Native app er generelt det bedste valg som applikation til at indsamle positionsdata● AJAX er bedst som alternativ, når der enten er tale om meget korte intervaller

mellem dataoverførslerne (2 eller 3 sekunder) eller meget lange intervaller mellem dataoverførslerne (30 eller 60 sekunder)

● Hvis der udelukkende skal indsamles data med korte intervaller, så er WebSockets et alternativ, som bør overvejes

● Hvis der er brug for hyppige indsamlinger af data, så kan der frit vælges mellem korte intervaller mindre end 5 sekunder

● Et interval på 20 sekunder mellem dataoverførslerne garanterer store besparelser i energiforbruget.

7.3 Intelligent mellemlagI denne sektion beskrives vores undersøgelse af energiforbruget i forbindelse med indsamling af data via en native Android app med et indbygget intelligent mellemlag.I vores udgave af app’en er mellemlaget dog begrænset til, at der kan angives et interval, hvormed lokationsdata opsamles og gemmes i en lokal Sqlite database på smartphonen, samtidigt med, at der kan angives et andet interval, hvormed de opsamlede data hentes fra den lokale database og sendes til serveren. Efter at data er sendt til serveren, så slettes alle data fra den lokale database.

7.3.1 MålingerAlle målinger foretaget med ARO værktøjet gav det samme resultat, som den tilsvarende måling foretaget ved den direkte indsamling for den samme frekvens for at sende data til serveren. Dette var forventeligt, da ARO kun måler energiforbrug i forbindelse med dataoverførsler. Så derfor er der ikke præsenteret resultater for målinger med ARO i denne sektion.Med PowerTutor har vi foretaget målinger, hvor vi for frekvenser på afsendelse af data til serveren på henholdsvis 30 og 60 sekunder har varieret den frekvens, hvormed data er indsamlet og gemt i den lokale database. Hermed har vi kunnet bedømme, hvad konsekvensen ved at indsamle og gemme data lokalt inden afsendelsen til serveren har på energiforbruget.Resultaterne er vist i figur 7.10, hvor middelværdien for energiforbruget i joule er vist. I alle tilfælde er standardafvigelsen under 0,1.

Figur 7.10 Målinger med PowerTutor Som det fremgår af tabellen, så er omkostningerne ved at indsamle og gemme data lokalt forsvindende lille. Resultaterne for de varierende indsamlingsfrekvenser er alle kun marginalt

41

højere end resultatet fra den direkte indsamling, hvor der er indsamlet og afsendt direkte uden at gemme data lokalt. Endvidere fremgår det på samme vis, at der ingen større forskel er på at indsamle med små intervaller ned til 2 sekunder og indsamle med større intervaller på 15 sekunder.Vi har lavet stikprøve målinger for nogle af de intervaller, som vi også har målt igennem for direkte indsamling. Og tendensen er, at resultaterne følger samme mønster med at lægge en smule over resultatet for den direkte indsamling med samme frekvens for dataoverførsler til serveren. Dette betyder, at man skal ud over det kraftige knæk på kurven i figur 7.9 ved 11 sekunder, før der kommer en rigtig signifikant energibesparelse.Så både ARO og PowerTutor viser, at det har meget lille betyding at indsamle og lagre data lokalt, mens det er frekvensen for dataoverførsler til serveren, som er den parameter, der skal arbejdes med, hvis der skal spares energi.

7.3.2 KonklusionVi har med vores applikation og målinger verificeret, at det næsten ikke koster noget energi at indsamle data og lagre dem lokalt i en database på den mobile enhed. Dette åbner op for muligheder for at spare rigtig meget energi i de tilfælde, hvor det ikke er vigtigt at have realtidsopdatering af data på serveren. For eksempel kan der spares 88% (97,6 joule) ved at indsamle data med 2 sekunders intervaller og så sende de indsamlede data til serveren med 30 sekunders intervaller i forhold til at sende data direkte med 2 sekunders intervaller.Så konklusionen er, at hvis man kun sender data til webserveren med et stort interval som 30 eller 60 sekunder, så kan man spare rigtig meget energi. Så for applikationer, hvor der ikke er behov for hurtig realtidsopdatering, så er det oplagt at indbygge en sådan logik. Grundet tidspres har vi desværre ikke kunnet udvide vores applikation med mere intelligens i mellemlaget. Så applikationen har primært til formål basalt at verificere vores hypotese om, at det er muligt at udvikle et intelligent mellemlag, som kan reducere energiforbruget ved indsamling af positionsdata.Men i en rigtig app til produktionsbrug er der mulighed for at lade intervallet, hvormed der sendes data til serveren, variere dynamisk ud fra fysiske parametre, som kan registreres af den mobile enhed. Her er listet nogle oplagte muligheder, som kan indbygges i et intelligent mellemlag for at mindske energiforbruget:

● Batteriniveau. Når batteriniveauet når under en given grænseværdi, så kan intervallet mellem dataoverførsler til serveren øges, sådan at energiforbruget mindskes. Evt. kan dataoverførslerne helt stoppe, når der nås en meget lav grænseværdi. Og så genoptages, når batteriniveauet kommer op på et acceptabelt niveau igen. Et sådant skema er indbygget i flere standardapplikationer på smartphones.

● WiFi. Den ultimative besparelse kan opnås ved kun at sende data, når den mobile enhed er tilsluttet WiFi, da dataoverførsler via WiFi næsten ingen energi koster, når datamængden er på et niveau, som ved registrering af positionsdata. Det betyder så i praksis, at data altid vil ankomme til serveren med en væsentligt forsinkelse i forhold til indsamlingstidspunktet. Men hvis man har et scenarie, hvor der f.eks. skal indsamles store mængder data over et længere tidsrum for derefter at foretage store beregninger og analyser af dataene efterfølgende, så er denne løsning absolut brugbar.

● Styrke af netværkssignal. Det er påvist i [8], at energiforbruget også afhænger af signalstyrken. Det kan derfor være fornuftigt at indbygge nogle grænseværdier, sådan at der sendes med større intervaller, når signalstyrken er lav.

● Accelerometer. Der kan indbygges logik, som tager højde for den hastighed, hvormed den mobile enhed bevæger sig. F.eks. at der sendes med større intervaller til serveren, hvis enheden bevæger sig langsomt. Eller måske slet ikke sendes, hvis enheden står

42

helt stille. Det skal bemærkes, at med de nyeste HTML 5 teknikker, så er det også muligt at bygge mere avanceret logik ind i AJAX eller WebSockets applikationerne. F.eks. kan LocalStorage udnyttes til at gemme data lokalt, ligesom vi har gjort i den native app. Dog er der nogen af de ovennævnte fysiske parametre, som endnu ikke er direkte tilgængelige i de mobile browsere. Men der bliver løbende åbnet op for adgang til flere og flere informationer omkring den fysiske enhed, som browseren kører på.Dette åbner igen op for de perspektiver omkring omkostningerne ved at udvikle forskellige type applikationer, som blev diskuteret i 7.2.5 ved konklusionen under den direkte indsamling, sådan at AJAX eller WebSockets kan udgøre et fornuftigt alternativ til native apps i nogle tilfælde, alt afhængigt af brugsscenariet.

43

8. KonklusionVi startede projektet ud med to hypoteser, som vi ville verificere:

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

Gennem udvikling og implementering af en løsning med tre forskellige klient applikationer, så har vi været i stand til foretage kvantitative målinger og tests, sådan at vi på baggrund af resultaterne fra målingerne har været i stand til at foretage en kvalificeret sammenligning af energiforbruget ved de tre forskellige metoder til direkte indsamling af positionsdata i 7.2.5. Ud fra vores betragtninger har vi samme sted opstillet nogle konkrete best practices for, hvordan indsamlingen af positionsdata kan foretages bedst muligt med hensyn til energiforbrug ud fra forskellige krav omkring realtidsopdatering.Vores hovedkonklusion er, at den bedste generelle løsning er en native app, mens vi nævner specifikke scenarier, hvor AJAX eller WebSockets er fornuftige alternativer, som kan overvejes. Endvidere er vores betragtning, at når WebSockets bliver en mere udbredt teknologi i mobile browsere og webservere, så vil denne teknologi helt klart kunne komme op som det bedste alternativ.Med disse konklusioner og best practices har vi verificeret den første hypotese. Efterfølgende har vi udvidet den native app til at kunne indsamle positionsdata og lagre disse data lokalt på den mobile enhed med en given frekvens. Og så sende disse data til serveren med et interval, som er længere end intervallet mellem indsamlingerne.Gennem målinger med forskellige frekvenser for indsamling og dataoverførsel har vi i 7.3.2 påvist, at det er muligt at spare endog rigtig meget energi ved at gemme de indsamlede data lokalt og kun sende dem til serveren med et større interval på f.eks. 30 eller 60 sekunder.Dermed har vi lavet et proof of concept på vores antagelse i den anden hypotese, som dermed også er verificeret. Endvidere har vi opstillet flere forslag til andre relevante logikker og heuristikker, som kunne indbygges i et intelligent mellemlag, sådan at det bliver muligt at lave en fleksibel og energibesparende indsamling af positionsdata. Udover verificeringen af de to opstillede hypoteser, så har vi undervejs i projektet arbejdet med og undersøgt flere ting, som har bidraget til vores forståelse af problemstillingerne omkring energiforbrug ved dataoverførsel på mobile enheder. Og som har givet os indsigt i og erfaring med udvikling af både native apps og webapps på Android platformen. Derfor er her opstillet de væsentligste punkter og bidrag i vores projekt:

● Gennemgået relevante artikler og teori omkring energiforbrug ved dataoverførsel på mobile enheder

44

● Fremfundet og udnyttet brugbare værktøjer til måling af energiforbrug på mobile enheder● Gennemført detaljerede målinger af energiforbruget for de forskellige applikationer og

foretaget grundige analyser af de opnåede måleresultater● Sammenholdt de opnåede måleresultater med den gennemgåede teori og forklaret

sammenhænge i resultaterne ud fra teorien● Opstillet konklusioner og relevante betragtninger på baggrund af analyserne af de

opnåede måleresultater● Opstillet best practices for indsamlingen af postionsdata under forskellige krav til

realtidsopdatering● Lavet proof of concept på et intelligent mellemlag● Udviklet en mobil applikation, som overfører data med WebSockets teknologien, hvilket

ikke umiddelbart er understøttet af mobile enheder på simpel vis● Afprøvet WebSockets teknologien i praksis på en Jetty webserver

45

9. Referencer[1] A. Balasubramanian, R. Mahajan, and A. Venkataramani.

Augmenting Mobile 3G Using WiFi. In Mobisys, 2010.

[2] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani.Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications. In IMC, 2009.

[3] H. Falaki, D. Lymberopoulos, R. Mahajan, S. Kandula, and D. Estrin.

A First Look at Traffic on Smartphones. In IMC, 2010. [4] J. Huang, Q. Xu, B. Tiwana, Z. M. Mao, M. Zhang, and P. Bahl.

Anatomizing Application Performance Differences on Smartphones. In Mobisys, 2010. [5] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck.

Characterizing Radio Resource Allocation for 3G Networks. In IMC, 2010. [6] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck.

TOP: Tail Optimization Protocol for Cellular Radio Resource Allocation. In ICNP, 2010. [7] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck.

Profiling Resource Usage for Mobile Applications: A Cross-layer Approach. In Mobysys, 2011.

[8] A. Schulman, V. Navda, R. Ramjee, N. Spring, P. Deshpande, C. Grunewald, K. Jain,

and V. Padmanabhan.Bartendr: A Practical Approach to Energy-aware Cellular Data Scheduling. In Mobicom, 2010.

[9] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. Dick, Z. M. Mao, and L. Yang.

Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones. In CODES+ISSS, 2010.

[10] http://developer.att.com/developer/forward.jsp?passedItemId=9700312 [11] https://play.google.com/store/apps/details?id=edu.umich.PowerTutor [12] https://github.com/msg555/PowerTutor [13] http://caniuse.com/websockets [14] http://www.websocket.org/quantum.html

46