Minimizing the Power Consumption of Location-Based Services on - - PDF document

Minimizing the Power Consumption of Location-Based Services on Mobile Phones

Mikkel Baun Kjærgaard∗

∗Department of Computer Science

University of Aarhus, Denmark mikkelbk@cs.au.dk

Abstract—Location-based services have to pay careful attention to their power consumption in order not to drain the batteries of mobile phones. It is not a simple task to build low-power location-based services that can run for hours, because such services make heavy use of many power-consuming features of mobile phones. In this article we discuss the power consumption of location-based services and mobile phone features, survey methods for how to minimize power consumption and summarize a number of design considerations for location-based service developers.

A successful Location-Based Service (LBS) must not drain the battery of, e.g., a mobile phone. Battery ca- pacity is a scarce resource in mobile phones, because the capacity of batteries is not increasing at the same pace as new power-demanding features are added to mobile phones. If users experience that a specific LBS drains or significantly shortens the battery’s lifetime, they might stop using the service. It is, however, not a simple task to build low-power-consuming LBSs because such services make heavy use of many power-consuming features of mobile phones, such as the screen to display maps, the radio to receive and send data, or a built-in GPS receiver for positioning. Therefore, an LBS has to take great care in how it uses a phone’s features to minimize the power consumption, especially if the service is to run continuously. In this article we dedicate

• ur attention to LBSs on mobile phones, but some LBSs

also use other types of battery-powered devices such as positionable tags, where minimal power consumption is also an important issue. So far research on the technical challenges of LBSs has mainly focused on how to improve positioning accuracy and coverage. Only a small amount of research has yet focussed on minimizing power consumption. This article provides an understanding of when it is important to minimize the power consumption of a LBS, how different mobile phone features consume power, and how existing LBSs consume power. Following that, the article gives a survey of methods for the minimization

• f power consumption and discuss design considerations

for LBS developers.

• I. POWER CONSUMPTION AND LOCATION-BASED

SERVICES The importance of an LBS saving power depends on the usage pattern, battery recharge options, and how the service uses the phone’s features. With regards to the usage pattern, an important parameter is how long a service will be running on the phone. The LBSs that are most important to minimize the consumption of are those that are long running for hours or days, however, as will be presented later, the power saving methods for such services are fortunately able to provide the largest savings. The importance of minimizing the power consumption also depends on users’ recharge options, because a service may consume a lot of power if a user is able to recharge the phone when finished using the service. Due to such considerations, it might be situation dependent how important it is for a user that a service consumes minimal power. In regards to the phone feature usage, the consumption impact depends on the power consumption of the individual features. Section II both describes how to profile the power consumption of individual phone features and gives some values for a typical mobile phone. A classification of the power consumption for different types of LBSs are shown in Figure 1. The classified types are inspired by the service types introduced by Bellavista 1

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

Power Minimized Services

Hours / Days Minutes Seconds Low (0.1w) x2 Medium (0.5w) x10 High (1w+) x20+

Reactive Location-Based Search Geotagging Sports Trackers Location-based Games Maps and Navigation Location-based Social Networking Proactive Location-based Search Place and Activity Recognition

Service Running Time Power Consumption

• Fig. 1.

Service types groups by service running time and power con- sumption with multiplicity factors for power consumption compared to a 0.05 watt stand-by consumption.

• et. al. [1]. The figure classifies service types with respect

to their running time and power consumption. Running times are classified into second-long, minute-long and hours / days-long, and power consumption into low-, medium- and high-consuming services; a factor is given indicating the impact on the battery lifetime compared to a stand-by battery consumption of 0.05 watt. The figure shows two service types that only run for

• seconds. Geotagging are services that attach location

information to other digital material, e.g., pictures, and reactive location-based search are services that, when requested, search for information related to the user’s location, for instance, about the nearest subway stations. The consumption of such services is medium to high due to that the screen, communication and positioning features are all used. Furthermore, the power consump- tion of such services is difficult to minimize by software means, because a short well-defined task has to be carried out. However, the impact on the battery lifetime is not significant, as these services are used for a short amount of time and not frequently rerun. Three service types are given that run for minutes. Maps and navigation are services that can show people where they are on maps or satellite imagery and pro- vide navigation directions to a location. Location-based games are games that use location as an element in the game play, for example, the finding of physical caches using GPS positioning known as Geocaching or Live Pac Man with real persons running around as monsters to catch you. Sports trackers are services that can log where and when you exercise for sharing and analysis. Again, the consumption of such services are medium to high but, because they run for minutes, their impact on the battery lifetime is higher. When services run for minutes it is an advantage that they have a low consumption but maybe not a must, e.g., if a user is able to recharge the phone when finished. However, one problem that users might experience is that if they forget to turn a service

• ff, it might discharge the phone without them noticing

this before it is too late. For this methods for minimizing the power consumption can be used to lower the power consumption to prolong the battery life. Three services are shown that run for hours or days. Place and activity recognition are services that can register the whereabouts and activities of a user to, e.g., construct a daily diary or calculate a CO2 footprint from the user’s behavior. Proactive location-based search are services that can push information to the user of query results, e.g., if a user registers a search for free city bikes, the user will be notified about free city bikes when in proximity of them. Location-based social networking are services that enable the user to link location to social networking, e.g., to be notified when in proximity

• f friends or events. Again, the consumption of such

services is medium to high but, because the services run for hours or days, it is very important that they consume a minimal amount of power, as they would

• therwise have a major impact on how fast the battery

will discharge, e.g., twenty times faster with a high con- sumption compared to stand-by consumption. Therefore, for long-running services, it is crucial to apply methods for minimizing the power consumption.

• II. POWER PROFILING A MOBILE PHONE

To understand the power consumption of mobile phones one could as a first step consult their specifica-

• tions. However, these will often not give the full picture,

because values are missing (e.g. CPU) and dynamic aspects are not considered. The dynamic aspects are due to that features do not instantly power on or off, e.g., a 3G radio needs several seconds to power on before 2

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

it is ready to send data and the same is true when it powers off. Therefore, the power consumed when sending data is not simply modelled as a single value for the consumption. A solution for capturing dynamic aspects is to power-profile a device to understand the dynamic behaviour of its features. To illustrate what information power profiling can provide, we have profiled a Nokia N95 8GB phone using the Nokia power profiler [2]. Several Python scripts were used to invoke the different features while the Nokia power profiler logged the power consumption. The profiled power consumption of relevant features for LBSs are listed in Table I. From the table one can notice the difference in consumption between using the accelerometer (0.05 watt) and using the GPS (0.32 watt). The processor use also makes a difference, with 0.06 watt at 1% use compared to 0.41 watt at 100% use. However, the largest consumption is that of a WiFi scan (1.37 watt) or of sending data over the 3G radio (1.11 watt). So, the total power consumption depends very much on which features are used by each LBS.

TABLE I N95 FEATURES’ AVERAGE POWER CONSUMPTION.

Feature

• Avg. Power [watt]

Processor 1% 0.06 Processor 100% 0.41 Accelerometer 0.05 Bluetooth 0.28 Microphone 0.26 Screen 0.23 WiFi scan 1.37 GPS 0.32 3G radio idle 0.47 3G radio sending 1.11 One caveat for the values in Table I is that feature’s power consumption depends slightly on the state of the

• battery. This is because as the battery discharges the

voltage of the battery will drop slightly. That this causes

• nly a slight drop is due to the power chip sets of modern

phones, which will try to keep the voltage as high and stable as possible as long as the battery can sustain this. To truthfully model the power consumption of a phone, one has to consider dynamic aspects in addition to the consumption of individual features. To highlight these aspects, Figure 2 shows a power profile of a phone running a Python script that every 60 seconds invokes the GPS to produce a single position fix, opens a TCP connection to a server over the 3G radio, sends the position fix and then closes the connection. It can be seen from the figure that the single steps are not executed instantly, that it takes some seconds for the GPS to produce a position fix and to send the position

• fix. Furthermore, afterwards both the 3G radio and the

GPS keep consuming power for a while. These aspects are important to model in order to correctly minimize the total power consumption of a service. We have in Kjærgaard et al. [3] proposed a power model that is able to capture such aspects.

• III. LEARNING FROM EXISTING LOCATION-BASED

SERVICES One may wonder how existing LBSs consume power. To study this, we deployed five commercial LBSs on a Nokia N95 8GB. We then let a user carry out some standard tasks for the individual LBS while we logged the phone’s power consumption. The power profiles for eight minutes of data for each service are shown in Figure 3. Using the power consumption of the individual features presented in the previous section, one can then start to interpret these graphs and correlate with the tasks carried out, listed above the graphs. The Geocache Navigator service is in the category

• f location-based games. This LBS can help you find

nearby caches, view descriptions of caches, find your way to the caches using a radar or a map view, and finally to log online the caches that you have found. If one interprets the collected profile, one can notice a high consumption in the beginning, when the LBS is determining the position of the user using GPS, receiving assisted GPS data, and fetching application data about caches, maps, and descriptions. During use, this LBS’s power consumption never goes below 0.5 watt, which indicates that the service keeps the GPS powered on. When the user later looks again at the map and radar view, the screen is lit up, and therefore there is an increase around 0.2 watt at these points. At the end, the user logs online that a cached item has been found. There is one event where some application data is sent

• r received which does not correlate with any user

behaviour. The Endomondo Tracker service is in the category of sports trackers. This LBS can help you track workouts and log them on a server. The logged workouts can later 3

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

0.5 1 1.5 2 2.5 3 10 20 30 40 50 60 70 Power [watt] Time [seconds]

GPS request GPS return GPS power off TCP connect TCP disconnect 3G radio idle mode 3G radio power off

• Fig. 2.

Power consumption for periodic position updating measured on a N95.

be reviewed on maps and in graphs, and shared with

• friends. The service also supports competitions between

friends such as ”Who is the first to run 100 km?”. When the LBS starts, it powers on the GPS, fetches assisted GPS data, and registers the user and the workout at the

• server. During the workout, the GPS is kept on and the

processor is regularly used at 100% to process incoming GPS data. When the workout is finished, the data is uploaded to the server. There is again an application data event, which might be some intermediate logging to push part of the collected data to the server. Google Maps and Nokia Maps are both in the cat- egory of maps and navigation. They can show maps and provide navigation guidance. Both LBSs consume power for powering the GPS and fetching assisted GPS

• data. The main difference between the two services is

that Google Maps fetches all data from the Internet, whereas Nokia Maps uses cached data on the phone. The difference can be clearly seen in Figure 3 when the user looks at the map in Google maps. This action is associated with a heavy power consumption, because the data is fetched from the Internet whereas for Nokia Maps a lower consumption is needed. Another difference is Nokia Maps’ sooner power off of the GPS. The graph depicting Google Maps’ consumption also has some application data peaks coming from either sharing the position of the user for Google latitude or fetching coordinates for GSM base stations to perform GSM positioning. ALOQA is in the category of proactive location-based

• search. The service can push relevant information to your

phone depending on your location and which content channels you have subscribed to. Many different content channels are supported by the service, such as ”Things to do with kids”, ”Movies” and ”Facebook Friends” which all deliver information based on the user’s location. When the service starts, it positions the phone and, while the user is looking at channel content, application data is sent and received. Afterwards, the service is regularly positioning and communicating to receive new content based on the changing position of the user and, therefore, the power consumption of the service is high most of the time. One can extract several lessons from these profiles about power consumption. Firstly, LBSs use a con- siderable amount of power, which is comparable to

• ther high-power-consuming phone tasks like making a

phone call, or Internet browsing, which both consume

• n average 1.3 watt. This is especially a problem for

the proactive location-based search service, which is supposed to be running continuously for hours or days. Secondly, to save power, the GPS should be turned off as much as possible. It is, however, not always trivial to establish when this can be done without impacting the user experience. Finally, a LBS should try to minimize the amount of data to be transmitted by phone-side caching and processing. However, how to efficiently cache and process the many different types of location related data without impacting application logic is a complex problem.

• IV. MINIMIZING POWER CONSUMPTION

Methods are needed that can minimize the power consumption for LBSs. A general concept behind many methods for saving power is to relax the required po- sitioning accuracy from the highest possible to what is

• necessary. This concept can be applied both at the phone

when considering different positioning options, but also at servers when considering how accurately the server needs to know the current position of a target. 4

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

0.5 1 1.5 2 2.5 3 60 120 180 240 300 360 420 480 Power [watt] Time [seconds] Choose Cache Look at map and description Look at map and radar view Look at radar view Log cache found

• App. Data

(a) Location-based Games: Geocache Navigator v. 2.04

0.5 1 1.5 2 2.5 3 60 120 180 240 300 360 420 480 Power [watt] Time [seconds] Setup and start workout Finish workout

• App. Data

(b) Sports Trackers: Endomondo v. 1.01

0.5 1 1.5 2 2.5 3 60 120 180 240 300 360 420 480 Power [watt] Time [seconds] Look at map Look at map

• App. Data
• App. Data

Look at map and Latitude Friends

(c) Navigation and Maps: Google Maps v. 3.0

0.5 1 1.5 2 2.5 3 60 120 180 240 300 360 420 480 Power [watt] Time [seconds] Look at map Look at map Look at map

(d) Navigation and Maps: Nokia Maps v. 1.2

0.5 1 1.5 2 2.5 3 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 Power [watt] Time [seconds] Looking at channels Looking at channels

(e) Proactive Location-based Search: ALOQA for symbian

• Fig. 3.

Power profiles of five LBSs on a N95 8GB.

One might ask when it is possible for an LBS to relax the required positioning accuracy. The answer is that it is possible in many situations. Firstly, map services, that show the positions of a number of mobile phones, can use the zoom level to determine relevant accuracy limits (such as 25 meters for street-level view, 100 meter for a suburb, and 200 meter for a city-wide view). Secondly, location-based social networking or proactive location- based search services can relax accuracy requirements depending on the positions of targets. For instance, proximity can be efficiently observed using methods such as the one proposed by K¨ upper et al. [4]. This method uses the distance between targets to calculate the required accuracy limit for each target. The accuracy limits produced by this calculation range from 10 meters, if targets are close, to several kilometers if they are far

• apart. Thirdly, services can adjust their service quality

based on how much battery power is left, for instance, a runner using a sports tracker service would rather have a less fine grained log of the whole trip and be able to call for help if he falls, than a fine grained log of only the first part and no voice service afterwards. Finally, privacy restrictions might require an LBS only to work with positions with limited accuracy. In this section we will divide our discussion of meth-

• ds that implement this concept into three parts, each

focusing on one of the following goals:

• Minimize needed position fixes.
• Use the least consuming feature for positioning.
• Do on-phone data caching and processing.
• A. Minimize Needed Position Fixes

In principle, every avoided position fix is equal to saved power consumption. It is necessary to model the error of the last known position to establish which position fixes can be avoided. As long as the modeled error does not exceed the accuracy limit, no positioning is necessary. An error model used in our former work Kjærgaard et

• al. [3] is based on estimated accuracy of the last position

5

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

fix upos, the time since the last position fix tpos, and the estimated speed vest. The error model then optimistically calculates the current error emodel for time t with respect to the last position fix as defined in Equation 1. emodel = ugps + (t − tgps) ∗ vest (1) In [3] we have proposed a system called EnTracked that minimizes the required position fixes using Equation 1 and applies GPS positioning for tracking pedestrian

• targets. The system uses the error model to predict when

the next GPS position is needed. In addition to an error model, the system also takes into account the delays associated with powering on and off features, which lowers the chance of exceeding accuracy limits. The sys- tem uses a power minimization algorithm implemented using dynamic programming to predict when a GPS position is needed. The algorithm uses a profiled power model to ensure that the system will correctly minimize the consumption. Evaluations of the system tracking a pedestrian target walking in a residential area resulted in power savings of 62.3% with an accuracy limit of 100 meters and 69.7% with an accuracy limit of 200 meters compared to periodic reporting. Many LBSs require that position fixes are transferred to a server, for instance, for location-based social net- working services to detect if targets are near or far from each other. The positioning server for such a service can also apply methods to minimize the number of position fixes requested from targets. An example is the cache- based method presented by Leonhardi et al. [5] which uses an error model at the server to calculate when it needs a new position fix. As long as the accuracy limit is not exceeded by the error model, the system answers LBSs with the cached last-known position of the

• target. When the limit is exceeded, the system updates

the cached position by requesting a new position from the target. Evaluations showed that the caching-based method was able to avoid 86% of the position requests, with an accuracy limit of 100 meters, when queried ten times per second by different services.

• B. Least Consuming Feature for Positioning

Considering Table I, again one notices that the differ- ent positioning options have different power consump-

• tion. If we consider a scenario where we estimate our

position every 30 seconds, the average power consump- tion would be 0.32 watt with GPS, 0.094 watt with WiFi, and 0.064 watt with GSM1. But on the other side, they also provide different levels of accuracy: Around 10 meters with GPS, 40 meters with WiFi and 400 meters with GSM [6]. To save power, one can then try to always switch to the least-consuming positioning feature that provides the needed accuracy, which can provide significant savings. Our previously mentioned EnTracked system switches between GPS and sensing motion using accelerometer

• readings. If the system can sense that a mobile phone has

not moved, there is no reason to update the position on the server and the GPS can be switched off. But as soon as motion is sensed, the system switches the GPS back

• n. As the accelerometer consumes a sixth of the GPS’s

power consumption and communication is avoided, this method provides significant power savings. Evaluations

• ver several hours of running the system provided power

savings of 85.7% compared to periodic reporting. The EnLoc system proposed by Constandache et al. [6] considers switching between GPS, WiFi and GSM

• positioning. They consider the energy consumption when

switching between the different positioning technolo- gies with an optimization algorithm implemented using dynamic programming. Furthermore, they extend their approach to also minimize needed position fixes by mobility profiling, e.g., to guess the possible paths that a target is taking and then only position the target when paths diverge. For LBSs that are only monitoring if a target is within a certain area, one can apply switching between GPS and GSM positioning in a different fashion, as proposed by Deblauwe et al. [7]. The key idea is that if a target enters a GSM cell that is fully contained within the monitoring area then one can switch to only monitor if the target stays within this GSM cell. This means that as long as the target stays within the GSM cell, the GPS can be switched off. Evaluation results for this method reported savings of up to 80% depending on the setting.

• C. Do On-Phone Data Caching and Processing

As stated earlier, the power consumption of sending and receiving data is high. Therefore, to save power, it makes sense to minimize the frequency and data size

• f transfers. An example from the profiling of existing

LBSs was the difference in power consumption between

1The low consumption of WiFi and GSM is due to that they can

quickly power on and off to scan for access points and base stations.

6

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

Nokia Maps using cached maps versus Google Maps using downloaded maps in Figure 3. Both GSM and WiFi positioning require access to a database that maps GSM cells and WiFi addresses to

• coordinates. More advanced GSM and WiFi positioning

(e.g., location fingerprinting [8]) requires a database with information about the strength of signals at various

• locations. This type of positioning is normally imple-

mented such that the phone has to contact a server which hosts the database. The required server connection at least doubles the power consumption of such methods. However, it is in most cases not possible to keep the database on the phone due to size, license issues, and the problem of how to keep it up to date. To address this problem, methods have been proposed by King et

• al. [9] and Kjærgaard et al. [10] which only cache a

subset of the database on the phone. Based on the user’s current location, these systems are able to efficiently select relevant parts of the database to be kept on the phone with minimal overhead. Many LBSs require that position-related data is sent to a server. An example is a LBS that transfers a stream of positions to a server to monitor and recognize the route a target takes. To save power, one can try to process data on the phone before sending it. For example, processing positions into routes on the phone as proposed by Brilingaite et al. [11]. In their system, the phone carries out some of the tasks of monitoring and recognizing routes, and only when necessary is the system in contact with a server.

• D. Overview

The methods surveyed deal with minimizing power consumption following different goals. In evaluations, the methods were able to provide significant power savings of up to 85%, which corresponds to an increase in battery lifetime of up to a factor of seven. Therefore, these methods can be used to lower the consumption of existing LBSs, especially long-running services. Gener- ally, methods focusing on GPS positioning have received most attention both for efficient handling of positions, zones and routes. Some methods also consider the fea- tures of accelerometers, GSM and WiFi positioning. But in several areas more research is needed to provide an even better understanding of the advantages and drawbacks of different goals, because few systems aim at several goals. Considering the combination of features some combinations have been tried, but other combina- tions are possible; the same is true for methods applied to minimize the power consumption. Furthermore, many

• f the systems have only been tested in smaller settings

and end-to-end studies of deployable systems are largely missing.

• V. DESIGN CONSIDERATIONS

In this section we will summarize a number of design considerations.

• A. Increase In Complexity

The methods presented in the previous section pro- vide evidence that it is possible, in many situations, to minimize the power consumption of LBSs. However, a drawback is that most of the methods add complexity to the LBS implementation. Thus, more specialized pro- cessing and messages are used, and the service might has to deal with several positioning methods instead of only

• ne. Another issue is that to correctly minimize power

consumption requires a correct model of how the specific phone model consumes power. Such a model needs to be parameterized by, e.g., power profiling phones, which also adds to the complexity.

• B. Solving the Right Problem

As highlighted earlier in the article, it might not always be the positioning part of an LBS which is the most power-hungry part. It might therefore have a larger impact to consider data transfers rather than positioning to minimize the power consumption. The data transfers that are associated with positioning might also be important to consider, as in the case of GSM

• positioning. In this respect, one might comment that

classic client-server architectures might have storage and processing benefits on the phone. But due to the high consumption of the needed data communication, such an architecture might not be the solution that minimizes the power consumption. Minimizing data communication to save power also provides other benefits, such as lowering bandwidth use, saving monetary cost for data traffic, and decreasing server demand.

• C. Power Consumption of LBSs

LBSs use a considerable amount of power, which is comparable to other high-power-consuming phone tasks such as making a phone call, or Internet browsing both

• f which consume around 1.3 watt. The impact of LBSs
• n the battery lifetime depends of course on how the

phone is used for other tasks. If the phone is only used 7

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

• ccasionally to make calls, browsing and playing music,

then the impact of using LBSs is large. However, if the phone is used extensively to make calls, browsing and playing music, then the impact of LBSs will be

• smaller. In this article, we considered lowering the power

consumption of LBSs, but one can also create LBSs that try to improve battery management on mobile phones by, for instance, warning the user if the LBS detects that the mobile phone can run out before the next charging

• pportunity is encountered, as proposed by Ravi et al.

[12].

• D. LBSs is an Active Research Area

The area of LBSs is growing and new services are emerging all the time, which compile new types of knowledge from the positions of targets. An example is indoor LBSs where only few services exists [1]. Modern phones also include more and more built-in sensors (compasses, gyros, temperature, etc.) which enable both new LBSs, and new methods for minimizing power

• consumption. Improvements in technology might also

change the power consumption levels of specific fea- tures, which might in turn change the trade-offs between different features.

• VI. CONCLUSIONS

Minimizing the power consumption of an LBS is a rather new research area. In this article we provided an understanding of what types of LBSs it is important to minimize power consumption of, how the different mobile phone features consume power, and applied this understanding to the power consumption of five commer- cial LBSs. Secondly, we presented three goals for how to minimize power consumption: Minimize needed position fixes, use the least-consuming feature for positioning, and do on-phone data caching and processing. The surveyed methods implementing these goals were able to provide significant power savings of up to 85%, which corresponds to an increase in battery lifetime of up to a factor of seven. Furthermore, we discussed design considerations in terms of LBS complexity, solving the right problem, the power consumption and, finally, highlighted that LBS is still an active research area, which is especially true for aspects of minimizing power consumption. REFERENCES

[1] P. Bellavista, A. K¨ upper, and S. Helal, “Location-based services: Back to the future,” IEEE Pervasive Computing, vol. 7, no. 2,

• pp. 85–89, 2008.

[2] “Nokia - Energy Profiler,” http://www.nokia.com, 2008. [3] M. B. Kjærgaard, J. Langdal, T. Godsk, and T. Toftkjær, “En- Tracked: Energy-Efficient Robust Position Tracking for Mobile Devices,” in Proceedings of the 7th International Conference on Mobile Systems, Applications, and Services. ACM, 2009, pp. 221–234. [4] A. K¨ upper and G. Treu, “Efficient proximity and separation detection among mobile targets for supporting location-based community services,” Mobile Computing and Communications Review, vol. 10, no. 3, pp. 1–12, 2006. [5] A. Leonhardi and K. Rothermel, “A Comparison of Protocols for Updating Location Information,” Cluster Computing, vol. 4,

• no. 4, pp. 355–367, 2001.

[6] I. Constandache, S. Gaonkar, M. Sayler, R. R. Choudhury, and L. Cox, “EnLoc: Energy Efficient Localization for Mobile Phones,” in Proceedings of the IEEE INFOCOM 2009 Mini Conference. IEEE, 2009. [7] N. Deblauwe and P. Ruppel, “Combining GPS and GSM Cell-ID positioning for Proactive Location-based Services,” in Proceed- ings of the 4th Annual International Conference on Mobile and Ubiquitous Systems. IEEE, 2007, pp. 1–7. [8] M. B. Kjærgaard, “A Taxonomy for Radio Location Fingerprint- ing,” in Proceedings of the Third International Symposium on Location- and Context-Awareness. Springer, 2007, pp. 139–156. [9] T. King, T. Haenselmann, and W. Effelsberg, “On-demand fingerprint selection for 802.11-based positioning systems,” in Proceedings of the 9th IEEE International Symposium on a World

• f Wireless, Mobile and Multimedia Networks.

IEEE, 2008, pp. 1–8. [10] M. B. Kjærgaard, G. Treu, and C. Linnhoff-Popien, “Zone-Based RSS Reporting for Location Fingerprinting,” in Proceedings

• f the 5th International Conference on Pervasive Computing.

Springer, 2007, pp. 316–333. [11] A. Brilingaite and C. S. Jensen, “Enabling Routes of Road Network Constrained Movements as Mobile Service Context,” GeoInformatica, vol. 11, no. 1, pp. 55–102, 2007. [12] N. Ravi, J. Scott, L. Han, and L. Iftode, “Context-aware Battery Management for Mobile Phones,” in Proceedings of the Sixth Annual IEEE International Conference on Pervasive Computing and Communications. IEEE Computer Society, 2008, pp. 224– 233.

8

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.

• VII. BIOGRAPHICAL INFORMATION

Mikkel Baun Kjærgaard is a Post Doc at the De- partment of Computer Science, Aarhus University. His current research interests are within the area of per- vasive positioning: positioning anywhere, anytime, of

• anything. His interests spans from innovative applica-

tions within this area to technical challenges such as energy efficiency. He holds a Ph.D in Computer Science from Aarhus University based on research on indoor positioning using radio location fingerprinting. Postal address: Aarhus University, Department of Computer Science, Aabogade 34, 8200 Aarhus N, Denmark. Email: mikkelbk@cs.au.dk

• VIII. CONTACT INFORMATION

Mikkel Baun Kjrgaard Department of Computer Sci- ence University of Aarhus, Denmark mikkelbk@cs.au.dk Phone +45 8942 5698 Fax +45 8942 5601

• IX. KEYWORDS

C.3.h Ubiquitous computing ¡ C.3 Special-Purpose and Application-Based Systems ¡ C Computer Systems Organization C.2.8 Mobile Computing ¡ C.2 Commu- nication/Networking and Information Technology ¡ C Computer Systems Organization 9

Digital Object Indentifier 10.1109/MPRV.2010.47 1536-1268/$26.00 ) 2010 IEEE This article has been accepted for publication in IEEE Pervasive Computing but has not yet been fully edited. Some content may change prior to final publication.