Power-saving localization techniques for mobile devices

The current issue and full text archive of this journal is available on Emerald Insight at: www.emeraldinsight.com/1742-7371.htm

IJPCC 11,1

Power-saving localization techniques for mobile devices A comparison between iOS and Android

Downloaded by JOHANNES KEPLER UNIVERSITAET LINZ At 00:56 14 April 2015 (PT)

102 Received 15 January 2015 Revised 15 January 2015 Accepted 22 January 2015

Wolfgang Narzt

Department of Business Informatics/Software Engineering, Johannes Kepler University, Linz, Austria Abstract Purpose – This paper aims to develop generic strategies for improving energy consumption for location sensing on smartphones and compares the results of iOS and Android implementations. Mobile smartphone applications utilizing localization sensors (e.g. Global Positioning System) collectively face the problem of battery draining. Energy consumption is at a peak when applications permanently and stolidly use those sensors, even if their excessive exploitation is avoidable (e.g. when the user carrying the device is not moving). Design/methodology/approach – Considering contextual parameters affecting localization of mobile devices (i.e. incorporating movement probability, speed, etc.) is the basic idea for developing a strategy capable of reducing energy consumption for location determination on mobile devices. This paper explains the paradigm and draws the architecture for a generic context-based energy saving strategy for mobile location-based services. Findings – The paper reveals the positive implications in terms of energy consumption measured in the course of exhaustive tests for iOS and Android devices and discusses accuracy issues and potential workarounds, especially focusing on Apple’s M7 motion co-processor for consuming accelerometer data on a low energy level. Originality/value – The paper identifies and measures energy issues for location determination on smartphones and presents a generic and heuristic concept for saving energy. Keywords Context, Mobile devices, Android, iOS, Energy-efficient localization, Location-based services Paper type Research paper

International Journal of Pervasive Computing and Communications Vol. 11 No. 1, 2015 pp. 102-126 © Emerald Group Publishing Limited 1742-7371 DOI 10.1108/IJPCC-01-2015-0001

1. Introduction Mobile location-based services (LBSs) are considered established information- and collaboration systems for public use available as apps for modern smartphones. Determination of position is achieved by built-in positioning technology utilizing Global Positioning System (GPS), cellular network triangulation, or wireless local area network service set identifier (WLAN SSID) mapping, supporting consumers to find a path from A to B, recognize things around one’s own position, record one’s training routes or exchange current positions with friends. Although mobile LBS are considered an engaged paradigm in mobile computing environments, continuous utilization of LBS still faces a considerable drawback in terms of batteries’ operating times. An active localization module may reduce the uptime of a smartphone to less than 10 per cent compared to the operating times in standby mode or to just a few hours, depending on the type of device (please, refer to the exact measurements in the following sections). In addition, the devices generate substantial


heat, which is not always perceived as pleasing. In most cases, permanent operation of GPS is the main reason for draining the battery. There is evidence on this statement due to several experiments, which we have conducted to figure out the energy guzzlers in LBS (see Section 5). Naturally, the transmission of packets via the cellular network or WLAN also impacts operating times, e.g. when the device is negotiating for handovers to neighbored antennas or has to increase transmission power at low signal strength (Barrows et al., 2013; Kellokoski et al., 2012). Energy reduction for data transmission is not subject of this survey though. Thus, our main research issue for mobile LBS was to find a way to extend the batteries’ operating times of smartphones for continuous active operation (i.e. in foreground and in background mode). Of course, there cannot be a general answer or method to this issue because LBS strongly differ in terms of required accuracy and/or latency of reaction times. If a service claims permanent use of GPS due to exact location-based examinations, there is hardly any chance to develop a strategy for energy saving. Thus, we define a family of LBS applications and constraints to be fulfilled to be suitable to apply the energy saving strategies, which we propose in this paper. The constraints are defined as follows: • The service is continuously operational, i.e. the position of the device must be determined both in foreground and in background mode. • When in foreground mode, the best possible position of one’s own device is required. • The service dynamically offers location-based points of interest (POIs), which have to be triggered, i.e. their content displayed, an alarm set off, an external service initiated, etc., when the device reaches spatial proximity to them. • An observation mechanism is included within a network of participating clients, i.e. the service shows the current whereabouts of other floating devices (i.e. a friend finder). • When in observation mode (presuming that there is no permanent monitoring station), the best possible positions of the monitored devices are required. This means that within a distributed LBS environment, an exact position is needed when the application is in foreground mode, observed by another client or close to POIs. For the remaining time (which represents the major part during operation in many cases, e.g. when the device is in background mode, not moving, not observed or generally in a static position in the office or at night times, etc.), less energy-consuming positioning methods (e.g. cellular network triangulation) could be used to extend the batteries’ operating times (with the drawback of less accurate localization in background mode and latency for the reactivation of GPS when required). Temporal inaccurate localization is acceptable for the constraints given above, though. Farrell et al. (2011) betook this concept “spatiotemporal tolerance for continuous range queries” and mean to relax accuracy requirements both in terms of spatial and temporal dimensions. It offers the chance to provide well-defined location queries to reduce the number of sensing operations and energy consumption. Our proposed concept also avoids utilization of GPS as often as possible and comprises alternative low-power localization techniques whenever applicable.

Power-saving localization techniques 103

IJPCC 11,1


104

The strategies are encapsulated in a social-Web app named “Spotnick”, which is available in the App Store for iOS devices and on Google Play for Android. It provides the measuring results included in this paper. For further details on Spotnick, please refer to the following sections. The paper is structured as follows: Section 2 deals with selected points of state-of-the-art methods and technology. Section 3 gives an insight into the proposed energy saving strategies. Section 4 sketches the test scenarios and measuring metrics. Section 5 provides figures and measured results and, finally, Section 6 concludes the paper and prospects future work. 2. State of the art Investigations concerning energy consumption for LBSs on mobile devices have been the focal point of research in various scientific and industry laboratories (Balasubramanian et al., 2009; Barbeau et al., 2008; Carroll and Heiser, 2010; Wang and Manner, 2010). Bareth and Küpper (2011), for example, confirmed our experiments and derived findings about energy consumption of the different positioning technologies available on smartphones (see Table I), where they measured the energy consumption for GPS, WiFi- and cell-based positioning techniques. Basically, there are four ways to face the draining problem: (1) directly on a hardware-related level, where ameliorations are achieved e.g. by considering Kalman filters (Taylor and Labrador, 2011); (2) by several software-based and application-related high-level strategies utilizing available software development kit (SDK) functions, software architectures and frameworks (Farrell et al., 2007; Gobriel et al., 2012; Oshin et al., 2012a, 2012b; Zhuang et al., 2010); (3) with hybrid approaches using additional (less energy consuming) sensor technology (e.g. accelerometers) and context-based movement detection algorithms as a substitute or an extension of functionality (Oshin et al., 2012a, 2012b; Rahmati and Zhong, 2007; Youssef et al., 2010); and (4) utilizing the surrounding infrastructure for localizing the device, i.e. the device is not using any of its built-in sensors but “asks” (via network data transfer) infrastructural facilities for its position. The strategy described in this paper can be classified to the aforementioned approach (2) and be regarded as an extension to existing similar methodologies: Kjaergaard et al. (2009), for example, developed a context-based model which tries to estimate and predict system conditions and movements to calculate a schedule for utilization of GPS. In a way, our approach can be compared to that, trying to schedule different positioning techniques due to system states (e.g. device is not moving). Although, the authors have succeeded in significantly saving energy using a Nokia N95, we give a more up-to-date

Table I. Properties of positioning techniques

Technology

Accuracy

A-GPS WiFi Cell-Id

10 m 50 m 5 km

Precision (%)

Energy (Ws)

95 90 65

6.616 2.852 1.013


approach using less complex algorithms and utilizing enhanced positioning techniques on iOS and Android devices. Oshin et al. (2012a, 2012b) confirm our measurements and present a method to evaluate the energy-efficiency of GPS, WLAN and GSM location sensing technologies of smartphones. Their model considers sensor usage, user context and required location accuracy and utilizes the embedded smartphone accelerometer for managing the activation and deactivation of the location sensors. Therefore, it is considered as the aforementioned hybrid approach (3). The authors state energy-savings of up to 57 per cent. Bareth and Küpper (2011) claim ameliorations of up to 90 per cent compared to a “naive GPS approach” (please note, that authors use different relative reference values) using a hierarchical positioning algorithm dynamically deactivating positioning technologies and activating the positioning method with the least energy consumption on demand. Their approach (of Category 2, implemented for Android devices) and also the results of their tests are in some aspects comparable to the Spotnick strategy. A generic (i.e. platform independent) approach for an energy-efficient localization method, however (which has been the main focus in our survey), faces some challenges in terms of direct access to different localization techniques and requires distinguished thought models. Jurdak et al. (2010, 2013) basically follow a similar approach of temporarily using GPS while simultaneously facing localization uncertainties. Their “duty cycles” (also already introduced by Constandache et al. (2009)) are supplemented by additional sensors and by considering neighbored mobile nodes at spatial proximity, enabling GPS load sharing among the nodes and an overall reduction in the use of GPS at each node. Another variant is to record and store GPS inaccuracy values (especially for places where the GPS is not functional) to decide upon duty cycles of GPS. Paek et al. (2010) propose such an approach and try to improve results by considering speed as a function of time and place for moving entities (e.g. in a car). Beyond the context-based strategies for energy-efficient localization of modern smartphones, there are alternative approaches to do so. Chatterjee et al. (2012) propose a cloud-based method: They utilize air pressure sensors measuring the altitude as a complement to GPS and try to map these data with pre-recorded route data in cloud systems (the aforementioned approach 4). The major challenge in this approach is accuracy, according to the authors. 3. Energy-efficient localization The energy saving strategies for our approach are settled on a high application-oriented level, variantly using, not using and switching between system functions provided by standard SDKs. They are not based on hardware-related optimization attempts. In principle, the strategy aims at avoiding usage of GPS whenever applicable. Instead, it uses cellular- or WiFi-based positioning or region monitoring (a technique which utilizes the WLAN and Cell-ID handover functions of the smartphone to detect a potential movement – so, no usage of accelerometers) and continuously tries to switch between those operation modes according to particular events (context). Thus, the architecture principally results in a finite state machine (FSM) and has to take decisions for state transitions between those states built upon the following contextual properties and its characteristics:


IJPCC 11,1

(1) (2) (3) (4)

106

Application mode: The app is either in foreground mode (f) (the user looks at it) or in background mode (b) (app is idle). Movement: The user/device is either moving (m) or stationary (s) (not moving). Observation mode: The device is either observed (o) or unobserved (u). POIs nearby: POIs for a device/user are either near (n) (i.e. within a distinct radius) or distant (d).


Thus, there are four properties having two values each, creating 16 different states, strictly speaking (see Table II). Most of them can be combined, though, because it is irrelevant for the strategy if the device is moving, observed or POIs are near or not when the app is in foreground mode (i.e. States 1 to 8 can be combined to one). In this state, the most accurate position is required. Also, States 9 to 11 can be combined to one state, in which the GPS is likely to be turned on because the device is either being observed while in background mode (States 9 and 10) or a POI is near, the approach to it must be exactly determined (State 11). From a technical point of view, those two combinations of States 1 to 8 and States 9 to 11 can be merged, once more, for they require the best possible position as a common characteristic (see State A in Figure 1). State 12 is unique: the app is in background mode, the device is moving, but not observed by any client and nor is it in the vicinity of any POI. This means that nobody takes notice of the app at that moment. Positioning must continue, though (by an inaccurate technique, see State B in Figure 1) to reactivate GPS at spatial proximity to a POI (which exactly requires to be triggered, transferred, etc.; for a deeper insight into location-triggered processes see Narzt and Schmitzberger (2009)) within the inaccuracy range of the used positioning method. Finally, States 13 to 16 can again be combined to one state where the region monitoring is used to recover from an idle mode where the app is in the background and the device is not moving (observation and POIs are irrelevant at that state, see state C in Figure 1). Note that

Table II. Transition parameters of the FSM

No.

Application mode

Movement

Observation mode

POIs near

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

f f f f f f f f b b b b b b b b

m m m m s s s s m m m m s s s s

o o u u o o u u o o u u o o u u

n d n d n d n d n d n d n d n d

FSM

A

B C

Power-saving localization techniques


107

Figure 1. State transitions of energy-saving strategy (excerpt)

States B and C can only be reached when the app is in background mode, while State A is accessible in both foreground and background mode. The consolidation of states reduces the complexity of the FSM to three states (A, B and C, see Figure 1). Its state transitions are principally extractable from Table II, which is a simplified depiction of the concept; the actual implementation considers several additional transition constraints (e.g. time) and works as follows. The strategy always starts in foreground mode and therefore with active GPS (state A, Figure 1). Please note that activation of the GPS is different for iOS and Android platforms. There is a simple “GPS provider” instance on Android for controlling the GPS module (and a corresponding “network provider” instance for WLAN- and cell-based localization). However, there is no SDK function for iOS to selectively activate or passivate GPS or the other sensors. This must be done indirectly by specifying the desired accuracy. iOS provides the following six different accuracy values. The first two values (“best for navigation” and “best”) presumably, but not compulsory turn on the GPS module. If a WiFi-based localization already provides the desired accuracy, iOS keeps the GPS turned off. For the other values, it is not transparent which positioning technique will be used by iOS. The last two values (“kilometer” and “three kilometers”), however, are likely to activate cellular-based localization and to turn off all other sensors. For our implementation, we have used value 1 (“best for navigation”) for State A and value 5 (“kilometer”) for State B. Accordingly for Android, we have used the GPS provider for State A and the network provider for State B. Starting from State A, the FSM transits to State B when the app goes to background mode, the user keeps moving for at least 3 minutes, but is not observed by another client nor in the vicinity of a POI (see transition 1 in Figure 1 and Formula 1):

IJPCC 11,1


108

A ! ((b & m & u & d) & "t # 3 min) B

(1)

The FSM transits back to State A when either the app gets to foreground mode or the device is observed by at least one client or when a POI is near (no further explanation on that due to space limitations). Transition 2 in Figure 1 and formula 2 explain: B ! (f $ o $ n) A

(2)

When the device is not moving, anymore, in background mode, then we switch to region monitoring (State C), i.e. the app is completely idle until a system signal wakes it up again due to a network handover event among WLAN access points or cellular antennas. To detect a non-moving device, we have defined a distance threshold %, which may not be crossed and a time interval !t, which must be exceeded (here: 2 minutes) until we assume a stationary state where the device is not moving. See Transition 3 in Figure 1 and formula 3: A ! ((b & s) & "t # 2 min) C

(3)

Almost the same is true for transiting from State B to State C, except the time constraint. See Transition 4 in Figure 1 and formula 4: B ! (b & s) C

(4)

Finally, when the app is in State C (i.e. in region monitoring mode), there is only a way back to State A (best accuracy) when the system detects a network handover (i.e. a possible movement of the device), not to State B. See Transition 5 in Figure 1 and formula 5: C!mA

(5)

The FSM in Figure 1 is a simplified excerpt of the actual implementation and omits further optimization details. Just to give one example: when transiting to a state requiring high accuracy, we do not immediately turn on the GPS. We first check the accuracy value of the WiFi network. If this value is good (i.e. just a few meters inaccuracy, which indicates the presence of a registered WLAN network, see State D and Transition 6 in Figure 2 and Formula 6), then there is no need to activate GPS, e.g. when residing within a building where the GPS is unavailable, anyway. Only a high inaccuracy value triggers the GPS module. Thus, the actual implementation of the FSM contains several additional states, mainly used for further optimization: B ! (f $ o $ n) D C ! mD D ! (accuracy # %) A

(6)

This strategy, as described above, has been implemented in the core of a social-Web application named Spotnick, comprising a friend finder for a user’s Facebook friends with the opportunity of mutually perceiving whereabouts with just a few seconds delay.



109

Figure 2. Extended FSM

When looking at the app, users are able to view their own position and those of their observed friends (see Figure 3, left screenshot) with maximum accuracy (depending on the devices’ positioning capabilities). In addition, a user can trigger the so-called spots, i.e. self-set POIs that actively announce the arrival of a user on his Facebook wall when he reaches spatial proximity to it (see Figure 3, right screenshot). Thus, Spotnick requires the best possible accuracy when the app is in foreground mode, when observing friends or at regional closeness to spots. For the remaining time of usage (which we presume represents the major part of a day for a human being, e.g. when he/she is in his/her office or at night times), less accurate positioning methods comply to keep the app functional but not wasting energy. 4. Metrics and test scenarios To benchmark the energy saving qualities of our proposed methods using our app Spotnick, we have repetitively conducted a series of tests, which were organized as follows: All tests have been carried out sequentially on the same two devices, an iPhone 4S with iOS 6.01 and an HTC Desire HD with Android 2.3.5 as the operating systems. All

IJPCC 11,1


110

Figure 3. Spotnick user interface

tests have used the same mini-apps, which have recorded time stamps, WGS84 coordinates (if available) and the battery status via the SDK functions in regular time intervals. Although, we have not been able to provide exact equal test conditions for the particular tests due to cellular network fluctuations, arbitrary WLAN availability, or the speed or duration of our trips while moving through the city traffic, we have at least tried to provide similar test conditions (Table III). Naturally, we have always used the same phone settings (i.e. WLAN turned on, Bluetooth turned off, universal mobile telecommunications system (UMTS) preferred but EDGE allowed, no phone calls, no messages, no Internet surfing, no other apps running, etc.) and have performed daily recurring procedures, i.e. driven the same route from home to the office, which is about 20 km distance or approximately half an hour of driving time (depending on the traffic situation) twice a day (bidirectional). We have Devices Settings Usage Actions Table III. Test parameters

iPhone 4S, iOS 6.01 HTC Desire HD, Android 2.3.5 Always same devices, both approximately 1 month old 3G enabled WLAN always on Bluetooth always off No app running except test app No Internet surfing No phone calls or messages 20 km driving 2 " a day (always same route from home to office) App is generally in background mode 6 " app in foreground mode for 3 min each (2" while driving, 2 " in office, 2 " at home) Minimum 8 " observation by other clients (for each relevant state of the FSM)


placed ten POIs to be triggered in constant gaps along the route. Please note that only triggering POIs require full accuracy, while “normal” POIs are not affected by the strategy. At home and in the office, the app has been used in foreground to see where the other clients are residing (twice for each location and approximately 3 minutes each – simulating an assumed behavior of people using such an app). While driving (complying with local laws in terms of mobile phone usage in cars), our device has been observed by one to three other clients (also for about 3 minutes each) in rather irregular time intervals, such that every possible status permutation (i.e. eight different states given by the FSM, see Table I) has been created at least once (app in foreground, in background, device moving, not moving, observed, not observed, while driving, when stationary, etc.). With these prerequisites, four test series have been conducted repetitively: (1) Standby mode test: This test examines the operating time when no app is running. It serves as a reference. (2) Full GPS test: This test should examine the practical operating time when the GPS is operational all the time, both in foreground and in background mode. (3) Full GPS and data transmission test: Same as the above-mentioned point 2, including the transmission of HTTP data packages every minute (simulating the transmission of position data). (4) Spotnick test: This test executed the app Spotnick, which contained the energy saving strategies described in Section 3.


5. Results According to the four test scenarios the measured results of our conducted tests are as follows [separately considering operating times, accuracy and limitations or drawbacks in corresponding subsections, see also (Narzt, 2013)]: 5.1 Operating times Table IV lists the parameters and typical results for one of the conducted Standby Mode Tests for each platform. The tests lasted for almost exact six days for the iPhone and nearly four days for the HTC until the batteries were drained completely. All location services were turned off (i.e. no GPS and no cellular or WLAN-based positioning; however, WLAN was turned on) and there was no data transmission during the test phase (i.e. no browsing, no mail traffic, no messaging, etc.). We measured an average decline of 0.7 per cent battery power per hour for iOS and 1.1 per cent for Android and took these values as a reference for the subsequent tests (i.e. the operating times are referred to as 100 per cent). Device Operating system Start date Location services Data transmission Duration Average decline Relative duration

iPhone 4S iOS 6.01 January 29, 2013 Off None, WLAN on 6d 0.7% p.h. 100.0%

HTC desire HD Android 2.3.5 January 31, 2013 Off None, WLAN on 3 d 21 h 36 min Table IV. Measurement results 1.1% p.h. standby mode 100.0%

IJPCC 11,1

Standby Mode: iPhone 4S / iOS 6.01

0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00

100 80 60 40 20 0

Standby Mode: HTC Desire HD / Android 2.3.5

Device Operating system Start date Location services Data transmission Duration Table V. Measurement results Average decline continuous GPS Relative duration

iPhone 4S iOS 6.01 February 12, 2013 On None, WLAN on 11 h 40 min 8.6% p.h. 8.1%

0:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

Figure 4. Battery consumption standby mode

100 80 60 40 20 0 06:00


112

Figure 4 illustrates the decline during the test. Please note that the tests were not started at midnight – just the scale starts at 0000 hours for an easier comparison to subsequent tests. We recognize an almost linear decline of battery power for both platforms. The variations are likely to depend on varying environmental conditions, e.g. (wasted) attempts of the device to connect to WLAN. However, we have not investigated these divergences in detail. Test number 2 was the Full GPS Test. Table V lists the parameters and results for one typical test run. For the iPhone, continuous use of the GPS and network-based localization reduced operating times down to 11 hours and 40 minutes (which is only 8.1 per cent of the time compared to the Standby Mode Test) with an average decline of 8.6 per cent battery consumption per hour. For the HTC, we measured similar bad results in a relative comparison with 9 hours and 7 minutes uptime, which is 11 per cent battery decline per hour, only 9.7 per cent of the operating times compared to the Standby Mode Test (see Table IV). Figure 5 illustrates this decline. For a better impression, the original scales in this graph are the same as in Figure 4.

HTC desire HD Android 2.3.5 February 4, 2013 On (GPS # Network) None, WLAN on 9 h 07 min 11.0% p.h. 9.7%


GPS: iPhone 4S / iOS 6.01 100 80 60 40 20

113

GPS: HTC Desire HD / Android 2.3.5

Figure 5. Battery consumption continuous GPS

0:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

100 80 60 40 20 0 06:00


0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00

0

However, it still goes worse. If we additionally transmit HTTP packets in regular time intervals (i.e. every minute in this example) containing an identification number, a timestamp, the position and accuracy of the device’s positioning technique such that other observing clients may perceive the current whereabouts of this device (Full GPS and Data Transmission Test, see Table VI and Figure 6), then we measure operating times of only 11 hours and 24 minutes for iOS and 7 hours for Android. Surprisingly, these results are marginally worse compared to the Full GPS Test. Initially, we expected a more significant decline due to repetitively executed data transfer every minute (which makes 684 packages sent and the same amount of establishing a connection and closing it again). The effective operating time is now 7.9 per cent for iOS and 7.5 per cent for Android compared to the Standby Mode Test. The battery loss is worse for Android with 14.3 per cent per hour compared to 8.8 per cent for iOS. We have not yet investigated the reasons for this divergence in the behavior for the two platforms. The measured results of Tests 2 and 3 (see Figures 5 and 6) tell their own tale in terms of energy consumption. It is obvious that continuous utilization of GPS (and beyond that coupled with regular data transmission) decisively decrease batteries’ operating times and, therefore, the

Device Operating system Start date Location services Data transmission Duration Average decline Relative duration

iPhone 4S iOS 6.01 February 14, 2013 On Every minute 11 h 24 min 8.8% p.h. 7.9%

HTC desire HD Android 2.3.5 February 6, 2013 On (GPS # Network) Every minute Table VI. Measurement results 7 h 00 min continuous GPS # 14.3% p.h. data transfer 7.5%

IJPCC 11,1

GPS + Requests (1min): iPhone 4S / iOS 6.01 100 80 60 40 20 0

GPS + Requests (1min): HTC Desire HD / Android 2.3.5

0:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

0:00

Figure 6. Battery consumption GPS # data transfer

12:00

100 80 60 40 20 0 06:00


0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00

114

attractiveness of LBSs for mobile devices permanently operational in the foreground and in background mode. Hence, the results for our proposed context-based energy saving strategies presented in Section 3 are vital (regarding the Spotnick Test). They are consolidated in Table VII. For the iOS platform, the test lasted a bit longer than three days, which is 50.5 per cent compared to the Standby Mode Test with an average decline of 1.4 per cent of battery power per hour. We have achieved slightly better results for the Android platform with 65.5 per cent uptime. Figure 7 reveals some reasons for that (note that the recording mechanism worked differently for iOS and Android, which is the reason for the different accuracy values of the curves). Considering the descent of the curve for the iOS device, it is clearly recognizable when the GPS was operational (State A, e.g. after the first 24-hour vertical line – the transparent red lines mark the driving times of approximately half an hour for each line). For this snapshot, it is not distinguishable whether the app was in foreground mode, he device has been observed or POIs have been near. The flattest parts of the curve represent the region monitoring states (State C), where the device has been stationary (e.g. at night times or in the office).

Device Operating system Start date Location services Data transmission Duration Table VII. Measurement results Average decline spotnick Relative duration

iPhone 4S iOS 6.01 February 25, 2013 Spotnick strategy On pos. updates 3 d 46 min 1.4% p.h. 50.5%

HTC desire HD Android 2.3.5 February 17, 2013 Spotnick strategy On pos. updates 2 d 13 h 16 min 1.6% p.h. 65.5%


Spotnick: iPhone 4S / iOS 6.01 100 0 80 8 60 6 40 4 20 2

115

Spotnick: HTC Desire HD / Android 2.3.5 100 00 80 60 40 20 0

0:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

Driving Times

06:00


0:00 6:00 12:00 18:00 8 00 0:00 6:00 12:00 8:00 18:00 0:00 6 00 6:00 12:00 18:00 8:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00

0

If we, for example, take a look at the descent after the second 24-hour vertical line for the iOS test, we recognize a movement in background mode (State B) while not being observed and no POIs near. The length of the line (i.e. the duration of the movement) is too long for a trip to the office. During our tests, we have recognized that the transition from State B to C (see formula 4) is tricky in some cases due to ambiguous calculations regarding the detection of minimal or no movement (using variable thresholds % for varying accuracy values of different positioning techniques). As a result, the FSM in some cases remains in State B is longer than desired for the iOS implementation. We do not recognize this effect for Android, which we interpret as one of the major reasons for better results on Android (beyond the fact that Android provides more precise methods in its SDK for controlling the localization modules of the devices). 5.2 Accuracy Considering the accuracy of the calculated positions, we have measured comparable results for both iOS and Android platforms. As a consequence, we do not present a side-by-side comparison considering platform differences, but compare the Spotnick results of one platform to the routes recorded by GPS. The top picture in Figure 8 (red line) shows a route detail driven in a car with the GPS turned on (Test number 2: Full GPS Test). The picture below (blue line) shows the same route recorded using the Spotnick strategy (here: measured by the iPhone). The comparison clearly demonstrates the thought principle of the strategy: less localization points and also sometimes less accurate localization points need less power for determination, but are still enough for recognizing the covered route to trigger POIs and to turn on the GPS when needed, e.g. when being observed by other devices of participating users.

Figure 7. Battery consumption Spotnick

IJPCC 11,1


116

Figure 8. Accuracy comparison GPS (red) vs Spotnick (blue)

Figure 9. Accuracy comparison GPS (red) vs Spotnick (blue)

Figure 9 (top-left picture) shows a clipping of the daily way from our office at the University of Linz (starting beyond the top-right corner) to a home location (beyond the left edge). The red line marks the path measured by GPS (recorded at Test 2). It represents the most accurate path we can get from the used mobile device (here: measured by the iPhone). The blue line marks the path from the Spotnick app including all energy saving mechanisms presented in Section 3 (also: measured be the iPhone). In the urban areas (in the right half of the map), the recorded positions are clearly distinguishable from the GPS points, however, for this use-case are still accurate enough to recognize an unambiguous movement along a particular city district. In the rural areas (in the left half of the map), the recorded positions were less in amount (because farther apart) and less accurate (because of rural cellular positioning, which is imprecise due to distant antennas). Nevertheless, also here an unambiguous movement is


recognizable for possible observers for the short period of time until the moving device is informed about being monitored and therefore turns on the GPS with a slight latency. The top-right picture of Figure 9 shows a switch from GPS (for a short period of time when a device is being monitored) to network positioning (see the blue line, clipped part out of the top picture). Coming from the top-right corner in this map, the GPS is turned on due to an observing client and it has been turned off right before the first junction in this map. Please note, that the blue line (even when the GPS is turned on) is built on just a few measured points, which is due to a minimum distance to be covered and a minimum period of time to be elapsed for a position to be recorded and transferred. When the GPS is turned off, the picture shows a deviation in the recorded points. Finally, the bottom picture in Figure 9 shows Spotnick’s behavior outside city boundaries when in background mode and not being observed. We recognize significant deviations to the GPS recorded route with less accurate values, however, also for rural areas, the strategy immediately provides an approximate position for potential sudden observers, who may perceive a friend’s position in the middle of a river for just a few seconds until the software recognizes being observed and turns on the GPS. 5.3 Limitations/drawbacks For short trips from home to our office and back (about 20 km or half an hour driving time), the strategy worked well, as for the major part of the day, the device was idle in State C. To also prove the validity of the strategy for long trips, we have conducted tests with 200 km or 2.5 hours of driving time for each direction (i.e. 400 km a day or 5 hours of driving time in total). The results were worse than for the short office trips, as expected, because of shorter idle State C. Nevertheless, we have managed to keep the batteries’ operational times significantly above 24 hours. Unfortunately, we cannot give a more precise figure due to the low number of tests conducted for long-term evaluations. Figure 10 gives an impression on the accuracy: We recognize single heaps of measured points along the route (e.g. when observed, when the app has been in foreground mode or in city areas with a greater antenna density). We also recognize long distances (several kilometers) without a measured point, which is likely to be due to a low antenna density in rural areas. Another problem was the latency of the region monitoring mode to detect a potential movement in rural areas. Whereas in urban areas, a state transition can be performed quickly due to a greater WLAN coverage (which increases the probability for WLAN roaming), this triggering event comes with a significant delay in rural areas. Figure 11 gives an example of this fact, where a trip has been started from the point at the top of the picture. The red line indicates the GPS recorded route and the blue line shows the actual location measurements by Spotnick. Only after approximately 1 km of driving (which are 770 m linear distance), the first cell-based handover occurred and triggered the transition from region monitoring to State A (best accuracy), which also marks the average latency in rural areas. The worst results show delays within 3 km. Both iOS and Android revealed comparable effects.


IJPCC 11,1


118

Figure 10. Spotick long-term strategy

Figure 11. Latency at region monitoring in rural areas

6. New options with Apple’s M7 Especially in terms of the latency issue in region monitoring mode, the iPhone 5S offers new options for the developers to improve the detected drawbacks. It includes a “motion co-processor” called M7 that works alongside the main processor capable of continuously measuring accelerometer, compass and gyroscope data at a low energy


level designed to move the weight off from the phone’s main chip. Apple claims improvements for both performance and battery life. From the developer’s perspective, the M7 provides discrete motion data, i.e. walking, running, driving (“automotive”) and not moving (“stationary”), e.g. prevents the smartphone from joining Wi-Fi networks as users pass by in “automotive” mode or reduces network pings while “stationary”, thus ameliorating energy consumption at various levels. With that in mind, we intended to modify our architecture such that it takes advantage of this new co-processor and tried to find those hooks where the new options could be plugged in. A simple and obvious hook is the region monitoring State C (see Figure 1), which represents an idle state where the device is stationary and waiting for a motion event when the user starts to move again. The transition features of the new M7 “core motion” API are meant to provide these data, so, a replacement of the corresponding region monitoring software component by a new implementation utilizing the M7 “core motion” API (by simultaneously keeping the original architecture concept and its collaborations) potentially improves both energy consumption and latency drawbacks, as discovered in Figure 11. Unfortunately, Apple restricts access to its new features and prevents apps from using them in background mode unless some privileged service is granted CPU resources when the device is in standby and put aside (e.g. location services, music services, etc., while the new “motion services” are not permitted). So, instead of simply replacing the region monitoring state by a new software component implementing the M7 “core motion” API, the actual design had to be a combination of both, as a consequence: The region monitoring component still ensures continuous CPU access (also while in background mode) and the M7 component utilizes additional sensor technology to quickly retrieve motion data concerning a potential movement after a “stationary” state. Figure 12 briefly illustrates this dual principle within a schematically unchanged State C. Due to Apple’s limitation, we do not expect less energy consumption (as the region monitoring component is still fully operational), however, there should be enhancements concerning the latency issue for detecting a potential movement after being stationary. To test the behavior of these modifications, as shown in Figure 12, we have conducted additional tests using the same test conditions as given in Table III with an iPhone 5S and the operating system iOS 7.1 installed. We have recorded data for the Standby Mode Test, the Full GPS Test and the Full GPS#Data Transmission Test to collect reference values (see Table VIII and Figures 13-15) and finally conducted the Spotnick Test again (two times, see Table IX and Figure 16: one with an unchanged software architecture as presented in Section 3 and another test with the modified architecture as sketched here in Section 6 with the following results: In general, we recognize a longer period of operation for the iPhone 5S with a maximum uptime of 8 full days and 10 hours compared to the iPhone 4S with 6 full days of operation at the Standby Mode Test. So, without any app running the average battery consumption seems to be better for the iPhone 5S with 0.5 per cent per hour (compared to 0.7 per cent p.h. at the iPhone 4S, again: this value serves as a reference of 100 per cent). As expected, the Full GPS Test emptied the batteries in short time, i.e. an uptime of only 12 hours and 41 minutes or a decline of 7.9 per cent relative to the Standby Mode Test (compare: 11 hours 40 minutes or 8.6 per cent for the iPhone 4S). A longer uptime and a slower decline in battery consumption compared to the 4S seems to be an improvement at the first glance; however, considering the value for the relative duration,


IJPCC 11,1

Figure 12. Modified architecture utilizing Apple’s M7

iPhone 5S iOS 7.1 Start date Location services Data transmission Duration Table VIII. Measurement results Average decline for the iPhone 5S Relative duration

Standby mode test

Full GPS test

GPS # data transfer

April 10, 2014 off None, WLAN on 8 d 10 h 0.5% p.h. 100%

April 25, 2014 on None, WLAN on 12 h 41 min 7.9% p.h. 6.3%

April 22, 2014 on Every minute, WLAN on 12 h 20 min 8.1% p.h. 6.1%

Standby Mode: iPhone 5S / iOS 7.1

Figure 13. Battery consumption standby iPhone 5S

100 80 60 40 20 0 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00


120


GPS: iPhone 5S / iOS 7.1 100 80 60 40 20

Figure 14. Battery consumption GPS iPhone 5S

0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00

0

100 80 60 40 20 0

GPS + Requests (1min): iPhone 5S / iOS 7.1

Figure 15. Battery consumption GSP # data iPhone 5S

0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00


we now recognize 6.3 per cent uptime for the 5S compared to 8.1 per cent for the 4S, thus indication a worsening in terms of energy consumption. We measured similar results for the Full GPS and Data Transmission Test with slightly worse results compared to the Full GPS Test: The total uptime was approximately 20 minutes shorter than for the Full GPS Test (i.e. 12 hours and 20 minutes), which meant a relative duration of 6.1 per cent compared to the Standby Mode Test (see: 7.9 per cent for the iPhone 4S). At the time of writing, we were not able to interpret these results: Obviously, the total battery uptime for the iPhone 5S is significantly longer than for the iPhone 4S in Standby Mode. Also, the absolute values for GPS utilization are better, however, the relative values reveal worse energy consumption for the localization sensors. Having these (non-interpreted) data as new reference values for the iPhone 5S, we have measured the energy consumption behavior using our proposed Spotnick strategy. To have a better comparison, we have conducted both tests with the unchanged software architecture (see middle column in Table IX) and with the modified region monitoring component utilizing the M7 (see right column in Table IX).

iPhone 5S iOS 7.1

Spotnick test original

Spotnick test with M7

Start date Location services Data transfer Duration Average decline Relative duration

April 2, 2014 Spotnick strategy On location update 4 d 2 h 30 min 1.01% p.h. 48.8%

April 6, 2014 Spotnick strategy On location update 4 d 1 h 10 min 1.03% p.h. 48.1%

Table IX. Measurement results for the iPhone 5S

IJPCC 11,1

Spotnick: iPhone 5S / iOS 7.1 100 80 60 40

Figure 16. Battery consumption Spotnick iPhone 5S

Figure 17. Latency issue using the M7

20 0 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 00:00


122

Both tests revealed about the same amount of energy consumption with slightly better results for the original Spotnick strategy, as expected (i.e. 4 days, 2 hours and 30 minutes compared to 4 days, 1 hour and 10 minutes). This is obviously due to the fact that the M7 API could not be used solitarily in background mode but had to be applied in addition to the original region monitoring mechanism, thus creating an auxiliary energy consumer. Again, compared to the iPhone 4S, the results are slightly worse with a relative uptime of 48.8 per cent (or 48.1 per cent) for the iPhone 5S and 50.5 per cent for the iPhone 4S. Nonetheless, both smartphones reach about half of the uptime using the Spotnick location strategy in relation to standby. Considering the latency issue for the reactivation of GPS after the device has been stationary in State C (see Figure 12), we clearly recognize an improvement: the blue line in Figure 17 represents the location points measured after the M7 processor has delivered a “moving” event (the red line depicts the corresponding route measured at the Full GPS Test). We recognize a couple of inaccurate points before the first GPS fix, but we immediately start

7. Summary and future work Continuous utilization of GPS in LBS for modern smartphones accelerates the process of draining batteries. To extend operating times, we have developed a generic context-based architecture for saving energy. In particular, we avoid usage of GPS whenever possible and use region monitoring when a device is not moved, e.g. at night times or while residing in the office, and network-based positioning when nobody takes notice of the app but continuous localization is required. As a consequence, accuracy is diminished in certain situations (e.g. while moving with the app in background) and we have to accept latency for the reactivation of GPS whenever needed (e.g. when leaving a static position or when being monitored by other devices). Nevertheless, we succeeded in saving energy while guaranteeing a full functional service regarding location-based operations. Figure 18 summarizes the results of our conducted tests with a theoretical optimum when the device is in standby mode (green line) and a worst result with GPS engaged and


iPhone 4S / iOS 6.01 Standby Mode 100

Spotnick

80

GPS

60

GPS+HTTP

40 20 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00

0

HTC Desire HD / Android 2.3.5 Standby Mode

100 80 60 40 20

0:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

18:00

12:00

0:00

06:00

0

iPhone 5S / iOS 7.1 100 80

Standby Mode GPS GPS+HTTP

60 40 20 0 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00 12:00 0:00


sensing the device’s location without a delay compared to the original Spotnick strategy, as shown in Figure 11.

Figure 18. Battery consumption overview

IJPCC 11,1


124

Table X. Comparison with other approaches

Approach Device, operating system Spotnick iOS iPhone 4S, iOS 6.01 Spotnick iOS iPhone 5S, iOS 7.1 Spotnick Android HTC desire HD, Android 2.3.5 Kjaergaard et al. (2009) Nokia N95, Symbian Oshin et al. (2012) HTC desire HD, Android 2.3.3 Bareth and Küpper (2011) Motorola milestone, Android 2.2

GPS (hours)

Strategy (hours)

Step-up (times)

Savings (%)

11.4

72.7

6.4

84.3

12.7

98.5

7.8

87.1

7.0

61.3

8.8

88.6

n.a.

n.a.

n.a.

43-56

11.0

25.0

2.3

56.0

7.6

66.6

8.8

88.6

repetitive data transmission (red line). In between are the results of our energy-efficient localization strategy used by Spotnick (blue line), which indicates a clear improvement compared to the exhaustive utilization of GPS and confirms its generic title for different devices and operating systems. Although the basic reference values are clearly different for the investigated systems (i.e. standby uptime ranges from four to more than eight days), the curves show similar gradients for all of them when we normalize the scales. Table X compares the quality of our results to other approaches. We recognize promising figures that are equal [for Bareth and Küpper (2011)] or significantly better than alternative energy-saving strategies. The proposed energy saving strategy is implemented within the cores of two proprietary applications for iOS and Android and is, therefore, encapsulated in a closed application component. Hence, it is supposed to be embedded into the libraries one level below the application layer (i.e. included in the SDK for each platform) to also provide the functions and strategies for other applications with similar requirements in terms of accuracy, latency of reaction and energy consumption. So, the next challenges in this field will be the consolidation of the various strategies developed and the integration of the most effective ideas into system libraries, abstracting from proprietary sensor systems and hardware features. We consider Apple’s approach of providing low-energy mobility data by a separate co-processor as a first step towards this direction, although its practical application is still restricted by company policies keeping preliminary results in terms of energy consumption beyond their potentials. Investigations on energy saving strategies for iOS and Android devices are still underway; however, the first version of Spotnick including these strategies is available for iPhones in the App Store and for Android on Google Play. Due to comparable results for iOS and Android, we regard our proposed context-based energy saving strategies as code of practice for mobile LBS, in general. References Balasubramanian, N., Balasubramanian, A. and Venkataramani, A. (2009), “Energy consumption in mobile phones: a measurement study and implications for network applications”, Proceedings of the 9th ACM SIGCOMM Conference on Internet Measurement Conference, New York, NY, pp. 280-293.


Barbeau, S.J., Labrador, M.A., Perez, A., Winters, P., Georggi, N., Aguilar, D. and Perez, R. (2008), “Dynamic management of real-time location data on GPS-enabled mobile phones”, Proceedings of the 2nd International Conference on Mobile Ubiquitous Computing, Systems, Services, and Technologies, Valencia, pp. 343-348. Bareth, U. and Küpper, A. (2011), “Energy-efficient position tracking in proactive location-based services for smartphone environments”, Proceedings of the 35th Annual Computer Software and Applications Conference, Munich, pp. 516-521. Barrows, C., Blumsack, S. and Bent, R. (2013), “Using network metrics to achieve computationally efficient optimal transmission switching”, Proceedings of the 46th Hawaii International Conference on System Sciences, HICSS, Wailea, Maui, HI, pp. 2187-2196. Carroll, A. and Heiser, G. (2010), “An analysis of power consumption in a smartphone”, Proceedings of the 2010 USENIX Annual Technical Conference, Boston, MA, USENIX Association Berkeley, CA, pp. 21-21. Chatterjee, S., Nurminen, J.K. and Siekkinen, M. (2012), “Low cost positioning by matching altitude readings with crowd-sourced route data”, Proceedings of the 10th International Conference on Advances in Mobile Computing & Multimedia, ACM, Bali, pp. 169-178. Constandache, I., Gaonkar, S., Sayler, M., Choudhury, R.R. and Cox, L. (2009), “Enloc: energy-efficient localization for mobile phones”, Proceedings IEEE INFOCOM, Rio de Janeiro, pp. 2716-2720. Farrell, T., Lange, R. and Rothermel, K. (2007), “Energy-efficient tracking of mobile objects with early distance-based reporting”, Proceedings of the Fourth Annual International Conference on Mobile and Ubiquitous Systems: Networking Services, Philadelphia, PA, pp. 1-8. Farrell, T., Rothermel, K. and Cheng, R. (2011), “Processing continuous range queries with spatiotemporal tolerance”, IEEE Transactions on Mobile Computing, Vol. 10 No. 3, pp. 320-334. Gobriel, S., Maciocco, C., Tai, C. and Min, A. (2012), “A EE-AOC: energy efficient always-on-connectivity architecture”, Proceedings of the 8th International IARIA Conference of Wireless and Mobile Communications, Venice, pp. 110-117. Jurdak, R., Corke, P., Cotillon, A., Dharman, D. and Crossman, C. (2013), “Energy-efficient localization: GPS duty cycling with radio ranging”, ACM Transactions on Sensor Networks (TOSN), Vol. 9 No. 2, Article No. 23. Jurdak, R., Corke, P., Dharman, D. and Salagnac, G. (2010), “Adaptive gps duty cycling and radio ranging for energy-efficient localization”, ACM Conference on Embedded Networked Sensor Systems, Zurich, pp. 57-70. Kellokoski, J., Koskinen, J., Nyrhinen, R. and Hamalainen, T. (2012), “Efficient handovers for machine-to-machine communications between IEEE 802.11 and 3GPP evolved packed core networks”, Proceedings of the IEEE International Conference on Green Computing and Communications, Besancon, pp. 722-725. Kjaergaard, M., Langdal, J., Godsk, T. and Toftkjaer, T. (2009), “EnTracked: energy-efficient robust position tracking for mobile devices”, Proceedings of the 7th International Conference on Mobile Systems, Applications, and Services, New York, NY, pp. 221-234. Narzt, W. (2013), “High-level energy saving strategies for mobile location-based services on android devices”, Proceedings of the 9th International Conference on Wireless & Mobile Communications, Nice, pp. 238-243. Narzt, W. and Schmitzberger, H. (2009), “Location-triggered code execution – dismissing displays and keypads for mobile interaction”, Proceedings of the 5th International Conference on Universal Access in Human-Computer Interaction, UAHCI ’09, San Diego, CA, Springer-Verlag, Berlin, Heidelberg, Part II, pp. 374-383. Oshin, T.O., Poslad, S. and Ma, A. (2012a), “A method to evaluate the energy-efficiency of wide-area location determination techniques used by smartphones”, Proceedings of the


IJPCC 11,1


126

15th International IEEE Conference on Computational Science and Engineering, CSE 2012, Paphos, pp. 326-333. Oshin, T.O., Poslad, S. and Ma, A. (2012b), “Improving the energy-efficiency of GPS based location sensing smartphone applications”, Proceedings of the 11th International IEEE Conference on Trust, Security and Privacy in Computing and Communications, TRUSTCOM, Liverpool, pp. 1698-1705. Paek, J., Kim, J. and Govindan, R. (2010), “Energy-efficient rate-adaptive GPS-based positioning for smartphones”, Proceedings of the ACM International Conference on Mobile Systems, Applications, and Services, New York, NY, pp. 299-314. Rahmati, A. and Zhong, L. (2007), “Context-for-wireless: context-sensitive energy-efficient wireless data transfer”, Proceedings of the 5th International Conference on Mobile Systems, Applications and Services, New York, NY, pp. 165-178. Taylor, I.M. and Labrador, M.A. (2011), “Improving the energy consumption in mobile phones by filtering noisy GPS fixes with modified Kalman filters”, Proceedings of IEEE Wireless Communications and Networking Conference, Cancun, pp. 2006-2011. Wang, L. and Manner, J. (2010), “Energy consumption analysis of WLAN, 2G and 3G interfaces”, Proceedings of the 2010 IEEE/ACM Int’l Conference on Green Computing and Communications, Hangzhou, pp. 300-307. Youssef, M., Yosef, M. and El-Derini, M. (2010), “GAC: energy-efficient hybrid GPS-accelerometer-compass GSM localization”, Proceedings of the IEEE Global Telecommunications Conference, Miami, Florida, pp. 1-5. Zhuang, Z., Kim, K. and Singh, J.P. (2010), “Improving energy efficiency of location sensing on smartphones”, Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services (MobiSys), ACM, New York, NY, ISBN: 978-1-60558-985-5, doi: http://dl.acm.org/citation.cfm?id$1814464, pp. 315-330. About the author Wolfgang Narzt graduated in Computer Science in 1997 in a cooperative project with Daimler Benz Airospace in Ulm (Germany). In 2000, he obtained his PhD at the Johannes Kepler University Linz in the course of a EU cooperation with Siemens (Germany), VOEST-Alpine (Austria) and Mandator Technics (Sweden). From 2000 to 2006, he worked at the Department for Pervasive Computing at the University of Linz, where he was responsible for several cooperative R&D projects with Siemens Corporate Technology in Munich (Germany). The main research focus in this time has been augmented reality in combination with location-based services. Since 2006, he has been working at the Department for Business Informatics at the University of Linz. The R&D focus has shifted to mobile computing, human computer interaction and, accordingly, machine-to-machine (m2m) communication for mobile location-based services. He was the head of a series of national and international research projects for mobile location-based services (e.g. in cooperation with MAN trucks, Hoedlmayr International, Austrian Railways federation, etc.) and has transferred scientific research results into industry products, thus bridging research and industry on a common level. Wolfgang Narzt can be contacted at: [email protected]

For instructions on how to order reprints of this article, please visit our website: www.emeraldgrouppublishing.com/licensing/reprints.htm Or contact us for further details: [email protected]

Power-saving localization techniques for mobile devices

Power-saving localization techniques for mobile devices

Suggest Documents

Indoor localization of mobile devices for wireless networks monitoring ...

Energy-Accuracy Aware Localization for Mobile Devices - Feng Zhao

Indoor localization of mobile devices for wireless networks ... - CiteSeerX

Indoor localization of mobile devices for wireless networks ... - CiteSeerX

Cooperative Positioning Techniques for Mobile Localization in 4G ...

Laser Based Localization Techniques for Indoor Mobile Robots

Localization of off-the-shelf mobile devices using audible sound

Energy-Efficient Localization and Tracking of Mobile Devices in ...

MaaS360 for Mobile Devices - FAQs

Telemedicine for Mobile Devices - Aecus

Game Programming for Mobile Devices

Java for Mobile Devices - Huihoo

Linux Powersaving - LUG@GT

Linux Powersaving - LUG@GT

Game Programming for Mobile Devices

XML Messaging for Mobile Devices

Telemedicine for Mobile devices - Aecus

Relative Localization for Mobile Robots

Crowdsourced Indoor Localization for Diverse Devices through ...

A survey on mobile anchor assisted localization techniques in wireless ...

Calibration Techniques for Industrial Mobile

Modulation Techniques for Biomedical Implanted Devices ... - CiteSeerX

Nanofabrication techniques for controlled drug-release devices

Characterization Techniques for Surface-Micromachined Devices