DEPENDABILITY OF LOCATION-BASED SERVICES: A LARGELY

OVERLOOKED ASPECT

Artem Katasonov

Information Technology Research Institute

University of Jyv

askyl

P.O.Box 35 (Agora), FIN-40014, Jyv

askyl

a, Finland

Keywords:

location-based services, m-commerce, mobile computing, dependability, quality.

Abstract:

There is obvious lack of attention to the dependability issues in literature on location-based services (LBS).

Both researchers and practitioners were so far too much concerned with the questions about what useful fea-

tures an LBS should have, while almost completely leaving out the questions about how to assure such basic

properties as reliability or response accuracy. However, LBSs are applications that require high dependability,

as we argue in this paper, so assuring those is both more critical and more difﬁcult than usually. We discuss the

existence of this disagreement between the actual importance of LBS dependability and the level of attention

towards it among practitioners and researchers. We also identify and brieﬂy discuss the major factors inﬂu-

encing dependability of LBSs, namely the quality of content, software reliability, algorithms appropriateness,

interface quality, and communication quality.

PROLOGUE

Let us start with an anecdote.

In a hospital, a nurse is writing down a mail from

the dictation of the man, who is completely cov-

ered by plaster, with arms and legs broken: Dear

editor, I would like to inform you that on the

page 14 of your manual “How to handle a he-

licopter” I discovered a minor misprint...

At this point, we wanted only to tell this “horror

story”. We will return to it later, in Section 2.

1 WHY ARE LBSs STILL IN AN

EARLY STAGE?

According to the latest statistics published by the

GSM Association (GSM Association, 2003), in May

2003 there were 863 million GSM subscribers world-

wide and 1218 millions wireless subscribers in total.

In May 2002, the numbers were 692 and 1008 mil-

lions, correspondingly. As can be seen, the market

is already huge yet still growing at fast pace. Al-

though being saturated in some developed countries,

such as Japan and many countries belonging to the

European Union, it is still expanding rapidly in devel-

oping countries, such as China and Russia.

This presents a huge customer potential for com-

mercial activities. The rapid growth of wireless mo-

bile networks, coupled with advances in Internet and

network technology, results in a fast development of

Mobile E-Commerce, or M-Commerce, i.e. the ac-

tivity of conducting E-commerce transactions over a

wireless network using mobile terminals. The high-

end mobile terminals have already reached the com-

plexity and performance of the personal computers

of mid 1990’s, and the development continues at fast

pace. Most new mobile phones are Java-enabled and

can run, in principle, any application with reasonable

resource needs. The small and light, yet powerful,

mobile terminals are carried by their owners almost

all the time.

In addition, the location of a mobile terminal can be

determined within mobile networks, by using satellite

navigation systems, or by some other available means.

Recent developments in these areas seamlessly ex-

tend the positioning of wireless devices into all the

environments where they can be used for voice and

data communication. Thus, location-based services

(LBSs) have become possible. We view an LBS as a

special case of M-commerce, where the actual posi-

tion of the terminal is used in the service provision.

There are many obvious needs that location-based

services could fulﬁll. When people are in an un-

familiar place or have some unusual problem, they

may need information about their surroundings. They

might like to receive some guidance about how to

reach a speciﬁc place, ﬁnd a place to park the car, eat,

spend a night and so forth. Traditionally, people solve

489

Katasonov A. (2004).

DEPENDABILITY OF LOCATION-BASED SERVICES: A LARGELY OVERLOOKED ASPECT.

In Proceedings of the Sixth Inter national Conference on Enterprise Information Systems, pages 489-496

DOI: 10.5220/0002620604890496

 SciTePress

these problems with the help of printed maps and vari-

ous handbooks and guides. Today, LBSs could enable

people to solve them in a more effective way. Studies

of potential location-aware applications can be found

in literature (Schilit et al., 1994; Dommety and Jain,

1996; Beadle et al., 1997), as well as recent discus-

sions of business opportunities in LBS and customer

value proposition (Rao and Minakakis, 2003; Barnes,

2003). The most basic LBS types are location-based

yellow pages (information on restaurants, hotels and

other points of interest) and route guidance (a map

with the current location of the user, route ﬁnding).

In addition to these services for personal information

and navigation, LBSs are considered to include also

such services as ﬁnding and tracking (friends, chil-

dren, property), functional services (e.g. calling a

taxi, roadside assistance) and some other. Ideas and

opinions expressed in this paper apply to all types of

LBSs to some extent; however, we have in mind those

informational and navigational services mainly when

speaking about “location-based services”. Overviews

of LBS enabling technologies and technical issues can

be found in books devoted to LBSs, e.g. (Hjelm,

2002; Jagoe, 2003), or numerous journal and con-

ference papers, e.g. (Dao et al., 2002; D’Roza and

Bilchev, 2003; Tsalgatidou et al., 2003).

Therefore, location-based services seem to have all

the prerequisites to become a very successful busi-

ness — the demand, the huge (and growing) market

and the good technological infrastructure, which is

still developing further. LBSs have been a hot topic

for both researchers and practitioners for a decade al-

ready, pushed forward by various players including

mobile operators expecting LBSs to form an impor-

tant revenue-generating class of mobile services, mo-

bile phone manufacturers, Geographic Information

Systems (GIS) community searching for possibilities

to sell their data, algorithms and software, and other

content providers (e.g. publishers of yellow-pages di-

rectories). According to the forecasts made in 2001,

the LBSs should have over 300 million users by the

end of the year 2004 (Singhal et al., 2001).

However, the reality we see is quite different. De-

spite all the opportunities and despite being a hot topic

for a decade, LBSs are still, in 2004, in a very early

stage. At least in Europe, location-based services are

rare, provided mainly by the mobile operators them-

selves, and rather simple. There are some barriers

delaying deployment of LBSs (Mitchell and Whit-

more, 2003): operator debt levels, waiting for UMTS,

limited LBS standards, pre-occupation with preci-

sion of available positioning solutions, privacy con-

cerns (operators are vulnerable to public criticism),

and business model paralysis (indecision by opera-

tors on whether to keep location for themselves or re-

lease to others). Nevertheless, many LBSs have been

launched in recent years – so, according to (The Re-

search Room, 2003), a total of 133 location-based ser-

vices from 38 cellular networks were commercially

available within Europe’s top 15 cellular markets at

the end of 4Q 2002.

However, many of those existing services do not

seem to be well adopted and heavily used by cus-

tomers, and this creates one more key barrier hinder-

ing development of new and more advanced LBSs.

This lack of user adoption is often a surprise for mo-

bile operators, who usually think that just providing

some relevant information at the appropriate place

and time means money. The lack of user adoption

seems to be a surprise for the research community as

well. Only recently, after a decade of discussing busi-

ness opportunities and developing prototype LBSs,

researchers have begun to investigate what require-

ments an LBS must fulﬁll in order to be successful.

Obviously, users must have a perceived need for the

LBS provided. Many authors proclaim the huge busi-

ness potential of location-based services; however, as

summarized in (Dao et al., 2002), the market for LBS

is currently very speculative while there is no deﬁnite

answer to the questions whether consumers are really

interested in LBS and whether they are willing to pay

for them. Also, there may often be a discrepancy be-

tween what services users really want and what ser-

vices the providers imagine them to want. The exis-

tence of such a phenomenon for mobile Internet ser-

vices in general was demonstrated in the study (Chae

et al., 2000). We believe, however, that even the sim-

plest and the most prevalent of the location-based ser-

vices available at present, namely of the yellow-pages

type, have a clear demand for them.

In some cases, potential users might also be totally

ignorant about some service that could be useful to

them. This is because visibility (the degree to which

the potential adopters are aware about existence of the

innovation), trialability (the degree to which one can

experiment with the innovation), and result demon-

strability (the degree to which the results of using the

innovation are observable and communicable to oth-

ers) are important factors inﬂuencing an innovation

adoption process (Karahanna et al., 1999). LBSs,

however, are advertised well (achieving visibility),

and delivered often on pay-per-request basis (leading

to considerable trialability); they provide information

or service that immediately applies to user’s life (good

result demonstrability).

We conclude, therefore, that existing location-

based services should have been adopted by users un-

less they had some considerable defects, i.e. their per-

ceived usefulness of perceived ease of use were insuf-

ﬁcient. As we said above, in recent few years publi-

cations started to appear supporting this conclusion.

Some researchers consider the technological im-

perfection of present LBSs to be the main factor.

So, (Grajski and Kirk, 2003) discuss that in Japan

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

490

location-based services seem to be more successful

than in Europe, and associate this with the fact that

in Japan 3G networks and precise Assisted-GPS posi-

tioning are already deployed. Other researchers con-

centrate on requirements for LBSs themselves. (Bis-

dikian et al., 2001) list the concern of privacy, the

need to consider context beyond location, the need

for service personalization, and usability of user in-

terfaces as the main success factors. (Unni and Har-

mon, 2003) concentrate on the requirement that the

price users pay for using the LBS must correspond

well to the perceived value of the service, and also

on the privacy concern. (Kaasinen, 2003) made an

evaluation of a few LBSs by interviewing their users,

and among users’ concerns she listed appropriate and

comprehensive contents, effective interaction with the

service, possibility of more detailed search options

than currently available, seamlessness, privacy, and

personalization. (K

ohne et al., 2003), based on dis-

cussion in student focus groups, list service price

and content quality as the main (even knock-out) at-

tributes of LBS, followed by technical aspects (device

properties, positioning accuracy, convenience of use,

conﬁguration possibilities), privacy concerns, level of

consumer activity (e.g. push vs. pull), and uniqueness

of features as compared to competitors.

Surprisingly, content quality is rarely discussed.

While agreeing with the importance of all the other re-

quirements; we share the view of (K

ohne et al., 2003)

that content quality is a knock-out criteria. One aspect

of this problem was noticed in the above-mentioned

study (Kaasinen, 2003): the author reported that the

limited content of the services (missing information)

was one of the main reasons why users considered the

services not useful. We “played” recently with a few

currently available yellow-pages LBSs. Reporting on

these experiments is outside the scope of this paper.

However, we also discovered that data provided by

these services is often outdated and incomplete. We

believe that it should be obvious that with a low con-

tent quality an LBS would not be adopted by users no

matter how well it is technologically advanced (e.g.,

with very precise positioning), how usable the inter-

face is, how well it is personalized, and how well the

privacy is protected. Content is what the users pay for.

Actually, a low content quality LBS would hardly be

adopted even if it cost no money to use it (for argu-

ments see Sections 2 and 3).

In this paper, we extend this view and hypothesize

that one of the major factors hindering user adoption

of existing LBSs is their low dependability. Depend-

ability is the trustworthiness of a computing system

which allows reliance to be justiﬁably placed on the

service it delivers (the deﬁnition by IFIP WG10.4). In

other words, low dependability implies that the users

just do not feel that they can rely on those services.

Content quality is obviously one of the constituents,

LBS dependability is affected by other factors as well

(we will discuss them in Section 4).

We cannot provide sufﬁcient empirical evidence

(besides mentioned above) supporting this hypothe-

sis, neither indicating that dependability of existing

services is low, nor that this is a major factor leading

to a lack of user adoption. The hypothesis is based

on our interpretation of the experience of about four

years of doing research in LBS and following devel-

opment of the ﬁeld. It is supported also by the ob-

vious lack of attention to the dependability issues in

literature, including both practically oriented and sci-

entiﬁc sources. The talk is always about opportuni-

ties, enabling technologies, at best also about privacy

and interface usability concerns, but never about the

dependability. Even books devoted to location-based

services, such as (Hjelm, 2002), trying to discuss all

the possible related topics do not spend a single page

on content quality or dependability requirements. As

we said above, so far we seen only two papers (Kaasi-

nen, 2003; K

ohne et al., 2003) that (very brieﬂy) men-

tion even the most obvious concern of content qual-

ity. (There were, however, also a few publications

which tried to apply theory from the information qual-

ity research ﬁeld in the context of general mobile ser-

vices (Chae and Kim, 2001; Landor, 2003) - therefore

showing recognition of the problem.)

For us, it is quite obvious that both LBS researchers

and practitioners were so far too much concerned

with the questions about what useful features an LBS

should have (i.e. utility), while almost completely

leaving out the questions about how to assure a suf-

ﬁcient level of such basic properties as reliability or

response accuracy (i.e. dependability). It seems that

it is just not recognized that the dependability require-

ments for LBSs are quite high, higher than for most

of conventional end-user applications, web or mobile

services (the reasons for this we will discuss in Sec-

tion 2), and that it may be insufﬁcient to rely on com-

mon practices and methods of assuring it. Moreover,

LBSs are usually developed as prototypes or pilots,

and thus receive even less quality control than con-

ventional software systems do.

We believe that in order to make LBSs a success,

the situation has to be changed. More attention should

be paid by LBS developers to the dependability is-

sues. Also, some speciﬁc LBS dependability oriented

research should probably be conducted in the scien-

tiﬁc community.

2 WHAT IS DIFFERENT ABOUT

LBSs?

In Section 1, we made a claim that location-based

services are more sensitive to dependability problems

DEPENDABILITY OF LOCATION-BASED SERVICES: A LARGELY OVERLOOKED ASPECT

491

than most conventional end-user applications (includ-

ing web and mobile services). Let us explain why we

think so.

LBSs evolved from desktop applications. This

evolution proceeds mainly by adding new technolo-

gies. Adding Internet support to desktop applications

gave birth to web services. Adding wireless networks

turned web services into mobile services. Adding

location support turned mobile services into LBSs.

Thinking this way hides the problem — there seems

to be nothing really different about LBSs.

However, this is a case where quantitative changes

lead to qualitative ones. LBSs are in fact philosoph-

ically very different from any of their predecessors.

Any location-based service is an augmented reality

application. Any information or functionality an LBS

provides does not have much value per se, but as-

sists in performing a primary user task, i.e. navigation

through a city, making some immediate decisions, etc.

If the user relies on the service, a failure of the service

very likely leads to a failure of the user.

Recall that anecdote from the prologue to this pa-

per. Small misprint in the manual leads to the heli-

copter crash. This is a joke, of course — no manual

is assumed to be used like that, during the ﬂight, but

must be studied beforehand. Responsibility lies with

that pilot completely. However, this is a nice example

of that a “small” error in data may turn out to be very

big if this data is used real-time, for making immedi-

ate decisions. Imagine also that instead of that printed

manual, the helicopter had a software adviser system

that depending on the situation gave tips to the pilot.

Similar “small” error in it may lead to similar con-

sequences — however, responsibility would lie now

with software vendor, because this system is assumed

to be used real-time, and it is assumed that the user

may rely on it.

Providing relevant data at right place and time is

a great business opportunity; however, it comes

with a great responsibility as well.

Any location-based service is assumed to be used in

the course of the activity it supports, not before start-

ing it. This signiﬁcantly raises the dependability re-

quirements for LBSs, as compared to similar purpose

but ofﬂine applications and data sources.

Consider the most common LBSs at present, of the

yellow-pages type. They are often developed as just

offering a location-based real-time access to data sets

collected for the purpose of printing phone books.

However, the quality requirements for such an LBS

are higher than for a printed phone book. LBS is in-

tended mainly for traveling people as a tool provid-

ing support in making decisions about where to go.

Therefore, wrong information may mean wrong de-

cisions, lost time and, as a result, anger of the client

(and losing him) in the best case and a lawsuit in a

worse case. We can imagine, for example, an emer-

gency situation where an LBS gives a wrong address

for a pharmacy and the user therefore does not get the

required medicine in time. But even if we do not con-

sider such worst-case scenarios, it must be obvious

that if a service provider plans to collect any revenues

from his LBSs he should consider the dependability

aspect very seriously. Clients are lost very quickly if

they feel that they cannot trust the service.

A few more reasons for raised dependability re-

quirements in LBSs are the following. First, once you

have a printed phone book, using it is free. In contrast,

the payment for using a commercial LBS is usually

based on how much you actually use it. For many

services, the client pays a ﬁxed fee for every query

made. Already a few erroneous answers may thus eas-

ily lead to losing the client. Second, phone books are

published usually once in a year; the customers are

therefore prepared to encounter some outdated infor-

mation. A user requesting information from a “new

technology” source and paying for this information

expects it to be always up-to-date. Third, an LBS usu-

ally presents only a few short records to the client as

the result of a query. This makes ﬂaws in data notice-

able easier even if they do not lead to critical failures.

One more reason for why location-based services

require better dependability than most of other mo-

bile applications is the following. Compare LBS, for

example, to an application providing mobile access to

e-mail. Mobile e-mail service offers a new informa-

tion channel to the user. If a user does not have this

service, he just cannot read his mails while traveling.

Therefore, he is probably ready to use the service even

if it has some ﬂaws. In contrast, an LBS aims for re-

placing an information channel. If a user does not

have an LBS helping him in ﬁnding a nearest hotel,

he will solve this problem anyway using a travel guide

or just asking people. Having an LBS might be bet-

ter; however, getting an erroneous answer even once

the user can easily give up on the service and return to

a traditional way of solving this kind of problems. In

other words, an LBS usually needs to compete with

other sources of information; dependability is there-

fore very important.

3 WHY IS DEPENDABILITY

FORGOTTEN?

Let us brieﬂy discuss why there is a lack of attention

to dependability of LBSs.

Imagine walking on an airplane for your next ﬂight

and you notice the following product warranty next

to the entry (we borrow this joke from (Carpenter,

1999)):

The software programs on this aircraft are sold

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

492

“as is” without warranty of any kind, either ex-

pressed or implied. The entire risk as to the qual-

ity and performance of the software is with you.

The developer does not warrant that the func-

tions contained in the programs will meet your

requirements or that the operation of the soft-

ware will be uninterrupted or error free.

That is really a joke. Nobody will be willing to get

on an airplane like this. Everybody knows that air-

planes software is safety-critical and must be subject

to a rigorous quality control.

In contrast, LBSs seem to be sold to users ex-

actly under this kind of product warranty. They are

therefore assumed to be something that should make

users happy just because it exists, even if it has ﬂaws

— “something is better than nothing”. Actually, it

is quite common when introducing an innovation to

concentrate ﬁrst on demonstrating its utility and then

gradually improve its dependability. This is often ap-

proapriate; however, based on arguments presented

in Section 2 we should conclude that LBSs are not

a case – they should be dependable from the very

beginning. (Discussing LBS content incompleteness

problem, (Kaasinen, 2003) makes a similar conclu-

sion: that it should be considered carefully how much

content a pilot service should include to be at all worth

releasing.) Lack of recognition of this is probably the

main reason for low attention to the dependability as-

pect in LBSs.

As we mentioned in Section 2, it is common to

consider location-based services to be a subset of mo-

bile services that are in turn a subset of web services.

So, in addition to traditional concerns about web ser-

vices and mobility only the obvious question of user’s

privacy is treated as a rule. Most of mobile services

provide some additional value to their users; they are

useful in the best case and useless in the worst case

– they cannot be harmful. But LBSs can. How-

ever, location-awareness is commonly considered as

a way to personalize mobile applications in this way

improving their usability and therefore value (LBSs

are presented in this way, e.g. in (Kaasinen, 2003)

and (Unni and Harmon, 2003)). An LBS therefore in-

herits the appearance of a service that always has a

positive value, and in the worst case is just a waste

of money with zero value. That fact is forgotten that

an LBSs, as any decision support system, may have

a negative impact if it is of a bad quality, i.e. there

is not only some value but also some risks associated

with use of the service. In other words, the responsi-

bility that comes along with the business opportunity

of providing relevant information at right place and

time is usually not recognized.

In addition, software systems quality assurance has

never been a popular topic, especially among prac-

titioners. Quality is not taught much in universities,

many of developers had no quality and testing edu-

cation in their formal studies or even training pro-

vided by the employer, quality assurance is seen as

a tedious and non-creative activity, see e.g. (Ahonen

et al., 2003). This attitude leads to the phenomenon

that a creative developer and a developer caring about

the quality are always two different persons, see e.g.

(Yamaura, 1998). As any innovation, LBSs are de-

veloped inside research labs, i.e. by creative people.

Therefore, this intensiﬁes the problem.

4 FACTORS INFLUENCING LBS

DEPENDABILITY

In this section, we identify and brieﬂy discuss the

main factors inﬂuencing dependability of location-

based services. They are content quality, software re-

liability, algorithms appropriateness, interface qual-

ity, and communication quality.

Content quality

Since LBSs are all about providing relevant infor-

mation at appropriate place and time, most services

are built around a dataset that is of interest for users.

Therefore, the ﬁrst dependability concern is about this

dataset quality.

The problem comes from the fact that this dataset is

usually repurposed for the LBS, i.e. it was created for

another reason. However, the quality requirements on

it in the LBS may be higher than in the original use. In

Section 2, we argued that the quality requirements on

data provided through a yellow-pages LBS are higher

than on information on the yellow pages of a phone

book. This means that a dataset that is good enough

as the source for a phone book may turn out to be of

insufﬁcient quality for using in the LBS.

Therefore, the quality of a repurposed dataset

should be veriﬁed. This is not a trivial task in most

cases, since the work of checking the entire dataset

may be equal to creating a new one. Consequently,

a statistical evaluation procedure should be applied.

The goal is to guarantee that the quality of the dataset

is not worse than required in the LBS (i.e. not worse

than the estimated level of clients’ tolerance). One

such procedure for evaluating the data quality in a

yellow-pages LBS was developed by us and presented

in (Katasonov and Sakkinen, 2003).

In many cases, the LBS developer, even while be-

ing able to verify the quality of the dataset used, can

hardly improve it. Then, a strategy for reducing data

quality requirements may be considered. For exam-

ple, changing the business model to one where user

pays a monthly fee for using the service should lead to

higher tolerance to service failures compared to a case

when the user pays for every individual query made.

DEPENDABILITY OF LOCATION-BASED SERVICES: A LARGELY OVERLOOKED ASPECT

493

Also, providing more data in response to a query (say,

data on 4 nearest restaurants instead of 2) should also

reduce the criticality of individual ﬂaws. Another way

is to reformulate the utility of the service – there is a

big difference between claims “the service reports on

the two nearest restaurants” and “the service reports

on two restaurants in close vicinity of the user”.

Software reliability

Quality of software, both on the server and on the

client side (if any), is another major concern. We

are not ready no say much beyond the triviality that

software, of course, should be reliable and therefore

should be rigorously tested. A good testing approach

is “horror-based testing” (Beizer, 1990). The worst-

case scenarios are identiﬁed, i.e. the worst things that

may happen because of software failures, and testing

then aims for guaranteeing that those situations will

not occur in practice.

The basic techniques for software testing and qual-

ity assurance apply to any kind of software-based sys-

tems including LBSs, of course. However, already

web and mobile technologies require new testing and

bug analysis methods (Nguyen et al., 2003), making it

worth writing special books on testing internet-based

and mobile systems. Probably, the LBS context will

also require development of new or adaptation of ex-

isting methods.

Algorithms appropriateness

Similar to repurposing existing datasets, LBS devel-

opers tend to build their services around already im-

plemented (or easily implementable) algorithms and

technological solutions. Therefore, LBSs are often

do “what is possible” instead of “what is required”.

However, the task in hand should be analyzed ﬁrst,

the requirements elicited, and appropriate algorithms

selected. A few examples follow.

• Positioning precision. For a yellow-pages LBS,

cell-based positioning would probably (but not al-

ways) be enough. However, for a route-ﬁnding

LBS this will obviously be insufﬁcient.

• Calculation of distances. For some tasks, straight-

line distance is appropriate measure. For some

other tasks, the road network must be taken into

account (e.g. the user may be frustrated when get-

ting a response that the nearest restaurant is only

one hundred meters away while it actually across

the river).

• Taking user’s movement into account. For some

tasks, it may be insufﬁcient to provide data related

to the location from which the user has sent the

query, but rather needed to provide data related to

the location where s(he) will receive the service re-

sponse.

In some situations, a cheaper alternative might be

sufﬁcient given just that the service provider keeps it

fair. So in the case of a simple yellow-pages LBS,

cell-based positioning and straight-line distance cal-

culation would be enough if it is claimed that the ser-

vice reports on two facilities in close vicinity of the

user. However, it is common to claim that the ser-

vice reports on the nearest facilities. This is hardly

required by a user from such a service; however, if

the claim is not met, this obviously creates a neg-

ative impression. In other words, claiming such an

unachievable utility, the service provider deliberately

reduces the dependability of the service. Existence of

the phenomenon of such claims about location-based

services provides additional support for the point that

very little attention is actually paid to the LBS de-

pendability.

Interface quality

This and the following factor are rather well known

since they are relevant for all the types of mobile ser-

vices and applications.

Mobile terminals have small and low-resolution

displays and limited input capabilities. This makes

it more difﬁcult to interact with a mobile terminal as

compared to interaction with a PC. In addition, the

practical conditions, when and where the mobile de-

vices are used, cannot be expected to be constant, as

it is usually in the case of a “desktop” application.

The mobile users are typically in very unstable en-

vironment in varying conditions, where their cogni-

tive capacity is demanded for other tasks as well. The

mobile users have less “mental bandwidth” - capacity

for absorbing and processing content - than a station-

ary user in front of a PC since the interaction with

the mobile phone often is reduced to a secondary task

that must not interfere with their primary task (e.g.,

driving or walking) (Chincholle et al., 2002).

All these peculiarities have to be taken very care-

fully into account when designing a new mobile ser-

vice. The basic implied requirement is that the user

interface should be very simple and user friendly and

the amount of presented information content limited

and well speciﬁed. The mobile users tend to use ser-

vices that allow both quick manipulations of the inter-

face and reduction in number of steps to access infor-

mation (Chincholle et al., 2002).

Usability issues of mobile interfaces are actively

studied by researchers from the Human-Computer In-

teraction (HCI) ﬁeld. An example of investigated area

is use of audio feedback in order to reduce the re-

quired visual attention, see e.g. (Brewster, 2002; Hol-

land et al., 2002).

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

494

Communication quality

The properties of mobile networks are: (relatively)

low bandwidth, high latency and unpredictable dis-

connections. These properties impose restrictions on

mobile services and must therefore be addressed in

the design of a new service. Some of the implied re-

quirements are: not very intensive use of the mobile

network and minimal volume of transmitted data, and

possibility of ofﬂine operation.

5 CONCLUSIONS

Most of the major mobile phone operators in Europe

already provide at least one location-based service to

their subscribers. However, on the background of a

decade of being a hot topic and very promising fore-

casts, LBSs are still in a surprisingly embryonic stage

of development. While there are obvious barriers de-

laying deployment of new LBSs, such as operator

debts and lack of standards, another problem is that

those existing services seem to experience a lack of

user acceptance. This should be surprising as well

– if one shares common beliefs about high utility of

LBSs (as we do).

One of the possible reasons for low adoption of

LBSs that is often mentioned is a lack of trust to the

service provider caused by user’s privacy concerns.

In this paper, we expressed our opinion that there is

another reason also – low dependability of existing

services.

There is obvious lack of attention to the depend-

ability issues in LBS literature. Both researchers and

practitioners were so far too much concerned with the

questions about what useful features an LBS should

have, while almost completely leaving out the ques-

tions about how to assure a sufﬁcient level of such

basic properties as reliability or response accuracy.

However, because of the LBS speciﬁcs, assuring it

is both more critical and more difﬁcult than for most

of conventional end-user applications, web or mo-

bile services, requiring therefore increased attention

in practice and probably even some research work

done.

LBSs are applications requiring high dependabil-

ity. Under some worst-case scenarios, a failure of

even the simplest yellow-pages LBS may lead to se-

rious consequences. But even if we do not consider

these worst-case scenarios, it must be obvious that if

a service provider plans to collect any revenues from

his LBSs he should consider the dependability ques-

tion very seriously. Because of the speciﬁcs of LBSs,

clients are lost very quickly if they feel that they can-

not trust the service. And dislike many other innova-

tions, LBSs must be dependable enough already upon

releasing. However, until this is recognized, LBSs are

mainly developed under mottoes like “let’s do what

is possible today” and “something is better than noth-

ing”.

As we mentioned in Section 1, the paper (Grajski

and Kirk, 2003) discusses that in Japan location-based

services seem to be more successful than in Europe.

The authors associate this with the fact that in Japan

more advanced technologies than in Europe are in

use. However, it must be obvious that an LBS with

a low dependability will not be accepted by users no

matter how well it is technologically advanced. On

the other hand, it is generally believed that Japanese

companies in general and Japanese software engi-

neers in particular care much more about quality than

Europeans or Americans, see e.g. (Yamaura, 1998).

Therefore, we could expect that their LBSs are of bet-

ter quality that those available in Europe. This is very

probably one of their main success factors.

In this paper, we also identiﬁed a few major fac-

tors inﬂuencing dependability of LBSs, namely con-

tent quality, software reliability, algorithms appropri-

ateness, interface quality, and communication quality.

A defect in the service with respect to any of these

factors may lead to the service failure. Data ﬂaw, soft-

ware failure or inappropriate algorithm may lead to an

incorrect (or of insufﬁcient precision) answer. Bad in-

terface may lead to user’s inability to comprehend the

answer in time-critical circumstances. Not taking into

account the latency and bandwidth of the mobile net-

work may lead to the situation when the answer fails

to arrive to the user in time.

REFERENCES

Ahonen, J., Junttila, T., Katasonov, A., and Sakkinen, M.

(2003). Insufﬁcient education hinders good testing -

a case study. In Proc. The IASTED Computer Science

and Technology Conference, Cancun, Mexico, pages

32–37.

Barnes, S. J. (2003). Known by the network: The emer-

gence of location-based mobile commerce. In Lim,

E.-P., editor, Advances in Mobile Commerce Tech-

nologies, pages 171–189. Idea Group Publishing.

Beadle, H., Harper, B., Maguire, G., and Judge, J. (1997).

Location aware mobile computing. In Proc. of

IEEE/IEE International Conference on Telecommuni-

cations (ICT’97), Melbourne, Australia, pages 1319–

1324.

Beizer, B. (1990). Software Testing Techniques. Interna-

tional Thompson Computer Press, 2nd edition.

Bisdikian, C., Christensen, J., Davis, II, J., Ebling, M. R.,

Hunt, G., Jerome, W., Lei, H., Maes, S., and Sow, D.

(2001). Enabling location-based applications. In Pro-

ceedings of the 1st international workshop on Mobile

commerce, pages 38–42. ACM Press.

DEPENDABILITY OF LOCATION-BASED SERVICES: A LARGELY OVERLOOKED ASPECT

495

Brewster, S. (2002). Overcoming the lack of screen space

on mobile computers. Personal and Ubiquitous Com-

puting, 6(3):188–205.

Carpenter, P. B. (1999). Veriﬁcation of requirements

for saftey-critical software. In Proceedings of the

1999 annual ACM SIGAda international conference

on Ada, pages 23–29. ACM Press.

Chae, M., Choi, Y., Kim, H., Yu, H., and Kim, J. (2000).

Premier pas of mobile internet business: A survey

research on mobile internet service. In Proc. 2000

KMIS/OA International Conference, Korea, pages

218–222.

Chae, M. and Kim, J. (2001). Information quality for mo-

bile internet services: A theoretical model with empir-

ical validation. In Proc. 22th International Conference

on Information Systems, New Orleans, Louisiana,

USA. Association for Information Systems.

Chincholle, D., Goldstein, M., Nyberg, M., and Eriksson,

M. (2002). Lost or found? A usability evaluation

of a mobile navigation and location-based service.

In Proc. Mobile HCI 2002, volume 2411 of Lecture

Notes in Computer Science, pages 211–224. Springer-

Verlag.

Dao, D., Rizos, C., and Wang, J. (2002). Location-based

services: Technical and business issues. GPS Solu-

tions, 6(3):169–178.

Dommety, G. and Jain, R. (1996). Potential networking ap-

plications of Global Positioning Systems (GPS), Tech.

Rep. TR-24. CS Dept., The Ohio State University.

D’Roza, T. and Bilchev, G. (2003). An overview of

location-based services. BT Technology Journal,

21(1):20–27.

Grajski, K. A. and Kirk, E. (2003). Towards a mobile mul-

timedia age - location-based services: A case study.

Wireless Personal Communications: An International

Journal, 26(2-3):105–116.

GSM Association (2003). Membership and market

statistics as at end of May 2003. Available through

http://www.gsmworld.com/news/statistics/stats

03.pdf.

Hjelm, J. (2002). Creating Location Services for the Wire-

less Web. John Wiley & Sons.

Holland, S., Morse, D. R., and Gedenryd, H. (2002). Audio-

GPS: Spatial audio navigation with a minimal atten-

tion interface. Personal and Ubiquitous Computing,

6(4):253–259.

Jagoe, A. (2003). Mobile Location Services: The Deﬁnitive

Guide. Prentice Hall PTR.

Kaasinen, E. (2003). User needs for location-aware mo-

bile services. Personal and Ubiquitous Computing,

7(1):70–79.

Karahanna, E., Straub, D. W., and Chervany, N. L. (1999).

Information technology adoption across time: A

cross-sectional comparison of pre-adoption and post-

adoption beliefs. MIS Quarterly, 23(2):183–213.

Katasonov, A. and Sakkinen, M. (2003). Information qual-

ity assessment of a yellow-pages location-based ser-

vice. In Proc. The 27th International Computer Soft-

ware and Applications Conference (COMPSAC’03),

Dallas, USA, pages 320–326. IEEE.

ohne, F., Totz, C., and Wehmeyer, K. (2003). Consumer

preferences for location-based service attributes - a

conjoint analysis. In Proc. The 2nd International Con-

ference on Mobile Business (M-Business’03), Vienna,

Austria, pages 115–127. Inderscience Publishers.

Landor, P. (2003). Understanding the foundation of mo-

bile content quality: A presentation of a new research

ﬁeld. In Proc. 36th Annual Hawaii International Con-

ference on System Sciences (HICSS’03) - Track 3,

page 88.2. IEEE Computer Society.

Mitchell, K. and Whitmore, M. (2003). Location based

services: Locating the money. In Mennecke, B. E.

and Strader, T. J., editors, Mobile commerce: tech-

nology, theory, and applications, pages 51–66. Idea

Group Publishing.

Nguyen, H. Q., Johnson, B., Hackett, M., and Johnson, R.

(2003). Testing Applications on the Web: Test Plan-

ning for Mobile and Internet-Based Systems. John Wi-

ley & Sons, 2nd edition.

Rao, B. and Minakakis, L. (2003). Evolution of mobile

location-based services. Communications of the ACM,

46(12):61–65.

Schilit, B. N., Adams, N. I., and Want, R. (1994). Context-

aware computing applications. In Proc. of the IEEE

Workshop on Mobile Computing Systems and Appli-

cations, Santa Cruz, USA, pages 85–90.

Singhal, S., Bridgman, T., Suryanarayana, L., Mauney, D.,

Alvinen, J., Bevis, D., Chan, J., and Hild, S. (2001).

The Wireless Application Protocol. Addison-Wesley,

Boston.

The Research Room (2003). European Location-

Based Services 2003: Operator Status & Market

Drivers - Report Overview. Available through

http://www.theresearchroom.com/Brochures/European

Location-Based Services - brochure.pdf.

Tsalgatidou, A., Veijalainen, J., Markkula, J., Katasonov,

A., and Hadjiefthymiades, S. (2003). Mobile E-

commerce and location-based services: Technology

and requirements. In Proc. 9th Scandinavian Re-

search Conference on Geographical Information Sci-

ences (ScanGIS’03), Espoo, Finland, pages 1–14.

Unni, R. and Harmon, R. (2003). Location-based services:

Models for strategy development in m-commerce. In

Proc. Portland International Conference on Manage-

ment of Engineering and Technology (PICMET’03),

pages 416 –424.

Yamaura, T. (1998). Why Johnny can’t test? IEEE Soft-

ware, 15(2):113–115.

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

496