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

 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

500

1000

1500

2000

0 500 1000 1500

Number of registers

query delay (ms)

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,5

1, 5

0510

Bandwidth (Mbps)

63 bytes

2 KB

7 KB

23 KB

0,2

0,4

0,6

0,8

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