EnTracked: Energy-Efficient Robust Position Tracking forMobile Devices

Mikkel Baun Kjrgaard, Jakob Langdal , Torben Godsk , Thomas ToftkjrDepartment of Computer Science

Aarhus University, Denmarkmikkelbk@cs.au.dk, jakobl@cs.au.dk, tbg@cs.au.dk, toughcar@cs.au.dk

ABSTRACTAn important feature of a modern mobile device is that itcan position itself. Not only for use on the device but also forremote applications that require tracking of the device. Tobe useful, such position tracking has to be energy-ecientto avoid having a major impact on the battery life of themobile device. Furthermore, tracking has to robustly de-liver position updates when faced with changing conditionssuch as delays due to positioning and communication, andchanging positioning accuracy.

This work proposes EnTracked a system that, based onthe estimation and prediction of system conditions and mo-bility, schedules position updates to both minimize energyconsumption and optimize robustness. The realized systemtracks pedestrian targets equipped with GPS-enabled de-vices. The system is congurable to realize dierent trade-os between energy consumption and robustness.

We provide extensive experimental results by prolinghow devices consume power, by emulation on collected dataand by validation in several real-world deployments. Resultsfrom this proling show how a device consumes power whiletracking its position. Results from the emulation indicatethat the system can estimate and predict system conditionsand mobility. Furthermore they provide evidence for thatthe system can lower the energy consumption considerablyand remain robust when faced with changing system con-ditions. By validation in several real-world deployments weprovide evidence that the real system works as predicted bythe emulation.

Categories and Subject Description: C.2.4 [Computer-Communication Networks]: Distributed Systems

General Terms: Experimentation, Measurement

Associated with the Alexandra Institute A/S, DenmarkAssociated with the Danish Agricultural Advisory Service,National Centre, DenmarkAssociated with Systematic A/S, Denmark

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MobiSys09, June 2225, 2009, Krakw, Poland.Copyright 2009 ACM 978-1-60558-566-6/09/06 ...$5.00.

1. INTRODUCTIONAn important feature of a modern mobile device is that

it can position itself. Not only for use locally on the de-vice but also for remote applications that require trackingof the device. Examples of such applications are geo-basedinformation applications [6] or proximity and separation de-tection for social networking applications [12] just to men-tion a few. To be useful, such position tracking has to beenergy-ecient to avoid having a major impact on the powerconsumption of the mobile device. Optimizing the operationof mobile devices for energy eciency is an important issueand research is trying to address it from many angles, forinstance, by trying to lower the impact of network protocolson power consumption [15] or by optimizing the execution atthe operating system level [4]. Furthermore, tracking has tobe robust in order to deliver position updates within limitswhen faced with changing conditions such as delays due topositioning and communication, and changing positioningaccuracy.

To quantify the impact of position tracking on power con-sumption, we measured the power consumption of a NokiaN95 phone for 30 minutes, while the phone periodically po-sitioned itself using the built-in GPS receiver and then sendthe position data using UMTS to a remote service hostedon an internet-connected server. The measurements wererepeated with dierent time intervals between the periodicposition updates. The average power consumption measuredis plotted in Figure 1. The results highlight that even formoderate time intervals between position updates such assixty seconds the power consumption is as high as 0.6 watt,which is twelve times more consumed power than when thephone is idle and the double amount of power compared towhen the phone is used with the screen turned on.

From Figure 1 one might propose to minimize the powerconsumption by using large intervals between position up-dates, but then maintaining position accuracy becomes aproblem, as a pedestrian target can walk or run quite farduring two to ve minutes. To address this problem previ-ous research such as [14, 19] has proposed dynamic trackingto try to minimize the frequency of needed position updatesby only requiring updates after the target has moved morethan a specied distance or has moved out of a speciedarea.

The systems proposed in previous research for such dy-namic tracking have several drawbacks. First, the researchassumes that power consumption for positioning and send-ing is instantaneous meaning that the power consumptionper position sensing and sending is a constant and that you

221

0

0.5

1

1.5

2

0 60 120 180 240 300

Pow

er [w

att]

Time between updates [seconds]Nokia N95 Instantaneous Model

Figure 1: Average power consumption for periodicposition updating measured on a N95.

can calculate the total power consumption by just multiply-ing this constant with the number of position updates. Forinstance, for the Nokia N95 this constant could be set to1.523 joules 1. Using this model to calculate the power con-sumption with dierent periodic intervals gives the results inFigure 1, which we denote by instantaneous model. Fromthe results we can see, that this model is not at all able toaccount for the real power consumption of a device. Thereason is that this model does not take into account the de-lays involved when either the GPS or the GSM transceiver isinitializing, nor the delays of it powering o. Second, previ-ous research assumes that positioning takes constant time.This is not true, for instance, for sensing position with aGPS module the positioning time depends on how well theGPS module knows the frequencies of visible satellites, thecurrent satellite constellation and several other parameters.Third, they considered the accuracy of positioning to beconstant. This is also incorrect: the accuracy of GPS posi-tioning depends on the number of visible satellites, signal-blocking structures near the receiver and several other fac-tors. Fourth, they did not deploy the systems on actualhardware. Systems were evaluated either by simulation oremulation.

This paper proposes EnTracked - a system that, based onthe estimation and prediction of system conditions and mo-bility, schedules position-updates to both minimize energyconsumption and optimize robustness. The realized systemtracks pedestrian targets equipped with GPS-enabled de-vices. The system is congurable to realize dierent trade-os between energy consumption and robustness.

We make the following contributions in this work: Firstof all, we present a system that uses the estimation and pre-diction of system conditions and mobility to build a robustenergy-ecient tracking system. Secondly, we prole howdevices consume power for tracking and propose a devicemodel that can account for the real power consumption ofa device. Thirdly, we propose methods for position track-ing that take the changing system conditions into account,e.g., positioning delays and position accuracy. Fourthly, wepropose a method (implemented by dynamic programming)that can minimize power consumption and satisfy robustnessby calculating the optimal plan for when to power on and

1We have based this value on the average energy consump-tion for updating position every second, assuming that oneupdate takes one second.

o features of the mobile devices such as the GPS moduleor the UMTS radio. Fifthly, we provide a deep investigationby means of emulation to show that the system can: esti-mate and predict system conditions and mobility; lower theenergy consumption considerably; and remain robust whenfaced with changing system conditions. Finally, we imple-ment EnTracked and use this prototype in a real deploymentto gather results showing that the real system works as pre-dicted by the emulation.

The remainder of this paper is structured as follows: InSection 2, we present the relevant related work. Subse-quently, we present our proling results and propose a devicemodel that can account for the real power consumption ofa device. Then we introduce the EnTracked System in Sec-tion 4. The results from evaluating our system by meansof emulation are presented in Section 5. In Section 6 wediscuss our implementation and the results of our real-worlddeployment. Finally, in Section 7 we provide a summarizingdiscussion and Section 8 concludes the paper and providesdirections for future work.

2. RELATED WORKAs mentioned earlier, existing research have proposed dy-

namic tracking for updating position information about atarget. Previous works such as [7, 13, 14] study dynamictracking to minimize communication and to minimize theload on server nodes by lowering the number of position up-dates. Leonhardi et al. [14] study time-based and distance-based tracking that takes a constant positioning accuracyand target speed into account. They study by simulation thenumber of updates each tracking technique produces and theaverage and maximum uncertainty of the server-known posi-tion. They have later extended this work for tracking basedon dead-reckoning [13]. Systems that tries to minimize thenumber of position updates for a specic application such asGeoPages have also been proposed [6].

A later work focusing on both energy eciency and GPSpositioning is Farrell et al. [8]. They propose methods thattake into account a constant positioning delay, target speed,and stress the importance of the fact, that it is not energy-free to use the GPS constantly as assumed by earlier work.The methods have been evaluated by simulation, where theycan save around 50% energy in the evaluated scenarios as-suming an instantaneous power model. They have later ex-tended this work for area-based tracking where they alsotake constant position accuracy and communication delaysinto account.

For sensor networks, Tilak et al. [19] propose dynamictracking techniques that take into account target speed andheading. They assume that the positioning uncertainty isnegligible. They evaluate the methods by simulation forproximity-based sensor network positioning. For an indoorsensor network setting, You et al. [20] propose dynamictracking techniques that take into account a constant po-sitioning accuracy and delay, target speed and accelerationto detect if the target is moving or not. They evaluate thetechniques by emulation for IEEE 802.15.4 signal-strength-based indoor positioning and one of their results is that con-siderable energy savings can be gained from the use of anaccelerometer to detect if the target is stationary or not.

In comparison, our work proposes techniques that takeinto account dynamically estimated position accuracy anddelays, communication delays, power constraints, target speed

222

and acceleration (to detect if the target is moving or not).Furthermore we evaluate our techniques both by emulationand in real-world deployments.

3. DEVICE MODELTo be able to dynamically track a mobile device robustly

and energy-eciently we require a device model that can ac-count for the delays and power consumption of the device.If we do not have such a model we cannot make decisionsthat will minimize the power consumption and make posi-tion updates within required limits. As motivated in the in-troduction previous research have assumed a simple, instan-taneous power model. When using a more detailed model,one drawback is that it depends on more device dependentparameters, therefore we discuss how such parameters auto-matically can be estimated and the generality of the modelin Section 7.

The proposed model is based on proling the delays andpower consumption of a Nokia N95 8GB2 mobile phone.The N95 is a 3G phone with an internal GPS module anda triaxial accelerometer, both of unspecied brand, and a1200 mAh battery. The main contributors to the delays andpower consumption of the phone are the individual compo-nents used in the N95 and as such we hypothesize that theproposed model is generalizable to a wider range of phonesthan just the N95. The phone runs the Symbian 60 oper-ating system version F1. We measured the power consump-tion of the phone by using the Nokia-developed tool NokiaEnergy Proler [2] version 1.1. The Nokia Energy Prolertool has been built by Nokia to enable developers to ana-lyze the power consumption of mobile applications and itsupports a power-sampling rate of 4Hz. To measure thedelays and power consumption of dierent features, severalPython scripts have been developed that enable and disablefeatures and measure various delays. The Python scriptsrun on the N95 with the aid of the Python Interpreter forS60, version 1.4.4 [3] and the included library that providesaccess to phone features such as the internal GPS and thetriaxial accelerometer. The internal GPS supports a sam-pling rate of 1Hz and the triaxial accelerometer a samplingrate of 30Hz. For the measurements involving sending datausing the phones UMTS radio, a TCP/IP server was imple-mented in Java and deployed on a server connected to theinternet and with a public IP address that the phone wasable to connect to over UMTS.

The proposed device model consists of two parts: a powermodel that describes the power usage of the phone; and adelay model that, for instance, describes the delays whenrequesting a phone feature, e.g., the time it takes for theGPS to return a position. In both models we consider thefollowing phone features:

accelerometer (a)

GPS (g) radio idle (r)

radio active (s) idle (include Python and Nokia Energy Proler) (i)

2For the remainder of this paper the Nokia N95 8GB phoneis abbreviated as the N95 phone or simply N95

These are the features that we nd relevant for phone track-ing, idle is not strictly a feature, but is included in thepower model for completeness. For interactive user applica-tions on the device, one would also need to take into accountthe power usage of features such as the computations of theapplication logic, the key strokes, camera use, and screenuse.

The power model consists of two functions dened in Equa-tion 1: the power function power and the consumption func-tion cd,p where d is a features power-o delay and p itspower consumption.

power(T ) =PT

t=1 ip + cad,ap(at) + cgd,gp(gt)

+ crd,rp(rt) + csd,sp(st)

cd,p(x) =

(p if x d

(1)

The equation uses the variables at, gt, rt, st for the dier-ent features listed in the feature list above. Each variabledenotes, at time step t, the number of seconds since the fea-ture was last powered o (a variable is zero if the featureis in use in the current time step t). Since the idle powerconsumption is constant no variable it is introduced. Fur-thermore the parameters ip, ap, gp, rp, sp denote the powerconsumption of a feature, e.g., 0.324 watt for the N95 inter-nal GPS. The parameters ad, gd, sd, rd denote the number ofseconds a feature takes to power o after last use, e.g., 30seconds for the N95 internal GPS. The values of the param-eters will be determined in Section 3.1 and Section 3.2 fromtraces collected from a N95 phone.

The delay model is given as two functions reqg, reqs thatdescribe the request delays for the GPS and for activatingthe radio for sending. For the other features the requestdelays are negligible in our case, because they are below100 milliseconds. The functions are dened and their valuesdetermined in Section 3.2.

3.1 Power ConsumptionTo determine the power parameters ip, ap, gp, rp, sp we

have collected a number of power consumption traces with aN95 phone with dierent features enabled and disabled. Be-fore each trace collection and before all other of our experi-ments, the phone was fully charged to counter the inuenceof the non-linear voltage decrease of batteries [5]. First, theNokia Energy Proler application was started. Then thepython interpreter was started with a Python script thatenabled or disabled certain features for a specic amountof time. The total script running time was ve minutesfor these measurements. Then the Python interpreter wasclosed and the Nokia energy proler was stopped. The powerconsumption trace collected with the Nokia energy prolerwas exported to a le. These traces were trimmed to re-move the consumption logged while the Python script wasnot running and when the screen was powered on. The aver-age feature consumptions were calculated from the trimmedtraces and is listed in Table 1. In the model we use theaverage values for the parameters. Table 1 also lists thestandard deviations. As these values are rather small, usingthe average value in our model is a reasonable choice. Justfor reference, we also measured the power consumption of

223

the screen, which is around 0.2 watt. However, as discussedearlier we do not use this value in our device model.

Table 1: N95 features power consumption.

Feature Avg. Power [watt] Std. Dev. [watt]Idle (ip) 0.0621 0.0173Idle (ip) + Logging 0.0647 0.0197Accelerometer (ap) 0.0503 0.035GPS (gp) 0.324 0.0435Radio idle (rp) 0.466 0.0324Radio active (sp) 0.645 0.0470

3.2 DelaysThe delay model includes two types of delays as intro-

duced earlier. The rst is request delays, which is the timea feature uses to get operational. The second type is de-lays when powering o, which is the time a feature takes topower o after the last usage.

3.2.1 Request DelaysThe request delays have been measured using the same ex-

perimental setup as described in Section 3.1, but with twochanges. First, for GPS request delays the Python scriptslogged the time dierence in the internal clock between re-questing a GPS measurement and the moment when a posi-tion was returned. Second, for the radio request delays thePython script logged the timestamp provided by the GPS foreach position. This timestamp is taken at nearly the sametime as when the Python script starts to request a TCP/IPconnection to the server and on the server the Java appli-cation logged the time of data reception. The server wascongured to synchronize its time using the Network TimeProtocol [16] which can synchronize the clock to a precisionof tens of milliseconds over the internet. The radio requestdelay was then measured as the dierence between the GPStimestamp and the reception timestamp on the server. Thisdierence includes both the time to activate the UMTS radioand the transmission time of the packet data.

A trace lasting fourteen hours was collected in order tomeasure the GPS request delays for varying periodic inter-vals between requests. For periodic intervals shorter than85 seconds, the interval was increased one second for everyve repetitions, while for periods equal to or longer than 85seconds the increase step was ve seconds. The collectedtrace is plotted in Figure 2(a) and shows that the requestdelays depend on the periodic interval between requests.

When a GPS device starts up it has to acquire the car-rier frequencies on which the satellites send their signalsand get data about the satellites orbits, also known asephemeris data [10]. The used N95 had Assisted GPS en-abled, which means that the GPS receives the approximatesignal frequencies, the ephemeris data, and other relevantdata through the cell network, which speeds up the acqui-sition process. The GPS still has to tune to and synchro-nize with the actual signals. This process can take severalseconds depending on the GPS device in use. The reasonwhy the GPS has to tune into the actual carrier frequenciesis that, due to eects such as the Doppler eect, the sig-nal frequencies are shifted on their way from the satellites.From Figure 2(a) one can note that with periods above 30seconds the GPS has to use at least ve seconds to lock-on

to the signals and estimate its position. With periods be-low 30 seconds it only takes around one second. The reasonfor this is that the 30 seconds period matches the power-odelay for the GPS module (this value is determined later inthis Section). So for 30 seconds after the last GPS requestthe GPS power is kept on and the GPS is locked on to thesignals and therefore it does not have to re-acquire the sig-nals. When the GPS powers o, it looses the signal locksand has to start over again. From the results we notice thatwith higher periods a longer acquisition time is needed to re-acquire a signal lock. Based on these results we have chosento model the GPS request delays as the function reqg givenin Equation 2 which depends on whether the periods beingbelow or above the 30 second limit. As can be noticed fromFigure 2(a), sometimes it takes even longer than 6 seconds,so to favour robustness over energy-eciency, one could setthis value higher. In comparison, previous work [9] uses aconstant value of 0.5 seconds for the GPS request delay.

reqg(x) =

(1 if x 30

reqr(x) =

(0.3 if x 6

(2)

To determine the UMTS radio request delay a trace last-ing 30 minutes was collected. During this trace data wassent from a N95 phone to a server over UMTS with dierentperiods. The collected data cover periods from one secondto fteen seconds and is shown in Figure 2(b). From Fig-ure 2(b) we can observe that with a period of less than 6seconds, the radio request delay is very short, around 300milliseconds. Above 6 seconds it is around 1100 millisecondswith some uctuations. The limit of 6 seconds matches thepower-o delay for the radio from active to idle, determinedlater in this section. The reason is that when the radio pow-ers o it can take the radio up to several seconds to be ac-tivated again as stated in the technical report published byNokia [17]. The uctuations can be explained by variationsin the communication path from the phone to the serverover both the cellular network and the Internet, e.g., lostpackets and delays. Based on these results we have chosento model the radio request delay as the function reqr givenin Equation 2. For both the function reqg and reqr we havefocused on the average case which (because of the existenceof higher delays) trades energy-eciency over robustness.

3.2.2 Power-Off DelaysThe power-o delay which is the time a feature takes to

power o after the last usage has also been measured usingthe same experimental setup as described in Section 3.1. Todetermine the power-o delays, thirty minutes of data wascollected where each minute, a GPS position was requested,then when a position was returned the position data was sentto a server and when the data was sent, the connection wasclosed. To determine the power-o delays, the power con-sumption traces were manually inspected and timestampsfor the enabling and disabling of dierent features were en-tered into a trace le. The enabling and disabling of a fea-ture could be determined from knowledge about the collec-tion procedure and from knowledge about the power con-sumption of each feature, as determined by the experimentspresented in Section 3.1. From the entries in the trace le

224

0 2 4 6 8

10 12 14 16 18

0 50 100 150 200 250 300

Del

ay [s

econ

ds]

Time between updates [seconds]

(a) GPS request delays

0

2

4

6

8

10

0 2 4 6 8 10 12 14 16

Del

ay [s

econ

ds]

Time between updates [seconds]

(b) Radio request delays

Figure 2: Request delays for GPS and the radio fordierent periods between requests on a N95.

Table 2: N95 power-o delays for features.

Feature Avg. [second] Std. Dev [second]GPS 30.0 0.735Radio idle 31.3 0.337Radio active 5.45 0.774

the values listed in Table 2 were calculated. The results in-dicate that the power-o delay for the GPS and for radioidle is around thirty seconds and a little below six secondsfor radio active. The power-o delay for radio idle is rela-tive to when radio active has powered o to idle mode. Thereason no power-o delay is listed for the accelerometer isthat the accelerometer did not power o when requested toby our Python code. Only when the interpreter was stoppedthe power consumption dropped for the accelerometer. Fur-thermore the accelerometer uses an order of magnitude lesspower than the radio and the GPS. Therefore the accelerom-eter is treated in the same manner as the idle consumption,i.e., as a constant power usage.

3.3 Device Model ValidationTo validate the proposed device model, we now compare

the average power consumption for the periodic samplingcalculated with this new model to the power consumptiontraces collected on a N95 phone. These traces were men-tioned earlier in Section 1 and have not been used in theabove sections to derive the model. Therefore they can beused to validate that the model can explain the power con-sumption of a real phone with high precision. Figure 3(a)plots data from the collected trace for 60 seconds periodictracking, overlaid with the predicted power consumption of

the two other models. We can see how the proposed modelclosely matches the real power consumption, whereas the in-stantaneous model does not. Average values have also beencalculated for a 30-minute scenario, which match the lengthof the traces collected on the N95 phone. The results of thecollected traces and the two models have been plotted in Fig-ure 3(b). The results show that the new model can describethe power consumption of a real phone with a much higherprecision. Therefore this model can be used to inform thedesign of our tracking techniques towards minimizing thepower consumption, whereas the instantaneous model hasmisinformed earlier research.

0

0.5

1

1.5

2

0 50 100 150 200 250

Pow

er [w

att]

Time [seconds]N95 measured

Instantaneous ModelProposed Model

(a) Over time for 60 seconds periodic track-ing

0

0.5

1

1.5

2

0 60 120 180 240 300

Pow

er [w

att]

Time between updates [seconds]Nokia N95

Instantaneous ModelProposed Model

(b) Average values

Figure 3: Power consumption on a Nokia N95, withthe instantaneous model and the proposed model.

4. ENTRACKEDThe goal of EnTracked is to dynamically track mobile de-

vices in both an energy-ecient and robust manner. Thus,robust, position updates have to be delivered to applicationswithin application-specied error limits, where error refersto the distance between the application-known position andthe real position of the device. Given that in this paperwe focus on pedestrian targets we can assume that there isan upper threshold on target speed vmax which we assumeto be 10m/s. Furthermore, the focus on pedestrian targetsguides us how to detect whether the target is moving or notby using an accelerometer.

To use EnTracked, position-based applications have toprovide error limits that they want targets tracked with.But one might ask if it is the case that position-based ap-plications always want the highest possible accuracy. Inpractice application providers will be motivated to minimizetheir applications power consumption by providing limits

225

because users will stop using their applications if they expe-rience that they quickly drain their devices battery. Privacyrestrictions might also provide error limits if users specifylower limits for the granularity of which an application isallowed to track them with. Another option is that usersthemselves can decide how they want to trade applicationexperience with energy eciency by setting the limits them-selves.

For a lot of applications it is also possible to calculaterelevant error limits. A map application, that shows thepositions of a number of mobile devices, can use the zoomlevel to determine relevant error limits (such as 25 metersfor street-level view, 100 meter for a suburb, and 200 meterfor a city-wide view). Another example is the many typesof social networking applications that focus on relationshipsbetween the positions of devices, for instance, to detect whenpeople come into proximity or when they separate. Methodshave been proposed to eciently track devices to reveal re-lationships, such as the ones proposed by Kupper et al. [12].The methods work by dynamically assigning tracking jobswith changing error limits that they calculate based on thedistance between the targets. Such methods produce track-ing error limits ranging from 10 meters to several kilometres,depending on the distance between the devices.

When a position-based application requests to use En-Tracked the steps illustrated in Figure 4 are carried out.Firstly, an application issues a request for the tracking of adevice with an error limit (1). Secondly, the server propa-gates the request to the client-side part of EnTracked (2).Thirdly, the client nds a start position and returns it throughthe server to the application (3)+(4). Fourthly, the En-Tracked client logic schedules features to deliver the nextposition within the error limit (5). Fifthly, at some pointlater EnTracked determines that a new position has to bedelivered to the client through the server (6)+(7). If sev-eral applications requests tracking for the same device, En-Tracked congures the device for tracking with the smallestrequested error limit to full both of the applications limits.

Position-based Application

EnTracked (Server)

EnTracked (Client="D8377")

Track "D8377",100m

Track 100m

(56.10,10.32)

(56.10,10.32)

(56.12,10.34)

1

2

3

4

EnTracked Client Logic

6

(56.12,10.34)

7

5

Figure 4: The steps of EnTracked when used by aposition-based application.

When a request has been received by the EnTracked client,the client handles the request following the steps illustratedin Figure 5. To return the initial position to the server aGPS position is requested (1) and reported to the server

Start

Get GPS Position

Report Position to Server

Is device moving?

Determine Speed with GPS

Determine Time Limit

Minimize Consumption

Schedule Features

Schedule GPS now?

False True

FalseTrue

1

2

3

4

5

6

7

8

Figure 5: Flow chart of the EnTracked client logic.

(2). Then, using the accelerometer-based method presentedin Section 4.1, it is determined if the device is moving or not(3). If not, the logic waits for movement. When moved, thespeed of the device is determined using GPS measurementsas described in Section 4.2 (4). Then, using the error modelpresented in Section 4.3, a time for the next GPS positionreading is calculated (5). This time limit is then given toa dynamic programming algorithm proposed in Section 4.4,that based on the current power state of device features nds the optimal strategy for minimizing the power con-sumption for this time limit and how to schedule featuresto satisfy the limit considering both possible GPS and radiodelays (6). Then, the logic follows the scheduling plan cal-culated by the dynamic algorithm (7), restarts the processwhen appropriate (8), and returns the next GPS position tothe server.

4.1 Detecting MovementMovement can be detected by using accelerometers and

has been proposed previously for indoor dynamic trackingby You et al. [20]. The Nokia N95 as many other mo-bile devices has a triaxial accelerometer which is used byEnTracked for movement detection. EnTracked only detectstwo states of movement, i.e. standing still and moving. Aswe have a robustness requirement stating that we have toposition within a certain limit, we are interested in a detec-tion scheme that has a low tolerance for movement, whichwill ensure that we detect movement very well. We haveused the following scheme for movement detection: rst, anaccelerometer measurement is collected for each of the threeaxes; next, for each axis the variance of the last 30 mea-surements is calculated and the three variance values aresummed. In Figure 6 we have plotted such summed variancevalues for a trace of accelerometer readings collected for aperson that, at rst is standing still, then starts walking andthen stops again. Figure 6 also plots a manually collectedground truth for when the person was moving. From Figure6 we can see that there is a noticeable dierence in variancebetween standing still and moving. To detect movement, weuse a threshold which was selected to be 1000 based on thereceiver-operating-characteristic curve plotted in Figure 7 tohave an equal tradeo between detecting still (true positiverate) and not detecting movement (false positive rate).

As the device running EnTracked could be carried and

226

0

1000

2000

3000

4000

5000

0 100 200 300 400

Var

ianc

e fo

r acc

eler

atio

n da

ta

time in millis

Acceleration Variance Ground Trurth Speed

Figure 6: Summed variance for each of the axes overaccelerometer data for 30 measurements.

90

92

94

96

98

100

0 2 4 6 8 10

True

Pos

itive

Rat

e

False Positive Rate

Threshold Results Selected Threshold

Figure 7: Receiver-operating-characteristic curvewith positive as detection of the device being still.

handled in many dierent ways, this might cause false de-tections. If a person is stationary, but gesturing with thedevice in hand the accelerometer will detect this movement,which will increase power consumption. If a person is walk-ing with the device in hand, and keeping the device steady,there might not be enough acceleration in any direction forthe variance to reach the threshold for movement detection.This poses a problem and can only be solved by using amore clever movement detection scheme such as the onesproposed by Reddy et al. [18]. However, for EnTracked onlyone sudden move with the device will make the state changeand then speed estimation based on GPS measurements willkick in.

4.2 Estimating SpeedThe movement speed of a mobile device vest can be es-

timated from GPS measurements vgps, however, we needto analyse whether or not it is reliable. GPS modules nor-mally implement a Kalman lter to estimate the speed ofthe GPS [10] from GPS positions and measured Dopplershifts of the satellite signals. Therefore we choose to usethe GPS module estimated speed because it gives more ac-curate speed estimates compared to the method used byearlier work such as [8], that only takes into considerationthe time dierence and distance between the two last GPSpositions received from the GPS. In order to evaluate theaccuracy of the GPS-estimated speed vgps, we compare itwith the ground truth speed vgroundtruth. The ground truthspeed is calculated by interpolating between manually col-lected timestamps for the visiting of well-known referencespots while collecting GPS measurements. Using a subsetof our trace data collected for emulation, we have plottedvest compared to vgroundtruth in Figure 8. From the gurewe see that vgps tends to correlate with vgroundtruth. Asvgps in many situations is underestimated, we have plottedvgps + vaccuracy in Figure 8. vaccuracy is the estimated accu-racy of the estimated GPS speed vgps provided by the GPS

module. vgps + vaccuracy is generally overestimated, whichimproves the robustness of the system. However, at very lowspeeds the GPS speed is largely overestimated because thevalue of the estimated accuracy is high. Therefore, for de-tecting stationary situations we rely on movement detectionwith an accelerometer as presented in Section 4.1.

In order to save power, we are interested in turning o theGPS, so that it doesnt consume unnecessary power. Whenthe GPS has been put to sleep for some time, we need toknow at what point we are able to trust the speed mea-surements provided by the GPS. Though we want to knowthe speed as quickly as possible, we dont want to use thespeed measurements until they give us the required accu-racy, which may vary depending on how long the GPS hasbeen sleeping and the number of measurements vgps is basedupon. We have investigated the number of necessary GPSmeasurements needed in order to get a vgps with sucientaccuracy. Figure 9 plots measurements where the GPS isput to sleep for a varying period of time and restarted. Af-ter restart, vgps based on one through four measurementshave been collected, and the dierence between vgps andvgroundtruth is calculated. During this test vgroundtruth isequal to zero meters per second. For reasons that we willnot investigate as a part of this work, there are some speedmeasurements that the used Python library returns as nota number. In order for such cases not to be neglected, theyare placed at the top of the graph (from 7.6 m/s for 4 mea-surements and up to 7.9 m/s for 1 measurement), but mustnot be considered valid, inaccurate measurements.

According to Figure 9, it seems that one GPS measure-ment is sucient as long as the GPS doesnt sleep morethan 30 seconds between measurements. However, as thesleeping period rises to 30 seconds or more, one, two andthree measurements become insucient. From 30 secondsonwards, it seems that four measurements provide the bestspeed measurements with some inaccuracy.

4.3 Error ModelFor calculating the time limit for when to deliver the next

GPS measurement to an application, we use the followingerror model inspired by the error model proposed by Ferrellet al. [9]. This error model takes into account the estimateduncertainty of the last GPS position delivered to the applica-tion ugps, the time since the last GPS position tgps, and theestimated speed vest (as described in Section 4.2). The errormodel then calculates the current error emodel with respectto the last delivered GPS position as dened in Equation 3.

emodel = ugps + (t tgps) vest (3)As an estimate for the uncertainty of a GPS position, we

use the horizontal accuracy outputted by the GPS in theN95 phone. Most GPS modules are able to output suchinformation calculated based on the quality of the satellitesignals and the quality of the signal processing. The hori-zontal accuracy outputted in Symbian OS is specied to bethe 68% error quartile [1], which means that in 68% of thetime the error should be less than this value. For one of thetraces collected for our emulation, we have plotted the realerror of a GPS position versus the horizontal accuracy forthe GPS position in Figure 10. The real error was calculatedwith respect to a manually entered ground truth. From theplot, we can see that the real error is largely overestimated,and to get an on-average more precise estimate, we choose to

227

0

0.5

1

1.5

2

2.5

3

3.5

4

0 0.5 1 1.5 2 2.5 3

GPS

Spe

ed [m

/s]

Ground Truth [m/s]Speed Speed + Accuracy

Figure 8: GPS speed versusground truth speed.

0

1

2

3

4

5

6

7

8

0 10 20 30 40 50 60

Diff

eren

ce [m

/s]

Time between requests [seconds]1 fix 2 fixes 3 fixes 4 fixes

Figure 9: Wake-up speed measure-ments.

0

10

20

30

40

50

60

70

0 5 10 15 20 25 30 35 40

Hor

izon

tal A

ccur

acy

[mete

r]

Real Error [meter]Raw

Uncertainty Mapped g(x)=3.71*x

Figure 10: Real error versus hori-zontal accuracy

use a linear model g(x) = a x to map the horizontal accu-racy outputted by the GPS. The parameter a was found byusing linear regression on the trace entries for the followingequation g(x) = a x 2; the 2 was added to (on-average)optimize the error to be overestimated with 2 meters. Thisvalue can be changed to trade power eciency (with small-est possible uncertainty values) and robustness (with largelyoverestimating uncertainty values). Figure 10 also plots thevalues that have been mapped by the linear model. Eventough the values are mapped, most still overestimate theerror to keep favouring robustness.

The calculation of the time limit for the next GPS po-sition tlimit is based on the application-dened error limitdlimit, the current error emodel (using Equation 3) and theestimated speed vest. The limit is found, using Equation4, as the time it will take the device to move beyond theapplication limit considering the current error with respectto the last delivered GPS position.

tlimit =dlimit emodel

vest(4)

4.4 Minimize ConsumptionTo minimize the power consumption and to be robust

based on the time limit, we need to calculate when to powerfeatures on and o. This calculation has to take into ac-count the delays for powering o features and the requestdelays when powering features on again. To calculate whento power features on and o, we have formalized the problemas a minimization problem for a set of recursive functionsas dened in Equation 5. The problem is dened for thevariables g, r, s that denote the number of seconds since theGPS, radio idle, and radio active, respectively was requestedto start powering o. The problem is to nd g, r, s (thatdenote the variable states when the features should be pow-ered on again) in comparison to g0, r0, s0 (the feature stateswhen calculating a solution to the minimization problem).The problem also takes into account the upper time limittlimit as dened in Equation 4.

reqg(x) =

(1 if x 30

reqs(x) = 1

Cu,p(t, x, x0) =

8>>>>>>>>>:

0 if t = 0, x = x0

p + Cu,p(t 1, x) if t > 0, x = 0Cu,p(t 1, x 1) if t > 0, x > up + Cu,p(t 1, x 1) if t > 0, 0 < x

Emulated Phone N95

Entracked Client Engine

MovementMinimal

Consumption

GPSLogged GPS / Acceleration Accelerometer

Error Model

Power Model

Energy Profiler

Figure 11: System architecture for emulation anddeployment

we can exchange the N95 phone with an emulation engine.The emulation engine reads data les of the same formatas the ones used for the analysis of the phone characteris-tics. The output of running the EnTracked client on topof the emulation engine contains the same information asrunning it on the actual N95 phone. Furthermore the emu-lation engine outputs information on the state of the phoneat all emulation time steps. This state information is used incombination with the normal output to calculate power con-sumption and robustness for various runs of the EnTrackedclient.

To evaluate the power consumption of EnTracked, we se-lected a number of parameter variations to emulate. Thedata used for emulation was collected using a N95 phonethat continuously sampled the GPS position and the ac-celerometers while walking a predetermined route. Duringthis data collection, the actual position was recorded man-ually on a small laptop. Based on the collected data wecorrelated the phones actual positions with the positionsreported by the GPS. We made three data collection runson the route shown in Figure 12, each lasting approximately35 minutes and the percentage of stationary time is 67.1%.The route runs through a parking lot and has a length of 700meters. We kept the phone stationary for several minutesat three locations, marked in the gure. During the run wemade sure only to walk in straight lines and we registeredthe actual position every time the direction was changed.Furthermore we made sure to maintain a steady pace be-tween these points, which allows us to calculate a reasonableestimate of the ground truth speed.

We evaluated EnTracked as described in Section 4 and aperiodic sampling algorithm in the emulation system. Herewe present three emulations: one for which the goal for thepositioning precision was dened to be 25 meter, i.e., thesystem should never report a position that is more than 25meter from the actual position of the phone; one for whichthe goal was 100 meter; and one for which the goal was200 meter. These limits corresponds to the value dlimit inSection 4.3.

A naive approach to obtain the required precision, whilestill conserving some power compared to continuous sam-pling, is to sample the position at an interval small enoughthat it would be impossible to move outside the area boundedby the requested precision between GPS xes. Assumingthat the GPS device is carried by a pedestrian these inter-vals is every 2.5th second, every 10th second and every 20thsecond for 25 meter, 100 meter and 200 meter respectively3.

3The interval is based on the assumption that it is very

Figure 12: Route used for collection of emulationdata. (0.7km)

We denote this sampling strategy by the name the periodicstrategy. For the emulation, the EnTracked algorithm waslimited to the desired precision and in the case that the GPSestimated speed was returned as not a number we set thespeed to the maximum possible speed of 10 m/s.

5.1 RobustnessOur robustness goal is that the real error must remain

below a given application limit. We have analyzed the ro-bustness in our emulations for the dierent strategies bycomparing the last GPS position sent to the server with theground truth known position. The real error is calculatedas the dierence between these two positions. In Figure 13and Figure 14 we compare the real error for 10 and a 20seconds periodic strategies with EnTracked congured witha limit of 100 meters and 200 meters, respectively. Fromthe gures we see that when EnTracked detects the deviceis stationary, it does not update the position and when itdetects that the device is moving, it schedules sleeps de-pending on the movement speed. During the sleep periodsthe error increases until the sleep ends and a new GPS po-sition is provided. The longer sleeps for EnTracked with a200 meter limit can also be seen.

0

50

100

150

200

0 200 400 600 800 1000 1200 1400 1600

Erro

r [me

ter]

Time [seconds]Periodic EnTracked Limit

Figure 13: Real error in emulation with a limit of100 meter and a periodic strategy.

unlikely that a pedestrian moves faster than the world recordfor 100 meter dash

229

0

50

100

150

200

0 200 400 600 800 1000 1200 1400 1600

Erro

r [me

ter]

Time [seconds]Periodic EnTracked Limit

Figure 14: Real error in emulation with a limit of200 meter and a periodic strategy.

Table 3: Robustness results as average error andpercentage of time above the error limit.

Periodic EnTracked() EnTracked

Avg.[m]25m 8.2 8.4 7.8100m 8.6 16.4 10.6200m 9.6 24.4 14.3

Limit25m 2.0% 3.2% 2.2%100m 0.0% 0.0% 0.0%200m 0.0% 0.0% 0.0%

The robustness results for both the periodic strategies andEnTracked and EnTracked() with the limits 25 meter, 100meter and 200 meter are summarized in Table 5 as the av-erage real error and the percentage of time the real errorwent above the threshold limit. EnTracked() is our sys-tem but without movement detection. The average error isgreater for EnTracked() because it only schedules sleeps.The reason why the average error is greater for EnTrackedwith a 200 meter limit than for 25 and 100 meter is that witha limit of 200 meter, longer sleeping periods are scheduledcompared to the 25 and 100 meter limits. This also enablesEnTracked with the 200 meter limit to provide better energysaving. The reason that the limit is crossed when conguredto 25 meter is that a single bad GPS measurement can havean error above the limit.

5.2 Energy EfficiencyBased on the emulations we have calculated the power

consumption of dierent periodic strategies and EnTrackedusing the device model described in Section 3. In Figure 15and Figure 16 we compare the power consumption for: a10 and a 20 seconds periodic strategy; EnTracked cong-ured with limits of 100 meters and 200 meters. From thegures we see that when EnTracked detects the device tobe still, no position updates are produced, thus the powerconsumption drops signicantly because the GPS and theradio can be switched o. During movement, sleeps arescheduled and depending on their length, the power usagedrops signicantly. The periodic strategy on the other handhas a repeating static power consumption pattern and neverdrops signicantly because the GPS and radio can never beswitched o.

Table 4 summarize the power usage of the periodic strate-gies and EnTracked and EnTracked() for limits of 25m,100m and 200m. Furthermore the power savings as the per-cent savings in comparison to the power use of continuous

Table 4: Power consumption

Periodic EnTracked() EnTracked

Avg.[W]25m 1.468 1.351 0.781100m 1.331 0.851 0.710200m 1.264 0.608 0.600

Savings25m 0.0% 6.89% 43.36%100m 9.19% 40.55% 48.73%200m 13.58% 56.05% 56.20%

sampling which in our case is similar to a one second peri-odic strategy. From the table we can see that EnTrackedsaves considerably more power than the periodic strategy.The fact that the EnTracked strategy uses motion detectionallows it to save power proportional to the time the deviceis stationary. Even without using the motion detection wecan see that the EnTracked client should be able to conservea fair amount of power, compared to the periodic strategy.With a limit of 200 meter EnTracked() nearly saves asmuch power as EnTracked because it is able to schedulelong sleeps on low estimated speeds. However, if the deviceis suddenly moved the EnTracked() might sleep while theerror limit is crossed, because a long sleep has been sched-uled. This makes EnTracked preferable over EnTracked().

0

1

2

0 200 400 600 800 1000 1200 1400 1600

Pow

er [w

att]

Time [seconds]Periodic EnTracked

Figure 15: Emulated power consumption with alimit of 100 meter and a periodic strategy.

0

1

2

0 200 400 600 800 1000 1200 1400 1600

Pow

er [w

att]

Time [seconds]Periodic EnTracked

Figure 16: Emulated power consumption with alimit of 200 meter and a periodic strategy.

6. REAL-WORLD VALIDATIONIn this section, we present our results obtained from pro-

totype deployment during a period of more than one week.The system was deployed for tracking of pedestrian targetsin both a residential neighborhood, as shown in Figure 17

230

and a larger part of the city of Aarhus in Denmark. In theresidential-neighborhood deployment, the system was eval-uated for energy-eciency and robustness. For the city de-ployment the system was evaluated for tracking everydaymovements of an oce worker focusing on energy-eciency.

We deployed EnTracked in three dierent versions to eval-uate some of our design choices in the deployment. First,EnTracked with all functionality. Second, EnTracked(),without movement detection as described in Section 5, Third,EnTracked() both without movement detection and onlyusing a single GPS measurement when estimating speed in-stead of the selected four. For the deployment we used sev-eral N95 phones installed with our EnTracked client, Pythonfor S60 and the Nokia Energy Proler. For the deploymentswe used the same implementation of our client as used foremulation only this time connected to the real GPS, ac-celerometer and UMTS radio on the N95 phones as illus-trated in Figure 11. The deployed clients were conguredwith a special phone ID for each phone to enable the serverto identify the dierent clients and dierent application lim-its that we wanted to test. All other client settings werekept as described in the previous sections of this paper.The clients also logged the state they were in. The serversetup used for power proling, as described in Section 3, wasreused for the deployments.

Figure 17: Residential neighborhood overlaid withwalking route and stop points.

In the residential neighborhood deployment, a person walkedalong a pre-congured route while carrying several phonesattached to a small laptop. The route is shown in Figure 17,it has a length of 1.7 kilometres and contains three stoppoints highlighted by markers (one of them used twice). Atthe stop points the person would rest for around ve minutesbefore continuing. The purpose of the route is to mimick-ing a person walking around in a neighborhood, stopping atcertain points to chat with neighbors. The person walkingthe route was instructed to change walking speed from slowwalk around 1 m/s, over moderate speed, around 2 m/s tofast run/jog, around 3 m/s making the system deal withdierent speeds. Including stopping time, it took around 35minutes to walk the route. The route was repeated threetimes. In the rst run, the phones was kept still 51.0% ofthe time, in the second 51.8% of the time and in the third54.3% of the time. A manually entered ground truth wascollected on the laptop using the same method as described

in Section 5. Before the person started each repetition theNokia Energy Proler was started on all phones and followedby the EnTracked client. When nishing with the route theNokia Energy Proler was stopped and trace les exported.

The route was repeated three times with three, three,and four phones respectively. In the rst, second and thirdrun, two phones ran EnTracked(), EnTracked(), and En-Tracked, respectively. One phone was congured with alimit of 100 meter and the other with a limit of 200 me-ter. The reason we left out the 25 m limit is that with a 25meter limit during walking as shown in Section 5 our strate-gies will only set the phone to sleep a few seconds at most.Therefore this limit is a less interesting scenario than thehigher limits that generate higher sleeping times and there-fore are more challenging for our system. The third phonein each of the repetitions had a one second periodic strategyinstalled to gather reference data for calculating the averageGPS accuracy in the area. We have calculated this averagevalue from the gathered data to be 9.04 meters. The fourthphone in the third repetition ran EnTracked with a 100 me-ter limit but without the uncertainty mapping described inSection 4.3 to favour robustness over energy-eciency.

6.1 RobustnessOur robustness goal is that the real error must remain

below a given application limit. We have analyzed the ro-bustness in our deployments by comparing the GPS posi-tion known at the server to the ground truth known posi-tion. Figure 18 and Figure 19 plots the errors of the serverknown positions with EnTracked for the limits of 100 me-ter and 200 meter, respectively. The plots also show thelimit and the state of the client: detected to be stationaryfrom accelerometer (A), sleeping until next scheduled GPSmeasurement (S) and getting GPS position and sending newposition to server (G/R).

From Figure 18 we can observe that the position knownat the server is less than the 100 meter limit, except in onesituation. Furthermore we see that the accelerometer quiteaccurately detects the four resting periods and that uponmovement, GPS measurements are read and the client is re-quested to sleep until the next scheduled GPS measurement.The scheduled sleeping periods are on average around 30 sec-onds with short periods down to 6 seconds and a few longones up to 102 seconds. It was the sleeping period of 102seconds that created the situation where the algorithm wentabove the limit. In this situation the speed was estimatedto 0.839 m/s and the error of the current position estimateto 5.82 meters. From these numbers the system calculateda sleeping period of 102 seconds. From the gure we can seethat the current error was actually lower, around 1 meter,but what happened is that the person actually speeded upto a speed of 1.59 m/s instead, thus letting the error crossthe limit.

The EnTracked client uses the parameters selected in Sec-tion 4. These parameters are selected to prioritize robust-ness and energy-eciency equally. However, our system canbe congured to have dierent prioritizations, which canhelp avoid situations, where the error can cross the limit.As stated earlier a version of EnTracked without the uncer-tainty mapping proposed in Section 4.3 was also deployedand the result is shown in Figure 20 overlaid on the errorgraph for the normal EnTracked version with a limit of 100meter. From the gure we can see that for EnTracked with-

231

Table 5: Robustness results for dierent versionsand limits.

EnTracked() EnTracked() EnTracked

Avg.[m]100m 25.9 30.2 24.8200m 47.7 44.9 34.8

Limit100m 2.5% 5.7% 2.6%200m 5.1% 0.0% 0.0%

out the uncertainty mapping, the calculated sleep periodsbecome shorter so more GPS measurements are taken andtherefore the error spikes become smaller. But more GPSmeasurements of course increases the power consumption aswill be discussed in Section 6.2.

From Figure 19 we can see, that with a 200 meter limit thesleep periods are longer, on average 90 seconds. In all situa-tions the error remains under the limit. We can also observethat because the sleeping intervals are larger, the client takeslonger time to realize that the device has stopped moving,e.g., for the sleeping period between 544 and 602 seconds andbetween 1324 and 1468 seconds. This means that it takeslonger time before we can switch to the accelerometer forobserving when the device starts moving again. To enablethe system to react faster to movement, an improvement toour system would be to consider cancelling sleeping periodsif the client is detected to be stationary for a period of time.

The robustness results for all three versions are summa-rized in Table 5 as the average error and the percentage oftime the error went above the limit. From these numbers wesee that the average error is higher for the 200 meter limitthan for the 100 meter limit, as we would expect. Thatthere is a trend, is especially clear for the 200 meter strat-egy, which has a declining average error for EnTracked com-pared to the two other versions. Furthermore we can seethat errors above the limit happened less frequently for the200 meter limit. For the 100 meter limit the unlisted versionwith no uncertainty mapping had an average error around24.4 meter, nearly the same as with the mapping. However,no errors above the limit were produced by the client.

Compared to the emulation results there were more situ-ations were the error went above the limit. One reason forthis dierence is that during emulation EnTracked receivedbetter speed estimates than during deployment. The reasonis that the emulation data was collected continuously withone GPS measurements per second and as discussed in Sec-tion 4.2 this gives much more precise measurements thanwhen the GPS is turned o between measurements. How-ever, the deployment area was also larger and the target didat no point walk back following the same line which alsocontributes to larger errors. Among the dierent EnTrackedversions in both the emulations and the deployment En-Tracked gave the best results in terms of both average errorand limit crossing.

6.2 Energy EfficiencyIn the deployments the Nokia Energy Proler was used to

collect power consumption traces on the phones. The powerconsumption is plotted in Figure 21 and 22 for EnTrackedwith the limits 100 meter and 200 meter, respectively. Thegure also plots the current client state in the same manneras in the previous section. We can see from the gures how

Table 6: Power consumption for dierent versionand limits.

EnTracked() EnTracked() EnTracked

Avg.[W]100m 0.630 0.600 0.574200m 0.451 0.379 0.462

Savings100m 58.6% 60.6% 62.3%200m 70.4% 75.1% 69.7%

the GPS and radio requests increases the power consumptionwith a factor of twenty compared to the consumption whenonly the accelerometer is in use. The higher number of GPSand radio requests for the 100 meter limit plot also createsmore spikes in the power consumption. We can also noticethe time it takes the dierent features to power o.

To summarize the results for the dierent versions Table6 lists the average power consumption and the power sav-ings as the percentage power saved compared to the powerusage of continuous sampling, which in our case is similarto a one second periodic strategy. For the 100 meter limit,EnTracked has the lowest average consumption because it ef-fectively power o features when stationary. The EnTrackedversion without uncertainty mapping mentioned in the pre-vious section consumed a bit more power, 0.864 watt com-pared to 0.574 watt, so the better robustness causes an in-crease in power consumption.

For a limit of 200 meters, EnTracked() provides the low-est average consumption because of its ability to schedulelong delays. EnTracked on the other hand uses more powerfor the 200 meter. Maybe because of the extra power con-sumption for the accelerometer can not be out weighted bythe savings it provides. However, the results for EnTracked()and EnTracked are not from the same data collection run,thus dierences in stopping periods and walking speed canto some degree explain the dierences. However, when com-pared to the periodic strategy all three versions provide largesavings.

The major part of the savings that EnTracked provides iswhen the device is kept still because the system can enterthe lowest power state during such periods. In the collectedscenarios the percentages are just above 50%, which is quitelow when compared to usual use cases for pedestrian track-ing (above 90%4). The reason we collected data with suchlow a percentage is that it is reasonably argued, that powercan be saved easily by using an accelerometer when the de-vice is stationary. We wanted data that focused more onrobustness and saving power when moving. To show thatfor a more normal use case the system can save a lot morepower we collected data for a four hour deployment where anoce worker carries the phone with EnTracked conguredto a 100 meter limit in his jacket pocket. During the deploy-ment the worker walks home from work which is a 1.45 kmtrip and then hangs the jacket with the phone in the fronthall which has windows so GPS reception is still possible.The jacket then hangs there for some hours until the workerlater takes a short walk in the neighborhood around 650 me-ter and then hangs the jacket back again. This scenario alsotests the system when placed in a jacket pocket and when

4corresponds to less than two and a half hours of movementper day.

232

0

50

100

150

200

0 500 1000 1500 2000ASG/R

Erro

r [me

ter]

Stat

e

Time [seconds]Error State Limit

Figure 18: Real error for 100 meterlimit

0

50

100

150

200

0 500 1000 1500 2000ASG/R

Erro

r [me

ter]

Stat

e

Time [seconds]Error State Limit

Figure 19: Real error for 200 meterlimit

0

50

100

150

200

200 400 600 800 1000 1200

Erro

r [me

ter]

Time [seconds]Mapping No Mapping Limit

Figure 20: Real error for 100 meterlimit with no uncertainty mapping

0

1

2

500 1000 1500 2000ASG/RP

ower

[watt

]

Stat

e

Time [seconds]Power State

Figure 21: Power consumption for100 meter limit

0

1

2

500 1000 1500 2000ASG/RP

ower

[watt

]

Stat

e

Time [seconds]Power State

Figure 22: Power consumption for200 meter limit

0

0.5

1

1.5

2

0 2000 4000 6000 8000 10000 12000 14000

Pow

er [w

att]

Time [seconds]

Figure 23: Power consumptionover four hours

used with free movement. The collected power trace is plot-ted in Figure 23 and the average power consumption duringthis trace is 0.173 W which is a 85.7% saving compared toa ten second periodic strategy.

Compared to the emulation results the deployment powersavings were around ten percent points higher. The fourhour deployment highlighted that even larger savings can beachieved in more realistic use cases with a higher percent-age of still time. For both the emulated and deployed per-centage of still time EnTracked had problems outperformingEnTracked(), however, we speculate that for scenarios witheven higher still time such as the four hour deployment thiswould be the case. However, there is a tradeo point werethe limit is so high that the power used by the accelerom-eter is higher than what is needed to occasionally wake upto do a position update and calculate a new sleeping period.However, such long sleeps would make the system very slowto react to movement which might result in repeated limitcrossings.

7. DISCUSSIONThe presented work have been based on a single device,

i.e., the Nokia N95 8GB phone. Furthermore, we imple-mented our system using Python. To explore if our systemcan be generalized to other devices we measured the param-eters for the device model on another Symbian S60 phone,i.e., the newer Nokia N96 phone. We found that the N96phones delays and power consumption are comparable tothe N95. Our system can thus assumably be generalized toother devices running Symbian S60 and Python. Furtherwork is needed to evaluate if our model generalizes to otherprogramming environment, e.g., Symbian C++ or J2ME,other operating systems like Microsoft Windows Mobile andother brands of phones.

One method to address that device models might haveto be parameterized for dierent brands of phones is autocalibration. Some operating systems provide an API for

collecting power measurements. Given such an API it wouldbe possible to write an application that could automaticallyprole a new device for power consumption and delays bystarting and stopping features and measuring the consumedpower when they power o. The needed parameters for thedevice model could then be calculated from the collectedproling data.

In our emulations and deployments we only experiencedvery bad GPS accuracy above 200 meter a few times. One ofthe methods EnTracked use to ght such situations is to usethe GPS-estimated uncertainty to quickly schedule a newmeasurement if a potential bad measurement is received.For the cell network we generally experienced good commu-nication throughput. However, in our logs we see that someresending of packets have taken place, and thereby increas-ing the delay for delivering position updates to the server.

In this work we evaluated tradeos between robustnessand energy eciency. In the case where we traded energy ef-ciency for robustness the power consumption was increasedfrom 0.574 watt to 0.864 watt, which is a substantial in-crease. However, for this case we only changed one out ofseveral possible adjustments points in our system. For in-stance, when we selected the delays in the device model weselected the average values instead of selecting more conser-vative values such as the average and two times the standarddeviation. Therefore it would be relevant to study the dier-ent adjustment points in more detail, in order to understandwhich ones are the best to use for tuning the system towardseither robustness or energy eciency.

A simple threshold-based algorithm for movement detec-tion was applied but more advanced algorithms do exists.Advanced algorithms could determine the mode of trans-portation such as those proposed by Reddy et al. [18]. Itwould be relevant to extend the systems with such algo-rithms to allow the tracking to scale to biking and car driv-ing as well. Furthermore such algorithms are also better athandling the many dierent ways that a person can carry a

233

phone; and ignore movements that are not part of an actualmovement, e.g., gestures.

An optimization for the system would be to skip sendingposition updates to the server if the newly measured posi-tion is close to the one that the server already know. Also itcould increase power savings for EnTracked if the accelerom-eter could be powered o when not needed, however, due tothe Python library used, this is not possible in the currentversion. Also more power could be saved if the Python li-brary allowed control of or simply was able to minimize thepower-o delays. In this paper we focused on position-basedapplications that run on a server or a dierent device thanthe tracked device. However, for applications running lo-cally on the device the proposed system could be used foroptimizing the use of the GPS only.

8. CONCLUSIONSThe primary contribution of this paper is the novel En-

Tracked system that can track mobile devices robustly andenergy-eciently. We proled how devices consume powerfor tracking and proposed a device model that can accountfor the real power consumption of a concrete device family.Furthermore, we propose methods for position tracking thattake the changing system conditions into account, speci-cally radio delays, positioning delays and position accuracy.We also proposed a method that can minimize power con-sumption and satisfy robustness by calculating the optimalplan for when to power on and o features of the mobiledevices such as the GPS module.

The results of our emulation was that the proposed meth-ods can lower the energy consumption considerably and re-main robust when faced with changing system conditions.These emulation results was validated by our real-world de-ployment where a mobile device was successfully energy-eciently tracked in an urban environment. The resultsalso provide insights into the limitations of our system andled to discussions on how to address these, e.g., by changingthe trade-o between robustness and energy eciency.

In our ongoing work we are trying to address several is-sues. These are: First, a further exploration of how to tuneparameters of our system to realize the best trade-os be-tween robustness and energy eciency. Second, proposemethods for automatically determine the parameters of ourdevice model for new devices. Third, apply the proposedmethods and ndings to other positioning technologies suchas location ngerprinting [11].

AcknowledgmentsWe thank Anders Kabell Kristensen for helping collectingmeasurements. The authors acknowledge the nancial sup-port granted by the Danish National Advanced TechnologyFoundation under J.nr. 009-2007-2.

9. REFERENCES[1] Location Acquisition API: Using Location Acquisition

API. http://www.forum.nokia.com, 2007.

[2] Nokia - Energy Proler. http://www.nokia.com, 2008.

[3] Python for S60.http://sourceforge.net/projects/pys60, 2008.

[4] M. Anand, E. B. Nightingale, and J. Flinn. Ghosts inthe machine: Interfaces for better power management.

In Proceedings of the Second International Conferenceon Mobile Systems, Applications, and Services, 2004.

[5] L. Brown, K. A. Karasyov, V. P. Levedev, A. Y.Starikovskiy, and R. P. Stanley. Linux Laptop BatteryLife. In Proc. of the Linux Symposium, 2006.

[6] Y. Cai and T. Xu. Design, analysis, andimplementation of a large-scale real-timelocation-based information sharing system. InProceedings of the 6th International Conference onMobile Systems, Applications, and Services, 2008.

[7] A. Civilis, C. S. Jensen, and S. Pakalnis. Techniquesfor ecient road-network-based tracking of movingobjects. IEEE Trans. Knowl. Data Eng.,17(5):698712, 2005.

[8] T. Farrell, R. Cheng, and K. Rothermel.Energy-ecient monitoring of mobile objects withuncertainty-aware tolerances. In Proceedings of theEleventh International Database Engineering andApplications Symposium, 2007.

[9] T. Farrell, R. Lange, and K. Rothermel.Energy-ecient tracking of mobile objects with earlydistance-based reporting. In Proceedings of 4th Int.Conference on Mobile and Ubiquitous Systems, 2007.

[10] E. Kaplan and C. Hegarty. Understanding GPS:Principles and Applications. Artech HouseIncorporated, second edition edition, 2005.

[11] M. B. Kjrgaard. A Taxonomy for Radio LocationFingerprinting. In Proceedings of the ThirdInternational Symposium on Location and ContextAwareness, 2007.

[12] A. Kupper and G. Treu. Ecient proximity andseparation detection among mobile targets forsupporting location-based community services. MobileComputing and Communications Review, 10(3):112,2006.

[13] A. Leonhardi, C. Nicu, and K. Rothermel. Amap-based dead-reckoning protocol for updatinglocation information. In Proceedings of 16th Int.Parallel and Distributed Processing Symposium, 2002.

[14] A. Leonhardi and K. Rothermel. A comparison ofprotocols for updating location information. ClusterComputing, 4(4):355367, 2001.

[15] J. Liu and L. Zhong. Micro power management ofactive 802.11 interfaces. In Proceedings of the 6thInternational Conference on Mobile Systems,Applications, and Services, 2008.

[16] D. Mills. Computer Network Time Synchronization -the Network Time Protocol. CRC Press, 2006.

[17] Nokia. S60 Platform: Eective Power and ResourceManagement, Version 3.1. Nokia, 2007.

[18] S. Reddy, J. Burke, D. Estrin, M. Hansen, andM. Srivastava. Determining transportation mode onmobile phones. In Proceedings of The 12th IEEE Int.Symposium on Wearable Computers, 2008.

[19] S. Tilak, V. Kolar, N. B. Abu-ghazaleh, and K. donKang. Dynamic localization protocols for mobilesensor networks. In Proceedings of IWSEEASN, 2005.

[20] C. wen You, P. Huang, H.-H. Chu, Y.-C. Chen, J.-R.Chiang, and S.-Y. Lau. Impact of sensor-enhancedmobility prediction on the design of energy-ecientlocalization. Ad Hoc Networks, 6(8):12211237, 2008.

234

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth 8 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /FlateEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 2.33333 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /PDFX1a:2001 ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles false /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /DocumentCMYK /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice