Check out the new USENIX Web site.

Home About USENIX Events Membership Publications Students
MobiSys '05 Paper    [MobiSys '05 Technical Program]

Deploying and Evaluating a Location-Aware System

R. K. Harle
Computer Laboratory
University of Cambridge, UK
Robert.Harle@cl.cam.ac.uk

A. Hopper
Computer Laboratory
University of Cambridge, UK
Andy.Hopper@cl.cam.ac.uk

Abstract

Location-aware systems are typically deployed on a small scale and evaluated technically, in terms of absolute errors. In this paper, the authors present their experience of deploying an indoor location system (the Bat system) over a larger area and running it for a period exceeding two years.
A number of technical considerations are highlighted: a need to consider aesthetics throughout deployment, the disadvantages of specialising sensors for location only, the need for autonomous maintenance of the computational world model, the dangers in coinciding physical and symbolic boundaries, the need to design for space usage rather than space and the need to incorporate feedback mechanisms and power management. An evaluation of long term user experiences is presented, derived from a survey, logged usage data, and empirical observations. Statistically, it is found that 35% wear their Bat daily, 35% characterise their Bat as useful, privacy concerns are rare for almost 90% of users, and users cite the introduction of more applications and the adoption of the system by other users as their chief incentives to be tracked.
Thia paper aims to highlight the need to evaluate large-scale deployments of such systems both technically and through user studies.

1  Introduction

Location-aware computing is an emerging field where the location of people and objects can be used by machines to derive contextual information with which to enhance and assist users in all aspects of their lives. Indoor environments are of particular interest, potentially requiring high precision location information (of the order of centimetres) to infer useful contextual clues from the typically dense distribution of small objects such as computers, telephones, and chairs. Many indoor location systems have been implemented in attempts to achieve such high precision. Over time the field has seen positioning solutions that utilise infrared (room-based accuracy [12,6,13]), ultrasound (centimetre accuracy [14,10,7]), visible light (10-100cm accuracy [11,8]), wireless LAN (metre accuracy [1,2,15]) and Ultra Wideband (UWB, approximately 15cm accuracy).
Historically, deployments of high precision indoor location systems have not involved large coverage areas due to the cost of instrumenting the environment. The most common approach is to instrument a single room, which then acts as a testbed for the location technology. However, this approach fails to represent a deployment from which usage characteristics can be reliably derived. Usage of such a room is likely to be sporadic and not representative of how users would use the space normally. In one attempt to address this, AT&T Research Cambridge and the University of Cambridge jointly developed the Bat system and deployed over a greater area.

2  The Bat System

The Bat system is an ultrasonic location system that makes use of a small, powered tag known as a `Bat' (Figure 1). Bats are encased in sturdy plastic, with approximate dimensions of 8.0×4.0×1.5cm and a weight of 50g. They can be worn on a necklace or attached to a belt clip, according to preference. Bats emit 40kHz ultrasonic pulses on command from a 433MHz radio channel. These pulses are received by a matrix of receivers in the ceiling, each accurately surveyed for position. Each receiver records the time elapsed between pulse emission and reception, thereby allowing determination of each Bat-receiver separation and hence calculation of the Bat position using a multilateration algorithm. Positional accuracy has been previously determined as within 3cm 95% of the time.
hardware.png
Figure 1: A ceiling receiver (left) and a Bat (right). Inset: An installed receiver
A number of applications are presently associated with the Bat system, the most salient of which are as follows:
Map
A graphical map of the coverage area designed for desktop machines.
Broadband Phone Map
A privacy-oriented version of the map, designed to run on a networked broadband phone installed on every desk (Figure 2).
Teleporting/hotdesking
Users can `teleport' any of a number of computer desktops to their nearest machine for truly mobile working.
Access Control
A display with a touch screen interface is mounted at the entrance to the laboratory. Visitors are presented with a list of tracked users who they can alert to their presence and then be directed to the current location of their host.
Pointing device
Bats can be used as a three-dimensional pointing device, analogous to a desktop mouse.
Scanner
The Bat system provides a convenient and intuitive interface to a number of peripherals, including a scanner.
Gaming
A few simple location-based games have been developed.
User-written
There is a large number of small applications that users have developed mostly for personal use. These include alerts for people returning to the office, new email notification, fresh coffee notification, diary reminders, etc. [9].
phone.png
Figure 2: A broadband phone showing a tracking application
The initial deployment of the Bat system at AT&T Research Cambridge covered three floors of a building and provided positioning almost throughout the volume. In this deployment, additional applications were available, including location-based telephone call routing and location-based physical access control. Unfortunately, this deployment is no longer in place.

3  Redeploying the Bat system

Following the decommissioning of the initial deployment, the Bat system was redeployed at Cambridge in 2002. Since then the authors have accrued some valuable general lessons in deploying a pervasive location system over a large area, which are shared here. The lessons are broadly classified into system and user issues. The former deals with issues caused by installing and maintaining the system, whilst the latter considers the experiences of the day to day users.
The redeployment covers a floor area of approximately 450m2 and contains seventeen offices and five communal areas (Figure 3). Positioning coverage is throughout the volume, except for within a small kitchen area and the bathrooms.
lab.png
Figure 3: The deployment area of the Bat system at Cambridge
The deployment was performed as the last stage of building work, after the structural components were installed, but before office furnishings and users were present. Installation, configuration and troubleshooting took approximately eight weeks, during which a number of general issues concerned with the installation and running of the system hardware were identified.

4  System Issues

Mistakes are expected in the deployment of any prototype hardware over a large volume. Here we present a summary of the lessons generated from the deployment.

4.1  Design to be aesthetically pleasing and for minimal distraction

Aesthetics are often overlooked when generating prototype hardware. However, evaluation over a medium- to large- scale deployment means that the hardware will penetrate into the working area of a wide variety of people and aesthetics are vitally important to ensure a pleasant working environment is maintained. The Bat system receivers were designed to be installed above a false ceiling and as such hidden from view. Thus aesthetics at design time were of little concern and the hardware consists of open circuit board shielded by a metal box and interconnected by blue 50-way ribbon cable (Figure 1). These design choices proved a constraint when deploying in the laboratory: a false ceiling had to be installed at extra cost and even then it was required to have `egg crate' ceiling tiles to prevent disruption of air flow in the building (inset, Figure 1). Hence the receivers and their interconnects are more visible than planned. Moreover, the displeasing aesthetics of the hardware has hindered subsequent attempts to redistribute the receivers in a more spatially homogeneous fashion.

4.2  Design for space usage rather than physical space

When deploying Bat receivers in the ceiling, selecting the ideal spatial distribution proved very difficult. Regular geometric patterns are not conducive to position calculation, whilst irregular distributions have negative aesthetics. In the current deployment, receiver locations were chosen to to avoid regular geometry and to give a reasonable spatial distribution for a sighting at any point in a room (Figure 4). The distributions derived from the combination of practicalities (ceiling accessibility, cable lengths) and the results of an optimisation simulation. This simulation aimed to find ceiling distributions that gave good and uniform positional coverage for the majority of the volume served. A regular three-dimensional grid of test points was defined for each room and the number of receivers set, based on room area. The simulated receivers were then allowed to move, with each individual configuration given an `energy' state based on calculating dilution of precision metrics across the test points. To settle on a final distribution, a simulated annealing approach was used to identify good spatial arrangements.
Since installation, however, it has become apparent that the distribution of sensors in the ceiling would be better deployed according to the regular use of the space, rather than its size and shape. For example, to achieve uniform positioning capabilities throughout a room typically required the slight degradation of positioning in one area to improve positioning elsewhere. Once office furniture was installed, it became apparent that uniform coverage was often unnecessary; users rarely use the whole of the space uniformly and the deployment distribution would be better tailored to the usage of the space. This favours the deployment of such a system after the space usage has been established. This complicates any deployment, but should improve performance.
receivers.png
Figure 4: Receiver distribution (compare with Figure 3)

4.3  Beware the coincidence of physical and symbolic boundaries

The Bat system was designed to be modular in operation, distributing the positioning calculations across multiple DSPs. Since ultrasound does not penetrate walls, a decision was made that each room would contain an independent chain of receivers and an independent DSP to handle any local multilateration calculations. Hence the system was segmented according to physical boundaries. In retrospect, however, this was a sub-optimal approach because it hinders reliable capture of room change events (since a handover from one receiver chain to another is necessary). Room changes are important location events since many applications trigger events when they occur. The per-room distribution of receiver chains effectively forces a Bat to transition from one chain to another when visibility of the sensors in either chain is at its lowest. Thus we observe positioning failures near doorways, resulting in delays for room change events (Figure 5(a)).
Abstracting from this experience, we find that it is not always ideal to coincide physical boundaries with virtual boundaries (in this case th physical boundary of the chains and the boundary between two symbolic room entities). In this particular example, the issue could be addressed by the inclusion of spatial chain mixing at transition points (Figure 5(b)). Equally, a system redesign could dispense with the notion of multiple sensor chains completely, but this would require an offload of all positioning calculations to a central processor, hindering scalability.
handovers0.png handovers1.png
Figure 5: Chain mixing at physical boundaries

4.4  Incorporate autonomous maintenance

Perhaps the most difficult aspect of maintaining a working location-aware system has proved to be maintenance of the computational world model: a spatial database of objects from which context is inferred from location data. A more accurate model may allow for a less accurate location system. For example, a user and computer both tracked to within 0.5m can be replaced with a user tracked to within 1m, and a computer at a known location. Thus, the creation and maintenance of an accurate world model is very important.
To keep the model synchronous with the physical world requires the precise tracking of people, furniture, devices, books, etc. Bats (and indeed, any powered tags) are not generally suitable for all classes of object - the infeasibility of regular battery changes, the added weight and cost make their deployment on truly everything prohibitive.
At present the world model used in the laboratory is hand-maintained, with changes being incorporated into the spatial database manually when reported or observed. Users of the Bat system have not felt it their responsibility to update the model when they effect any changes on the physical world, despite having software tools available to do so. Thus, maintenance is primarily achieved by manual intervention of the group members who make use of the location data. This manual approach is barely practicable on the laboratory scale, and limits the tracked objects to more bulky items that are less likely to move - the database has the capability to model arbitrary devices and objects, but the difficulties in maintaining it manually has resulted in only bulky furniture and computer hosts being modelled.. Any increase in deployment scale (without a corresponding increase in maintenance personnel) would render the approach altogether infeasible.
Over time, then, we have observed the world model to fall out of synchronisation with the real world and to require manual correction since the system does not incorporate an autonomous world model monitoring component. We have found that the loss of this synchronisation is of great significance: users become irate with the system, which does not perform as expected due to incorrect contextual inferences, and rejection of the entire location system can follow suit. Autonomous maintenance has proved to be a very difficult problem and we have actively researched ways in which it might be performed, identifying a number of starting points deriving from sighting distributions [5], and analysis of the ultrasonic signals in the system [3,4]. Future work will incorporate different tracking technologies for different classes of object.

4.5  Design to maximise context gathering

In examining the signals within the Bat system it has become apparent that the system could, in principle, be used to gather further contextual information. In practice, however, its design as a positioning system has resulted in optimisations that hinder extraction of this data. The major optimisation is the choice of ceiling mounted receivers: for Bats worn at chest height, this maximises receiver visibility. The Bats have been further optimised such that ultrasonic emissions are primarily upwards. Whilst this increases power efficiency, the inefficiency of allowing a Bat to emit ultrasound more homogeneously would benefit location-aware computing since the associated increased penetration of ultrasound into the surrounding environment allows inferences about the locality and assists in autonomous maintenance as previously mentioned.
Moreover, alongside more homogeneous spatial emissions of ultrasound from a Bat, it is useful to have a more homogeneous spatial distribution of receivers throughout a volume. It is infeasible to locate receivers in a truly homogeneous manner throughout three-dimensional space, but siting receivers at a variety of heights on the walls and outskirts of a room is possible (albeit aesthetically displeasing). The extra density may not increase positional accuracy significantly, but may allow for better signal penetration and positioning below objects (the ceiling-mounted system suffers from a loss of tracking if a tracked object lies beneath another, for example robots cannot be tracked under tables. Receiver visibility would be dramatically improved by receivers being placed at lower heights).
A distribution of receivers across the space rather than the ceiling also offers the ability to more accurately estimate the orientation of the user. At present, a coarse estimation is made by examining ultrasonic power distributions and shadowing (assuming users block the ultrasound to receivers behind them). A series of receivers placed around the vertical centre of the room would offer much better orientation estimation since it would allow for measurement of power distributions in the horizontal plane including the Bat. Orientation is a useful contextual clue and it is advisable for new location systems to offer the capability to detect it reliably.
In summary, the optimisations needed for a positioning system designed solely for positioning may differ from those for a positioning system designed to underpin an indoor location-aware service.

4.6  Beware false positives and false negatives

Experiences using the Bat system on a daily basis have highlighted that the location information is rarely definitive due to an unfortunate side effect of using a tag-based tracking system: false negatives and false positives.
False negatives occur when an application interprets a lack of sightings for a user as an indication of absence. For example, if a user cannot locate another through the Bat system they may assume they are not present. In fact they are faced with an ambiguity: is the user away or simply not wearing their Bat? The ambiguity can only be resolved by using traditional methods (physical sight, telephone calls, etc) and hence most users default to these initially.
False positives are most often associated with Bats being physically unassociated with the corresponding user location. So, for example, a user may leave their Bat on their desk at lunchtime and the system continues to report that they are tracked and within their office. This is misleading data that leads to confusion and annoyance.
To combat false negatives and false positives the Bat system supports the idea of a quiet zone - a small spatial region individual to each user within which the user's Bat will not be tracked. Users can thus leave their Bats in these zones if they do not wish to be tracked or as a way to tell the system that they are not present (although ambiguity still exists between these two states). False positives are prevented (assuming the user either wears their Bat or returns it to their quiet zone). False negatives still remain, since users can forget to take their Bat out of their quiet zone. As a by-product, Bats can be put into a sleep state when in such zones, conserving power. Jitter switches are used to rouse Bats when next picked up.
Initial experiences with quiet zones revealed that few users could be relied upon to return their Bat to their personal quiet zone despite having been the ones to locate them, making false positives an issue once more. Users often placed their Bats outside their zone since they had not chosen a zone with strong physical markers that allowed them to accurately recover the zone location.
To encourage the use of quiet zones and minimise incorrect context derivations a global quiet zone (a physically obvious communal region within which all Bats sleep) was introduced at the exit of our area and the system software was altered to emit a beep from any Bat when it entered the sleep state. A noticeable reduction in the number of Bats left outside quiet zones has occurred.

4.7  Include feedback capabilities

The introduction of a beep when Bats enter quiet zones is an example of the importance of including feedback in applications, a concept that has proved to be very important. The need for feedback has long been touted by the HCI domain, but it becomes even more important in location-aware computing, where traditional input/output devices are not available; a location-based system performing an action such as unlocking a door as a user approaches cannot assume there is a convenient visual display by the door to indicate the success (or failure) of the action. Whatever input device is used to enable, disable or configure location-aware applications must include some form of feedback to tell the user that input was successful. Similarly error conditions (such as the door failing to unlock) must be reported to give users an intuitive feeling of what is occurring and to allow them to retain a feeling of control. The inclusion of a simple tone-generating speaker in each Bat has been extremely useful: so much so, in fact, that the ten pre-configured tunes in the Bat firmware are becoming insufficient to allow communication of the many feedback messages that now exist (each alert and error alone needs a different tone or sequence of tones).

4.8  Include power management

In any active tag-based system, power management is a very important issue. Current battery technology means lightweight tags may not offer the optimum lifetime. Two approaches to battery lifetime are possible:
Minimise power consumption.
Reduce power consumption to maximise battery lifetime.
Fit recharging into human cycle.
Many users will have a daily cycle that allows for recharging with minimum irritation. For example, Bats could have been designed to support a 12-hour charge, and to be recharged overnight or when not in use. This would make them more lightweight, but cause issues when recharging is incomplete or accidentally forgotten about.
The Bat system as implemented opts for the former approach. In doing so, it uses a high capacity 3.6V battery in the AA form-factor. Regular battery changes are unacceptable, so each Bat features extensive power saving features: jitter switches are used to determine whether the tracked object is moving significantly, and the polling rate dynamically adapted to avoid fast polling when the user is seated or stationary. Very high polling rates are reserved for use with applications that need them. This provides a battery lifetime of approximately eighteen months for a Bat in regular and normal use. Furthermore, an on-board voltage monitor on each Bat can be interrogated so Bats with a dying battery can be identified and batteries changed before a loss of service occurs. Experiences show this to be a very useful feature and for the battery lifetime to be sufficiently long not to cause irritation.
A down side to such a lengthy power lifetime has been that users treat Bats as perpetual machines, assuming a hardware fault rather than a lack of power when the Bat stops functioning properly. However, the inclusion of a power-monitoring hardware component that can be remotely interrogated has allowed for recent battery failures to be pre-empted.

5  User Issues

Over the years the deployed Bat system has been available to all members of the laboratory and many visitors. The laboratory contains a significant mix of technical users with different specialisations: some users work within location-aware computing, some within high speed networking, and yet others in radio communications. The advantage of the laboratory deployment, then, is that the user base is not solely those who developed the system (as is often the case). There is no reason for users to wear a Bat unless they choose to do so: the system is purely opt-in.
Computed locations are logged and archived each day. The large number of events that flow through the system are not logged unless a fault diagnosis is required. This limits the conclusions we can draw from the archived data, especially since false negatives and false positives are both common in the logs. We have filtered the log data to attempt to identify Bats that were stationary (minimising false positives), but we have no mechanism to determine whether a user was present on a particular day and chose not to wear their Bat. To further gain insight into the usage of the system and the feelings of its long term users, we issued a short survey to all members of the laboratory, whether they had a Bat assigned or not (approximately 30 users). Twenty four responses to the survey were received, failing to represent the entire population. The makeup of the members assigned Bats is predominantly male (in the current deployment, a total of four women have been assigned Bats), to the extent that we cannot reasonably draw conclusions about differences between sexes.
We recognise that the survey results are not guaranteed to be bias-free but we use them, in conjunction with the logs we have archived, to illustrate the characteristics that have established themselves empirically over time through informal discussions and observations. Their use is also given in the hope it will encourage more detailed evaluations of similar systems and their users.
The results of the small study have been divided into three major categories; usage, applications, and user classifications.

5.1  Usage

graph2.png
Figure 6: User-rated comfort of wearing a Bat
graph5.png
Figure 7: Duration of the novelty period when assigned a Bat
graph12.png
Figure 8: Frequency of wearing a Bat
Since installation, all but three members of the laboratory have been assigned Bats (the others requesting not to be). The survey revealed that 77.3% considered wearing a Bat to be unnoticeable or an occasional distraction, whilst 13.6% found it annoying (Figure 6). It is difficult to design a robust powered tag that can be worn so as not to be obscured by other clothing or different human positions. For example, attachment to a belt may be more comfortable, but introduces problems when the tag is obscured by a jacket, or by a table for seated users. Wearing it at chest height (using a necklace) maintains a good visibility of ceiling receivers but does not suit some users, who find the occasional swinging motion annoying. One user commented that, having worn the Bat daily for some time, he now finds it more noticeable when he isn't wearing it.
Figure 9 shows the usage of a Bat for a frequent system user. The usage is typical, with the Bat being worn for the majority of the day. However, not all users use their Bat in the same way: Figure 10 shows the average number of sightings for nine (anonymised) users, captured over a 27 month period. The actual values cannot be taken as absolute since false positives may exist and an active user may accrue more sightings within a given time period than a less active colleague due to the variable polling rate. However, averaging each point over a month should minimise the impact of such concerns. It is apparent from the graph that Bat usage varied dramatically for all users over the 27 months. Of particular interest is the peak usages recorded in January 2003 - this corresponds to the full roll-out of the current system. What we observe is a novelty period during which the users wore their Bats religiously. A few months later, the average sightings per day have dropped significantly.
Figure 9: Typical usage of a Bat over one day
all.png
Figure 10: Logged system usage over 27 months
The survey revealed that users also recognise this period, but they reported a wide range of values for the duration of it (Figure 7). It seems reasonable to assume users will experience at least a few days of novelty interest. This highlights the importance of deploying a system with a wide variety of applications immediately available. User curiosity and interest is greatest during the novelty period and a readily available set of applications offers a powerful opportunity to demonstrate what location-aware computing can offer them and for them to integrate it into their routines. In the laboratory deployment, emphasis was placed on achieving a robust system, and not all applications were rolled out simultaneously (indeed, some were yet to be conceived).
Following the novelty factor usage often drops: the survey indicated only 42.1% of surveyed users wear their Bat on a daily basis and 31.5% hardly ever (Figure 8). Figure 11 shows a frequency count for the daily number of distinct users of the system over five months in 2004 (chosen to minimise the likelihood of holidays and excluding weekends). To reduce false positives, a user was included only if they were observed to move more than 1m within the day. The histogram data suggests an average of 12.2 people using their Bat daily, which is approximately 40% of the users currently assigned Bats. This supports the survey results, but the histogram further illustrates a high variability in usage,
histogram.png
Figure 11: Unique daily users in 2004
When asked to characterise their Bat a wide variety of responses were given (Figure 12), illustrating how different users perceive its usefulness. The majority of users appear to recognise that location-aware computing can contribute favourably to their lives, but these results suggest that at present not every user of the system is able to identify an application they find useful.
graph11.png
Figure 12: Characterising a Bat

5.2  Applications

Applications are clearly crucial in any large scale system deployment. The survey revealed a wide range in the frequency of application usage (Figure 13); a quarter only used location-aware applications when they felt they had to. Encouraging users to wear Bats and use the associated applications has been the subject of previous work [9], where specific audiences were identified and applications tailored to them. Interestingly, some users seemed also to associate a novelty period with new applications targeted at them. However, Bat usage quickly returned to its previous levels. The survey revealed that the two most popular incentives for users to increase their Bat usage were the implementation of more applications and for more users to wear their Bats (Figure 14).
graph6.png
Figure 13: Frequency of location-aware application use
graph14.png
Figure 14: What would encourage the wearing of a Bat? Key to answers: A - Nothing, B - Privacy Controls, C - More applications, D - Greater system reliability, E - More lightweight design, F - If more lab members wore one than currently do, G - A reminder to put it on
Users commonly indicate that they want more applications, but can rarely identify a specific application that would be useful to them. This echoes the fact that many users are unsure about exactly what location-aware technology can offer them and are presently keen to explore.
The latter suggestion - that users won't wear Bats until others choose to - leads to a pervasive application vicious cycle as shown in Figure 15. Breaking such a cycle has proved difficult - the most obvious methods for doing so are the introduction of a rule that Bats must be worn (generally undesirable, giving Bats a spy-like character) or the introduction of an application perceived globally to be of use (an ongoing research area).
cycle.png
Figure 15: The pervasive application vicious cycle
With regard to specific applications, the survey revealed that the most popular class of applications in use were mapping applications. These applications can be very useful for locating colleagues and assets in a busy office environment. The general consensus within the laboratory is that a larger deployment would increase the usage of such applications further.
The cost in walking to a neighbouring office to see who is there is not great enough to make it worth calling up a tracking application to check. A coverage zone extending over many floors means that the the cost of `manually' checking whether a colleague is in their office two floors below seems too large in comparison to checking a location-aware map, and we would expect adoption of mapping applications to be much greater. It is true to say that in the three storey building that housed AT&T Research, Bat usage was far more common, perhaps attributable to the need to locate people quickly over a larger volume. Similarly, three responses to the survey indicated that a larger coverage area (or the coverage of physically separated areas) would encourage them to wear their Bat more often. The true worth of some location-aware applications will only become apparent with a very large deployment, beyond any implementation so far.
One popular application quoted in the survey was an alert service for when fresh coffee was available. This has no location aspect to it all - it uses the ability of the Bats to provide aural feedback to use them as wireless pagers. So it is interesting to find that the addition of more traditional applications of wireless technology has encouraged the adoption of Bats, simultaneously discouraging the pervasive application vicious cycle.

5.3  User classification

Mansley et al. grouped users of the system according to their common aims and tasks [9]. Over time it has become apparent that users of the Bat system at any instant can be be more generally classified according to how they both perceive and use the Bat system and its associated services. The classifications exist within a hierarchy (illustrated in Figure 16):
users.png
Figure 16: Classifying users of the Bat system
Novelty Seeking
Users in this category wear their Bat and allow themselves to be tracked purely for novelty. Their main interest is in discovering the system capabilities and evaluating how it can enhance their lives, if at all.
Group oriented
Users in this category are concerned with all other users in the system and can subdivided as follows:
Adoptive users
These users adopt the system and use its applications on a regular basis. The majority of these are those researching location-aware computing.
Altruistic users
These users derive little use from the Bat system, but are prepared to wear their Bats regularly to increase the system utility for other users. For example, they are willing to be tracked so others can locate them using Bat applications, but use more traditional methods when seeking those colleagues themselves.
Individual oriented
These users view the system as it applies to them as individuals rather than group members. Within this category we find:
Benefit-seeking users
These users wear a Bat if there is a personal benefit. For example, so a particular application they find useful will function.
Cost-reducing users
The inverse of benefit-seeking users, these users will reject being tracked until a particular cost is removed, regardless of benefits. An example might be a user who will not be tracked because she feels she is being spied upon.
Figure 17 illustrates the difference in Bat usage for a benefit-seeking and an adoptive user. The data was collected across one month and clearly shows the benefit-seeker using the system sporadically, when it suits them. This contrasts with the adoptive user, who wears a Bat even when not using location-aware applications. We have very few examples of cost-reducing users within the laboratory, although a few have identified the cost of privacy to be a major issue. Indeed, in demonstrating the system to a wide variety of people the authors have become aware that the initial response of many is to fear a privacy invasion. The most common privacy fear quoted is that of the employer monitoring the employee. Interestingly, then, the survey found that privacy concerned laboratory users very little (Figure 18). This is perhaps attributable to two factors: firstly, the location data is not available outside the laboratory and so little information is available that could not be ascertained by walking through the laboratory; secondly, a Bat can be taken off at any time for privacy. It is also worth noting that, as a research establishment, working hours are not strict so there is little worry of them being policed. In a more commercial environment this may be more of a concern.
user_class.png
Figure 17: Daily sightings for two users over one month
graph7.png
Figure 18: How much privacy concerns users
The survey of how often users wear Bats (Figure 8) is consistent with the empirical observation that most laboratory users are now either adoptive or benefit-seeking in nature. The peaks observable in Figure 10 occur at significant times. In particular, we see increased usage in late 2003, which we attribute to the roll-out of location-aware applications on the broadband phone network, and some usage peaking around April 2004, when a further set of location-aware applications were made available.
When questioned about whether they would wear a Bat if it benefited their colleagues, 59% indicated that they would (Figure 19). Certainly, a higher proportion of users wear their Bats for limited periods when so requested for research or demonstration purposes. These facts indicate that many members can also be classified as altruistic in their Bat usage.
graph13.png
Figure 19: Ascertaining whether users would wear a Bat if it made the system more useful to others

6  Conclusions

This paper has presented a unique portrayal of the deployment and usage of a location-aware system encompassing a medium-sized volume and regularly available to a wide range of technical people over an extended period.
Deployment experiences have produced a set of non-obvious guidelines to assist future large-scale deployments:
  • Design for space usage rather than physical space.
  • Beware the coincidence of physical and symbolic boundaries.
  • Incorporate autonomous maintenance.
  • Design for maximal signal penetration.
  • Beware false positives and false negatives.
  • Include feedback capabilities.
  • Include power management.
This paper has also presented the results of surveying members of the laboratory that have access to Bats. The major highlights are:
  • The majority (77.3%) feel comfortable wearing a 50g tag around their neck.
  • Initial assignment of a location tag often results in a novelty period that typically lasts days.
  • 42.1% now wear a Bat on a daily basis.
  • The majority characterise their Bat as useful or fun.
  • Applications are crucial to a good deployment
  • A pervasive application vicious cycle is evident, where users reject some applications because others do not use them.
  • False negatives in tracking complicate location-aware applications.
  • Users differ in how they perceive and use the location-aware system, and distinct classifications are apparent.
  • Location privacy is rarely a concern in the deployment environment.
The survey presented cannot be taken as definitive: it represents a small sample space and relates to a research (office) environment with a majority of technically competent users. However it is representative of the observed usage of the system since deployment. It would be interesting to compare these results for a series of deployments across areas with different typical usages, and also to investigate whether different sexes perceive and use the technology in different ways. The present deployment has too few female users to draw useful conclusions (note that this is due to a male dominance in the field rather than women opting out).

7  Future Work

The work has highlighted a need for a greater diversity of location-aware applications to allow users to determine what the technology can offer them. It has also underlined how important it is to test such technology on a larger scale than a single room: new challenges become apparent (maintaining the world model, aesthetics, etc.) and usage can be evaluated by regular users of the space to see what it actually contributes.
It is hoped that this paper will encourage large deployments of location technology in spaces outside research establishments, and lead to detailed human factors studies.

8  Acknowledgements

Many of the findings herein are the fruits of discussions with a variety of members of the Laboratory for Communication Engineering, who we thank for their contributions. We also wish to thank the MobiSys reviewers and our paper shepherd, Anthony LaMarca, for their useful comments.

References

[1]
P. Bahl, V. N. Padmanabhan, and A. Balachandran. Enhancements to the RADAR user location and tracking system. Technical report, Microsoft Research, February 2000.
[2]
A. Bystrom, T. Dahlroth, J. Eriksson, L. Fernandez, D. Holmgren, T. Johansson, P. Larsson, I. Styf, M. Stahl, N. Varillas, and M. Wu. Advanced Wavelan Positioning System. SMD116 Program Project, May 2001.
[3]
R. K. Harle and A. Hopper. Building World Models By Ray-tracing Within Ceiling-Mounted Positioning Systems. In Proceedings of UbiComp, Seattle, Washington, US, October 2003.
[4]
R. K. Harle and A. Hopper. Dynamic World Models from Ray-tracing. In Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications, Orlando, Florida (PerCom 2004), March 2004.
[5]
R.K. Harle and A. Hopper. Using Personnel Movements For Indoor Autonomous Environment Discovery. In Proceedings of the First IEEE International Conference on Pervasive Computing and Communications, Fort Worth, TX, US (PerCom 2003), pages 125-132, March 2003.
[6]
A. Harter and A. Hopper. A distributed location system for the active office. IEEE Network, 8(1), 1994.
[7]
M. Hazas and A. Ward. A Novel Broadband Ultrasonic Location System. In Proceedings of UbiComp 2002: Fourth International Conference on Ubiquitous Computing, 2002.
[8]
J. Krumm, S. Harris, B. Meyers, B Brumitt, M. Hale, and S.. Shafer. Multi-Camera Multi-Person Tracking for EasyLiving. In Proceedings of the Third International Workshop on Visual Surveillance, July 2000.
[9]
K. Mansley, A. Beresford, and D. Scott. The Carrot Approach: Encouraging use of location systems. In Proceedings of UbiComp. Springer, September 2004.
[10]
N. B. Priyantha, A. Chakraborty, and H. Balakrishnan. The Cricket Location-Support System. Proceedings of the Sixth Annual ACM International Conference on Mobile Computing Networking, August 2000.
[11]
W. Rungsarityotin and T. Starner. Finding location using omnidirectional video on a wearable computing platform. In ISWC, pages 61-68, 2000.
[12]
R. Want, A. Hopper, V. Falcao, and J. Gibbons. The Active Badge Location System. ACM Transactions on Information Systems, January 1992.
[13]
R. Want, B. N. Schilit, N. I. Adams, R. Gold, K. Petersen, D. Goldberg, J. R. Ellis, and M. Weiser. An overview of the PARCTAB ubiquitous computing experiment. IEEE Personal Communications, 2(6):28-33, December 1995.
[14]
A. M. R. Ward. Sensor-driven Computing. PhD thesis, Cambridge University, August 1998.
[15]
M. A. Youssef, A. Agrawala, and A. U. Shankar. WLAN Location Determination via Clustering and Probability Distributions. In Proceedings of the First IEEE International Conference on Pervasive Computing and Communications, Fort Worth, TX, US (PerCom 2003), pages 143-152, mar 2003.

This paper was originally published in the Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services, Applications, and Services,
June 6–8, 2005
Seattle, WA

Last changed: 20 May 2005 aw
MobiSys '05 Technical Program
MobiSys '05 Home
USENIX home