Keywords: Location based services (LBS), Mobile systems, GPS
Abstract: Location-based services (henceforth referred to as LBS) have emerged as an important component of m-
commerce strategy. Location can determine consumers’ information needs and their product and service
choices. We propose and evaluate different architectures for LBS considering that service provider allocates
at different locations its information. Finally, we propose some design rules that consider the trade-off
between transfer delay and query database time to improve LBS response time.
1 INTRODUCTION
With the proliferation and widespread adoption of
mobile telephony and data, service providers have
been eager to exploit customer information they
have acquired over time (Rao 2003).
User location has traditionally been difficult to
use due to its inherent dynamism and
unpredictability (in this paper we use user and
customer interchangeably). With regulatory
pressures and the rollout of new technologies
integrated into lightweight mobile devices and
terminals, location is quickly becoming an exact
science. Carriers are being forced by regulators to
accurately position wireless emergency calls,
through E911 in the US, and E112 in the EU (Rao
2003). Agile technologies like GPS and triangulation
allow carriers to zoom in further on customer
activity. As these capabilities become more
accessible, accurate in real-time, various service
opportunities have been conceptualised (Jukic, 2003;
Rao 2003).
These location-based services have emerged as
an important component of m-commerce.
Predictions are that LBS will generate over $32
billion in Europe by 2005 (Stafford, 2003; Rao
2003).
1.1 Location based services
The implementation of location technologies opens
up a whole new world of services, communicating
and sending messages based on the location of the
user (Rao, 2003; Stafford, 2003).
A wide range of safety solutions open up by use
of location technology: emergency alert services,
like E-911 and E-112; roadside assistance; and,
safety alarm.
Location based charging allows a subscriber to
be charged different rates depending on the
subscriber’s location or geographic zone, or changes
in location or zone. This service may be provided on
an individual subscriber basis, or on a group basis.
Location may be defined for business groups to
include corporate campuses, work zones or business
zones with different charging rates. Charging zone
would be associated with the subscriber’s location.
When the subscriber moves to a different zone (or its
mobile system anticipate this movement), the
subscriber would be notified.
Fleet and asset management services allow the
tracking of location and status of specific service
group users.
Location based information services allow
subscriber to access information for which the
information is filtered and tailored based on the
location of the requesting user. Subscribers may
initiate Service requests on demand, or automatically
LOCAL vs REMOTE INFORMATION FOR LOCATION BASED
SERVICES
J. Villadangos, J. J. Astrain, A. Córodba, M. Prieto
Dpto. Matemática e Informática
Universidad Pública de Navarra
Campus de Arrosadia
31006 – Pamplona (SPAIN)
287
Villadangos J., J. Astrain J., Córdoba A. and Prieto M. (2004).
LOCAL vs REMOTE INFORMATION FOR LOCATION BASED SERVICES.
In Proceedings of the First International Conference on E-Business and Telecommunication Networ ks, pages 287-293
DOI: 10.5220/0001393402870293
Copyright
c
SciTePress
when triggering conditions are met, and may be a
singular request or result in periodic responses.
Examples of location based information services are:
city sightseeing, location dependent content
broadcast, driving directions and navigating.
In case the service is initiated by the subscribers,
he can indicate its location when requests the
service. However, whenever the service is
automatically initiated, location based services
should locate the customer at any time and,
prediction can be added in order to anticipate
customer location and therefore improve customer
satisfaction.
A key driver of LBS will be a degree of fit
between the system’s technical feasibility and the
overall marketing and platforms (including PDAs
and mobile phones). LBS providers will need to
focus on blending software, hardware, and wireless
connectivity into a plan for serving LBS content. In
(Jukic, 2003) it is concluded that designing low-cost,
reliable, and high-quality systems from a complex
puzzle of disparate software, hardware and
connectivity components presents a challenge.
However, success in this area will accelerate
networking effects that lead to widespread adoption,
an increase in the customer base, and lower
operating costs.
Three strategic considerations assume
importance while choosing and deploying these
technologies (Jukic, 2003). These include the range
of coverage and scalability of applications; the
degree of service quality that can be established and
maintained at a reasonable cost; and the careful
alignment of the overall technology cost with the
types of services customers will pay for.
In this paper we describe two architectures for
LBS: local LBA, where information is located at the
customer’s device; and, remote LBS, where
customer requests for information to a remote
server. We discuss these architectures based on
developed LBS and analyse them. The analysis
allows establishing in this paper a set of design rules
(engineering decisions) to be taken into account
when LBS is developed. Such rules will help to
evaluate the degree of service and the coverage and
scalability of LBS.
Firstly, we describe LBS architectures in Section
2, defining local and remote LBS. Section 3 is
devoted to present a local LBS (a guided tour). In
Section 4 we present some results for remote LBS.
Then, we establish a set of design rules to take into
account for LBS development. Finally, Conclusions
and References end the paper.
2 LBS ARCHITECTURES
LBS is composed by a set of elements that interact
together to provide a service. One of the most
important components is devoted to get the customer
position: location element. There are at least two
different alternatives for such element (SnapTrack,
2001; Tabbane, 1997): external processing units
destined to map the customers with its geographical
positions (triangulation based on signal power
transmission in cellular systems); or local processing
devices like GPS modules (Stafford, 2003) mounted
on the customer's mobile device (i.e. a PDA with a
GPS module).
The knowledge of customer's location allows
customizing the service for each customer. We
distinguish two different approaches depending on
information location: (i) the information is
completely stored in the mobile device before
service had been initiated; and (ii) the information is
downloaded on–demand from the service provider.
We distinguish two different architectures for
LBS depending on data location to provide the
service. So, we have a local LBS architecture
(henceforth referred as local LBS) meaning that the
mobile device contains the information to provide
the service (it is the case of route selection using
GPS signals). And, we have an LBS using remote
located information (henceforth referred as remote
LBS), which requires at least the interaction between
a remote server and the mobile device to transfer the
information. Moreover, remote LBS can operate in
two different modes: pull and push modes. The first
one considers that mobile devices request the server
for information (pull mode of operation), while in
the other case, the server sends the information to
the mobile device (push mode of operation) without
announce it.
In both cases, information will be stored usually
in a database and will be delivered in response to
customer's requests (pull mode) or because it has
been selected by the service provider for the
customer (push mode).
In order to evaluate the service, we consider
interactivity as the most important parameter, as
exposed in (Jukic, 2003). Customers will be satisfied
(good grade of service), whenever they obtain the
service on time. And, probably, in such a case,
customers will consider this service as a candidate to
pay for.
In this paper we assume some requirements: we
consider pull remote LBS and customers get from
the service provider the information they requested.
So, we can pay attention on the most important
elements that affect the interactivity of LBS (LBS
ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES
288
response time): information transfer time from
service provider to customer.
In such a case, the parameters that limit LBS
performance are the round trip time (RTT) in the
network and the query time in the database (time to
get the response from the database).
The RTT determines the transfer delay of the
information; while the query time determines the
time to process the customer's request. The query
processing time depends on the database
management system, the database structure and the
size of the database (amount of data).
2.1 Impact of information location on
LBS
One of the most interesting properties for LBS is the
ability to capture the user interactivity. Therefore,
such services should be designed taking into account
the user response. The customers access the
information and it should be displayed in a short
period of time. In other case, the customer
satisfaction will be degraded.
In order to increase user satisfaction we should
pay attention to the service design. There are two
possible strategies: local LBS, where the mobile
system stores all the required information to deliver
the service; and remote LBS, where the mobile
system is able to download the information on
demand.
In the first case, the limitation highly depends on
the mobile device. The resource limitation imposed
by a mobile device will affect LBS performance.
Whenever the mobile device can store all the
information and has enough processing capacity, the
customer will perceive a good service (we will get a
satisfied user). In this case, the LBS response time
will be short. However, resource limitation in mobile
devices is very common, therefore designs should be
optimised. Moreover, local LBS restrict service
operation to the local information stored in the
mobile device, which can reduce user interaction
with the service provider.
For remote LBS the database that stores the
information must be remotely accessed, and the
documents to be transferred can be of very different
sizes. There is not a storing problem, but the size
affects proportionally information transfer delay.
Moreover, transfer delay can be increased due to
congestion problems in communication networks
(some QoS guarantees should be ensured to provide
predictable LBS). Remote LBS require interaction
between customer and service provider, improving
customer profile gathering for service provider.
Table 1 resumes some parameters that should be
considered in LBS design.
Table 1 : Parameters for LBS design decisions.
local LBS
remote
LBS
DB size Limited Unlimited
Document size Limited Unlimited
Query delay < 1 s < 1 s
RTT not applicable < 200 ms
Congestion not applicable possible
Bandwidth not applicable limited
Figure 1: Trade-off between local and remote LBS.
From the consumer point of view, LBS response
time highly depends on the maximum delay to get
the service. In our case, there are two delay sources:
the network and the database. The relation between
the bandwidth and the query delay we figure that
should be similar to figure 1.
As database size increase, database response
time will increase. This situation is more
problematic for resource limited devices as it is
usually the case for local LBS. In other case,
bandwidth limits transfer delay (RTT should be
taking into account but we concentrate the
explanation on the above parameters). And remote
LBS will be limited by network performance and
document sizes. The greater the document size or the
lower available bandwidth, the greater the transfers
delay.
As we illustrate in figure 1, there is a trade-off
between bandwidth and database response time that
should be considered in the design of each LBS. The
main object of the paper is to obtain such relation
(figure 1), because it allows deciding the LBS
architecture depending on the working point of our
system.
We will illustrate such considerations presenting
developed local and remote LBS, with the main goal
to help customer to visit the outdoor Botanic garden
of the University. In the first case, the information is
stored in the customer mobile device and in the other
case the information is transferred through Internet
as web pages.
bandwi th
database size
delay
T r ansf er del ay Quer y del ay
LOCAL vs REMOTE INFORMATION FOR LOCATION BASED SERVICES
289
3 LOCAL INFORMATION LBS
WITH GPS LOCATION
In this section we describe a particular local LBS.
The service provides customers a guided visit to the
outdoor Botanic Garden of our University. There are
different green zones in the campus, each one
dedicated to a different continent or to a specific
country. So, we have the European garden, the
American garden, the British garden, etc. with trees
original from such geographical parts of the world.
Now, the University offers a paperback Green
guide containing the description of the different
zones and information (text and images) about trees
for each zone.
We have developed a local LBS using a PDA
(Compaq iPAQ H3970). The PDA is equipped with
a GPS module (CompactGPS from Pretec) that
locates customer with a maximum error of 6 meters.
The PDA stores a database with the whole
information about the Botanic Garden. The goal of
the LBS is to locate the customer and provide
information about its position on the campus and
about the trees next to the customer. That is, the
local LBS provide the Green guide on a PDA. The
customer to get the same information as the
contained in the book can use this portable device.
But, it is a more flexible than a book because
information can be easily updated in the PDA, while
a book requires a new edition.
The local LBS we have developed has the
interface presented in figure 2. We use an aerial
campus photo as background image and locate the
customer on it. The customer is represented by the
dot on the image.
In a similar way, the local LBS contains
information about the trees: location, general
information (common name, technical name, family,
original country, etc.) and its photography. Such
information is stored in a database on the PDA. Note
that this application should be considered as local
LBS, because all the information to provide the
service is contained in the mobile device.
Figure 2 : Green guide LBS interface
In addition to service location and tree
description, the local LBS provides other services as
the possibility to select a predefined route through
the campus to visit the Botanic garden. The local
LBS contains some audio components that apply to
warn the customer about the name of its location
area, when a border between areas is crossed.
It is very easy to conclude in this case, that LBS
can provide more powerful, flexible and customized
services to customers.
3.1 GPS customer location
We use a GPS module (CompactGPS) to locate the
customer. We verify its location precision by
comparing the position it provides and the
geographical UTM coordinates given by SITNA a
Geographical Information System of the Navarra
Government (SITNA, 2003).
We select a set of points in the University and
measure its position with the GPS module several
times and in different weather conditions. We show
that the GPS module requires 4 minutes in average
to give the first position, using, in general, a lower
number of satellites than the available ones at the
measurement instant. Precision location is around 9
meters in the 94,28% of the cases, as expressed by
the fabricant. Moreover, we have verified, as
expected, that we obtain greater position errors for
test points next to buildings. However, the average
position error is around 6,24 m, which is enough for
our application, mainly because tree concentration
places in the Botanic garden are not next to
buildings.
GPS module and PDA interact through the
NMEA 0183 protocol to get customer location in
WGS-84 (World Geodetic System) coordinates.
ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES
290
These coordinates correspond to a point in the
geodetic reference ellipsoid. Next we summary the
conversion process from WGS-84 to UTM
coordinates.
Our local LBS requires two steps after it gets the
WGS-84 coordinates from the GPS module.
First, the LBS transforms them to the local
ellipsoid using the Helmert transformation with 7
parameters (Hartum ellipsoid with Postdam datum –
ED50, which is the reference for Europe). This
transformation introduces an error. In our case, this
error does not introduce a significant customer
location error. We have measured an average error
of 0.0539 m and a maximum error of 0.5759 m.
Finally, the local LBS projects the coordinates to
obtain the UTM coordinate.
3.2 Local information architecture
Our local LBS contains information about the
outdoors Botanic garden of the University. This
information is stored in a database grouped in a set
of tables.
We structure each area of the park (British park,
Europe park, etc.) in a set of square regions (RegID)
associated with a region name (RegName) and
define its location giving the UTM coordinates of a
diagonal (VInfLeftX, VInfLeftY, VSupRightX,
VSupRightY). Each tree belongs to a family
(FamilyName) it is distinguished by an identifier
(FamilyID), and it is located at a given region with
coordinates (X_UTM, Y_UTM).
Local LBS provided from a PDA, a resource
limited device, can be limited by the query database
time. Figure 3 shows how the value of this
parameter grows, in our case, with the number of
registers stored in the database (database size).
In addition, there is an information scalability
problem, because the bigger the database, the greater
LBS response time.
In order to overcome the above scalability
problem and, consequently, to reduce the possibility
of service degradation we develop an adaptive
caching system for the local LBS. The cache is part
of the database where database views are stored. The
database view is the result of a query stored in the
database.
This technique allows to reduce the local LBS
response time, because data selection has been done
previously (figure 4). This technique is useful,
whenever the service will use often some configured
selections.
Figure 3 : Database query delay.
Then, in our case and based on the service to be
offered by the local LBS, we have configured some
views for each campus area.
However, we cannot store locally all possible
views due to resource limitations in the customer
device but we can store the sentences to build them
up. The next step is to execute appropriates
sentences depending on customer profile.
Figure 4: Views access delay for local LBS.
The caching system adapts itself using customer
location as its profile. So, the local LBS select the
sentences to build up the active views depending
where the customer is located. In fact, the customer
mobile device stores at least the views of the two
regions: the region where customer is located and its
neighbour region.
The local LBS automatically adapt the contents
of the database to store such views without customer
intervention. This technique reduces drastically the
local LBS response time, as depicted in figure 4,
compared with query delay time.
4 REMOTE INFORMATION LBS
WITH GPS LOCATION
Now, we use the application in a web framework.
The application sends customer’s location to the
remote LBS server. It responds with an HTML page
0
500
1000
1500
2000
0 500 1000 1500
Number of registers
query delay (ms)
0
2
4
6
0 500 1000 1500
Number of registers
views delay (s)
LOCAL vs REMOTE INFORMATION FOR LOCATION BASED SERVICES
291
containing the information depending on customer
location.
In this case, we use a script to convert the GPS
module output into the geographical coordinates of
the customer. Such information is transferred to the
service provider that returns the contents of the
corresponding URL. This html page contains the
new position of the customer and trees position next
to the customer to locate them on the background
photography; or information about the above trees.
The remote LBS, in this case, has the advantage
that minimize the amount of local memory, because
all the information is contained in the web page.
The limit will be the transfer delay of web pages.
Such pages can be optimised in size but most of the
time is required to transfer images.
Figure 5 shows the transfer delay for several
tests we have done over a wireless network to
transfer web pages located at different URLs in
Internet. In the experiments customer has assigned a
fixed bandwidth in the local network. Packet
transmission through the backbone (Internet) is done
in a best-effort way.
We show the delay function for different
bandwidth and page sizes (figure 5) using the
Internet as the backbone network. As performance
measure we consider the web page download time,
because it influences directly customer satisfaction.
Figure 5: Transfer delay for remote LBS.
In figure 5 can be shown that increments for
customer’s bandwidth do not implies directly a
reduction in the page transfer delay. So, bandwidth
increase cannot be the best solution to provide a
quality predictable remote LBS. Moreover, for each
document size we obtain a minimum delay, which is
limited by the RTT of the packet delivery
connection (it must be taken into account that
packets are transmitted in both directions, because it
is a TCP/IP connection).
5 REMOTE VS LOCAL
INFORMATION LBS
We have described and analysed, in previous
sections, two different applications to illustrate the
effect of information location in LBS. The results
can be summarized in the next figure (figure 6). In
this figure can be showed the trade-off we have
found between the query database delay and the
transfer delay.
Whenever the customer has a wide enough
bandwidth, there are not any problems to provide
remote LBS. However, it should be considered the
round trip time of the network, because it restricts
the interactivity. Moreover, remote LBS can be
affected by network congestion problems, which are
mainly unpredictable.
On the other side, local LBS are very interesting
whenever the application requires a low amount of
information accessible in a short period of time. For
example, it is the case of a little database. But most
of the applications includes of a lot of information to
be useful for different customers. For example, a
route selection application is sold with maps from all
the country but each customer will use a small part
of the whole information.
Figure 6 shows the delay the customer must wait
to get a document from Internet and from the
database (abscises are in logarithmic scale).
In addition, it is showed that a database, for our
PDA mobile device, with a set of 150 registers
provides a query delay similar to the minimum
measured transfer delay through Internet.
Figure 6: Local vs remote LBS trade-off
.
0
0,5
1
1, 5
0510
Bandwidth (Mbps)
63 bytes
2 KB
7 KB
23 KB
0
0,2
0,4
0,6
0,8
1
1, 2
1 10 100 1000
dat abase siz e - bandwidt h
ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES
292
6 CONCLUSIONS
In this paper we present the architecture of local and
remote information LBS, and evaluate them based
on practical applications.
We have found a trade-off between the query
processing time and the network transfer delay as
the most important factors to be considered in the
design of LBS. Finally, we propose some design
rules and a novel LBS architecture that improves
service response time.
REFERENCES
Jukic, N.; Sharma, A.; Jukic, B.; Parameswaran, M.
(2003). M-commerce: A location-based value
proposition.
SITNA, (2003). Geographical Informations Systems for
Navarra (SPAIN). http://sitna.cfnavarra.es
Rao, B.; Minakakis, L. (2003). Evolution of mobile
location-based services. Communications of the ACM,
46(12) 61:65.
SnapTrack, (2001). Location tecnologies for GSM, GPRS
and WCDMA networks. White Paper from SnapTrack
a Qualcomm company.
Tabbane, S. (1997). Location management methods for
third-generation mobile systems. IEEE
Communications Magazine, August 1997, 72:83.
Stafford, T. F.; Gillenson, M. L. (2003). Mobile
commerce: what it is and what it could be.
Communications of the ACM, 46(12) 33:35.
LOCAL vs REMOTE INFORMATION FOR LOCATION BASED SERVICES
293