Enabling Technologies for Wireless E-Business phần 9 pdf

12 Mo
bil
e Serv
i
ces Comput
i
n
g
307

1
2.5.1 Scenario
A car is parked in a parkin
g
lot, and th
e
owner of the car
g
ets off and walks
s
omewhere. Before he gets off the car, he t
u
rns on the alarm system. The owne
r

carries a cell phone with him, with the phone connected to a wireless alarm system
(
WAS) in the car. WAS has sensors that detect whether the car is touched by
s
omeone. If t
h

e car
i
s touc
h
e
d
, t
h
e WAS sen
d
s an a
l
ert to t
h
e owner’s ce
ll
p
h
one.
Th
ereafter
,
t
h
e owner sen
d
s a comman
d
to t
h

e WAS
t
o protect
hi
s car from
b
e
i
ng
s
to
l
en. Base
d
on t
h
e t
hi
ef’s
r
eact
i
on,
di
fferent requests
/
comman
d
s are sent to t
h

e
W
AS and the WAS
g
ives feedbacks to the thief until the car en
g
ine is locked
f
inall
y
. The WAS works based on not o
n
ly
the owner’s commands, but also
context information, such as t
h
e time, thief’s attem
p
t, and resources available.
T
he complete scenario of the WAS is shown in Fig. 12.2 and is explained as
f
ollows:
•
A t
hi
ef touc
h
es a car.
•

Th
e
d
etector
(
sensor
)
of t
h
e car
g
ets t
h
e
i
nformat
i
on an
d
sen
d
s
i
t to t
h
e
owner’s ce
ll
p
h

one.
•
T
he owner of the car sends an alert invocation command to the WAS.
•
T
he WAS
g
ives a speech-based alert to the theft, and the volume of
the alert is determined b
y
time: if i
t

i
s da
y
time, the volume ma
y
be
hi
g
h
er; ot
h
erw
i
se,
i
t

i
s
l
ower.
•
Th
e t
hi
ef cont
i
nues to tamper t
h
e car.
•
Th
e
d
etector
g
ets t
h
e
i
nformat
i
on, sen
d
s
i
t to t

h
e owner’s ce
ll
p
h
one,
an
d
prompts t
h
at t
h
e a
l
ert
d
oes not ta
k
e effect.
•
Th
e owner sen
d
s a p
i
cture-ta
ki
n
g
a

l
ert comman
d
to t
h
e WAS.
•
T
he WAS sends a s
p
eech-based alert that a
p
icture will be taken if the
theft continues.
•
T
he thief still continues to tam
p
er the car.
•
Th
e
d
etector gets t
h
e
i
nformat
i
on, sen

d
s
i
t to t
h
e owner’s ce
ll
p
h
one,
an
d
prompts t
h
at t
h
e ta
ki
ng-p
i
cture a
l
ert
did
not ta
k
e effect.
•
T
he owner sends a picture-takin

g
command to the WAS.
•
The WAS invokes the corresponding ser
vice and a picture is taken of
r
r
the thief and a speech alert is broadcast; if the disk space is not enou
g
h
to save the
p
icture, the resource
m
anager is invoked and virtual
memory is added.
•
Th
e t
hi
ef cont
i
nues to tamper t
h
e car.
•
Th
e
d
etector

g
ets t
h
e
i
nformat
i
on, sen
d
s
i
t to t
h
e owner’s ce
ll
p
h
one,
an
d
prompts t
h
at t
h
e p
i
ctur
e
-
ta

ki
n
g

did
not ta
k
e effect.
•
Th
e owner of t
h
e car sen
d
s a comman
d
to t
h
e WAS to
l
oc
k
t
h
e en
gi
ne.
•
T
he WAS invokes the service to lock the engine.

•
Hopefully the thief leaves the car alone.
•
Opt
i
ona
ll
y, t
h
e WAS can a
l
so connect to po
li
ce e
i
t
h
er automat
i
ca
ll
y or
b
ase
d
on t
h
e owner’s
i
nstruct

i
on, at any stage, to report t
h
e case.
3
08 L J. Z
h
an
g
, B. L
i
, an
d
Y. Son
g


Fig
. 12.2.
S
cenar
i
o of
W
A
S
1
2.5.2
S
olut

i
on
T
h
e arc
hi
tecture of t
h
e WAS
i
s s
h
own
i
n F
ig
. 12.3. T
hi
s
i
s an examp
l
e of a
t
y
p
i
ca
l
context-sens

i
t
i
ve m
obile

se
r
vice.
F
ou
r
se
r
vices
ar
e
ava
il
a
bl
e
i
n t
h
e WAS
,

name
ly

d
etector serv
i
ce, context serv
i
ce, a
l
ert serv
i
ce, an
d
camera serv
i
ce. S
i
nce
media data (
p
ictures) must be saved, a r
e
s
ource mana
g
er is desi
g
ned in case that
t
here is no adequate disk space. It is also possible that different t
y

pes of cell
p
hones are used in the WAS so that a device moderator is desi
g
ned to suppor
t

communications between cell
p
hones and mobile devices.
I
n this im
p
lementation, the service is
p
rovided by a small device that is
connected to the car. In general, HTTP p
r
otocol is not supported by it. So
a

s
pec
i
f
i
c commun
i
cat
i

on protoco
l
must
b
e use
d
, for examp
l
e
,
802.11. In a
ddi
t
i
on
,

th
e ce
ll
p
h
one m
igh
t
b
e connecte
d
to t
h

e Internet
by
GPRS. T
h
erefore,
a
mu
l
t
i
mo
d
a
l
a
d
aptat
i
on
i
s requ
i
re
d
. T
h
e ce
ll
p
h

one must
h
ave t
h
e capa
bili
t
y
to
d
etect location and the current time, since thi
s
inf
o
rmati
o
n i
s
th
e

co
nt
e
xt tha
t

su
pp
orts the mobile service. In

s
ummary, each mobile device satisfies the basic
r
e
q
uirements of mobile services, i.e., multimodal ada
p
tor, context ada
p
tor, an
d

c
ontext information collector are included in each of them.
1
2 Mo
bil
e Serv
i
ces Comput
i
n
g
309
F
i
g
. 12.3. The architecture of WAS
12.6 Summary
W

e
b
serv
i
ce
i
s an effect
i
ve tec
h
n
i
que for
i
mprov
i
ng
b
us
i
ness eff
i
c
i
ency
b
y
automat
i
ng t

h
e co
ll
a
b
orat
i
o
n
of
h
eterogeneous
i
nformat
i
on systems. Its potent
i
a
l
app
li
cat
i
on
i
n t
h
e rea
l
wor

ld

i
s
li
m
i
t
l
ess an
d

h
as
b
een ent
h
us
i
ast
i
ca
lly
em
b
race
d

by

t
h
e IT
i
n
d
ustr
y
. B
y
exten
di
n
g

i
t to t
h
e
w
i
re
l
ess an
d
mo
bil
e wor
ld
, muc

h
more
p
eop
l
e can
b
e connecte
d
to t
h
e enormous We
b
of
i
nformat
i
on an
d
serv
i
ces,
anywhere and anytime. The scope and eff
e
c
tiveness of those i
n
f
ormation services
will transcend to a new level, where unlimited new business o

pp
ortunities exist.
Some exam
p
les are mobile entertainment, mobile enter
p
rise, and mobile law
e
nforcement. Part
i
cu
l
ar
l
y, mo
bil
e We
b
serv
i
ce
i
s an
i
mportant approac
h
for
rea
li
z

i
ng m-commerce, w
hi
c
h

i
s expecte
d
to
b
ecome
i
ncreas
i
ng
l
y popu
l
ar,
f
ollowing successful desktop e-commerce. Mobil
e
service is the next direction of
We
b
serv
i
ce. Un
i

que tec
h
n
i
ca
l
c
h
a
ll
en
g
es
li
e a
h
ea
d
,
i
f mo
bil
e serv
i
ces are to
b
e as
successfu
l
as re

g
u
l
ar We
b
serv
i
ces.
3
10 L J. Z
h
an
g
, B. L
i
, an
d
Y. Son
g


4
.
eXtens
ibl
e Mar
k
up Lan
g
ua

g
e,
h
ttp:
//
www.w3.or
g/
XML
/

5.
W
e
b
Serv
i
ces Descr
i
pt
i
on Lan
g
ua
g
e
,
h
ttp:
//
www.w

3
.or
g/
TR
/
ws
dl

6
.
Si
mp
l
e O
bj
ect Access Protoc
o
l
,
h
ttp:
//
www.w3.or
g/
TR
/
soap
/

7

.
U
niversal Description, Discovery a
n
d
Integration, htt
p
://www.ud
d
i.org
/

8.
I
EEE Transactions on Mobile Computing, Los Alamitos, CA: IEEE
C
omputer Soc
i
ety, 2002
9.
S
.N. C
h
uang, A.T.S. C
h
an, J. Cao, an
d
R.
Ch
eung, Act

i
ve
l
y
d
ep
l
oya
bl
e mo
bil
e
serv
i
ces for a
d
apt
i
ve we
b
access, IEEE Internet Comput
i
ng 8
(
2
)
, 2004, 26–33
10
.
J.F. Hu

b
er, Mo
bil
e next-
g
enerat
i
on networ
k
s, IEEE Mu
l
t
i
me
di
a 11
(
1
)
, 2004,
7
2–83
11
.
U
n
i
versa
l
Resource Locator,

h
ttp:
//
www.w3.or
g/
A
dd
ress
i
n
g/
12
.
B
luetooth,
g/

13
.
Wi-Fi,
g
/
14
.
3G, http://www.3
g
.co.uk
/

1

5.
U
. Vars
h
ney, R.J. Vetter, an
d
R. Ka
l
a
k
o
t
a,
Mo
bil
e commerce: A new front
i
er
,
Computer 33
(
10
)
, 2000, 32–38
16
. J.A. Senn, T
h
e emergence of m-commerce, Computer 33
(
12

)
, 2000, 148–150
17.
S. Sc
h
w
id
ers
ki
-Grosc
h
e, an
d
H. Knospe, Secure mo
bil
e commerce, E
l
ectron
i
cs
& Commun
i
cat
i
on En
gi
neer
i
n
g

Journa
l
14
(
5
)
, 2002, 228–238
1
8
.
B
.N. Sc
hili
t
,
D.M. H
ilb
ert
,
an
d
J. Trevor
,

C
ontext-aware commun
i
cat
i
on

,
I
EEE Wireless Communications
[
see also IEEE Personal Communications
]

9(
5
)
, 2002, 46–54
1
9
.
J Y. Pan, C P. Tan, W T. Lee
,
Context-aware service
p
rotocol, Wireless
Commun
i
cat
i
ons an
d
Networ
ki
ng, 2003, WCNC 2003, 2003 IEEE, vo
l
ume

3,
16–20 Marc
h

2
003
, pp.
20
5
8
–
2063
20.
G. N
ikl
fe
ld,
M. Puc
h
er
,
R. F
i
nan
,
an
d
W. Ec
kh
art

,
Mo
bil
e mu
l
t
i
-mo
d
a
l

d
ata
s
erv
i
ces for GPRS p
h
ones an
d

b
e
y
on
d
, mu
l
t

i
mo
d
a
l

i
nterfaces, 2002.
P
rocee
di
n
g
s of Fourt
h
IEEE Internat
i
ona
l
Conference on 14–16 Octo
b
er
2002,
pp
. 337–342
2
1
.
P.D. Le, B. Srinivasan, V. Malhotra, and N. Mani, Resource and load sharin
g

i
n mobile computin
g
environments TENCON ’98, 1998. IEEE Re
g
ion 10
International Conference on Global
C
onnectivity in Energy, Computer,
Communication and Control
,
vo
l
ume 1, 17–19 December 1998,
pp
. 82–85
22.
G. Le Grand, J. Ben-Othman, and E. Horlait, Providing quality of service in
mo
bil
e env
i
ronments w
i
t
h
MIR
(
mo
bil

e IP reservat
i
on protoco
l)
, networ
k
s,

References
1.
W
or
ld

Wid
e
W
e
b

Co
n
sort
i
um,
h
ttp:
//
www.w3.or
g

2.
W
3C
,
“We
b
Serv
i
ces Arc
hi
tectu
r
e,”
h
ttp:
//
w3
.
or
g/
TR
/
ws-arc
h/

3.
H
y
pertext Transfer Protoco

l
,
h
ttp:
//
www.w3.or
g/
Protoco
l
s
/
2000
(
ICON 2000
)
. Procee
di
ngs o
f

I
EEE Internat
i
ona
l

Co
n
f
erence on 5–8

Septem
b
er 2000, pp. 24–29
2
3
.
D. Bar
k
a
i
, Peer-to-Peer Comput
i
n
g:
Tec
h
no
l
o
gi
es for S
h
ar
i
n
g
an
d
Co
ll

a
b
o
-
rat
i
n
g
on t
h
e Net, H
ill
s
b
oro, OR: Inte
l
Press, 2001
1
2 Mobile Services Computin
g
311

24.
8
02.11,
2
5
.
W
ireless A

pp
lication Protocol,
h
tt
p
://www.w3schools.com/wa
p
/
26.
R.J. Bates
,
GPRS: General Packet Radio Service
,
New York: McGraw-Hill
,
2002

27.
I R. C
h
en, N.A. P
h
an, an
d
I L. Yen, A
l
gor
i
t
h

ms for support
i
ng
di
sconnecte
d

w
r
i
te operat
i
ons for w
i
re
l
ess we
b
access
i
n mo
bil
e c
li
ent–server env
i
ronments,
IEEE Transactions on Mobile Computin
g
1(1), 2002, 46–58

2
8
.
M. Ber
g
er, M. Bouzid, M. Buckland, H. Lee, N. Lhuillier, D. Olpp, J. Picault,
and J. Shepherdson, An approach to agent-based service composition and its
a
pp
lication to mobile business
p
rocesses, IEEE Transactions on Mobile
C
omputing 2(3), 2003, 197–206
29.
E
. Ceram
i
, We
b
Serv
i
ces Essent
i
a
l
s, Be
iji
ng, Se
b

astopo
l
, CA: O’Re
ill
y,
2002
30.
B. L
i
, W T. Tsa
i
, L J. Z
h
ang, Bu
ildi
ng e-commerce systems us
i
ng t
h
e
s
emantic a
pp
lication framework, International Journal of
W
eb En
g
ineerin
g
and Technolo

gy
1(3),
2
004, 297–319
13 Location-Aware Services and its Infrastructure
Support
Y
. Chen and D. Liu
IBM China Research Laboratory
13.1 Introduction
Wi
t
h
a
d
vances
i
n w
i
re
l
ess Internet a
nd mobile computing, location-based services
(
LBS
)

h
ave emerge
d

as a
k
ey va
l
ue-a
dd
e
d
serv
i
ce for te
l
ecom operators to
d
e
li
ve
r

p
ersonalized location-aware content to their subscribers usin
g
its wireless
i
nfrastructure. Besides telecom o
p
erators, more and more service
p
roviders, suc
h

as
p
ublic wireless LAN (PWLAN)
p
roviders, enterprises, etc. are developin
g
an
d

deploying location-aware services for consumers and employees to gain more
revenue and productivity. These location-aware services
p
roviders (LASPs) are
f
ac
i
ng
b
ot
h
tec
h
n
i
ca
l
a
n
d
soc

i
a
l
c
h
a
ll
en
g
e
s, suc
h
as pos
i
t
i
on
i
ng
i
n var
i
ous
e
nv
i
ronments us
i
ng
di

fferent
l
ocat
i
ng mec
h
an
i
sms,
l
ocat
i
on trac
ki
ng,
i
nformat
i
on
d
e
li
very mo
d
e
l
s, pr
i
vacy protect
i

on, an
d

d
eve
l
op
i
ng
i
nnovat
i
ve LBS app
li
cat
i
ons
to achieve more business impact and value, amon
g
others. It has been realized tha
t

a fl
e
xi
b
l
e
an
d

r
es
ili
e
nt mi
dd
l
ew
ar
e

s
h
ou
l
d

be
built as the enablin
g
infrastructure to
s
upport different pla
y
ers, so that service provider can efficientl
y
and effectivel
y

develop and deploy LBS applications, a

n
d
su
pp
ort innovative location-aware
applications quickly. The location-aware infrastructure should address key
challenges in location-aware computing
a
s identified in [1], such as technology-
i
n
d
epen
d
ent
l
ocat
i
on sens
i
ng, en
d
-to-en
d
con
t
ro
l
of
l

ocat
i
on
i
nformat
i
on, trac
ki
ng
an
d
pre
di
cat
i
on, an
d
ot
h
er researc
h
c
h
a
ll
enges
i
nvo
l
v

i
ng geospat
i
a
l

i
nformat
i
on
p
rocess
i
ng an
d

h
uman
i
nteract
i
on w
i
t
h
t
h
ese
i
nformat

i
on.
T
o a
dd
ress t
h
ese c
h
a
ll
en
g
es from a m
iddl
eware
i
nfrastructure po
i
nt of v
i
ew,
a

l
ocat
i
on operat
i
n

g
reference mo
d
e
l

(
LORE
)

i
s
d
eve
l
ope
d
to capture t
h
e
l
ocat
i
on
operat
i
on semant
i
cs from a
l

a
y
ere
d
perspect
i
ve, w
h
ere r
i
c
h
er
l
ocat
i
on operat
i
on
s
emantic is modeled at a higher layer. The
p
resented location o
p
eration semantics
addresses many issues, for example, how t
o
retrieve the location data, how the
l
ocation data are modeled, how to fuse location from different location sources,

h
ow to query t
h
e
l
ocat
i
on
d
ata,
h
ow to use trac
ki
ng mec
h
an
i
sm to
d
e
li
ve
r

i
nte
lli
gent
l
ocat

i
on-aware not
i
f
i
cat
i
on
,
etc. In a
ddi
t
i
on to t
h
e semant
i
cs
,
two ot
h
er
i
mportant
di
mens
i
ons
i
n

l
ocat
i
on-awar
e
comput
i
n
g
, pr
i
vac
y
protect
i
on an
d

mana
g
ement, are a
l
so covere
d

by
t
h
e L
O

R
E mo
d
e
l
. Base
d
on t
h
e LORE mo
d
e
l,
di
fferent components of t
h
e
l
ocat
i
on-aware
i
nfrastructure are
b
u
il
t to meet t
h
e
requirements of different la

y
ers and expose APIs to develo
p
ers to build other
components that could plu
g
into the mode
l
.
In the followin
g
sections, several ke
y

com
p
onents of the LORE infrastructure are i
n
tr
oduced
t
o

s
h
ow
h
ow
i
ssues

o
f th
e
1
3 Location-Aware Services and its Infrastructure Su
pp
ort 313
l
ocation-aware computin
g
addressed and how the composition of components
could facilitate the develo
p
ment of various location-aware services.
The chapter is organized as follows. In Sect. 13.2 the LORE model and the
i
nfrastructure are presented. Three key com
p
onents of the infrastructure, location
s
erver w
i
t
h
common a
d
apter framewor
k

(C
AF
)
, mov
i
ng o
bj
ect
d
ata
b
ase
(
MOD
)
,
an
d
spat
i
a
l
pu
bli
s
h/
su
b
scr
ib

e eng
i
ne are
i
ntro
d
uce
d

i
n Sects. 13.3, 13.4, an
d
13.5,
respect
i
ve
l
y. Sect
i
on 13.6 out
li
nes t
h
ere
l
ate
d
wor
k
s

,
w
hil
e
S
ect. 13.8 summar
i
zes
our studies and
p
resents future directions.
13.2 Location Operating Reference Model and Infrastructure
Fi
g
ure 13.1a illustrates the LORE model pr
o
p
osed to ca
p
ture the semantics an
d

management issues required by b
u
i
lding location-aware serv
i
ces. The LORE
model includes four domains: o
p

eration semantics, management, privacy an
d

s
ecur
i
ty, an
d
agent.
1
3.2.1 Operat
i
on
S
emant
i
cs Doma
i
n
T
he o
p
eration semantics dom
a
in includes layered com
p
onents that, from botto
m

to top, are pos

i
t
i
on
i
ng, mo
d
e
li
ng, fu
si
on, query, trac
ki
ng, an
d

i
nte
lli
gent
not
i
f
i
cat
i
on. T
h
e
l

ayere
d
components exp
l
i
c
i
t
l
y
d
escr
ib
e t
h
e
d
epen
d
enc
i
es among
components,
i
.e., t
h
e upper component uses t
h
e funct
i

ona
li
t
i
es expose
d

b
y
l
owe
r

com
p
onents to build more advanced functionalities. The overall functionalities
p
rovide the ca
p
abilities f
o
r
location-aware a
pp
lications
r
equirin
g
rich location
operatin

g
semantics.
The
positioning component
addresses the issue of technology-independent
t
l
ocation sensing, i.e., how to get the l
o
c
ation information of target objects via
s
pecific positioning mechanism
s
. Technical neutral positioning requires that the
p
os
i
t
i
on
i
ng component
i
nterface w
i
t
h

h

eterogeneous pos
i
t
i
on
i
ng equ
i
pment an
d
e
xpose a un
i
form v
i
rtua
l
pos
i
t
i
on
i
ng
m
ec
h
an
i
sm for ot

h
er components. T
h
e
component
h
as to
d
ea
l
w
i
t
h
two
di
fferent mo
d
es of pos
i
t
i
on
i
ng: server
b
ase
d
an
d

c
li
ent
b
ase
d
. In server-
b
ase
d
mo
d
e, t
h
e
l
ocat
i
on of t
h
e tar
g
et o
bj
ect
i
s measure
d
an

d
ca
l
cu
l
ate
d
on t
h
e server s
id
e, for examp
l
e, t
h
e GSM networ
k
s cou
ld

d
eterm
i
ne
t
h
e su
b
scr
ib

er’s pos
i
t
i
on
by
th
e ce
ll
w
h
ere t
h
e mo
bil
e p
h
one
i
s
b
e
i
n
g
serve
d
. I
n

client-based mode, the device does self-
p
o
s
itioning, e.g., a device with GPS can
determine its location. The
m
ajor difference between the two modes is how the
p
os
i
t
i
on
i
ng component retr
i
eves t
h
e
l
ocat
i
on
i
nformat
i
on. In t
h
e server-

b
ase
d

mo
d
e, t
h
e component pu
ll
s t
h
e
l
ocat
i
on from server
b
y access
i
ng t
h
e
l
ocat
i
on
i
nterface
(

e.g., LIF [2]
i
nterface
)
expose
d

b
y t
h
e server. In t
h
e c
li
ent-
b
ase
d
mo
d
e,
t
h
e
d
ev
i
ce a
l
wa

y
s pus
h
es t
h
e
l
ocat
i
on to t
h
e pos
i
t
i
on
i
n
g
component,
b
ecause
i
t
i
s
di
ff
i
cu

l
t for c
li
ent to
h
ave a
l
ocat
i
on
i
nterface. Two pos
i
t
i
on
i
n
g
mo
d
es requ
i
re t
h
e
p
os
i
t

i
on
i
n
g
component to support
b
ot
h
pus
h
an
d
pu
ll
mo
d
e
l
s.
3
14 Y. Chen and D. Liu
Fig. 13.1
.

(
a
)
Location operating reference model.
(

b
)
Infrastructure supporting
l
ocat
i
on-aware serv
i
ces
T
he
modeling component
describes the semantics of location information. As it
t
comes from different positioning mechan
i
sms, the location data show grea
t

h
eterogene
i
t
i
es
i
n syntax, name, type, an
d
metr
i

c system. For examp
l
e, t
h
e LIF
exposes
l
ocat
i
on
d
ata
i
n
X
ML format, w
hil
e GPS exposes t
h
e
l
ocat
i
on
d
ata
i
n
compact
bi

nary format. GPS can prov
id
e ve
l
oc
i
ty
i
nformat
i
on
,
w
hil
e most
GS
M
p
os
i
t
i
on
i
n
g
approac
h
es cannot prov
id

e suc
h

d
ata. T
h
e mo
d
e
li
n
g
component
i
nte
g
rates
h
etero
g
eneous
l
ocat
i
on
d
ata
by

p

rov
idi
n
g
a un
i
form
l
ocat
i
on mo
d
e
l
t
h
a
t

f
ac
ili
tates t
h
e
d
eve
l
opment of f
l

ex
ibl
e serv
i
ces. T
h
e
l
ocat
i
on mo
d
e
l
captures
enough information on location, inclu
d
ing coordinates, time, velocity, error, and
other related information.
T
he
fusion component
addresses the issue of how to derive accurate location by
t
fus
i
ng
l
ocat
i

on reports from mu
l
t
i
p
l
e
d
ev
i
c
es for one target o
bj
ect. For examp
l
e,
a

p
erson
h
as a ce
ll
p
h
one, a note
b
oo
k
computer w

i
t
h
w
i
re
l
ess car
d
, an
d
a GPS
r
ece
i
ver, a
ll
t
h
ese
d
ev
i
ces can
b
e pos
i
t
i
one

d
an
d
t
h
e
i
r
l
ocat
i
on reports are sent to
t
h
e fus
i
on component for
d
eterm
i
n
i
n
g
t
h
e
prec
i
se

l
ocat
i
on. T
h
e fus
i
on component
d
er
i
ves t
h
e prec
i
se
l
ocat
i
on
b
ase
d
on pre
d
e
f
i
ne
d

ru
l
e set, w
hi
c
h
ma
y

d
ef
i
ne t
h
e
p
ossibilities of the location accurac
y
in a different context. There are lot o
f

i
nterestin
g
topics in the location fusion al
g
orithms an
d
r
u

l
e

se
t t
o

be
r
ese
ar
c
h
ed.
T
h
e
query component
provides spatio-temporal query interfaces from which
t
app
li
cat
i
ons an
d
en
d
users cou
ld

get
l
ocat
io
n
i
nformat
i
on of
i
ntereste
d
o
bj
ects an
d

1
3 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 315
issue

l
oc
ati
o
n-r
e
lat
ed
queries. The quer
y
could inv
o
lve not onl
y
current location
i
nformation, but also historical and/o
r
future location inf
o
r
mation. A typical
l
ocation query is “
P
lease re
p
ort the loca
t
ion of object X

.
” Another more com
p
lex
s
patio-temporal query involving historical information is
“
Please report the
“
ob
jects t
h
at are in zone X at time Y
.
” T
h
e query component uses t
h
e pos
i
t
i
on
i
ng
an
d/
or fus
i
on components to get t

h
e
l
ocat
i
on
d
ata. For support
i
ng effect
i
ve
hi
stor
i
ca
l
an
d
current
l
ocat
i
on
i
nformat
i
on retr
i
eva

l
, t
h
e query component emp
l
oys
s
patial index to improve the quer
y
performance. The spatial index could be R-tree
and its variation,
g
rid index, Z-order,
a
nd so on. Location
p
redication mechanisms
are used b
y
the quer
y
component to answ
e
r the
q
uestion about th
e
f
u
t

u
r
e
l
oc
ati
o
n
of specific objects.
The
tracking component
plays a key role in LBS in the sense that most of LBS
t
app
li
cat
i
ons requ
i
re trac
ki
ng
l
ocat
i
ons of target o
bj
ects to get t
h
e tra

j
ectory an
d

p
rov
id
es
i
nformat
i
on
b
ase
d
on t
h
e
l
ocat
i
on o
r
trajectory. Typical applications
r
i
nc
l
u
d

e f
l
eet management, tax
i

di
spatc
h
, an
d
roa
d
ass
i
stance nav
i
gat
i
on. Trac
ki
ng
p
uts si
g
nificant performance
i
mpact on the underl
y
in
g

positionin
g
component b
y

p
ositionin
g
the location of t
h
e ob
j
ects continuousl
y
o
r

i
n a s
p
ecified time interval.
T
h
e

intelligent notification component
brings new user experience by sending
t
l
ocation-de

p
endent m
e
s
sage, including sales prom
o
t
ion, weather and traffic
i
nformation, nearby events, and so on.
A
typical application of the intelligen
t

notification is
“
Please sen
d
me promotion message while I am in zone X
.
” The key
t
ec
h
no
l
ogy
b
e
hi

n
d
t
h
e
i
nte
lli
gent not
i
f
i
cat
i
on
i
s spat
i
a
l
pu
bli
s
h/
su
b
scr
i
pt
i

on
s
erv
i
ce w
h
ere users
d
ef
i
ne t
h
e events t
h
ey are
i
ntereste
d

i
n,
i
n a
d
vance,
b
y
s
pec
i

fy
i
ng spat
i
o-tempora
l
con
d
i
t
i
ons
,
an
d
t
h
en t
h
e not
i
f
i
cat
i
on w
ill

b
e

d
e
li
vere
d

to
t
he
m
while
t
he

c
on
di
t
i
on
i
s met
by
ta
ki
n
g
t
h
e users’

l
ocat
i
on
i
nformat
i
on
i
nto
cons
id
erat
i
on. W
h
en t
h
e
i
nte
llig
ent not
i
f
i
cat
i
on component
i

s
d
ep
l
o
y
e
d
fo
r

s
upport
i
n
g
a
l
ar
g
e num
b
e
r

o
f users, t
h
e spat
i

a
l
pu
b/
su
b
s
h
ou
ld
a
l
so prov
id
e
s
calable mechanism to ena
b
le intelligent location-aware services.
1
3.2.2 Management Domain
Th
e mana
g
ement
d
oma
i
n
i

nc
l
u
d
es a
ll
necessar
y
mec
h
an
i
sms to support mana
gi
n
g
t
he components in the operation semantics domain except privac
y
and securit
y

i
ssues, such as confi
g
uration mana
g
ement, polic
y
mana

g
ement, monitorin
g
an
d

l
ogg
i
ng, component ava
il
a
bili
ty, an
d
so on.
1
3.2.3 Pr
i
vacy and
S
ecur
i
ty Doma
i
n
Privac
y
and securit
y

pla
y
important roles
i
n buildin
g
l
o
c
ati
o
n-a
w
ar
e

bus
in
ess

s
erv
i
ces w
h
ere
l
ocat
i
on an

d
t
h
e user’s pr
i
vate
i
nformat
i
on s
h
ou
ld

b
e protecte
d

f
rom a
b
use. T
h
e pr
i
vacy an
d
secur
i
ty

d
oma
i
n prov
id
es a framewor
k
to guarantee
th
at t
h
e use of
l
ocat
i
on
i
nformat
i
on
i
s un
d
er contro
l

i
n t
h
e

l
ocat
i
on-aware serv
i
ces
e
nv
i
ronment. In t
h
e pr
i
vac
y
framewor
k
,
a
use
r
c
an
decide

who

o
r
which

se
r
vice

is
a
bl
e to
g
et
hi
s
/h
er
l
ocat
i
on
i
nformat
i
o
n
,
an
d
furt
h
ermore

,
t
h
e user can
d
ef
i
ne
3
16 Y. Chen and D. Liu
where, when, and wh
y
(
for what
p
ur
p
ose) the inf
o
rmati
o
n
cou
l
d

be
r
e
tri

eved

or

used. The security framework protects the location information by leveraging
p
roven security mechanisms, such as encryption, digital signature, and secure
trans
p
ortation
p
rotocol.
1
3.2.4 Agent Doma
i
n
W
ith advances in mobile computing, mobile devices, such as mobile phone and
PDA, get more capabilities in computing, networking, and storage. Taking
a
d
vantage of t
h
e resources
i
n suc
h

d
ev

i
ces cou
ld

h
e
l
p

b
u
ild
more sca
l
a
bl
e
l
ocat
i
on-
aware serv
i
ces an
d

i
nnovat
i
ve user exper

i
ences. T
h
e agent
d
oma
i
n
i
ntro
d
uces t
h
e
l
ocat
i
on-aware agent t
h
at res
id
es
i
n t
h
e mo
bil
e
d
ev

i
ce an
d
cooperates w
i
t
h
servers to
comp
l
ete t
h
e
l
ocat
i
on-aware serv
i
ces. For examp
l
e,
i
n t
h
e trac
ki
n
g
serv
i

ce, a se
l
f
-
p
os
i
t
i
on
i
n
g
c
li
ent, for re
d
uc
i
ng
t
h
e networ
k
traff
i
c an
d
resource consumpt
i

on on t
h
e
s
erver side, could send the location info
r
mation to server only when the changes of
rr
the location is larger than a predefined threshold. The agent domain provides the
f
ramework for building service-specific location-aware agent.
1
3.2.5 In
f
rastructure
S
upport
i
ng LORE Model
Based on the LORE model, an infrastructure supportin
g
location-aware services is
p
ro
p
osed as de
p
icted in Fi
g. 13.1b. With the support
of the infrastructure,

t
l
ocat
i
on-aware serv
i
ces, suc
h
as ye
ll
ow pages, emergence serv
i
ces, an
d
nav
i
gat
i
on
s
erv
i
ces
,
cou
ld

b
e create
d

an
d
deployed easily. Three prototypes of the key
d
components
i
n t
h
e LBS m
iddl
eware of t
h
e
i
n
f
rastructure are
im
plemented, and all
m
m
t
h
e components
i
n t
h
e LORE op
e
r

at
io
n
se
mant
ics

do
ma
i
n ar
e

cove
r
ed.
•
L
ocat
i
on server prov
id
es t
h
e pos
i
t
i
on
i

n
g
, mo
d
e
li
n
g
, an
d
fus
i
on com-
p
onents
i
n t
h
e LORE operat
i
ons se
m
ant
i
c
d
oma
i
n. A
l

so
i
t supports
s
imple quer
y
and trackin
g
funct
i
onalities. A CAF is introduced to
s
upport technolo
gy
-
i
ndependent location sensin
g
, whic
h
i
s

de
tail
ed
in
Sect. 13.3. The location server su
pp
orts WAP [3] location API and LIF

[
2]
i
nterface for retr
i
ev
i
ng an
d
query
i
n
g
l
ocat
i
on
i
nforma
ti
on. A
l
so t
h
e
l
ocat
i
on server
i

nc
l
u
d
es a pr
i
vacy mec
h
an
i
sm to protect t
h
e
l
ocat
i
o
n

i
nformat
i
on from
b
e
i
n
g
use
d

w
i
t
h
out t
h
e owner’s perm
i
ss
i
on.
•
M
OD mana
g
es t
h
e
l
ocat
i
on
d
ata co
ll
ecte
d
from t
h
e

l
ocat
i
on server an
d

p
rov
id
es t
h
e quer
y
an
d
trac
ki
n
g
components
i
n t
h
e LORE operat
i
ons
s
emantic domain. Continuous, active monitorin
g
en

g
ine for location
-
b
ased services
(
CAMEL
)
[4] is built
a
s a MOD protot
y
pe which
s
u
pp
orts
q
ueries of both historical
a
n
d

cu
rr
e
nt l
oc
ati
o

n inf
o
rmati
o
n
.

MO
D
di
scusse
d

i
n
S
ect. 13.4.
•
Spat
i
a
l
pu
b/
su
b
eng
i
ne
s

upports t
h
e
i
nte
lli
gen
t
not
i
f
i
cat
i
on componen
t

i
n LORE operat
i
ons semant
i
c
d
oma
i
n. It prov
id
es
i

nterfaces fo
r

s
u
b
scr
ibi
n
g

l
ocat
i
on-aware messa
g
e an
d

d
ef
i
n
i
n
g
t
h
e s
y

stem w
id
e o
r

13 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 317
a
pp
lication-s
p
ecific location information for subscri
p
tion. The s
p
atial
p
ub/sub is discuss
e
d in Sect. 13.5.
Besides the LBS middleware, the infrastructure also incl

u
des mobility location
client (MLC) that su
pp
orts the l
o
c
ation-aware agent domain
i
n LORE model. A
n

MLC framewor
k

b
ase
d
on J2ME
i
s
i
mp
l
emente
d,
an
d

it

s
upports t
h
e JSR179
s
pec
i
f
i
cat
i
on. T
h
e MLC ena
b
l
es t
h
e app
li
cat
i
ons
i
n mo
b
il
e
d

ev
i
ces
l
everage
l
oca
l

resource an
d
cooperate w
i
t
h
a remote server to
i
mprove system performance an
d

r
educe
n
e
t
wo
rk traffi
c.
13.3 Location Server
L

ocation server provides the positionin
g
, modelin
g
, and fusion components of the
L
ORE o
p
erations semantic domain, and su
pp
ort
s
privacy and security domain an
d

management domain in the LORE model. The architecture of location server is
d
ep
i
cte
d

i
n F
i
g. 13.2. T
h
ere are t
h
ree

l
ayers
i
n ULS:
l
ocat
i
on APIs, serv
i
ce
management framewor
k
, an
d
CAF. T
h
e
l
ocat
i
on server
i
s
d
es
i
gne
d
w
i

t
h
t
h
ree
f
eatures
i
n m
i
n
d,
f
l
ex
ib
ili
ty
i
n
l
ocat
i
on API, sca
l
a
bili
ty
i
n comman

d
a
d
apter
f
ramework, and extensibilit
y
in service mana
g
ement.
Fig
. 13.2
.
L
oc
ati
o
n
se
r
ve
r ar
c
hit
ec
t
u
r
e
P

r
i
vac
y
S
erv
i
c
e
Cache
S
erv
i
c
e
F
lo
w
C
ontrol
U
/
D
A
ut
h
entication
Revers
e
G

eocodin
g
Serv
i
ce
B
i
ll
ing
S
ervi
ce
Service Mana
g
ement Framewor
k
Common A
d
a
p
ter Framewor
k
A
dapte
r
E
ricsson
M
P
S

Adapter
A
ironet
LCS
Adapter
Oth
er

F
Q
uer
y
Perio
d
Quer
y
L
ocat
i
o
n API
P

3
18 Y.
Ch
en an
d
D. L
i

u
1
3.3.1 Common Ada
p
ter Framewor
k

C
AF
p
rovides standard APIs to fetch locati
o
n information of the tar
g
et ob
j
ect
i
ndependent of positionin
g
mechanisms. It defines a common ada
p
ter interface
i
ntended to shield the details of vario
u
s positioning systems and provides a
n

adapter implementing this interface for each underlying positioning system. Each

ven
d
or-spec
i
f
i
c a
d
apter focuses on
l
y on
d
ea
li
ng w
i
t
h
transport
(H
TTP or TCP
)
an
d
t
h
e XML format transco
di
ng. A new a
d

a
pter
i
s very eas
il
y
d
eve
l
ope
d
an
d
can
b
e p
l
ugge
d

i
nto t
h
e framewor
k
rap
idl
y.
I
n some specified infrastructures, e.

g
., in GSM/CDMA wireless network,
p
ositionin
g
is a resource- and time-consumin
g
process, CAF provides
p
erformance o
p
timization mechanisms, such as connection
p
ools and mobile
s
tation identifier
(
MSID
)
combination,
s
pecified as circle P in the figure.
C
onnection pools are designed to reuse s
o
cket connections and restrict the
max
i
mum networ
k

traff
i
c. MSID com
bi
nat
i
on can
bi
n
d
mu
l
t
i
p
l
e concurrent
l
ocat
i
on quer
i
es to one
l
ocat
i
on query
s
o t
h

at t
h
e correspon
d
i
ng a
d
apter on
l
y
communicates to the positioning equipment
once and gets location information of
t
multi
p
le MSIDs.
C
AF su
pp
orts multi
p
le ada
pt
ers simultaneousl
y
b
y
various fusion al
g
orithms,

s
pecified as circle F in Fi
g.
13.2. There are man
y
kinds of polic
y
for retrievin
g

l
ocation from multi
p
le ada
p
ters. A simple way is a br
ute force solution in which
r
r
e
very request is permitted to go to all adapters and the proper one is selected.
Another way is all adapters are ordered according to their probabilities an
d

ca
l
cu
l
ate
d

b
y t
h
e
hi
story
i
nformat
i
on.
Th
e fus
i
on a
l
gor
i
t
h
m fro
m
mu
l
t
i
p
l
e a
d

apters
i
s st
ill
a researc
h
c
h
a
ll
enge.
1
3.3.2
S
erv
i
ce Management Framewor
k

Th
e goa
l
of t
h
e serv
i
ce management framewor
k

i

s to a
dd
ress
th
e
i
ssues
i
n pr
i
vacy
and security and management
domains of the LORE. These services implement
t
t
h
e common serv
i
ce
i
nterfaces
d
ef
i
ne
d

b
y t
h

e framewor
k
an
d
can
b
e ca
ll
e
d
pr
i
or
to or after t
h
e
l
ocat
i
on acqu
i
s
i
t
i
on
i
s conf
ig
ure

d
. T
h
e serv
i
ces current
ly
supporte
d

by
t
h
e framewor
k
are pr
i
vac
y
, user
/d
ev
i
ce
(
U
/
D
)
aut

h
ent
i
cat
i
on serv
i
ces, cac
h
e,
fl
ow contro
l
, reverse
g
eoco
di
n
g
, an
d

b
illi
n
g
. New serv
i
ces can
b

e
d
eve
l
ope
d
an
d

p
lu
gg
ed to the framework based on the interface.
U
ser
/
Dev
i
ce
(
U
/
D
)
Authent
i
cat
i
on
S

erv
i
ce
S
i
nce pr
i
vacy contro
l

i
s
b
ase
d
on use
r
an
d

l
ocat
i
on acqu
i
s
i
t
i
on

i
s from
d
ev
i
ce
,
t
h
e
p
a
i
r of U
/
D s
h
ou
ld

b
e comp
l
ete
l
y aut
h
ent
i
cate

d
to avo
id
po
t
ent
i
a
l

di
sc
l
osure o
f

p
r
i
vac
y

i
nformat
i
on. U
/
D aut
h
ent

i
cat
i
on serv
i
ce prov
id
e
s t
h
e U
/
D mapp
i
n
g

i
nformat
i
on accor
di
n
g
to t
h
e open U
/
D a
u

t
h
ent
i
cat
i
on API
d
ef
i
ne
d

i
n t
h
e s
y
stem.
N
ote t
h
at t
h
ere
i
s no concrete
i
mp
l

em
e
ntat
i
on for
U/
D aut
h
ent
i
cat
i
on serv
i
ce
i
n
l
ocation server. The service is im
p
lemented in a domain-s
p
ecific or solution
-
s
pecific wa
y
. For example, it can be implemented based on the enterprise
1
3 Locat

i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 319
e
mplo
y
ee database for an enterprise location-aware s
y
stem, or on the user profile
repository for mobile operators to deploy LBS applications.
Pr
i
vacy
S
erv
i
ce
In
di
scr
i
m
i

nate use of
l
ocat
i
on
i
nformat
i
on for peop
l
e can
i
nfr
i
n
g
e peop
l
e’s
p
r
i
vac
y
. T
h
erefore, f
i
ne-
g

ra
i
ne
d
access contro
l
to
l
ocat
i
on
i
nformat
i
on
i
s
n
ecessar
y
. Privac
y
service provides the privac
y
protection mechanism based on
role-based access control (RBAC) model with
t
im
e
an

d
l
oc
ati
o
n
co
n
s
traint
s.
A
use
r
c
an
de
t
e
rmin
e

w
h
o

c
an a
ccess
t

o

w
hat l
oc
ati
o
n inf
o
rmati
o
n
u
n
de
r
w
hi
c
h
circumstances.
C
ache
S
erv
i
ce
Th
e
l

ocat
i
on acqu
i
s
i
t
i
on
i
s a t
i
me- an
d
resource-consum
i
n
g
process; so t
h
e cac
h
e
s
erv
i
ce
i
s
i

ntro
d
uce
d
to acce
l
erate t
h
e respons
i
veness. T
h
e
g
oa
l
of cac
h
e serv
i
ce
i
s
to maximize the usa
g
e of available l
oc
ati
o
n inf

o
rmati
o
n
u
n
d
e
r the cachin
g
strate
gy

to reduce the consumption of s
y
st
em resource and im
prove performance.
m
m
F
low Control Service
Flow control service
p
revents location server from traffic congestion and assures
a

f
air play among applications. There are two kinds of constraints: a
pp

lication-
i
n
d
epen
d
ent constra
i
nt, suc
h
as t
h
emax
i
mum concurrence requests’
li
m
i
t, an
d

app
li
cat
i
on-
d
epen
d
ent constra

i
nt, suc
h
as t
h
e max
i
mum num
b
er of requests
allowed within the
g
iven period of time and the minimum interval amon
g
consecutive successful requests. B
y
supportin
g
effective and efficient flow
control, location server could avoid DOS-like
(
denial of service
)
attack and
resource overspending.
Bi
ll
i
n
g

S
erv
i
ce
B
illi
n
g
serv
i
ce
i
s a spec
i
a
l

l
o
ggi
n
g
serv
i
ce to fac
ili
tate
billi
n

g
for
l
ocat
i
on serv
i
ces.
It
l
o
g
s
d
eta
il
e
d

d
ata re
l
ate
d
to request
/
response
i
nto output f
il

es from w
hi
c
h

necessar
y

i
nformat
i
on can
b
e extracte
d

by
var
i
ous
billi
n
g
en
g
i
n
es
t
o

co
n
duc
t
char
g
e and
g
enerate billin
g
report.
Reverse Geocoding Service
Reverse geocoding defines the interface to map the raw location data to
a

normalized and meaningful symbolic address like city, street, zipcode, etc.
C
onsequent
ly
, t
h
ere are two t
y
pes of reverse
g
eoco
di
n
g

. One
i
s a common process
t
h
at prov
id
es
d
oma
i
n-
i
n
d
epen
d
ent reverse
g
eoco
d
i
n
g
, e.
g
., at t
h
e c
i

t
y
or countr
y

l
eve
l
, an
d
anot
h
er
i
s app
li
cat
i
on-
s
p
ec
i
f
i
c process, w
hi
c
h
prov

id
es
d
oma
i
n
-
dependent reverse
g
eocodin
g
, such as for an enterprise or office buildin
g
. The
3
20 Y. Chen and D. Liu
i
m
p
lementation for this service can eithe
r

b
e self-develo
p
ed or a wra
pp
er for third-
p
arty reverse-geocoding modules.

13.3.3 Location APIs
L
ocation server addresses the
m
o
deling issue by defini
n
g a common open location
model, including geolocation, address,
t
imestam
p
, and a
pp
lication-s
p
ecific
i
nformat
i
on. T
h
e
l
ocat
i
on
i
nformat
i

on
b
a
s
e
d
on t
hi
s mo
d
e
l
a
d
apts to var
i
ous
p
os
i
t
i
on
i
ng tec
h
n
i
ques an
d

covers
all

i
nformat
i
on nee
d
e
d

b
y app
li
cat
i
on.
Two
ki
n
d
s of query mo
d
es are supporte
d
: query an
d
su
b
scr

i
pt
i
on. In t
h
e query
mode, the location of tar
g
et ob
j
ect
cou
l
d

be

se
nt t
o
the requester immediatel
y
. In
the subscri
p
tion mode,
t
he locations of tar
g
et ob

j
ect are sent to the requester in a
s
pecified interval. Two sets of primitive messages’
a
re defined for the modes, the
query service primitive messages’ set and the subscribe
s
ervice
p
rimitive
messages set. Each set includes several pri
m
i
tive messages that describe the
i
nteract
i
on pattern
b
etween t
h
e requestor an
d
t
h
e requestee
(l
ocat
i

on server
)
.
Base
d
on t
h
e two core serv
i
ces an
d
correspon
di
ng pr
i
m
i
t
i
ve messages,
i
t
i
s easy to
support
di
fferent
i
n
d

ustry stan
d
ar
d

l
ocat
i
on APIs suc
h
as WAP an
d
LIF
b
y
mappin
g
them to core services at location server. For example, WAP immediate
quer
y
service and deferred quer
y
service are mapped to quer
y
service an
d

subscribe service, respectivel
y
.

13.3.4 Positioning Technology
T
he foundation for LBS is retrieving the location information of the target moving
object using various location determination
methods. Based on the scope of the
n
moving object, there are two kinds of
l
ocating method, indoor positioning for
determining location in building and outdoor
positioning for determining location out
r
of
b
u
ildi
ng. T
h
ere are
l
ots of
i
n
d
oor pos
i
ti
on
i
ng met

h
o
d
s
b
ase
d
on
di
fferent, most
ly

p
ropr
i
etary, met
h
o
d
s for
l
ocat
i
ng o
bj
ects, suc
h
as us
i
ng w

i
re
l
ess LAN
i
nc
l
u
di
ng
access
p
oints (AP) to which the mobile de
v
i
ces associates, active bad
g
e that can be
s
ensed b
y
stationar
y
sensors and positionin
g
based on Bluetooth. Indoor positionin
g

normall
y

achieves more accurate location data than outdoor, the precision of the
location positioned by indoor positioning met
hod is normally less than 10 m, even
t
t
l
ess than 1 m. Traditional outdoor positionin
g
method is global positioning system
(GPS), which was developed by the US Navy
for military purpose and now is used
y
wor
ld
w
id
e for var
i
ous c
i
v
il
purposes, suc
h
as roa
d
ass
i
stance an
d

a
i
r nav
i
gat
i
on.
N
orma
ll
y GPS can ac
hi
eve 10–30 m
a
ccuracy; us
i
ng
di
fferent
i
a
l
GPS tec
h
no
l
ogy
(DGPS) can achieve more accurate location with 1–10 m.
I
n t

y
pical LBS application, mobile users or
m
ovin
g
ob
j
ects are located in a
mobile network, e.
g
., GSM and CDMA, where t
y
pical approaches are cell of ori
g
i
n

(COO), time of arrival (TOA), angle of arrival (AOA), enhanced observed time
difference
(
E-OTD
)
, and assisted GPS
(
AGPS
)
. Based on
t
he location of positioning
mechanism, there are three modes, handset based, network based, and mixed mode.

13 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 321
In the handset-based mode, the handset or device
g
ets necessar
y
information from
the network and calculates the location data, the network-based mode calculates the
l
ocation data from data collected fr
o
m
network e
q
ui
p
ment, and the mixed mode
de
p
ends both on handset and network to estimate the location data.
C

ell of Ori
g
in (COO)
C
OO uses the network base station cell
a
rea to identif
y
t
h
e
l
oc
ati
o
n
o
f th
e

c
all
e
r
.
T
he accurac
y
depends upon the cell area and the accurac
y

can be up to 150 m fo
r

an urban area. COO is network based. Althou
g
h the accurac
y
is not hi
g
h and
cannot be applied for emergency usage, it is popular amongst the operators as it
does not require any modifications in t
h
e handset or the network
,
hence it is
comparatively cheap to deploy.
Time of Arrival (TOA)
Here the difference in the TOA of the si
g
nal from the mobile to more than one
b
a
se

s
tati
o
n i
s

used
t
o

c
al
cu
lat
e
th
e
l
oc
ati
o
n of the device. This needs s
y
nchro
-
nization of cellular network usin
g
GPS or atomic clock at each base station. The
cell sites are fitted with location measurement
u
nits (LMUs). By measuring the
s
ignal from the mobile phone, the
L
MUs can triangulate the user’s position. TOA

i
s also network based and can achieve more accurate
p
osition than COO but it is
more expens
i
ve
b
ecause of t
h
e
l
ar
g
e num
b
er of LMUs requ
i
re
d
.
An
g
le of Arrival (AOA)
T
his method uses multi
p
le antennas a
t

a

b
a
se

s
tati
o
n t
o

de
t
e
rmin
e
th
e
in
c
i
de
nt
an
g
le of an arrivin
g
si
g

nal from the
m
ob
il
e

dev
i
ce.
Th
e
inf
o
rmati
o
n
o
f t
wo

b
a
se
s
tations allows to calculate the
p
osition of
t
he mobile device. This techni
q

ue is
very sensitive for multipath signals, which hav
e
to be accounted for. Installing an
d

aligning antenna arrays on base
s
tations can be a sensitive and costly process. The
networ
k
-
b
ase
d
A
O
A
could
a
chieve
t
he
a
ccu
r
ac
y
o
f

100–200 m.
Advanced Forward Link Trilateration (A-FLT)
T
his method of location is uni
q
ue to code division multi
p
le access (CDMA)
networks, since the
y
are inherentl
y
s
y
nchronous in their o
p
eration. It measures the
p
hase delay between signals sent to a pair of base stations and then compares this
to the same data taken from another
p
air. Data of three base stations can be used to
p
ositively locate a mobile device. The accuracy is from 50 to 200 m.
E
nhanced Observed Time Difference (E-OTD)
E
-OTD s
y
stems operate

by
p
l
ac
i
n
g

l
ocat
i
on rece
i
vers, over
l
a
id
on t
h
e ce
ll
u
l
ar
network as a LMU at multi
p
le sites
g
eo
g

raphicall
y
dispersed in a wide area. Each
of these LMU has an accurate timin
g
source. When a si
g
nal from at least three
3
22 Y.
Ch
en an
d
D. L
i
u
b
ase stations is received b
y
an E-OTD software-enabled mobile and the LMU, the
time differences of arrival of the signal from each BTS at the handset and the
L
MU are calculated. The differences in time are combined to produce intersecting
hyperbolic lines from which the l
o
c
ation is estimated. E-OTD schemes offer
g
reater pos
i

t
i
on
i
ng accuracy t
h
an COO,
be
t
ween 50 an
d
125 m
,

b
ut
h
ave a s
l
owe
r

s
pee
d
of response, typ
i
ca
ll
y aroun

d
5 s, a
n
d
requ
i
re software mo
di
f
i
e
d

h
an
d
sets.
E-OTD is handset based and requires net
work modification. An example of an
t
t
E
-OTD s
y
stem is the Cambrid
g
e positionin
g
s
y

stems (CPS) Cursor™ s
y
stem.
O
bserved Time Difference of Arrival (OTDOA)
It is similar to E-OTD but may provide lower yield (percentage of successful
p
osition determinations) and operates only on UMTS networks. The accuracy is
f
rom 50 to 200 m.
Assisted Global Positionin
g
S
y
stem (AGPS)
AGPS relies on wireless devices that have an inte
g
rated GPS receiver.
A
ss
i
s
tan
ce

d
ata
c
an
be

tran
s
mitt
ed
fr
o
m th
e
n
e
twork to expedite the GPS si
g
nal
s
earch and possibly improve sensitivity.
T
he network sends GPS information it
has
p
icked u
p
to the mobil
e
handset
,
which uses this information to detect GPS
s
ignals from the satellites. The mobile handset then returns data about the
sig
na

l
s
i
t rece
i
ve
d
to t
h
e networ
k
, w
h
ere
i
t
i
s use
d
to compute t
h
e
h
an
d
set’s
l
ocat
i
on.

Si
nce t
h
e ca
l
cu
l
at
i
on of t
h
e exact
p
os
i
t
i
on
i
s
d
one w
i
t
hi
n t
h
e networ
k
,

t
h
e
h
an
d
set
d
oes not nee
d
to
b
e comp
l
ex an
d
expens
i
ve. T
h
e m
i
xe
d
mo
d
e-
b
ase
d

AGPS can be accurate u
p
to 10 m.
13.4 Moving Objects Databases
C
AMEL is a hi
g
h-performance en
g
ine mana
g
in
g
location stream to support quer
y
,
tracking, and intelligent notification components in LORE operation semantic
domain. These components are typically from requirements of building next
-
g
eneration intelligen
t
location-aware services. CAMEL tak
e
s a MOD a
pp
roac
h

t
h
at not on
l
y stores
hi
s
t
or
i
ca
l
an
d
current
l
ocat
i
on
i
nfor
m
a
t
i
on of mo
bil
e users
,

b
u
t

a
l
so pre
di
cts t
h
e future
l
ocat
i
ons of a user. In a
ddi
t
i
on
,
t
h
e
hi
stor
i
ca
l

i

nformat
i
on
captured in CAMEL can be used by a data
mining tool to discover mobility
a
p
atterns. Fi
g
ure 13.3 illustrates the overall architecture for CAMEL. CAMEL is
com
p
osed of several com
p
onents that can
b
e ph
y
sicall
y
distributed in differen
t

network nodes, which communicate with
e
ach other using standard protocols and
i
nterfaces such as TCP/IP, HTTP, and JDBC. CAMEL com
p
onents include

l
ocation listener (LL), query eng
i
ne (QE), location filter (LF), trigger handle
r

(
TH
)
,
d
ata server
(
DS
)
,
d
ata
b
ase
(
DB
)
, an
d
a
d
m
i
n conso

l
e
(
CON
)
. T
h
e
di
str
ib
ute
d

component
b
ase
d
arc
hi
tecture not on
l
y ma
k
es t
h
e system ro
b
ust
b

ut a
l
so fac
ili
tates
13 Location-Aware Services and its Infrastructure Su
pp
ort 323
the easy deployment of CAMEL in different
environments. In this section we
t
briefly introduce the components.
F
ig
. 13.3
.
CAMEL – The movin
g
ob
j
ect database architecture
13
.
4
.
1
Database
T
he DB com
p

onent is the heart of CAME
L
, and it serves not onl
y
as the location
data stora
g
e but also as the re
g
istr
y

a
nd confi
g
uration repositor
y
. The re
g
istr
y
is
used by the system to record component
running information, such as host
t
address, port number, and running status. When starting up, each componen
t

registers in the registry its host address and port information through which othe
r

d
epen
d
ent components can f
i
n
d

i
t. T
h
e conf
i
gurat
i
on repos
i
tory
i
s a centra
l
repos
i
tory for a
ll
components to store c
o
m
ponent-spec

i
f
i
c parame
t
e
rs. T
h
e reg
i
str
y

an
d
conf
i
gurat
i
on repos
i
tor
i
es ma
k
e
th
e system more f
l
ex

ibl
e an
d
managea
bl
e.
Locat
i
on
d
ata of eac
h
mov
i
n
g
o
bj
ect at c
h
ec
k
p
o
i
nt t
i
m
e
ar

e

s
t
o
r
ed

i
n an
o
bj
ect c
h
ec
k
po
i
nt ta
bl
e
(
OCT
)

i
n t
h
e DB. OCT recor
d

s t
h
e
hi
stor
i
ca
l

i
nforma
-
t
ion of a moving object and is used for historical queries and data mining. For
e
xample, the query “Please give the trajectory of object A from time t1 to t
2
”
DB
L
ocatio
n
F
il
t
e
r
Trigge
r
H

an
dler
Data
S
erve
r
N
N
NO
D
E
J
DB
C
L
ocat
i
on L
i
stener
Q
uery Eng
i
ne
TCP,UDP
,
HTTP
,
UDP
,

Web Service
A
d
min
C
onsole
CA
MEL
Applicatio
n
Location Publish
ion
ion
Protocol (LPP)
o
c
o
oco
L
ocation
S
trea
m
Notification
3
24 Y. Chen and D. Liu
can be answered b
y
functions:
t

ra
j
ector
y
(select location
f
rom OCT, where oid = A
and

t1
<
=
t
<
=
t2
)
.
1
3.4.2 Location Listener
L
L accepts location reports from reporters, such as the trackin
g
server or self
-
p
ositionin
g
devices, usin
g

a location
p
u
blish
p
rotocol (LPP) based on HTTP. An
y

authenticated re
p
orter can send location re
p
orts to LL via LPP. For
p
erformance
reason, a location re
p
ort
p
rotocol that
u
ses Java-object serialization over UDP is
also supported by LL and facilitates Java-based CAMEL a
pp
lications. U
p
on
rece
i
v

i
ng a
l
ocat
i
on report, LL propagates
i
t us
i
ng IP mu
l
t
i
cast to ot
h
er reg
i
stere
d

l
ocat
i
on rece
i
vers t
h
at
h
ave reg

i
stere
d
t
h
emse
l
ves w
i
t
h
LL at start-up. Potent
i
a
l

l
ocat
i
on rece
i
vers are LF, TH, an
d
DS. T
h
e presence of LL ma
k
es
i
t easy to a

dd
new com
p
onents (location receivers) into t
h
e s
y
stem as well as prevent incomplete
o
r in
v
ali
d
l
oc
ati
o
n
d
ata from enterin
g
s
y
stem.
1
3.4.3
Q
uer
y
En

gi
ne
QE
i
s t
h
e ma
i
n
i
nterface for
i
ssu
i
n
g
quer
i
es over mov
i
n
g
o
bj
ects. Current
ly
, t
h
e
f

o
ll
ow
i
n
g
t
y
pes of quer
y
are supporte
d
:
1.
GetLocat
i
on – Get
l
ocat
i
on of an o
bj
ect at a spec
i
f
i
e
d
t
i

me.
2
.
W
indow Query – Get objects that are within a s
p
ecified distance from a
s
pecified object.
3
. KNN – Get the k nearest objects relative to a specified object.
4
.
T
r
i
gger – Sen
d
a not
i
f
i
cat
i
on w
h
en t
h
e
l

ocat
i
on of a spec
i
f
i
e
d
o
bj
ec
t

meets a pre
d
ef
i
ne
d
con
di
t
i
on.
5
.H
i
stor
i
ca

l
query.
Th
e QE exposes
i
ts
i
nterface us
i
n
g
We
b
s
erv
i
ces tec
h
no
l
o
gy
an
d
t
h
e quer
y

s

upporte
d

i
s represente
d

by
WSDL. QE f
o
r
war
d
s some t
y
pe of quer
y
us
i
n
g
TCP to
underl
y
in
g
components,
s
uch as TH and DS.
1

3.4.4 Location Filter
A
high
arr
i
va
l
rate of
l
ocat
i
on report
s
from
l
ocat
i
on reporters
i
ntro
d
uces two
difficulties: DB insertion of location data ma
y
become a bottleneck, and there is
a

p
ossibilit
y

of redundant location data. LF is desi
g
ned to filter incomin
g
location
d
ata t
o
r
educe
th
e
l
oc
ati
o
n
s
tr
e
am
w
hile
g
uaranteein
g
its qualit
y
. LF is
i

mp
l
emente
d
as a
l
ocat
i
on rece
i
ver of LL an
d

i
t wr
i
tes t
h
e f
il
tere
d

lo
c
at
i
on
i
nto t

h
e
OCT DB ta
bl
e. CAMEL
i
mp
l
ements severa
l

fil
ter a
l
gor
i
t
h
ms t
h
at typ
i
ca
ll
y re
d
uce
t
h
e or

i
g
i
na
l

l
ocat
i
on stream
b
y
6
0–80
%
w
hil
e ma
i
nta
in
i
ng reasona
bl
e
l
ocat
i
on
accurac

y
.
1
3 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 325
1
3.4.5 Trigger Handler
Spatial trigger is a very important kind of
query in a MOD and the base for push-
f
b
ased services in LBS. In CAMEL, trigge
r

Tr
is defined by a tuple
r
Tr
= (
r
SP,

Sin
k
), where
k
k
SP
is a spatial predicate with location variables and
P
Sink
is the access
k
p
oint of the notification receiver w
h
en the trigger is fired. Currently fou
r
Sin
k
types are supporte
d
: HTTP, TCP
,
UDP
,
an
d
conso
l
e t
h

at
o
n
l
y pr
i
nt t
h
e not
i
f
i
cat
i
on
on t
h
e stan
d
ar
d
output. W
h
en a
l
ocat
i
on arr
i
ves

,
TH eva
l
u
a
t
es
i
t aga
i
nst t
h
e
d
ef
i
ne
d
tr
i
ggers
i
n t
h
e system
(bi
n
di
ng t
h

e
l
ocat
i
on to t
h
e pre
di
cate
)
to c
h
ec
k

i
f
it

s
atisfies an
y
tri
gg
er predicate. If one tri
gg
er is satisfied, the notification alon
g
with
the tri

gg
ered location is sent to the sink d
e
fined in the tri
gg
er. TH is implemented
as a location receiver of LL and it supports tri
gg
er operations CREATE
T
RIGGER and DROP TRIGGER. In Sect. 13.5 we discuss spatial triggers in more
detail and how it can support spatial pub/sub engine.
1
3.4.6 Data
S
erver
As mentioned earlier, CAMEL su
pp
orts historical, current, a
n
d
future location
q
ueries. In
p
ractice, most
q
ueries are related to the current lo
c
ation of objects, fo

r

e
xamp
l
e,
k
NN an
d

wi
n
d
ow query, an
d
requ
i
res rea
l
t
i
me process
i
ng. DS
i
s
respons
ibl
e for process
i

ng quer
i
es concern
i
n
g
current
l
ocat
i
ons on
l
y, w
hi
c
h

i
s t
h
e
most common query
i
n
l
ocat
i
on aware se
r
v

i
ces. To
i
mprove t
h
e performance of
t
h
e quer
y
re
l
ate
d
to current
l
ocat
i
on an
d
avo
idi
n
g
access to DB, a ma
i
n memor
y
s
naps

h
ot of mov
i
n
g
o
bj
ects
i
s use
d
to mana
g
e curre
n
t
l
ocat
i
ons. More spec
i
f
i
ca
lly
,
t
h
e snaps
h

ot stores t
h
e
l
atest
l
ocat
i
on
s
from reporters
i
nstea
d

o
f
cu
rr
e
nt
loc
at
io
n
s

of moving objects. The snapshot is organized as a spatial index that accelerates the
p
rocessing of some queries like window query and kNN query. Meanwhile, the

sp
atial index is re
q
uired to sustain high-performance updates and lookups because
of t
h
e
hi
g
h
arr
i
va
l
rate of
l
ocat
i
o
n

d
ata. After compar
i
ng severa
l
spat
i
a
l

i
n
d
ex
methods, making a trade-off
between updating and searching, and taking the main
f
memory c
h
aracter
i
st
i
c
i
nto cons
id
erat
i
on, CAMEL emp
l
oys a gr
id

i
n
d
ex as
i

ts
s
naps
h
ot
i
n
d
ex
i
n
g
mec
h
an
i
sm. T
h
e ma
i
n reason
i
s t
h
at t
h
e
i
n
d

ex sca
l
es up we
ll

un
d
er
high
up
d
ate rates an
d

h
as a c
l
ean
i
mp
l
ementat
i
on w
i
t
h

g
oo

d
performance
i
n
s
earc
hi
n
g

i
n ma
i
n memor
y
, w
hil
e an R
-
t
ree an
d

i
ts var
i
at
i
ons suffer from frequen
t

i
ndex entr
y
splittin
g
and mer
g
in
g
. Don
g
seop Kwon [5] proposed a laz
y
update
R-tree (LUR-tree) to reduce u
p
dates in R-tree. It is, however, based on continuous
mo
d
e
l
t
h
at requ
i
res pre
d
ef
i

ne
d

m
ov
i
ng pattern
lik
e spee
d
.
O
ne cons
id
erat
i
on
i
s w
h
et
h
er
C
AMEL w
ill

be
set up
i

n a reg
i
on w
i
t
h
a
l
arge
area, or severa
l
sma
ll
a
d
m
i
n
i
strat
i
on reg
i
o
n
s
. An examp
l
e of t
h

e
l
atter
i
s Be
iji
ng, a
l
ar
g
e c
i
t
y
compose
d
of severa
l

di
str
i
cts. For sca
l
a
bili
t
y
an
d

l
oa
d

b
a
l
anc
i
n
g
, DS
i
s
designed with a distributed architect
ure where new components, NODEs, are
t
t
a
dd
e
d
to
h
an
dl
e t
h
e mov

i
n
g
o
bj
ects t
h
at
b
e
l
on
g
to eac
h
re
gi
on. T
h
e use of NODEs
b
rin
g
s new issues like distribute
d
quer
y
processin
g
and mobile ob

j
ec
t

mi
g
ration/roamin
g
. In addition, new
m
echanisms, such as distributed quer
y

mana
g
er and roamin
g
mana
g
ers, are also introduced in DS.
3
26 Y.
Ch
en an
d
D. L
i
u
13.4.7 Admin Console
C

ON is a text interface console used to confi
g
ure and monitor other components
i
n system. The conso
l
e reads runtime information from the DB and connects to the
various com
p
onents. In addition, the user can use the console to issue
q
ueries an
d

use it as a testing tool.
13.5 Spatial Publish/Subscribe Engine
S
patial Pub
/S
ub Mana
g
e
r
S
p
atia
l
M
atc
hi

n
g
En
g
in
e
L
ocat
i
on
A
gent
C
ontrolle
r
M
oD Tri
gg
e
r
H
an
dl
e
r
Mob
il
e
L
ocat

i
o
n
A
gen
t
Mob
il
e
L
oca
ti
o
n
A
gent
XML
XML
X
M
L
JMS
AP
I
Privac
y
M
anage
r
Z

on
e
Definition
E
ngine
Z
DE API
P
r
i
vacy
AP
I
Zo
n
e
R
epos
i
tor
y
Fig. 13.4. Spatial pub/sub engine architecture
W
i
t
h
t
h
e su
pp

ort of
l
ocat
i
on server an
d
MOD, LBS cou
ld

b
e
d
e
li
vere
d
to su
pp
or
t

a
pplications such as location-aware
y
ellow pa
g
es, road assistance, and trackin
g
.
S

pat
i
a
l
pu
b/
su
b
eng
i
ne
b
r
i
ngs r
i
c
h

lo
c
at
i
on operat
i
on semant
i
c an
d
new use

r

exper
i
ences
by
ena
bli
n
g
act
i
ve messa
gi
n
g
pus
h

b
ase
d
on users’ su
b
scr
i
pt
i
on. I
n

t
hi
s sect
i
on, t
h
e spat
i
a
l
pu
b/
su
b
en
g
i
ne to su
pp
ort
i
n
t
e
llig
ent not
i
f
i

cat
i
on
c
omponent of the LORE model is describ
e
d. The architecture of the engine is
ill
ustrate
d

i
n F
i
g. 13.4. T
h
e eng
i
ne a
d
opts a nove
l
c
li
ent-s
id
e event process
i
ng
a

pproac
h
to
i
mprove performance
by
e
li
m
i
nat
i
n
g
server s
id
e-comput
i
n
g
cost. T
h
e
m
obile location agent, cooperating with location agent controller, implements the
r
ole of location-aware agent in LORE model. The key components include spatial
pu
b/
su

b
mana
g
er, spat
i
a
l
matc
hi
n
g
en
gi
ne, zone
d
ef
i
n
i
t
i
on en
gi
ne,
l
ocat
i
on a
g
en

t

c
ontroller, and mobile location a
g
ent.
13
.5.
1
Models
T
h
e mo
d
e
l
s a
d
opte
d

by
pu
b/
su
b
en
gi
ne
i

nc
l
u
d
e sp
a
t
i
a
l
event mo
d
e
l
, spat
i
a
l
su
b
scr
ip
t
i
on mo
d
e
l
, an
d

not
i
f
i
cat
i
on mo
d
e
l
.
1
3 Location-Aware Services and its Infrastructure Su
pp
ort 327
S
p
atial Event Model
A spatial event is described by a set of properties specified by name–value (NV)
p
airs. The three mandatory prope
r
ties for a s
p
atial event are:
•
O
bj
ect
id

ent
i
f
i
er
(
OID
)

i
s a un
i
que
id
e
nt
i
t
y

i
n
di
cat
i
n
g
t
h
e owner of t

h
e
l
ocat
i
on. T
h
e o
bj
ect
i
s a person, a
d
ev
i
ce, or an
y
t
hi
n
g
t
h
at can
b
e
loc
at
ed.

•
T
imestamp (TS) is the time when the ob
j
ect is positioned.
•
L
ocation (LOC) is the
g
eo
g
raphical location specified b
y
predefine
d

s
patial reference s
y
stem (SRS) or textual descri
p
tion of location that
could be translated into geogra
phical location via geocoding.
a
a
These three properties describe the most im
portant three dime
m
m

ns
i
ons perta
i
n
i
ng to
a spat
i
a
l
event: w
h
o, w
h
en, an
d
w
h
ere. Ot
h
er opt
i
on
a
l
propert
i
es cou
ld

a
l
so
b
e
i
ntr
oduced
t
o
fa
cili
tat
e
t
he
process
i
n
g
of spat
i
a
l

e
vents
,
suc
h

as:
•
Uncertainty
(UNC), which describes the
y
u
ncerta
i
nt
y
of t
h
e
l
ocat
i
on
de
t
ec
t
ed.

•
Location provider identifier
(LPID), which is the
pr
r
o
vider of the

l
ocation information.
Bes
id
es t
h
e pre
d
ef
i
ne
d
man
d
atory an
d
o
p
t
i
ona
l
names for propert
i
es, ot
h
er
p
ropert
i

es cou
ld

b
e attac
h
e
d
to t
h
e
s
pat
i
a
l
event to
d
escr
ib
e
d
oma
i
n- or
app
li
cat
i
on-spec

i
f
i
c
i
nformat
io
n
. Usua
ll
y t
hi
s
i
nformat
i
on
i
s
i
nten
d
e
d
for t
h
e
s
u
b

scr
i
pt
i
on app
li
cat
i
on an
d

i
s
n
ot processe
d

by
t
h
e pu
b/
su
b
en
gi
ne.
S
pat
i

al
S
ubscr
i
pt
i
on Model
S
p
atial subscri
p
tions are u
s
ed b
y
subscribers for expressin
g
their interests o
n
sp
atial events. In the
s
patial pub/sub s
y
stem, a spatial subscri
p
tion is defined as
tup
l
e

(
SP
,
T
o
S
), where
S
S
SP
is spatial predicate defined upon location of objects and
P
To
S
is a type of services that are discus
S
se
d

l
ater. T
h
e semant
i
c for a spat
i
a
l
su
b

scr
i
pt
i
on
i
s:
a
notification (base
d
on notification mo
d
el
)
is sent to a subscribe
r

when an incomin
g
spatial event (based on spatial event model) meets SP and ToS
r
equirement
.
Current
ly
two
ki
n
d
s o

f

SP
are supported in the spatial pub/sub
P
sy
s
t
em:
•
W
it
h
i
n
pre
di
cate
h
as t
h
e s
y
ntax
(
oid-1
,
oid-2
,
…

,
oid-n) within (zone-1
,
z
one-2
,
…
,
zone-n
)
. T
h
e pre
di
cate
i
s true
i
f an
d
on
ly

i
f one of t
h
e
l
ocat
i

ons of t
h
e mo
bil
e user
(
oid-i
)

i
s w
i
t
hi
n one of t
h
e zones
(
zone-
j
)
.
A
zone is used to re
p
resent an interested re
g
ion. Subscription usin
g
“

within”
p
redicate can be used to su
pp
ort services like “Please send
me e-coupon w
hil
e I am near ABC s
h
opp
i
ng ma
ll
.”
•
D
istanc
e
pre
di
cate
h
as t
h
e syntax (oid) distance (
D
,
oid-1
,
oid-

2
,

…
,
oid-n). The
p
redicate is true if an
d
onl
y
if distance between
oid
and
d
oid
-
i

(
1
,
…
,
i
,
…
.
n
) is less than

D
.
Subscription usin
g
distance tri
gg
er
can su
pp
ort services like
m
o
bile buddy list thro
u
gh which a user can
d
efine his buddy list and ask for an aler
t
when any of hi
s
buddy is near
to
hi
m.
3
28 Y. Chen and D. Liu
T
h
e
t

wo
S
Ps discussed here could meet a lar
g
e amount of requirement of location-
aware applications, and we are investigating other
S
Ps for constructing more
com
p
lex location-aware a
pp
lication. Traditional pub/sub sys
t
ems are based on the
“publish-match-notify” operational cycle, therefore, a spatial event is always sen
t

to su
b
scr
ib
ers w
h
en a s
p
at
i
a
l

su
b
scr
i
pt
i
on
i
s sat
i
sf
i
e
d

b
y t
h
e event. In t
h
e contex
t

of
l
ocat
i
on-aware app
li
cat

i
ons,
h
owever, t
h
e event f
il
ter mec
h
an
i
sm cou
ld

s
omet
i
mes confuse t
h
e user. For examp
l
e, a user
d
ef
i
nes a “w
i
t
hi
n” su

b
scr
i
pt
i
on
“
(oid1) within (zone1
)
”
, where z
one1
is the predefined area of a shoppin
g
mall.
When the user (
oid
1
) enters the zone (
zone
1
(
(
)
, he receives a promotion messa
g
e.
T
he within subscri
p

tion is alwa
y
s evaluated to be true when the user sta
y
s in the
shopping mall, so that he continuously receives the promotion message. Obviously
i
n this case only one promotion message makes sense both to the user and the
promot
i
on prov
id
er. One-t
i
me semant
i
c of su
b
scr
i
pt
i
on spec
i
f
i
e
d

b

y
ToS
is
S
i
ntro
d
uce
d
to guarantee t
h
at t
h
e user rece
i
ves on
l
y one promot
i
on message. W
hil
e
th
e To
S
is set to once, one-time semantic
S
of su
b
scr

i
pt
i
on
i
s app
li
e
d

b
y spat
i
a
l

m
atc
hi
n
g
en
gi
ne.
Notification Model
Notification takes the same NV
p
airs’ format as event model and includes two
p
ar

t
s:
•
O
riginal event part copied from the event information.
•
S
u
b
scr
i
pt
i
on-spec
i
f
i
c part
d
er
i
ve
d
from t
h
e process of matc
hi
n
g
su

b
scr
i
pt
i
ons w
i
t
h
events.
13.5.2 Spatial Pub/Sub Mana
g
er
T
h
e pu
b/
su
b
manager manages event su
b
scr
i
pt
i
on
/
pu
bli
s

h
an
d
exposes Java
m
essag
i
ng serv
i
ce
(
JMS
)
[6]
i
nterface. Message se
l
ectors from JMS are
e
xtended to support spatial subscription whose s
y
ntax is based on a subscription
m
odel. For a subscription request, privac
y
check should be done first. Instead o
f

f
orwardin

g
all subscriptions to spatial matchin
g
en
g
ine, the pub/sub mana
g
er
e
x
p
loits the semantic of the subscri
p
tions and sends “within” subscri
p
tions to a
location agent controller. As a result, the workload of spatial matching engine is
relieved.
13.5.3
S
pat
i
al Match
i
ng Eng
i
ne
The matching engine takes charge of filtering spatial events. For achieving high
performance in spatial matching, the engine uses spatial index technique to
a

cce
l
erate t
h
e matc
hi
ng process. For “w
i
t
hi
n” pre
di
cate, R-tree
i
s emp
l
oye
d
to
i
n
d
ex pre
d
ef
i
ne
d
zones
b

ase
d
on t
h
e
ir

mi
n
i
mum
b
oun
di
ng rectang
l
e
(
MBR
)
an
d

t
ransform su
b
scr
i
pt
i

on eva
l
uat
i
on to R-tree searc
hi
n
g
. Eac
h
zone ma
i
nta
i
ns a
h
as
h

t
a
ble
t
o
r
eco
r
d
t
he

lis
t
o
f
i
nt
e
r
es
t
ed

us
e
rs.
Wh
en a mo
bil
e user’s
l
ocat
i
on
i
s w
i
t
hi
n

13 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 329
a z
o
n
e
an
d
th
e
m
ob
il
e

use
r i
s
in th
e
h

a
s
h ta
b
l
e

o
f th
e
z
one, a notification is sen
t

out. Distance evaluation involves more
t
han one mobile
u
ser, and the location
cache is provided to store the latest location data of those users and an objec
t

t
rigger graph mechanism is employed to
h
andle the case. Spatial match engine
reuses t
h
e mo
d

u
l
e ca
ll
e
d
TH from t
h
e CAMEL pro
j
e
ct [4]. T
h
e
d
eta
il
e
d

a
l
gor
i
t
h
ms an
d
performance compar
i

son can
b
e foun
d

i
n [4]. T
h
e resu
l
t s
h
ows t
h
a
t

th
e matc
hi
ng eng
i
ne
h
as
g
oo
d
performance an
d

sca
l
a
bili
ty.
1
3.5.4 Zone De
fi
n
i
t
i
on En
gi
ne
The zone definition engine (ZDE) is used by
the system administrator and/or end
y
u
sers to
d
ef
i
ne t
h
e we
ll
-
k
nown zone of

i
nterest
(
ZOI
)
or user-spec
i
f
i
c ZOI, w
hi
c
h

could be a pol
yg
on (includin
g
rectan
g
le) o
r
a circle. For example, in Bei
j
in
g
, ho
t

p

laces such as Xidan can be predefined in the s
y
stem as a pol
yg
on based on its
g
eographic coordination (latitude, longitude), and each user can define his/her
home according to its geographic location. Predefined ZOI can be referred to in a
s
ystem as a symbol name, like SYSTEM.Xidan or Mike.HOME, where the prefix
SYSTEM stan
d
s for system
d
ef
i
ne
d
ZOI, ot
h
erw
i
se
i
t can
b
e t
h
e name of t
h

e use
r

w
h
o
d
ef
i
nes t
h
e Z
O
I.
Z
DE exposes ZDE API
f
or c
li
ent app
li
cat
i
ons an
d
spat
i
a
l
p

u
b/
su
b
manager to man
i
pu
l
ate zones.
1
3.5.5 Locat
i
on A
g
ent
C
ontroller
Th
e contro
ll
er manages a
ll

m
o
bil
e
l
ocat
i

on agents runn
i
ng on
i
nte
lli
gent
d
ev
i
ces.
It prov
id
es aut
h
ent
i
cat
i
on mec
h
an
i
s
m
for these agents,
m
s
en
d

s re
l
ate
d
spat
i
a
l
s
u
b
scr
i
pt
i
ons to t
h
em, rece
i
ves t
h
e matc
hi
n
g
spat
i
a
l
events from t

h
em, an
d

f
orwar
d
s t
h
ose matc
hi
n
g
events to t
h
e spat
i
a
l
pu
b/
su
b
mana
g
er. W
h
en t
h
e mo

bil
e
user involves “distance”
p
redicates, the controller sends a command of
p
eriodical
l
ocation report to the a
g
ent, receives locations of the mobile user periodicall
y
, an
d

p
asses t
h
em to spat
i
a
l
matc
hi
ng eng
i
ne. T
h
e
i

nterface
b
etween t
h
e contro
ll
er an
d

t
h
e agent
i
s
b
ase
d
on XML.
1
3.5.6 Mob
i
le Locat
i
on A
g
ent
Runn
i
ng on
i

nte
llig
ent
d
ev
i
ces, t
h
e agent f
o
cuses on o
b
ta
i
n
i
ng
i
ts
l
ocat
i
on
i
nformat
i
on from em
b
e
dd

e
d
pos
i
t
i
on
i
n
g
mo
d
u
l
es suc
h
as GPS an
d

h
an
dli
n
g

“
w
i
t
hi

n” pre
di
cates sent
by
t
h
e contro
ll
er. It eva
l
uates spat
i
a
l
pre
di
cates
b
ase
d
on
t
he

cu
rr
e
nt
loc
at

io
n
o
f t
he

m
o
bil
e
d
ev
i
ce. W
h
en a spat
i
a
l

p
re
di
cate
i
s eva
l
uate
d
to

b
e true, the matchin
g
spatial event will
be

se
nt t
o
th
e

co
ntr
o
ll
e
r
.
Al
so
m
ob
il
e

l
ocation a
g
ent can send the location of the mobile device periodicall

y
accordin
g
to
i
n
s
tr
uc
ti
o
n
s
fr
o
m
t
h
e

co
ntr
o
ll
e
r
.

3
30 Y.

Ch
en an
d
D. L
i
u
13.6 Related Works
Th
ere are
l
ots of researc
h
an
d
efforts
b
ot
h

i
n aca
d
em
i
a an
d

i
n
d

ustry on
l
ocat
i
on
-
aware comput
i
n
g
. To our
k
now
l
e
dg
e,
h
owever, none of t
h
em proposes
a

comprehensive framework on buildin
g
location-aware services like the LORE
model. Several se
p
arate works related to
p

artial com
p
onents or domains in the
L
ORE model are introduced in the followin
g
para
g
raphs.
Much research has focused on developing services architecture for location
-
b
ased applications. Building on the acti
v
e badge location technology, researchers
at Olivetti
p
ro
p
osed and develo
p
ed the architecture for a distributed location
s
erv
i
ce [7]. T
h
e O
li
vett

i
system
i
s t
i
e
d
to t
h
e spec
i
f
i
c pos
i
t
i
on
i
ng tec
h
no
l
ogy. ULF
L
eon
h
ar
d
t presents a g

l
o
b
a
l
genera
l

l
ocat
i
on serv
i
ce to support
l
ocat
i
on-awareness
i
n open distributed s
y
stems [8]. He
e
mphasizes the importance of inte
g
ratin
g

various location techniques and depicts a hierarchical, semis
y

mbolic location
model and uses polic
y
-based access control to protect location privac
y
. Althou
g
h
his effort influences our location model, it is short of abundant auxiliary services
to simplify LBS development. The work of
Tom Pfeifer et al. [9] has many
f
as
p
ects in common with our work on locat
i
on server. They introduce a modular
l
ocat
i
on-aware serv
i
ce an
d
an app
li
cat
i
on p
l

atform. T
h
e p
l
atform prov
id
es
mo
d
u
l
ar, un
i
f
i
e
d
access to var
i
ous serv
i
ces, w
hi
c
h
are common
l
y use
d

b
y mu
l
t
i
p
l
e
app
li
cat
i
ons. Its prototype,
h
owever,
i
s
b
ase
d
on CORBA, an
d

l
ess effort
h
as
b
een
made for privac

y
control. Privac
y
is consi
d
e
red to be the critical issue in LB
S
.
A
j
ith K. Nara
y
anan presents the idea of lo
g
i
c
al l
oc
ati
o
n
co
nt
e
x
t
s, which
p
rovides

e
nhanced privac
y
in location-aware mobile computin
g
[10]. His work has helped
us to build an advanced privacy control mechanism.
MOD research addresses the issues of storing and processing continuously
moving objects arising in a wide range of ap
p
lications, including traffic control
an
d
mon
i
tor
i
ng, transportat
i
on
a
n
d
supp
l
y c
h
a
i
n man

a
g
ement,
di
g
i
ta
l

b
att
l
ef
i
e
ld
s,
an
d
mo
bil
e e-commerce [11]. T
h
e p
i
oneer
i
ng wor
k

i
n MOD
i
s from Wo
l
fson a
t

Un
i
vers
i
ty of I
lli
no
i
s
i
n C
hi
cago. In t
h
e
i
r DOMINO prototype [12, 13], t
h
ey
p
ropose
d

t
h
e MOST mo
d
e
l
[14] an
d
FTL quer
y

l
an
g
ua
g
e for mo
d
e
li
n
g
an
d

quer
yi
n
g
mov

i
n
g
o
bj
ects’
l
ocat
i
ons. C
A
MEL s
h
ares t
h
e same
g
oa
l
of mana
gi
n
g

moving objects’ locations and also attempts to manage historical locations o
f

moving objects for furth
e
r use in data mining.

The challenge in MOD is to support dynamic, continuously evolving data an
d

mov
i
ng quer
i
es. As a spat
i
o-tempora
l
DB, MOD manages
d
ata w
i
t
h
spat
i
a
l
an
d

t
empora
l

di
mens

i
ons. To
i
mprove query performance,
i
n
d
ex
i
ng mov
i
ng o
bj
ects
i
s
nee
d
e
d
. Severa
l
met
h
o
d
s of
i
n
d

ex
i
ng mov
i
ng o
bj
ects
(
[15–19]
)

b
ase
d
on R-trees
h
ave
b
een put forwar
d

i
n
li
terature. Two
d
ata mo
d
e
l

s are
i
nvest
ig
ate
d
on
i
n
d
ex
i
n
g

mov
i
n
g
o
bj
ects:
•
C
ontinuous model. Mov
i
n
g
o
bj

ects are mo
d
e
l
e
d
as po
i
nts
i
n MOST t
h
a
t
s
tart moving from a specific location with a
co
n
st
an
t

ve
l
ocity vector.
Some indexing methods, like time-
p
arametrized R-tree (TPR-tree) [17]
and indexing scheme [20], are develo
p

ed based on this model.
1
3 Locat
i
on-Aware
S
erv
i
ces an
d

i
ts Infrastructure Support 331
•
Disc
r
ete

model
.
In this model, onl
y
the locati
o
ns of movin
g
ob
j
ect are
stored in a DB as (LOC, TS) tuples. Pf

oser et al. [16]
f
f
f
urther develo
p
ed
t
he model to describe trajectory segments and proposed two access
methods based on the model: s
p
atial tem
p
oral R-tree (STR-tree) an
d

t
ra
j
ector
y
-Bun
dl
e tree
(
TB-tree
)
to
i
n

d
ex t
h
e
hi
stor
i
ca
l
tra
j
ector
y
o
f

mov
i
n
g
o
bj
ects.
Th
e cont
i
nuous mo
d
e
l

i
mp
li
c
i
t
ly
requ
i
res
th
at mov
i
n
g
o
bj
ects report
b
ot
h
t
h
e
ir

l
ocation and velocit
y

to the location man
a
g
ement s
y
stem. This model is feasible in
areas like vehicle trackin
g
and di
g
ital
b
attlefield where advanced devices e
q
ui
pp
e
d

with GPS receivers can re
p
ort the r
e
quired data to the system. However, in LBS
t
hat serve mobile users, a large portion of the potential customers only have cell
p
hones that have no capacity of self-po
s
i

tioning and require
a
ssistance from the
w
i
re
l
ess networ
k
to
d
eterm
i
ne t
h
e
i
r
l
ocat
i
ons. T
h
us, t
h
e ve
l
oc
i
t

i
es of many mo
bil
e
u
sers are
h
ar
d
to
d
eterm
i
ne
di
rect
l
y
i
n rea
l

li
fe. For t
hi
s reason, CAMEL emp
l
oys
a
di

screte
l
ocat
i
on mo
d
e
l

i
nstea
d
of a
c
ont
i
nuous mo
d
e
l
, an
d

i
t rece
i
ves on
l
y
l

ocation information with TSs from a trackin
g
serve
r

o
r fr
o
m th
e

dev
i
ce
it
se
lf
.
Th
e

i
nherent differences between the two models su
gg
est different wa
y
s to process
q
ueries and to index locations.
G

ryphon [21] and Siena [22] are c
o
ntent-based
p
ub/sub systems. Grypho
n

p
rovided an efficient and scalable filtering algorithm to h
a
n
dle event matching.
S
iena
p
rovided ex
p
ressive subscri
p
tion l
a
n
guage for subscribers to select
i
ntereste
d
events. Bot
h
of t
h

em supporte
d
pr
i
m
i
t
i
ve
da
t
a types w
hil
e our spat
i
a
l
pu
b/
su
b
system can
h
an
dl
e comp
li
cate
d
spat

i
a
l

d
a
t
a type. Ivana Po
d
nar et a
l
.
presente
d
t
h
e arc
hi
tecture to
d
e
li
very content to mo
bil
e users
b
ase
d
on t
h

e
publish/subscriber paradi
g
m [23]. The
i
r publish/subscribe s
y
stem can wor
k

t
o
g
ether with location mana
g
ement to deliver location-aware messa
g
e to mobile
u
sers. However, the spatial pub/sub s
y
stem
p
ro
p
osed in this research focused on
spatial-related information matching and perf
o
r
mance im

p
rovement. An event
specification language that can be used to ex
p
ress s
p
atial
e
vents is
p
resented in
[
24]. Semant
i
cs of
b
as
i
c spat
i
a
l
events
i
s t
h
e same as ours. T
h
ey pa
id

more
a
ttent
i
on to event
d
ef
i
n
i
t
i
on an
d
event compos
i
t
i
on, w
hil
e we put
i
n great effort
o
n spat
i
a
l
su
b

scr
i
pt
i
on an
d
spat
i
a
l
event matc
hi
ng. Wo
rk
at Cam
b
r
id
ge
h
as
investigated services that, based on registra
tion of interest in user locations and
a
prox
i
m
i
t
i

es, not
i
f
y
c
li
ents w
h
en c
h
an
g
es occur [25]. T
h
e
i
r s
y
stem arc
hi
tecture
c
a
ll
e
d

C
ALAI
S

was
b
ase
d
on
di
str
ib
ut
e
d
events tec
h
no
l
o
gy
an
d
a
dy
nam
i
ca
lly
m
odifiable R-tree index, fed with a stream of location events, was used to monitor
locations and
p
roximities. CALAIS was suitable for the su

pp
ort of context-aware
a
pplications operating within a typical indoor, office domain, while our s
p
atial
pu
b/
su
b
system
i
s more su
it
a
bl
e for out
d
oor env
i
ronmen
t
by leveraging intelligent
t
d
ev
i
ces to prov
id
e a

hi
g
h
-performance spat
i
a
l
event process
i
ng. A sca
l
a
bl
e
l
ocat
i
on-aware system Rover [26],
d
eve
l
ope
d

i
n Un
i
vers
i
ty of Mary

l
an
d
, Co
ll
ege
Par
k
, prov
id
e
d
s
i
m
il
ar funct
i
on as our ea
gl
e
d
emo. Rover focuses on ac
hi
ev
i
n
g

s

y
stem sca
l
a
bili
t
y
to ver
y

l
ar
g
e c
li
ent sets
by

i
ntro
d
uc
i
n
g
an act
i
on mo
d
e

l

c
oncurrent software arc
hi
tecture an
d
our Ea
gl
e
d
emo tar
g
ets
high
-performance
s
p
atial
p
ub/sub mechanisms.