Extending battery lifetime of mobile devices with geofence capabilities ...

Extending battery lifetime of mobile devices with geofence capabilities on dynamic-speed urban environments Luis Loyola

Fernando Wong

Daniel Pereira

R&D Division SkillUpJapan Corporation Tokyo, Japan

R&D Division SkillUpJapan Corporation Tokyo, Japan

R&D Division SkillUpJapan Corporation Tokyo, Japan

[email protected] [email protected] [email protected] Horacio Sanson R&D Division SkillUpJapan Corporation Tokyo, Japan

[email protected] ABSTRACT

1.

In this work we present a battery-saving algorithm for Location Based Services (LBS) that exploits the geofence functionalities provided by modern mobile operating systems such as iOS and Android. The algorithm detects the surrounding areas of interest (AoI) by taking advantage of the underlying structure of quadtrees, considerably saving the number of requests to the LBS server made by the application, thus extending its battery lifetime even in dynamicspeed environments. The areas of interest can have any arbitrary shape and are not constrained to circles as in previous work. In our experiments, through empirical and simulation tests, we show that a substantial reduction of battery consumption can be achieved (up to 45%) while keeping a perfect detection accuracy of areas of interest in comparison with periodic polling techniques widely used in current mobile applications, with error rates of up to 55%.

The number of geolocation and geotargeting-based applications is surging rapidly along with the penetration of GPS-enabled mobile devices at affordable prices. The penetration of smartphones in developed countries such as UK, Australia or Sweden has already exceeded 50% in 2012 and is increasing at a rapid pace in developing countries as well. A novel and exciting market based on the association of physical places with their corresponding metadata is creating great opportunities for new services and applications. In this scenario, the technique of geofencing is emerging as a powerful technology that offers the base for many of those location-based services and applications, making it possible for users to define areas of interest around different places. In the context of this paper, an area of interest (AoI) corresponds to a geographical area such as a park or a stadium, a 100m-radius circle around a store or a private residence, etc. In this paper we describe a technique for saving valuable battery resources based on the calculation of the minimum distance to an AoI, which can be considered the minimum wake-up distance for a mobile device running a LBS application. Thus, if the closest AoI is located at 600 meters from the current location, the LBS application can safely switch off its server polling module for that distance irrespective of the time dimension. Furthermore, such minimum wakeup distance may differ depending on the direction the user is moving so that, for instance, it could be 100 m, 300 m, 600 m and 2 Km when heading for North, South, East and West, respectively. In practice, however, the quality of GPS receivers substantially varies among devices, so an application developer cannot totally rely on the location detected by the device, and for that reason it is always advisable to consider time thresholds as well. This paper proposes an efficient technique for mobile devices to scan surrounding AoIs across many possible directions. Our scanning technique works on the top of a quadtree data structure where AoIs are mapped to. The original contributions of this paper are: a scanning algorithm for geofence-capable mobile devices that (i) exploits the features provided by the underlying quadtree data structure, (ii) can deal with AoIs of any arbitrary shape without be-

Categories and Subject Descriptors I.3.5 [Computational Geometry and Object Modeling]: Geometric algorithms, languages, and systems; E.1 [Data Structures]: Trees; H.3.3 [Information Search and Retrieval]: Retrieval models; D.2.8 [Software Engineering]: MetricsPerformance measures

General Terms Algorithms, Experimentation, Measurement, Performance

Keywords Geofence; Quad-trees; Location based services; Battery saving; Open-data; Walk model Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. MobiGIS’13, November 05 2013, Orlando, FL, USA Copyright 2013 ACM 978-1-4503-2531-8/13/11 ...$15.00. http://dx.doi.org/10.1145/2534190.2534193.

INTRODUCTION

ing constrained to circles as in previous work, (iii) can work in dynamic-speed environments, and (iv) provides an improved urban mobility model for cities with a strong public transportation system like Tokyo. Our preliminary simulation results suggest that our proposed technique is able to considerably extend the battery life while preserving its AoI detection accuracy.

2. 2.1

BACKGROUND Geofencing

A geofence is a virtual-perimeter over a real-world geographic area that can trigger events when a user enters or leaves it. Geofences are being used for a vast array of applications and services like reminder applications based on area, location sharing and localized advertising. In this paper we argue that geofences can be used to reduce the energy consumption of LBSs that require the application to report its location to a remote service. Both Android and iOS mobile devices support the creation of geofences, but device constraints such as memory and processing capacity limits the geofences to simple circular shapes and the maximum number of geofences that can be processed at a time to 100. These limitations can be problematic in large metropolitan cities (e.g. Tokyo) where the density of AoIs can be larger than the 100 limit imposed by current mobile devices. This limiting factor raises the need for remote geofencing services that can process thousands of geofences and return a smaller subset of them, which are relevant to the user’s current location and context.

2.2

Quadtree Decomposition

A quadtree is a spatial data structure employed for partitioning a two-dimensional space into quadrilaterals, or quads for short, of adaptable sizes. A rectangular region of the space can be represented as a quad in the tree. At the same time, each quad can be recursively partitioned into four smaller child quads, allowing the quadtree to partition the space with quads of varying sizes as necessary. Common applications of quadtrees include image compression [9] and pattern analysis on images [4] among others. In particular, these structures have seen a high degree of success in the development of geographic information systems. Recently, popular NoSQL databases such as MongoDB [1] have employed quadtree-based algorithms for efficiently performing queries of documents located at a certain pair of coordinates or within a particular geographical area. In this work, we employ a similar approach as that used in MongoDB in order to allow users to store any number of AoIs into our prototype system, through the decomposition or mapping of AoIs into quads of varying sizes along different levels of a quadtree structure. This not only allows us to efficiently look for all user-defined AoIs overlapping a given location, but also, by taking advantage of the inherent properties of quadtrees, lets us return information that can be used by mobile devices to make a more efficient use of their batteries, as described in later sections of this paper.

3.

RELATED WORK

Research in energy-efficient location sensing and tracking has been focused on algorithms to reduce the duty-cycle of location sensors (e.g. GPS, WiFi, 3G) available in mobile

devices [6, 8, 10, 11] and regulate location update intervals [7] based on factors such as distance to AoIs and transit modes (e.g. idle, walking, driving). While searching for near AoIs, these algorithms assume the AoIs are static and known a priori, assumptions that fail in practice. Finding the nearest AoIs to a point is a well researched topic [5, 12] that uses complex tree structures for indexing and searching. For practical applications, however, such tree complexity can become a bottleneck, specially for applications that require real time responses. In this paper we map the geometry of each AoI to a set of quadrilaterals through a quadtree decomposition algorithm. This mapping allows us to find, for any location coordinate, which quadrilateral contains it as well as all neighboring quads that map to an AoI with a simple query. As the mapping and demapping correspond to dynamic processes related with the creation and removal of AoIs, our system does not need to have an a priori knowledge of the registered AoIs. Furthermore we can relate the quadtree hierarchy level with the mobile device speed to adjust the size of the search area. This way we can consider AoIs far away when moving fast (e.g. car) and only closer AoIs while moving at slow speeds (e.g. walking) or not moving at all.

4.

PROPOSED SCHEME

4.1

Polygon to Quadtree Decomposition

The proposed technique is based on the use of a quadtree structure for representing the polygonal shapes of AoIs [13]. Each AoI is decomposed into several quadrilaterals distributed along the hierarchy levels of the quadtree. Iterating from the unique quadrilateral of level 0 (i.e. the largest one), downwards along the quadtree architecture, we perform the following process: if a given quadrilateral is completely contained inside an AoI, then it is registered as part of said AoI. Otherwise, if the AoI partially overlaps it, the quadrilateral is split into its four children located at the next level of the quadtree, and the process is repeated on each of them. In such manner, an AoI can be decomposed into a collection of quadrilaterals of varying sizes, distributed along different levels of the quadtree structure as shown in Figure 1. This process is performed as follows: 1. Map the AoI to the first level of the quadtree, assigning to it all quadrilaterals that are fully or partially covered by it. 2. Select the set Q of all quadrilaterals of the current quadtree level that are partially covered by the AoI, i.e. those intersected by the edges of the AoI. 3. Split each quadrilateral in Q into the four smaller ones located at the next quadtree level as mentioned earlier, and map to the AoI only the child quadrilaterals that are fully or partially covered by it. 4. Iteratively repeat Steps 2 and 3 for all quadtree levels, until reaching the final level, or until the amount of quadrilaterals mapped to the AoI surpasses the maximum threshold. Mapping the AoI to each level of the quadtree as done in Steps 1 and 3, as well as finding the quadrilaterals partially overlapped by it as in Step 2, is easily achieved through

(a) Area of interest (AoI)

(b) Quadtree decomposition

Figure 1: Example result of the AoI to quadtree decomposition process.

raster graphics algorithms [2]. These algorithms are optimized for speed, allowing us to perform AoI decompositions in near real-time. Handling modifications to an AoI consists in simply demapping the AoI from its assigned quadrilaterals and performing the decomposition process once more on the new geometry of the AoI.

4.2

Detecting AoI Events in Quadtrees

By taking advantage of the properties of quadtrees, we can efficiently determine if an event is triggered within a certain quad of the tree, namely, if the mobile device is entering or leaving an AoI.

4.2.1

Detecting events within a single quad

Assuming an AoI has been already decomposed and mapped to the quadtree, if a given quad has children, this means the area in question partially overlaps it, and thus, the possibility of entering or leaving the area exists within the region of that quad. To the contrary, if the quad exists but has no children, then it is contained entirely within the AoI and thus, there is no possibility of leaving or entering the area at any point within the quad. This easily extends to the case of having multiple overlapping AoIs, provided they are all mapped to the same quadtree structure. Figure 2 shows these two cases, where the left quad is fully contained within the blue AoI, while the right quad is partially overlapped by the red area, splitting the quad into its children accordingly.

4.2.2

Detecting events when moving from one quad to a neighboring one

In the case of determining whether an event is triggered by moving from a given quad into another one in its 8neighborhood, we need to check if either one of two possible conditions occur. The first condition occurs when the neighboring quad has children, such as in the case of moving from the central quad to the right quad in Figure 2. The second condition occurs if the neighboring quad (or its parents) is mapped to at least one AoI to which the center quad (or its parents) is not mapped to (or vice versa), as in the case of moving from the central quad to the left quad in Figure 2.

4.3

Placing Geofences for Battery Saving

A pseudo-code of our geofence placement algorithm for battery saving is shown in Algorithm 1. The inputs to the algorithm are (1) a quadtree structure where a collection of AoIs with possibly different shapes are mapped to, (2) a reference time frame (60 seconds in our implementation), as well as (3) the location and (4) average speed of the device. The output is a collection of at most nine circular geofences

Figure 2: Detecting Events Figure 3: Example of Gein the 8-Neighborhood of a ofence Placement for Battery Quad. Saving.

covering different regions of the quadtree. The geofence placement starts by locating a GPS-enabled device (marked as a triangle in Figure 3) within a given quad of the quadtree. This quad is chosen so that it overlaps the device location, and we consider both the average speed of the device as well as the overall size of the AoIs overlapping the current location. The idea is to scan a region of the quadtree that can be covered by the mobile device at its current speed within a reasonable amount of time, while at the same time considering if the device location is overlapped by a single large-sized AoI (or if the nearest AoI is located significantly far from the device), as no events will be triggered until reaching the AoI boundaries. This process is better explained in lines 2 to 4 of Algorithm 1, which describes the pseudo-code used by our proposed battery-saving algorithm. After locating the quad as mentioned earlier, we then scan the 8-neighborhood of the located quad, and for each neighbor we check if it fulfills any of the two conditions previously mentioned in Section 4.2.2. If the conditions are satisfied, we place over the neighboring quad a circular-shaped geofence with an arrive-trigger, that is, the mobile device is instructed to send a server request if it “arrives” at this geofence (marked in yellow in Figure 3). In addition, if the central quad (the one where the device is located) happens to be partially overlapped by an AoI (Section 4.2.1), we place a circular geofence centered at the current device location (marked in red in Figure 3), with its radius set as the shortest distance from it to the AoI. This geofence is assigned a leave-trigger to it, instructing the device to send a request if it “leaves” its perimeter. If the central quad is not partially overlapped by any AoI, we place a leave-trigger geofence covering its 8-neighborhood, so that a request is sent if the device leaves the boundaries of the scanned quadtree region.

5.

TESTS AND RESULTS

In this section we will describe the experiments conducted to compare the proposed algorithm with two, widely used, mechanisms to report location updates to a LBS server: periodic requests on both time and space. The former refers to sending requests to the server at a constant rate in time (i.e. one request every s seconds) while the latter to sending a new request to the server after moving a certain distance (i.e. one request every m meters). We present in Section 5.1 empirical measurements of the device battery capabili-

3G

Battery behaviour on a 3G connection Input: quadtree, location, speed and time Output: geofences[] array

2: 3:

distance ← speed ×time; /* Lower quadtree levels are composed of larger-sized quads in smaller quantities, while higher levels contain quads of smaller sizes but in larger quantities. */ levelDist ← Max. quadtree level that could contain distance; levelQuad ← Max. quadtree level containing quads overlapping location;

4:

/* Select the lowest of the two computed quadtree levels. This ensures we consider both the speed of the device, as well as the size of the AoIs overlapping the current location. */ level ← Min(levelDist, levelQuad);

5:

/* Get quad containing location at the quadtree level. quad ← QuadTree(level, location);

13:

14:

/* Set a geofence centered at origin. Send a request if the device leaves it. */ geofences[] ←NewGeofence(origin, radius, ’LEAVING’ );

7: 8: 9: 10:

11: 12:

18:

foreach neighbor in NeighborsOf(quad) do if HasChildren(neighbor) or ParentsDiffer(neighbor, quad) then /* Set a geofence located at the center of the neighbor quad and whose radius covers it. */ origin ←CentroidOf(neighbor); radius ←WidthOf(neighbor) / 2 ;

19:

/* Send a request if the device arrives at the geofence. */ geofences[] ←NewGeofence(origin,radius, ’ARRIVING’ );

15: 16:

17:

end

20:

5000

10000

15000

20000

25000

30000

Time (s)

120 req/m 1 req/m

15 req/m idle

5 req/m

Figure 4: Battery behavior on a 3G connection

ther see, the battery decreases near linearly in time, which correlates with the results presented in [3], when messages are larger than 1KB. This makes our model easy to implement as the only variable we need to take into account is the request rate at which the client updates its location. Batterylevel = bt0 − α × nreq

(1)

where bt0 is the initial battery level, α is a constant greater than zero and nreq is the number of requests to the server (in our implementation α = 25/110).

5.2

Simulation Methodology

In order to accomplish a large-scale benchmark with mobile devices in a large city, a considerable amount of equipment and resources become necessary. For that reason, our work is based on a simulation performed with an improved urban-mobility model that exploits open geographical data in order to create realistic walk paths. Page 1

21:

end

22:

return geofences[];

Algorithm 1: Grid scanning algorithm

ties, in order to deduce a consumption model. In Section 5.2 we present simulations for our proposed method based on a novel mobility-model that exploits open-data geographical information. In Section 5.3 we describe the test setup and introduce the obtained results, while in Section 5.4 we discuss the results from the simulations.

5.1

0

*/

if HasChildren(quad) then /* Set geofence radius as the distance from the current location to the closest child of quad. */ closest ← FindClosestChildTo(quad,location); radius ← DistBetween(location,CentroidOf(closest)); origin ← location; else /* Set geofence radius to cover the entire 8-neighborhood of the quad being inspected. */ radius ← (WidthOf(quad) × 3)/2; origin ← CentroidOf(quad); end

6:

Battery (mAh)

1:

1600 1400 1200 1000 800 600 400 200 0

Device measurements

Measurements of battery draining were conducted using actual iOS (v 6.1.1) devices with a custom application that would make requests at a certain time frequency. We ran tests spanning several days with a varying number of requests per minute. Figure 4 depicts our average measurements in iOS devices. It shows that making fewer requests increases the battery life significantly while making more than 15 requests per minute (less than a request every 4 seconds) gives the user nearly the same battery performance. A polling rate of 120 requests per minute makes the battery last for 17342 seconds (∼289 minutes) while a rate of 15 requests per minute reduces its life to 15645 seconds (∼261 minutes). Making 5 requests per minute or less gives the user a battery lifetime of 22432 seconds (∼374 minutes) while when making only 1 request per minute a battery life of 29839 seconds (∼497 minutes) is attained. As we can fur-

5.2.1

Open-Data processing

The paths used in this work are created using street arcs, i.e. segments of road between crossroads, and are obtained from OpenStreetmaps1 and transport information available from the Japanese government, for the city of Tokyo2 , as standard GIS shape files. These arcs also include metadata not always readily available, such as paths inside parks, gardens, parking lots and entertainment zones that can be interesting for a number of services. In addition, we complement the paths with train station information from the same sources. The goal is to influence the path processing and create paths that mimic users walking towards public transportation areas. In this work, an arc is defined as an array of geographical points (each of the points having latitude and longitude information), with at least two points. On the other hand, a train station is defined as a single point with latitude and longitude information. We start by processing the shape files, extracting the arcs and meta-data, and storing each arc in MongoDB [1], a document-based database with efficient geospatial indexing and search capabilities. This allows us to index longitude and latitude coordinates as well as search for coordinates within a certain radius. Each of the arcs is stored as a document with a head and tail point, corresponding to the first 1 2

http://downloads.cloudmade.com/asia/eastern asia/japan http://nlftp.mlit.go.jp/ksj/gml/gml datalist.html

and last point of the segment. All the remaining points are stored as a regular array inside each document. The reasoning for separating the first and last elements of the paths is to index those points in the database and increase search efficiency. The simulation will only need to search for the next arc when it has finished walking through all the points of the current arc, therefore those points do not need to be indexed. Lastly, the length of the arcs is computed and stored but not indexed. The distance information is not directly available in the open-data and can be further used in later stages of the path creation and simulator, i.e. used as weight if the choice of longer or shorter paths is needed. Some examples of the documents can be seen in Listing 1 and Listing 2 . Listing 1: Example arc data-structure in JSON 1 2 3 4 5 6 7 8 9 10 11 12

{ " idx_loc " : { " lat " : 1 3 5 . 1 2 3 4 3 5 4 , " lon " : 3 8 . 2 3 4 5 5 4 3 }, " type " : " head " , " body " : [ [139.698028564453, 35.6629943847656], ... , [139.6994996, 35.6657032] ], " distance " : 2 5 0 } The train stations information, being a single coordinate in space for each station, have all their points indexed. Metadata about the train station, line and train company is stored but not indexed. Listing 2: Example station data-structure in JSON

1 2 3 4 5 6 7 8

{ " idx_loc " : { " lat " : 1 3 5 . 1 2 3 4 3 5 4 , " lon " : 3 8 . 2 3 4 5 5 4 3 }, " station " : " Shinjuku " , " line " : " Yamanote " , " company " : " JR " }

5.2.2

be selected and allow backtracking of arcs when no further arcs are available on the current path.



1 −x2 /2σ 2

Pc (x) = √ e

σ 2π

(2)

where x is the position in the sorted array of arcs (thus x >= 0) and σ 2 = 3. Finally as our model aims to essentially reproduce behavior from pedestrians, we assume users are independent and do not affect each other. Therefore, the velocity of each arc to be walked is chosen by a uniform distribution with a PDF Pv (x), as expressed by Equation 2. Thus, a simulated user will randomly change its speed between arcs from a km/h to b km/h, with no memory of the state on the previous arc. ( 1 for x ∈ [a, b] Pv (x) = b−a (3) 0 otherwise where a = 4 and b = 6. This walk model composes the core of the simulation that will be presented in the next section.

5.2.3

Simulation implementation

The simulation makes use of walk paths taken from the walk model in Section 5.2.2. As detailed in Section 4, a device should make a request to the server when leaving a leave-trigger geofence or entering an arrive-trigger geofence. In order to test the proposed work, geofencing frameworks similar to the ones provided by mobile operating systems were developed, where devices locally check whether the current location is inside a given geofence or not. The simulator was developed under a Ruby-1.9 environment with help of RGeo-0.3.20 gem. To further vizualize the created paths and functioning of the system, a simple website using Google Maps was developed, as depicted in Figure 5.

Walk model

This work introduces a walk model that makes use of the arcs described in Section 5.2.1 to recreate an urban-walk path. We use transportation facilities information to influence the choice of arcs so the arcs that lead to a facility (e.g. train, bus station) have higher probability of being chosen. This resembles the behavior in metropolitan cities where users walk between AoIs and transportation facilities such as train stations. Given a random longitude and latitude, we begin generating walk paths by randomly choosing an arc from an array of nearby candidate arcs, ordered by ascending distance to a train station from the last point of each arc. When reaching the end of the chosen arc, we recalculate the array of candidate arcs from the last point of the finishing arc. The choice of the arc follows a normal distribution with a probability density function (PDF) Pc (x), as per Equation 2. To avoid loops and dead-ends we limit the number of times an arc can

Figure 5: Simple website to verify the test environment In Figure 5, the gray shades represent the geofences, the red circles represent the arrive-trigger perimeters, and the blue circle represent the leave-trigger perimeter. The walk path is drawn as the red line, with a red arrow marking the current location and direction of the user in the path. All the setup and code used is available in our open repository 3 . 3

https://git.skillupjapan.net/geo/geo-walk/tree/v2.0

Simulation setup and results

This section describes the tested parameters, the setup used for running the simulations and a brief presentation of the obtained results.

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0

Setup

To test our battery saving approach we performed several simulated tests following the battery draining model presented in section 5.1. For this setup, variable-size polygons of different shapes with average areas of 0.25 Km2 were defined as AoIs, with a varying geofence density from 0.1 to 1.0, inside a total area of 27.5 km2 . An example of the geofences with density of 0.5 is depicted in Figure 6. The density is defined as the ratio of the geofences’ total surface over the defined testing area (i.e. the area occupied by geofences is proportional to the density value). Each walk path has a length of 25 Km and the results of 10 distinct paths were analyzed for each scenario density. Moreover, to show the benefits of the proposed approach against distance-based approaches, additional simulations, using shapes with average areas of 1 Km2 and 5 Km2 , were performed.

15 28 37 47 56 66 77 87 96 107

Leavetrigger radius 98.8m 71.8m 59.6m 49.7m 45.5m 43.1m 40.7m 39.2m 37.7m 36m

Average visited AoIs 14.7 22.5 27.8 31.6 43.4 45.6 47 49.7 51.2 48

Combined graphs

Table 1: Simulation measurements of the proposed approach Number of requests per scenario 90

Battery consumption (%)

5.3.1

Average number of requests 232.2 335.4 414.3 520.1 549.1 556.6 562.4 568 568.9 584.1

Density AoIs

80

60

70

50

60 Error rate (%)

5.3

50 40 30 20

40 30 20 10

10

0

0 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.1

1

Scenario density Proposed approach (5km/h)

Proposed approach (11km/h)

Proposed approach (25km/h)

Time ba sed (25s @ 5 Km/h)

Time based (25s @ 11 Km/h)

Time ba sed (25s @ 25 Km/h)

Distance based (40m)

Figure 7: Number of requests per density scenario

60

50

50

40

40

30 20 10

0.1

30 20 10

0

0 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Scenario density

5 Km/h

Proposed approach (11km/h)

(25km/h) Time ba sed (25s @ 5 Km/h) Table 1 showsProposed someapproach values obtained from the simulation. Time based (25s @ 11 Km/h) Time ba sed (25s @ 25 Km/h) At each density Distance we measure the number of AoIs defined in based (40m) this scenario, the average number of requests done to the server by the simulator, the average radius of the leavetrigger circle (in meters) and the average number of visited AoIs visited by the generated walks. It is worth noticing how the leave-trigger radius decreases as the number of AoIs increases. This is due to the increasingly closer distance to neighbouring AoIs from any randomly located point in the testing area as the number of AoIs becomes larger. Figure 7 depicts the battery consumption of each scenario, at different speeds, against distance and time based requests for a fixed path of 25 Km/h. The battery levels were calcu-

20

0 60

11 Km/h

25 Km/h

Figure 8: Time-based error rate, Page 1 with requests every 270 Time-based error rate (Requests every 810 s) seconds 60

Figures 8 and 9 compare the error rate for the time-based 50 approach for requests made at speeds of 5, 11 and 25 Km/h 40 for 270 and 810 seconds, respectively, while Figure 10 com30 pares the error rate for the distance-based approach, with 20 requests every 40, 360 and 1080 meters. Figures 11 and 12 further contrast the error-rate behav10 ior 0against the battery consumption between the proposed 0.3 0.4 0.9 1 method0.1with0.2different AoI 0.5 areas,0.6and0.7the 0.8 distance-based Scenario density method with different distances, respectively.

Error rate (%)

ResultsProposed approach (5km/h)

30

60

Scenario density

5.3.2

40

10

Error rate (%)

Battery consumption (%)

In order to test several walk scenarios, our tests include per8scenario three speed rangesNumber of 4 toof 6requests Km/h, to 12 Km/h and 20 90 to 30 Km/h to mimic walk, running and cycling speeds, 80 respectively, using the model described in Section 5.2.2. 70 The measurements of interest are the battery consumption 60 between the three approaches (proposed approach, distance50 based and time-based) and the error rates between them. 40 We 30define error rate as the number of AoIs that were missed by an approach versus the number of AoIs a given path tra20 versed. This allows us to better capture the benefit of the 10 tested 0 approaches, by contrasting errors and battery con0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 sumption.

lated from the real measurements shown in Section 5.1 and computed into battery consumption Combined graphs from actual requests. The average number of actual requests is also shown in Table 1. Time-based error rate (Requests every 270 s)

Error rate (%)

Figure 6: Drawn AoIs example for a density of 0.5

Error rate (%)

50

5 Km/h

11 Km/h

25 Km/h

0.1

Scenario density Scenario density

5 Km/h

ch (11km/h)

11 Km/h 40Km/h & 120m 25 360m

Scenario density Distance (meters)

40 &Battery 120m measurements 360m 1080m

1080m

Error rate

@ 5 Km/h) @ 25 Km/h)

Time-based error rate (Requests every 810 s) 60

Battery usage(%)

Error rate (%)

50 40 30 20 10 0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

80

70

70

60

60

50

50

40

40

30

30

20

20

10

10

0 0.25

0 0.1

80

1

11 Km/h

Error rate

Figure 11: Error-rate and battery consumption for the proposed method

over 50% in denser scenarios. Likewise, the distance-based approach also experiences high error rates. Figure 10 compares scenario densities between 0.1 and 1.0 for period distances of 40, 360 and 1080 Page 4 meters. For distances of 40 meters (and 120 meters, although not depicted in this graph) the error rate is near to zero (although not zero). However, as shown next, the amount of requests will be much higher, resulting in an excessive battery consumption. For requests performed every 360 and 1080 meters, error rates of 10% and 20% are seen, with errors of nearly 30% on higher densities. This stems from the time- and distance-based approaches having no knowledge of AoIs and not being able to dynamically adjust their parameters to the surrounding environment. A fixed and estimated value needs to be predefined for such approaches, making their usage very inefficient. Moreover, Figure 11 and Figure 12 compare battery measurements with the error rates for the proposed method and the distance-based approach. We use the average area of the AoIs as the comparison criteria as that measurement better correlates with the distance-based metric. In Figure 12, it can be seen that, as a device makes requests after short traveled distances, the battery usage increases and the error rate is very low, as already seen in Figure 10. In contrast, as the distance at which the requests are made increases, the battery usage is lower and the error rate increases. In contrast, as shown in Figure 11, the dynamic approach proposed in this work attains, for all the speeds (for simplicity, simply shown as the overall battery measurements), a zero error rate while allowing the device use less battery when the AoIs’ area gets smaller (i.e. dense scenarios). While a balance that provides a tolerable error rate and Combined graphs reasonable battery consumption can be achieved by using either the time- or distance-based approaches, it is very difDistance-based method

Discussion of Results

The graph in Figure 7 shows the overall measurements of the battery consumption for the proposed battery-saving method at three different average speeds (5, 11 and 25 Km/h) Page The 2 for a set of 10 fixed 25 Km paths. battery consumption increases with the varying density of the scenarios, showing little consumption variation between each speed. This shows how the proposed method adapts well to any given user speed or activity. Moreover, when compared with the time- and distance-based approaches, it achieves a lower power consumption even on very dense scenarios, for timed requests of 25 seconds at 5 Km/h and traveled distances of up to 40 meters, respectively. When using higher speed values for the time-based approach and longer distances for the distance-based approach, the battery consumption decreases, since the user will travel faster and therefore make less requests. However, and as we will analyze next, such values have the drawback of making these methods have a higher number of errors —i.e. skipped AoIs— while the proposed scheme maintains no errors. Figure 8 and Figure 9 depicts the timed-based approach error rates for simulations at 5, 11 and 25 Km/h speeds for 270 second and 810 second intervals, respectively, showing the inherent weakness of making a request after an elapsed amount of time. The error rates not only increase with a higher speed or lower request rate, but are also aggravated with the increasing density of AoIs. For requests performed every 270 seconds, shown in Figure 8, the error rates vary from 10% to 20% , reaching values over 30% in denser scenarios. Figure 9 shows requests made every 810 seconds, Combined graphs with error rates varying from 20% to 40%, with error rates

)

5

Battery measurements

25 Km/h

Figure 9: Time-based error rate, with requests every 810 seconds

5.4

0 1 Average area of geofences (Km²)

Scenario density

5 Km/h

Error rate (%)

Proposed method

Distance-based error rate (fences of 0.24 m^2) Distance-based error rate (fences of 0.24 m^2) 60

20 10

0.1

0 0.2

0.3 0.1 0.2

0.4 0.3

0.5 0.4

0.6 0.5

0.7 0.6

0.8 0.7

0.9 0.8

1 0.9

70

60

60

50

50

40

40

30

30

20

20

10

10

0 1

40

Scenario density Scenario density

360m 1080m 40 & 120m 360m

120

0 1080

360 Distance (meters)

1080m

Battery measurements

Figure 10: Distance-based error rate, with requests every 40, 360 and 1080 meters

Error rate

Figure 12: Error-rate and battery consumption for the Proposed method distance-based method Proposed method 80

80

70

70

80 80 70 70

60

60

60 60

50

50 50

40

40 40 30 30

50 40 30 20 10

Battery usage(%)

40 & 120m

Battery usage(%)

1

20 10

0 0.9

30

80

70

30 20 10

20 20 10 10

Error rate (%)

30

40

80

Error rate (%)

40

Battery usage(%)

50 Error rate (%)

Error rate (%)

50

Error rate (%)

60

ficult to make it adaptive to dynamic conditions such as speed, as well as the size or density of surrounding AoIs. For instance, as shown in Figure 12, making distance-based requests every 120 meters provides a good balance for the specific scenario using AoIs with average size of 0.25 Km2 , such as the one simulated, but incremental changes of the AoIs’ average size from the latter value would rapidly worsen this result. Our proposed approach solves this problem while providing no AoI detection errors and reducing the battery consumption, even in scenarios with variable AoI sizes and dynamic mobile device speeds.

6.

CONCLUSIONS AND FUTURE WORK

In this paper we have shown that the readily-available geofencing capabilities of modern mobile OS such as Android and iOS can be utilized to reduce the energy consumption in the context of Location Based Services. Our approach exploits quadtree decomposition on the server side providing an efficient detection of nearby AoIs, and overcoming the limitation of a maximum number of geofences (currently about a hundred) that can be handled in Android and iOS devices. In contrast with previous work which focused only on circular-shape AoIs, and to the best of the authors’ knowledge, the proposed algorithm deals for the first time with AoIs of any arbitrary shape, extending the limitation of working only with circular geofences in Android and iOS systems. To the best of our knowledge, it also proposes for the first time a battery saving technique for LBSs that works on dynamic-speed environments. Our simulation results based on a realistic urban-mobility model show that in comparison with two widely-used periodic polling approaches, our method provides large battery-saving improvements as well as perfect detection of nearby AoIs, even in scenarios with a high density of AoIs and variable-speed mobile devices. Future steps in this research include further extensions to allow our platform to simulate network queries with delay, as well as consider GPS errors inherent in mobile devices. We are also planning on simulating walk paths of users that ride train lines and perform daily activities. Moreover, we are currently developing mobile client applications (in both iOS and Android) to perform field tests of our battery saving algorithm.

7.

REFERENCES

[1] 10gen, Inc. MongoDB, 2013. http://www.mongodb.org/. [2] J. D. Foley, A. van Dam, S. K. Feiner, and J. F. Hughes. Computer graphics: principles and practice (2nd ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1990. [3] E. Harjula, O. Kassinen, and M. Ylianttila. Energy consumption model for mobile devices in 3g and wlan networks. In Consumer Communications and Networking Conference (CCNC), 2012 IEEE, pages 532–537, 2012. [4] G. M. Hunter and K. Steiglitz. Operations on images using quad trees. IEEE Trans. Pattern Anal. Mach. Intell., 1(2):145–153, Feb. 1979. [5] R. Kanth and V. Kothuri. Quadtree and r-tree indexes in oracle spatial: a comparison using gis data. In Proceedings of ACM SIGMOD Conference, pages 546–557, 2002.

[6] D. H. Kim, Y. Kim, D. Estrin, and M. B. Srivastava. Sensloc: sensing everyday places and paths using less energy. In Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, SenSys ’10, pages 43–56, New York, NY, USA, 2010. ACM. [7] M. B. Kjaergaard, J. Langdal, T. Godsk, and T. Toftkjaer. Entracked: energy-efficient robust position tracking for mobile devices. In Proceedings of the 7th international conference on Mobile systems, applications, and services, MobiSys ’09, pages 221–234, New York, NY, USA, 2009. ACM. [8] M. D. M. F. Bulut. Energy efficient proximity alert on android. In Proceedings of the IEEE Workshop on Pervasive Collaboration and Social Networking (PerCol), PerCol 2013, 2013. [9] T. Markas and J. Reif. Quad tree structures for image compression applications. Inf. Process. Manage., 28(6):707–721, Nov. 1992. [10] J. Paek, J. Kim, and R. Govindan. Energy-efficient rate-adaptive gps-based positioning for smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, MobiSys ’10, pages 299–314, New York, NY, USA, 2010. ACM. [11] J. Paek, K.-H. Kim, J. P. Singh, and R. Govindan. Energy-efficient positioning for smartphones using cell-id sequence matching. In Proceedings of the 9th international conference on Mobile systems, applications, and services, MobiSys ’11, pages 293–306, New York, NY, USA, 2011. ACM. [12] N. Roussopoulos, S. Kelley, and F. Vincent. Nearest neighbor queries. In Proceedings of the 1995 ACM SIGMOD international conference on Management of data, SIGMOD ’95, pages 71–79, New York, NY, USA, 1995. ACM. [13] H. Samet and R. E. Webber. Storing a collection of polygons using quadtrees. ACM Trans. Graph., 4(3):182–222, July 1985.