Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 892 (2007)
(USC DC Other)
USC Computer Science Technical Reports, no. 892 (2007)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
Partition-BasedLazyUpdatesforContinuousQueriesoverMovingObjects
Yu-Ling Hsueh
†
Roger Zimmermann
‡
Haojun Wang
†
Wei-Shinn Ku
§
†
Dept. of Computer Science, University of Southern California, Los Angeles, CA 90089
‡
Computer Science Department, National University of Singapore, Singapore 117543
§
Dept. of Computer Science and Software Engineering, Auburn University, Auburn, AL 36849
{hsueh@usc.edu, rogerz@comp.nus.edu.sg, haojunwa@usc.edu, weishinn@eng.auburn.edu}
Abstract
Continuousspatialqueriespostedwithinanenvironmentofmov-
ing objects produce as their results a time-varying set of objects.
In the most ambitious case both queries and data objects are dy-
namic, making it very challenging to find an efficient query eval-
uation strategy. The significant overhead related to frequent lo-
cation updates from moving objects often results in poor perfor-
mance. The most advanced existing techniques use the concept of
simple geometric safe regions to delay or avoid location updates.
We introduce a Partition-basedLazy Update (PLU)algorithmthat
elevates this idea further by adopting Location Information Ta-
bles (LIT) which (a) allow each moving object to estimate possi-
blequerymovementsandissuealocationupdateonlywhenitmay
affect any query results and (b) enable smart server probing that
results in fewer messages. Among the significant advantages, our
techniqueperformswelleveninveryhighlydynamicenvironments
(with up to 100% mobility) where many other techniques deteri-
orate. PLU can be efficiently implemented and we demonstrate
its query performance improvement of up to 28% over the current
state-of-the-art.
1. Introduction
The impressive advancement of mobile communication tech-
nologies, such as IEEE 802.11 and cellular networks, together with
ever more capable handheld devices has sparked intense interest in
location-aware services. One of the most challenging core func-
tions is the efficient evaluation of continuous queries over moving
objects, given an environment with a large number of objects and
concurrent queries.
With the mobility introduced by portable and handheld devices,
the performance bottleneck for continuous spatial query processing
is often concentrated in the handling of the frequent location up-
dates at the server and the utilization of the communication chan-
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 thefirst page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
GIS’07, November 7-9, 2007, Seattle, Washington,USA.
Copyright 2007 ACM 978-1-59593-701-8/07/0009 ...$5.00.
nel between the moving client objects (also called mobiles)and
the server. Wireless bandwidth is generally still much more scarce
than wired bandwidth and – adding to the challenge – the move-
ment dynamics of such an environment require frequent mobile–
server message exchanges that contain location information for the
database engine to maintain an up-to-date view of the world.
Therefore, one of the key challenges is minimizing the number
of wireless location update messages. A number of previously pro-
posed techniques have provided significant insight into this issue.
In the simplest case, whenever an object moves it sends its new
location to the server. Obviously this can be very wasteful, for ex-
ample if the moving object is located in an area where it does not
affect any query results. Making informed decisions when to com-
municate update messages becomes a key design issue to improve
scalability. The message count can be reduced through the follow-
ing optimizations. The mobile client may be equipped with com-
putation capabilities to maintain asafe region [8] with the purpose
that movements within the safe region will not affect any query re-
sults (hence no location updates must be sent to the server). Safe
regions are bounded by the nearest query rectangles around a mo-
bile client and must be recomputed when certain events take place
such as a new query is inserted or a moving object moves beyond
its safe region boundary. In some cases (e.g., query insertion) a
moving object is initially unaware of the event and the server must
probe its current location. Because of the usually simple shape of
safe regions (e.g., rectangles or spheres) they can only help to avoid
a fraction of unnecessary location updates.
In this paper, we propose a novel partition-based lazy update
approach that significantly reduces unnecessary location updates
by maintaining a Location Information Table (LIT) on each mov-
ing object. A LIT represents the detailed query boundaries and
distances across the terrain locally around the object. We build a
mobile-side LIT from m × m tiles where each tile corresponds
to a LIT cell that stores the distance to the closest query bound-
ary. The representation is easy to maintain and can be built on
top of existing indexing methods for tracking moving objects, such
as grids or R-trees. The server maintains its own vector of LITs
where each vector element is of size n × n (with n ≥ m)and
represents the complete service space at the time instance of a spe-
cific event. Significantly, a LIT encapsulates surrounding query
information in much more detail, yet compactly, as compared with
geometric safe regions. This concept (plus other enhancements)
allows our Partition-based Lazy Update (PLU) technique to reduce
unnecessary update messages and perform significantly better than
Database
Server
Mobile Clients
Event Time
Server-side LITs
Mobile-side LIT
0
t
1
t
0
t
3
t
Figure 1. System framework
traditional techniques.
The remainder of this paper is organized as follows. Section 2
describes the related work. Section 3 presents and details our con-
tinuous query processing design illustrated in Figure 1. We exten-
sively verify the performance of our technique in Section 4 and
finally conclude with Section 5.
2. RelatedWork
A number of pioneering techniques have been designed for pro-
cessing of continuous queries over moving objects. Prabhakar et
al. [8] first proposed two elementary techniques called Query In-
dexing and Velocity Constrained Indexing (VCI) and also intro-
duced the important concept ofsaferegions. Cai et al. [1] proposed
the Monitoring Query Management (MQM) approach to leverage
the computational capabilities of moving objects for efficient pro-
cessing of continuous range queries. Subsequently, Hu et al. [3]
proposed a generic framework to handle continuous queries by
leveraging the concept of safe regions through which the location
updates from mobile clients can be further reduced. However, these
methods only address part of the mobility challenge since they are
based on the assumption that queries are static. Nowadays, an
extensive number of spatial applications require the capability to
process moving objects in conjunction with dynamic continuous
queries.
The two main challenges in supporting both a large number of
objects and continuous queries in a highly dynamic environment
are to (a) reduce the object tracking and query evaluation costs and
(b) minimize the communication costs of location updates from
objects and queries. To address these two issues, the design of an
efficient index structure that can manage the locations of moving
objects has been intensely studied. For example, predicting the
movement of objects (i.e., their trajectory) has been used with R-
tree-based structures (e.g., the TPR-tree and its variants [9, 10])
and B-tree-based structures (e.g., the B
x
tree [4]). However, these
index structures require knowledge of object trajectories, which is
not available in many environments. In order to handle arbitrary
object movements, periodic position updates from moving objects
are widely used. However, with such a paradigm tree-based indices
suffer from excessive node reconstructions when tracking object
locations. As an alternative, grid-based indices (e.g., LUGrid [12])
have attracted much attention because of their simplicity and scal-
ability in handling position updates.
Mobile Client
1
q
2
q
3
q
4
q
5
q
6
q
7
q
8
q
9
q
10
q
1
p
2
p
LIT view
Mobile-side LIT
Traditional safe regions
Figure 2. Illustration of conecpts
Utilizing a grid index, some methods have been proposed to
process dynamic continuous queries over moving objects. For in-
stance,MobiEyes [2] introduced a distributed infrastructure to pro-
cess dynamic range queries where the server is acting as a mediator
to coordinate query processing on both the server and moving ob-
ject sides. The main drawback of this method is that an object will
repeatedly send location updates to the server when it is enclosed
by a query, which consumes a large amount of bandwidth when the
query density is high. SINA [6] has been introduced as centralized
solution to process continuous range and k nearest neighbor (kNN)
queries over moving objects. Yu et al. [13] proposed an algorithm
that computes the query results by defining a search region based
on the maximum distance between the query point and the cur-
rent locations of previous kNNs. However, the algorithm results in
high re-computation costs when the query point is highly dynamic.
Similarly, Xiong et al. [11] suggested the SEA-CNN framework
which uses the concept of shared execution. SEA-CNN continu-
ously maintains the search radius of the query point to avoid re-
building the query result once the query point changes its location.
As an enhancement, Mouratidis et al. [7] presented a technique
called CPM that defines a conceptual partitioning of the space by
organizing grid cells into rectangles. Location updates are handled
only when objects fall into the vicinity of queries, hence improving
system throughput.
Our PLU approach is inspired by some of these prior tech-
niques. Its main contribution lies in the development of “smarter”
safe regions represented via location information tables that enable
enhanced (i.e., more independent) mobile-side decision making for
location updates. The technique does not deteriorate when faced
with high mobility rates as demonstrated by our simulation results.
3. TheSystemOverview
To describe what motivates our work, let us first illustrate how
the best current techniques operate with Figure 2 serving as an ex-
ample. The gray areas represent the safe regions of two moving
objects p1 and p2. A traditional safe region is either a rectangle or
a sphere which is determined by the set of surrounding queries [8].
When an object moves outside of its safe region, it incurs a location
update. From the example we can observe that, as p1 moves out of
its safe region (in the direction of the arrow), it issues an unnec-
essary update because of the limited safe region information. Fur-
thermore, the safe region of a moving object is determined based
on its current location. When a query moves to a new location
or a new query is inserted, the server triggers a location probe to
the affected moving objects and re-calculates new safe regions for
them. When receiving the location probes (downstream) from the
server, the moving objects need to send their locations (upstream)
back to the server. Once the server completes the safe region com-
putations, it sends the safe regions (downstream) to those moving
objects. Hence a total of three network messages are sent back
and forth between the server and each mobile client. As illustrated,
the safe region approach incurs significant network trafficinthis
scenario.
In contrast, we propose a partition-based technique by defining
a grid-like LIT (also shown in Figure 2) which provides a mov-
ing object with a detailed view of the surrounding query locations
across the terrain. As an additional advantage, a LIT is determined
without referring to the locations of moving objects. If a query
is inserted, the server can send the new LIT with the added query
information (downstream) to the affected moving objects directly,
and only a fraction of the mobile clients that receive the updated
LIT must issue location updates (upstream) back to the server (–
namely if they are part of the new query result). Therefore, the
number of network messages is reduced to at most two. The over-
all PLU process is discussed in detail in the subsequent sections.
To enable a focused discussion we make some explicit assump-
tions. A centralized server is assumed in the environment to pro-
cess continuous queries. The mobile units consist of a set of dy-
namic query objects Q and a set of moving objects P . Both queries
and moving objects are identified by a unique identifier to distin-
guish their types. Each mobile unit can move arbitrarily without
exceeding a given maximum speed λ. The communication be-
tween the server and moving objects is through wireless messages.
We use a main-memory grid G as the underlying structure to index
moving objects because of its simplicity and ease-of-maintainance
in a highly dynamic environment. Because of space constraints
we focus on range queries in this paper. For high performance an
event-driven approach is adopted to evaluate continuous queries.
To maintain the correctness of the query results, the server monitors
registered query objects and requires that each query object update
the server when changing its location. Thus, the server can evaluate
the query based on its new location. We assume that each mobile
unit has enough computational capabilities and memory to carry
out the required tasks. We describe the details of the data structures
used in this paper in Section 3.1. The LIT design and the procedure
for generating a LIT are described in Section 3.2. Mobile-side and
server-side processing are discussed in Sections 3.3 and 3.4, re-
spectively. Finally, we analyze a spatial data compression scheme
for LITs to reduce the number of messages sent from the server in
Section 3.5.
3.1 Data Structures
We use the following data structures in the system, also shown
in Figure 3.
• Object Grid (G): A w × w object grid G is used to in-
dex the moving objects. We adopt a grid structure that is
similar to the one proposed in [7]. During an execution
interval, each cell c
(i,j)
maintains a moving object list de-
noted by M
(i,j)
. Every moving object is represented by a
tuple ID,LocXY,LIT
id
where ID is the object identi-
fier, LocXY is the latest reported location information and
LIT
id
is an identifier of the server-side LIT where the mobile-
side LIT of the moving objects was retrieved.
• Query List (Q): Queries are organized via an in-memory se-
quential list Q. Each query entry is of the formID,LocXY,
ANS,where ANS is a set of the query results.
-1 -1 -1 -1
-1
-1 -1 -1 -1
-1
-1 -1
-1
00
0
0
0
0 0 0 0 0
1
1
1
2
1
0
1
1
00
0
0
-1
0
0
0
1
1
1
11 1 1 1
3
2
2
2
2 3
2
2
2
LIT Vector
P
Object Grid
serv
LIT
) (
3
t LIT
) (
2
t LIT
) (
1
t LIT
) (
0
t LIT
Figure 3. Data Structures
• LIT serv : A server-side location information table consists
of n× n cells of uniform side length δ.A LIT serv has an
identifier LIT serv.id and each LIT serv cell maintains a pair
of valuesLIT serv.value, TBound where LIT serv.value
stores an integer value to indicate the query boundaries and
TBound is the actual coordinates of the boundary that the
LIT serv cell corresponds to on the terrain. Locating a LIT serv
cell for a moving object p with coordinates (x,y) can be done
by calculating the index LIT servi, j where i =
x
δ
and
j =
y
δ
.
• LIT Vector (LIT): A LIT vector stores a list of LITs gen-
erated for every specific event time. LIT(i) returns a LIT
created at time instance t i. When there is no moving object
engaging a LIT, it is removed from the LIT Vector.
• LIT
mob
: A mobile-side LIT is a subset m × m table ex-
tracted from the latest server-side LIT with m ≤ n.When
a mobile object p obtains its mobile-side LIT which is ex-
tracted from LIT serv,wetermthat preferences to LIT serv .
Let (i, j) be the residing cell index of p on the server-side
LIT. The mobile-side LIT of p is extracted from the area of
[i−...i + , j−...j + ] on the server-side LIT where
is defined as a level of the mobile-side LIT. Therefore, the
size of a mobile-side LIT m is 2+1.
The five data structures presented above support the operation
of our PLU technique as follows. Initially, startup mobile-side LITs
are generated by the server and sent to each registered moving ob-
ject. With the possession of an LIT, each moving object can lo-
cally determine a location update and send it only when the new
location may affect a query result. When an object issues a lo-
cation update, it is receives the latest mobile LIT in response with
newly reported positions of query boundaries. The previous server-
side LITs are referenced later during the processing of query inser-
tions and movements. To achieve memory efficiency the system
removes the old server-side LITs when there are no more objects
referencing it. A flushing mechanism is also used to force objects
which have not reported their location for a certain period of time
to issue an update, hence allowing the old server-side LITs to be
removed from memory. An LIT
mob
assigned to a moving object
is in general a subset table of the server-side LIT due to memory
limitations of moving objects and to reduce communication costs.
Table 1 summarizes the symbols and functions we use throughout
the following sections.
3.2 LIT Details
Symbol Description
G A w×w object grid where objects are hashed based
on their locations to the grid cells.
Q A set of query objects
P A set of moving objects
LIT serv A n× n server-side LIT
LIT
mob
A m× m client-side LIT
LIT A server-side LIT vector
λ Maximum speed for any object
χ Unit maximum moving distance
Table 1. Symbols used in this paper
3 2 104
0
1
2
56
3
4
5
6
1
q
3
p
2
q
1
p 2
p
4
p
6
p
7
p
5
p
(a) Object Grid at t0
3 2 104
0
1
2
56
3
4
5
6 0
0
0
-1
-1
00
-1
-1
0
0
0
0 0 0
1 1 1 1
21
1 2
2 2
3 3
0
0 -1 -1 -1
-1 -1
0 011
0
0 1 2
1
2
2
1
-1 -1 -1
level 1
level 2
(b) LIT serve at t0
Figure 4. The object grid and a server-side LIT ex-
ample
Wefirst describe the server-side LIT details. A LIT serv is gen-
erated when one of the following two events happen: (1) an ex-
isting query changes its location or (2) a new query is registered
with the system. The general attributes described in this section for
the sever-side LIT are also applicable to the mobile-side LITs ex-
tracted from it. A mobile-side LIT simply inherits all the attributes
and query boundary information from the server-side LIT. How-
ever, each moving object maintains (i.e., updates) the mobile-side
LIT locally after receiving it from the server based on a specific
event.
A LIT.value for LIT serv(i, j) stores an integer number that
represents a safe distance. The safe distance for LIT serv(i, j) is
defined as the minimal linear distance in cells from the LIT serv(i, j)
cell to the nearest query boundary. We distinguish two cases when
assigning a value to LIT serv(i, j): LIT.value≥ 0,if LIT serv(i, j)
does not overlap a query boundary; and LIT.value = −1,if
LIT serv(i, j) is covered by a query boundary. Figure 4(a) shows
an object grid with a set of registered queries and moving objects
on the terrain at time t0. The corresponding server-side LIT cre-
ated at t0 is illustrated in Figure 4(b). In this example we assume
that the server-side LIT size is the same as the object grid. The
LIT values of the cells that overlap the boundaries of query q1 and
q2 are set to -1. We define two types of cell zones: a border zone
(LIT value = -1) and a zero zone (LIT value = 0). A border zone
consists of cells that overlap with the boundaries of some queries.
A zero zone is essentially a prediction zone which might be cov-
ered by nearby moving queries as time proceeds. Since a zero zone
has a safe distance equal to zero, it is more likely to be covered
by a moving query, say q1, soon. Both border and zero zones are
important indicators for a moving object to decide on a location up-
date. In order to predict the moving query locations, each moving
object updates its local LIT and marks the new prediction cells as
zero zones. The detailed update mechanism for mobile-side LITs
will be described later. Algorithm 1 presents the pseudo code of
generating a server-side LIT. Lines 2-4 assign -1 to the cells which
are covered by a query boundary first and lines 5-11 calculate the
LIT value for the rest of the cells. To compute a LIT value for
LIT serv(i, j), the algorithm checks its surrounding cells level by
level by calling GetCellsAtLevel(LIT serv(i, j),l),where l is a
level number. The procedure terminates the loop when a cell with
a LIT value equal to -1 appears. Figure 4(b) shows such levels of
LIT5,5 in different gray scales. Since -1s appear at level 2, the
loop is terminated and we obtain 1 as the LIT value for LIT5,5.
Algorithm1 CreateLIT(G, Q)
1: Let LIT be a n× n table and initialize the value of each cell to∞
2: for (every q ∈ Q)do
3: Set the value equal to -1 for each LIT cell that are covered by the
query boundary of q
4: endfor
5: for (every cell LIT serv(i, j), which has the LIT value= -1)do
6: Let LIT serv(i, j).value=0 and l=1
7: while (GetCellsAtLevel(LIT serv(i, j), l) returns C AND C = φ)
do
8: if (any cell in C has LIT value equal to -1)then break the loop
9: else Increment LIT serv(i, j).value and l by one
10: endwhile
11: endfor
3.3 Mobile-Side Processing
Each moving object independently performs the following two
major tasks to achieve the desired location update traffic reduction:
progressive revision of the mobile-side LIT and determination of
when to send location updates. Each time a moving object trans-
mits its location to the server, an up-to-date mobile-side LIT will
be sent to the moving object. However, since we consider dynamic
queries in this paper, the LITs are subject to change whenever the
queries change their locations during the course of the execution.
Instead of sending a new mobile-side LIT with the latest query lo-
cations to each moving object repeatedly, we propose a periodic
LIT update method to independently adjust the mobile-side LIT to
reflect all the possible query movements while ensuring the cor-
rectness of the query results. Wefirst discuss how a moving object
updates its local LIT and then describe the mechanisms for trigger-
ing a location update based on the mobile-side LIT.
3.3.1 Mobile-sideLITUpdates
Since the maximum speed λ for mobile units is limited, we can
estimate the possible query locations in the mobile-side LIT. Con-
tinuing the example shown in Figure 4, each moving object p is
given a mobile-side LIT by the server as shown in Figure 4(b).
Without loss of generality we assume that the size for an object
grid, server-side LIT and mobile-side LIT are the same in this ex-
ample. Figure 5(a) illustrates the current locations of mobile units
at time t1 and Figure 5(b) shows the mobile-side LIT updated by
p at t1. One can observe that in the worst case, by considering
that a query may move to its surrounding cells in any direction, the
area between two dashed rectangles shows all the possible cover-
age of the query boundary with such movements. Since a border
zone may overlap more than one query boundary anywhere within
the zone, the two solid rectangles represent the outermost query
boundaries of the zone. For simplicity, we draw two dashed rect-
angles inwardly (shrunk) and outwardly (expanded) by extending
3 2 104
0
1
2
56
3
4
5
6
1
q
3
p
2
q
1
p 2
p
4
p
6
p
1
q c 7
p
5
p
(a) Moving objects at t1
3 2 104
0
1
2
56
3
4
5
6
0
0
0
1 1 1 1
21
1 2
2 2
3 3
-1 -1
-1 -1
-1
1
1
12
2
2
00
1 1
0
0 0 0 0
0
0
0
0
0
0
0
F F -1 -1 -1
-1
-1
-1
-1
(b) Mobile-side LIT
mob
at t1
3 2 104
0
1
2
56
3
4
5
6
3
p
(c) One-level (3× 3) LIT
mob
Figure 5. Object grid and mobile LIT
the solid rectangle by the length of the maximum moving distance
χ (= λ×Δt) for every time instance. The cells that are newly cov-
ered by the area between the dashed rectangles become zero zones.
As afinal step, the LIT values of the remaining cells need to be up-
dated. The procedure for computing the new LIT values for each
cell can be found in the lines 2-11 of Algorithm 1.
3.3.2 LocationUpdateCheck
The event-driven procedure for deciding on a location update is
performed by the moving object only when it moves to a new loca-
tion. We continue with the example of Figure 5(a) that shows the
new locations of queries and moving objects at time t1. Refering to
the mobile-side LIT in Figure 5(b), p2 in LIT mov(3, 3) steps into
a zero zone in LIT mog(4, 2) which is a zero zone, so p2 might
overlap with a query at this moment. p4 was in a border zone and it
changed its location since the latest update to the server, so it may
exit or enter a query boundary. Therefore, both p2 and p4 have
to issue a location update at t1. We describe the location update
checking procedure in this section. Let LIT
mob
(i, j) be the cell
in which an object originally resided since the last update to the
server, and LIT
mob
(i
,j
)(= LIT
mob
(i, j)) be the cell where the
object is currently located some time after it updated the server. To
determine a location update request for p, we perform the follow-
ing steps:
Step 1: Check if p was originally located in the border zone
LIT
mob
(i, j) since its last update to the server. If this is the
case, p issues a location update and exits the checking steps.
Otherwise, continue to Step 2.
Step2: Check if p currently stepped into a border zone or zero
zone LIT
mob
(i
,j
). If this is the case, p issues a location
update and exits the checking steps. Otherwise, continue to
Step 3.
Step3: Check if p currently stepped into a cell LIT
mob
(i
,j
)
which is outside of the mobile-side LIT boundary; p issues a
location update and terminates the checking steps.
In Step 1, we monitor the objects that are in the border zones.
Since these moving objects are close to some query boundaries,
they are more likely to alter any query results. If a moving object
moves into a border or zero zone as described in Step 2, it may
enter a range query. Therefore, it has to report its current location
to the server. In Step 3, when the moving object moves out of its
local LIT boundary, it issues a location update. Figure 5(c) shows
a one-level 3×3 LIT for p3 and after some time instances at t3, p3
moves out of the LIT boundary to LIT
mob
(4, 3), and therefore it
must issue a location update at t3.
The above procedures is called push mode, since the location
updates are issued from the moving objects. We also propose a
pull mode that is executed by the server to request a location up-
date from the mobile clients. To take advantages of the pull mode
approach, we describe the following scenariofirst. In Figure 5(a),
p7 was located in a zero zone LIT
mob
(4, 4) at t0 and moves to
LIT
mob
(5, 3) at t1. At this time p7 does not issue a location
update since LIT
mob
(5, 3) is neither a border nor a zero zone.
However, the latest reported location of p7 is still in LIT
mob
(4, 4)
at the server and it might be evaluated as a query result because
LIT
mob
(4, 4) is a zero zone indicating a nearby moving query
boundary might cover it. Therefore, p7 needs to inform the server
about its current location for further validation. As a result, it in-
curs many unnecessary location updates from the moving objects
as time proceeds (many zero zones appear due to the mobile-side
LIT updates). We propose a server-side detection procedure Dec-
tObj to handle this case. Since the server has the latest locations of
the queries, it is able to determine whether LIT
mob
(4, 4) is actu-
ally covered by some query. If this is true, the server sends the latest
LIT to p and requests for its current location. In this example, since
the actual new position of q1 at t1 does not cover LIT
mob
(4, 4),
the server does not need to send the latest LIT to p.
3.4 Server-Side Processing
We implement an event-driven approach to handle the requests
from mobile units. There are two major server-side procedures:
DectObj, which was discussed in the previous section for hand-
ing query updates and QurIns for processing query insertions. We
focus on theQurIns procedure in this section.
Whenanew query q is inserted, instead of informing the en-
tire registered moving objects population (that lack this new query
boundary information) of the changes, the server performs theQurIns
0
6
6
0
-1
-1
1
2
2
2
1
2
3
4
3 2 1045
0
-1
-1
0
1
1
1
5 1 0
3
0 -1 -1 -1
0
0
0
0
0 -1 -1 0
0 1 2 3
0
0
1
2
q
R
x 0 0
1 1 1
21 2
0
-1 -1 -1
y
O
q c O c q c p
Figure 6. LIT serv generated at t0
procedure to determine a set of moving objects P
that may enter
the new query boundary. Then it sends the latest mobile-side LIT to
these objects only. In order to determine P
, the procedure needs to
utilize the old server-side LITs which are referenced by some of the
moving objects. First, for every old server-side LIT,QurIns checks
each moving object p in the set of LIT cells O, where the objects
have the mobile-side LIT overlapping with R (the set of LIT cells
covered by the new query boundary). Let c ∈ R be the nearest
LIT cell of p. In the worst case, the procedure computes the mini-
mum distance between p and c and the distance between c and the
nearest border zone R. If the latter is smaller, the server does not
have to inform p of the query insertion. This is because through the
mobile-side LIT updates on p, the area covered by R will become
zero zones before p moves into that area. Therefore, the query in-
sertion will not cause any missed location updates. When q moves
to a new location later, the system needs to perform theQurIns pro-
cedure again to inform the moving objects that have neither been
informed of the query insertion by QurIns previously nor been as-
signed a new LIT with q’s location. The pseudo code of theQurIns
procedure is shown in Algorithm 2. In line 7, the procedure checks
c’s LIT value because it represents the nearest distance (in cells) to
the border zone.
Algorithm2 QurIns(i,LIT)
1: P
= φ
2: for (every old server-side LIT K)do
3: Let R be the set of LIT cells covering by the range of query i.
4: Let O be the set of LIT cells where the objects’ mobile-side LIT
overlapping with R
5: for (each object p∈ O) AND p has not noticed yetdo
6: Let c∈ R be the closest cell to p
7: Let v be the LIT value of c by checking the server-side LIT K
8: Let x = v× δ
9: Let y = mindist(p, c)
10: if (x≥ y) then
11: Insert p into P
12: endif
13: endfor
14: endfor
Consider the following example. A new query q registers with
the system at t1. Assume that p references to LIT serv as shown in
Figure 6, and each moving object is assigned a 3× 3 (level =1)
mobile-side LIT. The new query q covers the gray area R.Since
a one-level mobile-side LIT is assigned to each moving object, the
area O is one-level larger than R.Sincex>y, p may reach the
closest cell c1,2 earlier than c1,2 becomes a zero zone through p’s
mobile-side LIT updates. Therefore, the server needs to inform p
of the new insertion. Now let us assume that q moves to q
later
at t2. The dark gray area O
represents the area where the objects
have not been checked by QurIns at t1,so the QurIns procedure
only checks the moving objects in this area at t2.
The pseudo code of Algorithm 3 represents the complete server-
side event-driven system function. In line 7, the QurIns proce-
dure determines a set of objects that may be affected by newly
inserted queries. Line 9 sends mobile-side LITs directly to ob-
jects O (downstream), because a mobile-side LIT is extracted from
a server-side LIT, which is obtained based on the query locations
only. The system can send the latest mobile-side LITs to O with-
out probing their locations first. The mobile-side LITs here are
extracted based their latest reported locations on the server. There-
fore, each object o ∈ O can determine a location update based on
the new mobile-side LIT. Any object o in O issues a location up-
date (upstream) only when it is part of the result of the new query.
Likewise, DectObj in lines 13-15 obtains a set of objects whose
last reported locations at the server are covered by existing queries.
Line 15 sends the latest mobile-side LIT to those objects and at
the same time requests for the current locations (downstream). The
moving objects then send back their current locations to the server
(upstream). By applying these techniques our goal of reducing the
overall network traffic is achieved.
Algorithm3 System Overview
1: while (there is a request from a mobile unit r)do
2: Let B be a buffer
3: if (the request is a moving object insertion)then
4: Insert r to B
5: elseif (the request is a query insertion)then
6: Insert r into the query index
7: Call QurIns(r,LIT) that returns a set of objects O
8: Perform CreateLIT(G,Q) to generate a new server-side LIT.
9: Send each o∈ O the latest mobile-side LIT
10: elseif (the request is a moving object or query deletion)then
11: Remove r from the system
12: elseif (the request is a query update)then
13: Call DectObj(r) that returns a set of objects Z
14: Perform CreateLIT(G,Q) to generate a new server-side LIT.
15: Send each z ∈ Z the latest mobile-side LIT and request for z’s
current location
16: Insert Z to B
17: if (r is an inserted query during the execution)then
18: Call QurIns(r,LIT) that returns a set of objects O
19: Send each o∈ O the latest LIT
20: endif
21: elseif (the request is a moving object update)then
22: Insert r to B
23: endif
24: endwhile
25: Update/insert b’s location and cell index,∀b∈ B
26: Call RangeQuery(Q) to retrieve query results
27: For each b∈ B, Sent the latest mobile-side LIT to b if it does not have
the latest LIT
3.5 Spatial Data Compression for Local LITs
Each moving object obtains a m× m mobile-side LIT. While a
large value for m provides more location information to a moving
object, the data streams for the mobile-side LIT need to be bro-
ken up into more packets that adversely affect performance. In this
paper, we use the Internet standard for the largest amount of data
packet payload size (MTU) equal to 1500 bytes. In some prior
techniques, such as the safe region approach, basically only a pair
of x- and y-coordinates must be sent to the each moving object.
Hence such information can easily be fitted into a single packet.
Our goal here is to use a data compression method to compress a
LIT small enough tofit into one packet to perform on par with ex-
isting techniques. We apply three lossless data compression meth-
ods: quantization, run-length encoding (RLE) and Huffman encod-
ing. Firstly, we de-correlate the LIT values by subtracting pairs of
adjacent LIT numbers. This is effective since the LIT values are
highly correlated or spatially redundant. As a result, the difference
values are repetitive and smaller than the original LIT values. Sec-
ondly, RLE is utilized to take advantage of the large amount of
spatial redundancy in a LIT and we use a Hilbert curve as the data
scanning path along which we count repeated numbers. An extra
marker bit is used to distinguish the count bit and number values.
Finally, we performed Huffman encoding which is based on the
frequency of occurrence of a data item and uses a lower number
of bits to encode the data that occur more frequently. Huffman en-
coding following RLE is a natural choice since the result of RLE
is a set of symbols representing run lengths that occur with varying
frequencies. Overall, our experimental result shows the combina-
tion of these methods can reduce the size of a LIT by up to 79%
from its original size. To pack a mobile-side LIT within a 1500
bytes packet, we suggest a maximum table size of 64× 64 for a
mobile-side LIT.
4. ExperimentalEvaluation
We evaluated the performance of the partition-based lazy up-
date algorithm (PLU) by comparing it with the safe region ap-
proach [3, 8] and the traditional periodical update approach (PER).
For a fair comparison, we extended the safe region approach to han-
dle dynamic queries. To process a query insertion, the safe-region
approach probes a set of objects whose safe regions overlap with
the boundary of the new query. In the case when a query changes
its location, it is treated as a query insertion. We implement the
extended safe region approach with safe rectangles (SR*-Rec) and
safe spheres (SR*-SP).
We use a main memory 100× 100 grid as the underlying index
structure for all the approaches. Our data sets are generated on a
terrain service space of [0, 1000] based on the random walk mobil-
ity model [5]. Each object moves with a constant velocity until an
expiration time. The velocity is then replaced by an new velocity
with a new expiration time. For the range query, the query bound-
ary is a square and the side length q
len
is in the range of [1,10].
The number of queries is up to 1k. The maximum moving distance
per time step for any moving object is in the range [0.48, 1.25],
which corresponds to a speed of 35 to 90 miles per hour. The mo-
bility f move (the percentage of objects that move within a time
step) for the objects is set in a range from 30% to 100%.Wese-
lect an optimal size n for the sever-side LIT from [100, 500] per
side and choose the level from [1,10] for a mobile-side LIT. The
main measurement in the following simulations is the number of
network messages sent between the server and moving objects. At
the server side, we count the number of messages (downstream)
from probing an object’s location and sending an LIT to an object;
at the mobile client side, we count the number of messages (up-
stream) from issuing a location update to the server. Experiments
are conducted with a Pentium 2.4 GHz CPU and 1 GByte of mem-
ory. The query results are evaluated in a even-driven approach.
Our experiments use several metrics to compare these algorithms.
Table 2 summarizes the default parameter settings in the following
simulations.
Parameter Default Range
P 100k -
Q 1000 300, 500, 1000
f move 50% 30%,50%, 70%, 100%
λ 1.25 0.48(35mph)-1.25(90mph)
q
len
5 1, 5, 10
m 250 100, 200, 250, 500
5 1, 5, 10
Table 2. Simulation parameters
4.1 LIT Size
First, we measured the overall number of network messages in-
cluding upstream and downstream directions of the PLU algorithm
by varying the server-side LIT size. The choice of the server-side
LIT size is a trade-off between the number of network messages
and the server performance. Figures 7(a) and (b) show the number
of overall network messages and CPU overheads v.s. the LIT sizes
ranging from 100× 100 to 500× 500, respectively. When the LIT
size is set to more than 500 per side, the performance of PLU is de-
graded in terms of the number of network messages and CPU time
because it incurs more LIT value calculations for all the LIT cells.
The LIT size 250× 250 constitutes a good tradeoff between the
number of network messages and CPU time. Therefore, 250×250
is chosen as the server-side LIT size for the rest of our experiments.
10
12
14
16
18
20
22
24
500 250 200 100
Network Messages (k)
Number of Cells (Per axis)
PLU
(a) Network messages
0
2
4
6
8
10
12
14
500 250 200 100
CPU Time (Sec)
Number of Cells (Per axis)
PLU
(b) CPU time (sec)
Figure 7. Performance v.s. server-side LIT size
Next we examine the size for a mobile-side LIT. Figures 8 mea-
sures the effect of varying the size of the mobile-side LIT from
level 1 (3× 3)tolevel 5(11× 11) in terms of network messages.
The size of a mobile-side LIT significantly affects the number of
network messages. When a mobile-side LIT is small, a moving
object issues more network messages because it has more chance
to move out of the LIT boundary; when a mobile-side LIT is large,
it also incurs more network messages from the query insertion pro-
cess since the procedure needs to check more objects from a larger
area where the moving objects have the mobile-side LITs overlap-
ping with the new query boundary. We choose = 5 as the mobile-
side LIT size for the remaining experiments, because it achieves
better performance in terms of the network messages.
10
12
14
16
18
20
22
24
10 5 1
Network Messages (k)
Number of Cells (Per axis)
PLU
Figure 8. Performance v.s. mobile-side LIT size
4.2 Query Coverage
The query coverage on the terrain is a crucial factor in the per-
formance of continuous query algorithms. The query coverage
varies with the number and side length of the queries. Figure 9(a)
shows the network messages as a function of the number of queries.
Overall, the number of network messages increases as a function
of the number of queries, because the chance of moving into the
query boundaries for a moving object is high. PLU achieves a
significant reductions in the number of updates compared to the
other techniques. For the PER approach, since the server does not
perform any computations regarding the location update reduction,
we only count the number of network messages sent from the mo-
bile clients. PER approach is independent of the query coverage,
because the number of updates depends on the mobility only in
PER approach. Therefore, the network messages remain the same
in this simulation. In Figure 9(b), we evaluate the side length of
queries with the values [1, 5, 10]. Obviously, when the length of
queries increases, SR*-Rec and SR*-SP incur more updates, be-
cause SR*-Rec and SR*-SP perform server-side probes to those
objects which have the safe regions overlapping with the queries.
When the length of the queries increases, the server needs to probe
more moving objects when queries change to new locations or
when new queries are inserted. When q
len
=10, SR*-SP has the
same network messages as the baseline PER approach. The sim-
ulation results confirm the importance of adopting PLU approach
which significantly reduces the network messages and hence de-
creases the communication cost.
10
20
30
40
50
60
70
80
90
100
1000 500 300
Network Messages (k)
Number of Queries
PLU
SR*-SP
SR*-Rec
PER
(a) Q with q
len
=5
10
20
30
40
50
60
70
80
90
100
10 5 1
Network Messages (k)
Side Length of Queries
PLU
SR*-SP
SR*-Rec
PER
(b) q
len
with Q = 1000
Figure 9. Effect of query coverage with Q and q
len
4.3 Mobility
Finally, we evaluated the impact of the mobility rate. Figure 10(a)
shows the number of network messages as a function of the object
mobility. The PLU approach achieves a higher location update
reduction than the other three approaches for all mobility rates.
Figure 10(b) illustrates the CPU time v.s. the object mobility. Al-
though PLU applies more server-side procedures (e.g.DectObj and
QurIns) to reduce the network messages, PLU still has a compet-
itive CPU performance with SR*-SP. However, SR*-Rec has the
worst performance in terms of network messages and CPU over-
heads. The degradation is caused by the expensive calculations of
safe rectangles. SR*-Rec in general computes larger safe regions
for moving objects than SR*-SP, so SR*-Rec incurs many server-
side probes to the moving objects when queries change their loca-
tions.
5. Conclusions
We have designed a partition-based lazy update approach for
highly dynamic environments where mobile units (including queries)
may freely change their locations. The novel concept of a Loca-
tion Information Table is introduced to provide a mobile object
20
40
60
80
100
120
140
160
100 70 50 30 10
Update Messages (k)
Object Mobility
PLU
SR-SP
SR-Rec
PER
(a) Network messages
5
10
15
20
25
30
35
40
45
100 70 50 30 10
CPU Time (Sec)
Object Mobility
PLU
SR*-SP
SR*-Rec
PER
(b) CPU time (sec)
Figure 10. Performance v.s. object mobility
with information about queries, hence enabling it to estimate query
movements and transmit a location update to the server only when
it affects the query results. To further reduce network trafficthe
server uses smart on-demand location probes. Finally, the pro-
posed mechanism efficiently determines the set of objects that are
affected by a query insertion, improving scalability. The data struc-
ture for a LIT is larger than for a safe region and we present a spa-
tial data compression method to reduce its size andfit it into an In-
ternet packet. Experimental results demonstrate that our approach
scales better than existing techniques as it reduces the update mes-
sage traffic by 10% to 28% compared with the extended safe sphere
method, and from 10% to 70% for the periodic approach. These re-
sults are even more noteworthy as we compare our technique with
an enhanced version of the safe region approach that we improved
to handle moving queries.
6. Acknowledgments
This research has been funded in part by NSF grants EEC-9529152 (IMSC ERC),
CMS-0219463 (ITR), IIS-0534761, NUS AcRF grant WBS R-252-050-280-101/133
and equipment gifts from the Intel Corporation, Hewlett-Packard, Sun Microsystems
and Raptor Networks Technology. We also acknowledge the support of the NUS In-
teractive and Digital Media Institute (IDMI).
7. References
[1] Y . Cai, K. Hua, and G. Cao. Processing Range-Monitoring Queries on
Heterogeneous Mobile Objects. InMDM, 2004.
[2] B. Gedik and L. Liu. MobiEyes: Distributed Processing of Continuously
Moving Queries on Moving Objects in a Mobile System. In EDBT, 2004.
[3] H. Hu, J. Xu, and D. L. Lee. A generic framework for monitoring continuous
spatial queries over moving objects. InSIGMODConference, pages 479–490,
2005.
[4] C. S. Jensen, D. Lin, and B. C. Ooi. Query and Update Efficient B+-Tree Based
Indexing of Moving Objects. InVLDB, 2004.
[5] A. B. McDonald. A mobility-based framework for adaptive dynamic
cluster-based hybrid routing in wireless ad-hoc networks, 1999.
[6] M. F. Mokbel, X. Xiong, and W. G. Aref. Sina: Scalable incremental
processing of continuous queries in spatio-temporal databases. In SIGMOD
Conference, pages 623–634, 2004.
[7] K. Mouratidis, M. Hadjieleftheriou, and D. Papadias. Conceptual Partitioning:
An Efficient Method for Continuous Nearest Neighbor Monitoring. In
SIGMODConference, 2005.
[8] S. Prabhakar, Y . Xia, D. V . Kalashnikov, W. G. Aref, and S. E. Hambrusch.
Query Indexing and Velocity Constrained Indexing: Scalable Techniques for
Continuous Queries on Moving Objects.IEEETrans. Computers,
51(10):1124–1140, 2002.
[9] S. Saltenis, C. S. Jensen, S. T. Leutenegger, and M. A. Lopez. Indexing the
Positions of Continuously Moving Objects. InSIGMODConference, 2000.
[10] Y . Tao, D. Papadias, and J. Sun. The TPR*-Tree: An Optimized
Spatio-Temporal Access Method for Predictive Queries. InVLDB, pages
790–801, 2003.
[11] X. Xiong, M. F. Mokbel, and W. G. Aref. SEA-CNN: Scalable processing of
continuous k-nearest neighbor queries in spatio-temporal databases. In ICDE,
pages 643–654, 2005.
[12] X. Xiong, M. F. Mokbel, and W. G. Aref. LUGrid: Update-tolerant grid-based
indexing for moving objects. InMDM, 2006.
[13] X. Yu, K. Q. Pu, and N. Koudas. Monitoring k-nearest neighbor queries over
moving objects. InICDE, pages 631–642, 2005.
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 909 (2009)
PDF
USC Computer Science Technical Reports, no. 908 (2009)
PDF
USC Computer Science Technical Reports, no. 871 (2005)
PDF
USC Computer Science Technical Reports, no. 843 (2005)
PDF
USC Computer Science Technical Reports, no. 891 (2007)
PDF
USC Computer Science Technical Reports, no. 886 (2006)
PDF
USC Computer Science Technical Reports, no. 899 (2008)
PDF
USC Computer Science Technical Reports, no. 628 (1996)
PDF
USC Computer Science Technical Reports, no. 893 (2007)
PDF
USC Computer Science Technical Reports, no. 912 (2009)
PDF
USC Computer Science Technical Reports, no. 699 (1999)
PDF
USC Computer Science Technical Reports, no. 748 (2001)
PDF
USC Computer Science Technical Reports, no. 795 (2003)
PDF
USC Computer Science Technical Reports, no. 742 (2001)
PDF
USC Computer Science Technical Reports, no. 846 (2005)
PDF
USC Computer Science Technical Reports, no. 627 (1996)
PDF
USC Computer Science Technical Reports, no. 762 (2002)
PDF
USC Computer Science Technical Reports, no. 685 (1998)
PDF
USC Computer Science Technical Reports, no. 754 (2002)
PDF
USC Computer Science Technical Reports, no. 744 (2001)
Description
Yu-Ling Hsueh, Roger Zimmermann, Haojun Wang, Wei-Shinn Ku. "Partition-based lazy updates for continuous queries over moving objects." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 892 (2007).
Asset Metadata
Creator
Hsueh, Yu-Ling
(author),
Ku, Wei-Shinn
(author),
Wang, Haojun
(author),
Zimmermann, Roger
(author)
Core Title
USC Computer Science Technical Reports, no. 892 (2007)
Alternative Title
Partition-based lazy updates for continuous queries over moving objects (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
8 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16269191
Identifier
07-892 Partition-Based Lazy Updates for Continuous Queries over Moving Objects (filename)
Legacy Identifier
usc-cstr-07-892
Format
8 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/