Kien A. Hua University of Central Florida. Overview Background - Location-based services & challenges Range Query in Open Space Dynamic Range Query.

LOCATION-BASED SERVICES

Mmoving Object Ddatabases

Kien A. Hua

University of Central Florida

Overview

Background - Location-based services &

challenges

Range Query in Open Space

Dynamic Range Query in Road Networks

Sensor Approach to Location-based

Services

Location-based Services (LBS)

Rapid development and commercialization ofwireless network technologylocalization technologiessmart mobile devicessensor networks

Location-based Services

Allow users to query their environment and

use the spatial data for various purposes

LBS Example

• The phone uploads its GPS coordinates to the LBS server every few minutes.

• You can view up to 100 of the last reported spots the person has been on a Google map.

Integrate a mobile device’s position with other information so as to provide added value to the users.

Range Monitoring Queries in Location-based Services

Moving Object DatabaseMoving object database is the core of a location-based service

AB

C

D

E

H

I

G

F

J

K

L

k-NN QueryRange Query

Location-Based Queries Two kinds of location-based queries:

Snapshot queries: “Tell me the 3 nearest cars around me now ”

Continuous queries: “Monitor 3 nearest restaurants around me for the next 10 minutes ”

We focus on one continuous query type called Range Monitoring Query (RMQ).

Range-Monitoring Query

What is range-monitoring query ?

Retrieve mobile objects in a spatial region, and

continuously monitor the population in the area

aQ2

Q1 bc

f

d

e

Range Monitoring Queries

a

Q2

Q1bc

f

d

e

Range Monitoring Queries

Key Challenges Communication bottleneck

Very large number of mobile objects repeatedly update their locations

Computation bottleneck Maintain a very large constantly changing location

databasesConstantly compute many queries

Location uncertaintyLocation of moving objects known when sampled,

may have moved by time server processes the queries

• How to minimize location updates ? – Each update involves mobile

communication costs and server processing costs

• How to minimize query processing cost ?– Query results keep changing

• Traditional and spatial databases are not suitable for these tasks

Performance Issues

Q1

Q5

Q2

Q4

Q3

Circular Safe Region

RectangularSafe Region

a

Safe Region

Weaknesses of Safe Regions

Computing a safe region takes from O(n) to O(n log3n)

A solution - Using Resident Domain

Adding a new query requires recomputation of safe regions for all objects

A solution - Using Spatial Index

MQM - Resident Domain

A mobile object A contacts the server when Aexits the current

resident domain, or

enters or exits a query in the resident domain

Q1

Q2

Q7

Q6Q3

Q5

Q4

Resident Domain

A

N = 3

Q8

Q9

Safe Region vs. Resident Domain

Q1

Q2

Q7

Q6Q3

Q5

Q4

Resident Domain

A

Q8

Q9

Safe Region

Safe Region is relatively smaller, and incurs substantially more communication messages

Q1

Q4

Q2

Q3

R1

R42

R21

R31

R22

R41

Determine the Resident Domain

Query Q2 overlaps query Q3

Q2 and Q3

are relevant to monitoring region R22

Space is dynamically partitioned into disjoint subdomains

A monitoring

region

Q1

Q4

Q2

Q3

R1

R42

R21

R31

R22

R41

a

Determine the Resident Domain

Too small for a

Q1

Q4

Q2

Q3

R1

R42

R21

R31

R22

R41

a

Determine the Resident Domain

Use a larger Resident domain

for a

Domain Decomposition Suddomains and monitoring

regions are maintained using BP-tree (Binary Partitioning Tree)

For each new query, Search BP-tree to find the overlapping

subdomains, each corresponding to a monitoring region.

Insert the monitoring regions into their subdomain

Split a subdomain if its number of monitoring regions exceeds the threshold

R11R12

Query

Overlapping subdomains

Two monitoring regions

D

D domain node

data node

BP-tree Example

Q1Q1

D

d1

d1 d2d2

BP-tree Example

Q7Q1 R72

R71

d1

d1 d2d21

d22

d21 d22

D

BP-tree Example

Q9R91

R911 R912

Advantages over Safe Regions

Resident domains can be determined efficiently

A new query generally affects only a small number of existing resident domains

Resident domain are generally much larger resulting in less location updates

Offloads query processing tasks to mobile unitsDistributed processing Trading computation for communications to

conserve energy

0

5

10

15

20

25

30

10 20 30 40 50 60 70 80 90 100Num

ber

of

mes

sage

s se

nt

by m

obile

obj

ects

(m

illio

ns)

Number of monitoring queries (thousands)

MQM

Safe Region

Mobile Communication Cost

0.1

1

10

100

1000

10 20 30 40 50 60 70 80 90 100Num

ber

of in

dex

node

s ac

cess

ed (

mill

ions

)

Number of monitoring queries (thousands)

MQMSafe Region

Server Processing Cost

Summary Safe Region

Object A does not need to update its location as long as it moves within the safe region

Resident Domain

When Object A enters or exits a query’s area, A updates its location (and the query result)

Q1

Q2

Q7

Q6Q3

Q5

Q4

Resident Domain

A

Q8

Q9

Safe Region

Resident Domain - Summary

Resident Domain approach is highly scalable in terms of

Mobile communication costs, and

Server processing costs

for real-time range monitoring queries

Many Variants

Some examples: Jun Zhang, Manli Zhu, Dimitris Papadias, Yufei Tao, and

Dik Lee, “Location-based Spatial Queries,” in SIGMOD’03

Bugra Gelik and Ling Liu, “MobiEyes: Distributed Processing of Continuously Moving Queries on Moving Objects in Mobile Systems,” in EDBT’04

Fuyu Liu, Kien A. Hua, and Tai Do, “A P2P Technique for Continuous kNN Query in Road Networks,” in DEXA’07

Kihwan Kim, Ying Cai, and Wallapak Tavanapong, “Safe Time: Distributed Real-time Monitoring of cKNN in Mobile Peer-to-Peer Networks,” in MDM’08

Moving Queries over Stationary Objects Safe Region and Resident Domain are proposed

for stationary queries over moving objects

Moving queries over stationary objects

Example: Tell me gas stations within 3 miles of my current location

Technique:

─ The server sends a Self Computing Region (SCR) to each querying object

─ This SCR includes a set of stationary objects (e.g., gas stations) in the proximity

─ The querying object computes and updates its own query result

─ The querying object contacts the server when it moves out of its current SCR

DYNAMIC RANGE QUERY IN SPATIAL NETWORK ENVIRONMENTS

Moving Range Query

Defined by a range (e.g., within 5 miles)

Moves in accordance with a specific moving object (e.g., car)

Results include objects (e.g., gas stations, other cars) currently inside the specified range.

Example - Moving Range Query

Airport

Show me Italian restaurants

within 5 miles

UCF

Query Properties Query Mobility: moving vs. stationary

Query Shape: static vs. dynamic

Objects: moving vs. stationary

Environment: open space vs. networkOpen space: dealing with Euclidean

distanceNetwork: dealing with network distance

Dynamic Range Query (DRQ)

Moving Range Query

Dynamic Range Query

Query Mobility Moving Moving

Query Shape Static Dynamic*

Database Objects Moving Moving

Environment Network Network

Complexity Less challenging More challenging

* Shape of query footprint changes dynamically

Network Distance

d

d

Not included in the query

result

Included in the query result

Moving Range Query

Dynamic Range Query

Example – Dynamic Range Query

Give me all the AAA vehicles on service within five miles from me, while I am driving from Orlando to Miami.

How to answer such queries efficiently ?

DRQ - Dynamic Footprint

Query Object

DRQ - Dynamic Footprint

DRQ - Dynamic Footprint

DRQ - Dynamic Footprint

DRQ - Dynamic Footprint

Challenges

Server workload

Communication bandwidth

Limited battery power on client side

Dynamic query footprints One additional challenge !

System Assumptions

Every moving object is equipped with a positioning device.

Every moving object has some computing capability.

Modeling Graph Network

Undirected graph G = (N, E)N: a set of nodesE: a set of edges

Edgee = <ni, nj>If i < j

○ ni: start node○ nj: end node n3 - start

node

n4 - end node

Edge Distance

Edge distance is the shortest netwrok distance between two edges:

d(ei , ej) = min( (dSS(ei , ej), dSE(ei , ej), dES(ei , ej), dEE(ei , ej) )

SS SE ES EE

Network Distance between two edges

– Four types of edge distance between two distinct edges: SS, SE, ES, EE

Moving Objects Two types of moving objects for a given query

Query object: the moving object defined as the spatial center of the dynamic range query

Data object: other objects A moving object is a moving point in the road network

< o, pos, direction, speed, reportTime, IsQuery > pos = relative position from the S-node (start node) direction = +1 if moving from S-node to E-node;

-1, otherwise. Speed = object speed. Query objects must report new

speed IsQuery = 1 if the object is a query object

Compute New position of a moving object:newPos = (currentTime – reportTime) speed direction +

pos

Object DistanceFour possible network distances between two objects

SS SE ES EE

na

nb

oi

nc

nd

oj

nb

oi

nc

nd

oj

nb

oi

nc

nd

oj

na na

nb

oi

nc

nd

oj

na

The object distance is the minimum of the four, i.e., the shortest network distance.

Dynamic Range Query (DRQ) Query has two

parameters q = <Oq ,

range>

Oq : query object

range : the network space within the length distance from Oq makes

up the query range

Query result all moving objects within the query range (e.g., Od )

Query object Qq &query range = 5

Query result = {oi | oi O, d(oi , oq ) ≤ length}

Monitoring Region

Position of query object Q

determines the set of edges (road segments) that overlap with the current query range

As Q moves over an edge E, the union of the sets of overlapping edges corresponding to the different positions of Q defines the monitoring region of the DRQ when Q moves on E.

Monitoring Region Example

Consider a query object Q moving on edge n1 n6 with a query range of 5

n1n6

n2

n3

n10

n9 n7

n8

n5

n4

4

32 2

4

6

6

7

6

5

Q

The server first computes the monitoring region (purple segments), e.g.,D(n1n6 , n2n10 ) = min (3, 4, 7, 8) < 5 n2n10 is part of the monitoring region

<n1n6, SS, 0>, <n1n6, EE, 0>

<n1n2, SS, 0>, <n1n8, SS, 0>, <n1n9, SS, 0>

<n2n3, SS, 3>, <n2n10, SS, 3>

<n3n6, EE, 0>, <n5n6, EE, 0>, <n6n7, SE, 0>

<n2n3, EE, 2>, <n3n4, SE, 2>

<n1n2, EE, 4>, <n2n10, SE, 4>The SE-

distance from n1n6 is 2

For each edge in the monitoring region, the server then multicasts its edge distance from <n1,n6> to all objects in the region

n1

n6

n2

n3

n10

n9 n7

n8

n5

n4

4

3

2

2

4

6

6

7

6

5

Q

D

Processing on Mobile Host (1) Query object Q /w range = 5, at location 3.6 on edge

n1n6.

Data object D at location 0.5 on edge n2n10.

Object D picks up only part of the message:

{ <n2n10, SS, 3> , <n2n10, SE, 4> , object Q ’s information }

<n1n6, SS, 0> , <n1n6, EE, 0>

<n1n2, SS, 0>, <n1n8, SS, 0>, <n1n9, SS, 0>

<n2n3, SS, 3>, <n2n10, SS, 3>

<n3n6, EE, 0>, <n5n6, EE, 0>, <n6n7, SE, 0>

<n2n3, EE, 2>, <n3n4, SE, 2>

<n1n2, EE, 4>, <n2n10, SE, 4>

Multicast Message:

Edge distances from <n1,n6>

E

S

S

E

n1

n6

n2

n3

n10

n9 n7

n8

n5

n4

4

3

2

2

4

6

6

7

6

5

Q

D

Processing on Mobile Host (2) Query object Q /w Range = 5, at location 3.6 on edge

n1n6

Data object D at location 0.5 on edge n2n10

<n2n10, SS, 3> <n2n10, SE, 4>

0.5 + 3 + 3.6

= 7.1 > 50.5 + 4 + (4 – 3.6)

= 4.9 < 5

• d(D,Q) = 4.9 < 5 Object D should be included in the query’s result.

• Object D continues to monitor its distance from Q (by estimating Q’s current positions) and update the query result on the server accordingly

Object D uses the edge distances received from the multicast to compute its distance to QS

S

E

E

Some Storage Techniques for Networks

J. Zhao and A. Zaki, “Spatial Data Traversal in Road Map Databases: A Graph Indexing Approach,” CIKM ’94

D. Papadias, J. Zhang, N. Mamoulis and Y. Tao, “Query Processing in Spatial Network Databases,” VLDB ’03

S. Shekhar and D. Liu, “CCAM: A Connectivity Clustered Access Method for Networks and Network Computations,” IEEE Trans. on Knowledge and Data Engineering, 9(1), 1997

Summary The server

computes the monitoring region for each DRQ, and

multicasts the information to moving objects inside the monitoring region.

Moving objectuses the information received from the

server to monitor if it is inside the query’s range.

updates the server only when the new location changes the query result

Simulation Setup Area of interest

a square shaped region of 10,000 square miles

2000 nodes4000 edges

100,000 moving objectsSpeeds vary between 0.5 and 1 mile per time

unitInitial speeds follow a Zipf distribution with a

skew factor of 0.7Every time step, 10% of the objects change

their speed at a small increment 10 to 1,000 queries

Performance Comparisons (1)

Communication costCompared to Query-Blind Optimal (QBO) technique:

○ Moving objects send messages to server whenever they change speed or move to a new road segment

○ Server estimates object locations and update query results. Server can become a bottleneck

This scheme incurs low communication cost and is used as a reference to study communication costs.

Performance Comparisons (2) Server computation cost

Compared to Query Indexing techniqueWe adapted the Query Indexing technique for

spatial network environments.

Server maintains a list of relevant k-NN queries for each road segment

When server receives location update from an object, the server

○ determines the segment the object is on,

○ retrieve the relevant k-NN queries,

○ updates the affected queries.

Server Communication CostEffect of # of queries on server communication cost

0

20000

40000

60000

80000

100000

120000

10 20 50 100 200 500 1000

# of Queries

# o

f M

essa

ges

/Tim

e u

nit

DRQ Query-blind Optimal Naive

Naïve: Every object repeatedly reports its new location

Every object constantly updates its location regardless of number of queries.

Objects updates their location when they enter a new road segment or change speed regardless of number of queries.

As number of queries increases, objects have more queries to update their results

Object Communication CostEffect of # of queries on object-side communication cost

0

20000

40000

60000

80000

100000

120000

10 20 50 100 200 500 1000

# of Queries

# o

f M

essa

ges

/Tim

e u

nit

DRQ Query-blind Optimal Naive

Query Blind Optimal - Server Computation Cost is very high

Server Computation Cost(#segments loaded per time unit)

1

10

100

1000

10000

100000

10 20 50 100 200 500 1000# of Queries

# S

egm

ents

/Tim

e u

nit

DRQ Query Index

Offloading query processing to mobile nodes greatly reduces server computation cost

Remarks Use “road segment” as the unit for

monitoring regions Moving objects utilize their own

computing power to help reduce server load and save wireless bandwidth

Distributed servers can be used for a very-large deployment, in which case the proposed technique keeps the number of servers low

A limitation - query result is an approximation due to location estimationA solution: Query objects must report their

new speed

A Semi-P2P Approach Query Processing

Tracking the moving objects and the query regions

Update query results when objects move in or out of the query regions

The DRQ solution is a semi-P2P approach Every moving object participates in query

processing as a peer

Server only provides the database service

A SENSOR-BASED APPROACH TO

Location-based Services

Limitations To mitigate communication bottleneck with

the database serverSafe RegionResident Domain

Limitations

Communication Cost: still increases rapidly with the increases in number of participating objects

Deployment Cost: is proportional to the number of participating objects

Objects must be equipped with a GPS, computing device, and communication apparatus

Challenge Is there a solution such that the deployment

cost and the demand on server bandwidth are fixed regardless of the number of participants ?

Such an approach would be less expensive, andscalable to support a very large user

community

Using SensorsSensor-based Location-based Services (SLBS)

As opposed to sending location updates from the objects to the server, mobile sensors (e.g., RFID readers) report the identities of mobile objects they detect

SLBS - Advantages

Number of sensors required is proportional to the area of the application terrain, not the number of participants

Demand on server bandwidth is proportional to the number of sensors, not the number of participants

Participants are not required to carry GPS and computing equipment → SLBS is applicable to a variety of applications

SLBS - Challenges

Standard LBS approach processes queries based on “precise” locations of moving objects

SLBS must process queries based on the presence of moving objects

Due to location uncertainty, server must fuse information from multiple sensors to deduct the query results

Standard LBS deals with a Different Kind of Location Uncertainty Location uncertainty due to communication delay Some solutions

Apply dead-reckoning update policy○ Both server and mobile node estimate the new node

location

○ If an estimated location deviates from the actual location by a certain threshold, the mobile node updates its location with the server

Update when condition changes○ Assume that objects move at constant speed on a known

road

○ Objects notify server every time there is a change in direction or speed of movement

SLBS Example - RFID RFID tags and readers

Passive Tags: Use the radio frequency from the reader to transmit their data signal (i.e.. ID)

Active Tags: Have on-board battery for power to transmit their data signal.

RFID Readers can detect the identification of mobile objects in the proximity (as opposed to sending location updates from objects to server)

The exact locations of the target objects are not known

CAWA: Continuous Approximate Where-About Queries

A CAWA query is a continuous query that tracks locations of a moving object to determine its whereabouts in the past t time units

The whereabouts of the object are represented by an MBR that encompasses the locations of the query object in the past t time units t = 1

t = 2

t = 3

t = 4

t = 5

Whereabouts in the past 4 time units

MotivationMany applications do not demand the precise locations of the objects of interest Parents want to know if their child is still waiting

at school

A student wants to know if a particular book has been returned to the library

A passenger wants to know if the next bus is arriving soon

The army wants to know that the convoy is currently contained within a friendly area

Uncertainty Region If a target object is

detected by one sensor, its uncertainty region is the entire sensing area

If a target object is detected by multiple sensors, its whereabouts can be narrowed down to a small region

Whereabouts

Whereabouts

Approximate Sensing Range

Approximating the sensing area with a minimum bounding square.

Uncertainty Region

Moving object

Sensing range

Object detected by a single sensor

Uncertainty Region

Moving object

Sensing range

Uncertainty region (i.e., whereabouts) equals the

sensing range

Object detected by a single sensor

Uncertainty Region

Less uncertainty

Object detected by two sensors

Uncertainty Region

Uncertainty reduces

rapidly with increases in number of sensors

Object detected by multiple sensors

CAWA: Continuous Approximate Whereabouts Query

t = 1

t = 2

t = 3

t = 4

t = 5

Precise Answer

CAWA Query Processing

t = 1

t = 2 CAWA resultat time 2

Whereaboutsat time 1

CAWA Query Processing

t = 1

t = 2

t = 3

CAWA result attime 3

CAWA Query Processing

t = 1

t = 2

t = 3

t = 4

CAWA result attime 4

CAWA Query Processing

t = 1

t = 2

t = 3

t = 4

t = 5

CAWA answerQuery Window = 4

CAWA Query Processing

t = 1

t = 2

t = 3

t = 4

t = 5

CAWA answerQuery Window = 4

t = 5

Next CAWA answer, i.e., whereabouts in the last

5 time units

False Positive

t = 1

t = 2

t = 3

t = 4

t = 5

CAWA answer

Precise answer

False positive

CAWA AlgorithmSensorLocTable Contains mobile sensor locations

QueryTable Contains current query objects

DedectedObjTableContains query objects detected by sensor in the current iteration

WhereaboutsTableThe whereabouts of all query objects for each iteration of the last Tmax time units (there could be multiple queries on the same query object)

Periodically, the server performs the following procedure1. Receives updates from sensors, updates SensorLocTable, and

create new DetectedObjTable

2. Update the WhereabotsTable with new whereabouts computed from DetectedObjTable

3. Scan WhereaboutsTable to compute the query result for each query object Qi by computing the MBR for the whereabouts in the past Wi time units.

4. Reports query results to users as the results become available

Distributed Processing - Initial Assignment

A query can be submitted to any one of the servers

If the initial server does not find the query object in its subdomain, it broadcasts the query to all other servers

The server that detects the new query object takes ownership of this new query

Distributed Processing - HandoverWhen a query object is within a threshold of a neighboring subdomain belonging to server Si

The current server informs Si about the query

Si activates a timer and expects the query object to cross over by the end of the set time

If Si still does not see the query object when the timer expires, Si can discard this handover request; otherwise Si is elevated to be the new responsible query server for this particular query

Performance StudyMetric Description

TP, true positiveThe overlapping area between the approximate (where-about) area and the exact area (ground truth)

FN, false negativeThe area of the exact area (ground truth), that is not a part of the TP area

FP, false positiveThe area of the approximate (where-about) area that is not a part of the TP area

FP

TP

FN

QueryResult

GroundTruth

Parameters - Default Values

Terrain: 200 200 m2

Sensing Coverage: 500% Sensing Range: 2 2 m2

Number of mobile nodes: 1,000 Number of queries: 100 Mobility Model: Random Waypoint model Total simulation time is 1,000 seconds Query window is 50 seconds

Effect of Sensor Coverage

100% 150% 200% 250% 300% 350% 400%70%

75%

80%

85%

90%

95%

100%Effect of Sensor Coverage

Precision Recall

Effect of Sensor Range

1 2 3 4 5 6 7 8 9 1090%

91%

92%

93%

94%

95%

96%

97%

98%

99%

100%

Effect of Sensor Range

Precision Recall

Effect of Node Mobility

5 9 13 17 2190%

91%

92%

93%

94%

95%

96%

97%

98%

99%

100%

Effect of Node Mobility

Precision Recall

Effect of relatively slow mobility

The object moves within some initial where-about area

A large CAWA answer compared to the correct answer

To address this effect, we need more mobile sensors.

Sensor S1

Sensor S2

CAWA answer

Correct answer

Summary & Conclusions CAWA is a less expensive framework for location-

based servicesDeployment cost is proportional to the area of the

application terrain, not the number of participating mobile objects

Precision and Recall are excellent with adequate sensing coverage (about 300% in our simulation study)

Computation complexity is O(N), with respect to number of sensors, not tracked objectsScalable – computation dependent on number of

sensors, not number of moving objects

Similarly, communication cost is proportional to the number of sensors, not mobile objects.

k-NN Query Object is assumed to be at

center of its uncertainty region

3-NN of query Ok are T1 , T3 , T4.

OkUk

vT4

T2

T1

T5

T3

U2

U3

U4

U5

U1

Query object QkUncertainty

region

k-NN Query Processing1. Determine the MBR that

encloses the sensing ranges of all sensors that detect the query objects

Q

S1

S2

S3

MBR

k-NN Query Processing1. Determine the MBR that

encloses the sensing ranges of all sensors that detect the query objects

2. Count number of objects, OMBR , detected inside the MBR

3. Compute area per object (i.e., inverse of density): Q

S1

S2

S3

MBR

k-NN Query Processing1. Determine the MBR that

encloses the sensing ranges of all sensors that detect the query objects

2. Count number of objects, OMBR , detected inside the MBR

3. Compute area per object (i.e., inverse of density):

4. Determine query area:

5. Determine dimensions of initial query area S×S:

6. Expand the query area, centered at query object, if there are less than k objects inside

7. Determine the k-NN from the set of objects inside the query area

Performance