![](bg2.png)
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