FUTURE WIRELESS APPLICATIONS
`
`PAWNS: SATISFYING THE NEED FOR
`UBIQUITOUS SECURE CONNECTIVITY AND
`LOCATION SERVICES
`
`PARAMVIR BAHL, WILF RUSSELL, AND YI-MIN WANG, MICROSOFT RESEARCH
`ANAND BALACHANDRAN AND GEOFFREY M. VOELKER, UNIVERSITY OF CALIFORNIA
`ALLEN MIU, MIT
`
`Policy
`manager
`
`n
`
`Wireless subnet
`
`Implementing and
`deploying public-area
`wireless networks
`present a number of
`practical challenges,
`including network
`security, privacy,
`authentication,
`mobility management,
`and provisioning
`of key services.
`
`ABSTRACT
`The dawning of the 21st century has seen
`unprecedented growth in the number of wireless
`users, applications, and network access technolo-
`gies. This trend is enabling the vision of perva-
`sive ubiquitous computing where users have
`network access anytime, anywhere, and applica-
`tions are location-sensitive and context-aware.
`To realize this vision, we need to extend network
`connectivity beyond private networks, such as
`corporate and university networks, into public
`spaces like airports, malls, hotels, parks, arenas,
`and so on — those places where individuals
`spend a considerable amount of their time out-
`side private networks.
`In this article we argue that wireless LAN
`technologies are the ideal mechanism for extend-
`ing network connectivity to these public places,
`and enabling location and context-aware applica-
`tions in them. However, implementing and
`deploying public area wireless networks
`(PAWNs) present a number of practical chal-
`lenges, including network security, privacy,
`authentication, mobility management, and provi-
`sioning of key services. We discuss these chal-
`lenges as a general problem for PAWNs, and
`then describe a PAWN we have designed, imple-
`mented, and deployed called CHOICE that
`addresses them. We describe the architecture
`and components of CHOICE, the service models
`it supports, and the location services and con-
`text-aware applications we have implemented
`and deployed in it.
`INTRODUCTION
`The dawning of the 21st century has seen
`unprecedented growth in the number of wireless
`users, applications, and network access technolo-
`gies. This trend is enabling the vision of pervasive
`ubiquitous computing where users have network
`access anytime, anywhere, and applications are
`location-sensitive and context-aware. To realize
`this vision, we need to extend network connectivity
`beyond private networks, such as corporate and
`
`university networks, into public spaces like air-
`ports, malls, hotels, parks, arenas, and so on; those
`places where individuals spend a considerable
`amount of their time outside of private networks.
`In this article we argue that the substantial per-
`formance benefits of wireless LANs make them
`ideal for public area wireless networks (PAWNs).
`Although next-generation cellular networks will
`undoubtedly play a role in providing wide-area
`long-range service, advances in indoor short-range
`wireless communication technology and the prolif-
`eration of lightweight handheld devices with built-
`in high-speed radio access have made wireless
`LAN deployments increasingly common. Based on
`the IEEE 802.11 standard [1], wireless LANs are
`emerging as the ideal solution for providing high-
`speed connectivity in private networks and, to a
`limited extent so far, public places. As a result,
`network connectivity at 11 Mb/s is becoming com-
`monplace, and this data rate is expected to grow
`tenfold in the next three years [2].
`However, wireless LANs alone are not suffi-
`cient for implementing public-area wireless net-
`works, and there are a number of challenges in
`making them a viable platform for PAWNs. First,
`network access in public places must be able to
`support a wide range of service models, from free
`access to paid connectivity to differentiated quali-
`ty of service. As a result, PAWNs must support
`mechanisms that enable providers to implement a
`wide range of policies for providing user access to
`the wireless network. For policies that restrict
`user access (i.e., nonfree access), PAWNs must
`authenticate users before providing them service,
`and must secure the network against unautho-
`rized and malicious access. For policies that
`require payment, PAWNs must provide mecha-
`nisms for implementing accounting and billing
`services. Second, to support location-sensitive and
`context-aware applications, PAWNs must also
`provide mechanisms for both determining and
`disseminating location and other contextual infor-
`mation about users to their applications. Finally,
`PAWNs must keep all personal information, such
`as communication traffic and contextual informa-
`tion like user location, private and secure.
`
`40
`
`1070-9916/02/$17.00 © 2002 IEEE
`
`IEEE Wireless Communications • Feburary 2002
`
`STARWOOD Ex 1004, page 1
`
`

`

`A new set of
`transactional and
`collaborative
`applications that
`exploit the
`knowledge of user
`locations can be
`deployed in the
`public setting
`according to the
`users’ needs and
`preferences. In other
`words, users can
`“shop” for multiple
`levels of network
`services.
`
`Over the past year, we have designed, imple-
`mented, and deployed a PAWN called CHOICE
`that addresses these challenges in one integrated
`system [3]. CHOICE is a service platform on
`which any number of network providers can
`offer network services, enabling users to choose
`the kind of service that best fits their needs. It
`supports two kinds of service models, one that
`enables free access to local intranet services like
`a local Web server, and a second enhanced ser-
`vice model that supports billed access with full
`Internet connectivity with various quality of ser-
`vice options. It uses a network admission server
`in conjunction with a global authentication
`database to authenticate users and grant them
`access to the wired network. It uses a traffic con-
`trol gateway to perform per-packet verification
`to enforce authorized access, quality of service
`policies, and accounting constraints. Finally, it
`supports various mechanisms for determining
`user location and propagating that information
`to location-sensitive and context-aware applica-
`tions. Altogether, CHOICE demonstrates that
`wireless LANs are a compelling technology for
`providing high-performance wireless network
`access in public places.
`The rest of this article is organized as follows.
`We discuss the deployment considerations for
`implementing a PAWN, particularly one that
`supports context-aware applications. We describe
`the architecture, service models, and location
`services and applications of CHOICE, a PAWN
`we have implemented and deployed. We explain
`why a PAWN such as CHOICE is practical and
`a commercially viable alternative to other net-
`work architectures such as cellular networks.
`Finally, we summarize the article.
`PUBLIC AREA WIRELESS NETWORKS
`In this section we begin by discussing the deploy-
`ment issues that make PAWNs different from
`network deployments in home and enterprise
`settings. We then describe the types of access
`services PAWNs can be expected to provide.
`Finally, we discuss the issues in providing loca-
`tion services in PAWNs.
`DEPLOYMENT ISSUES
`PAWNs present many challenges to the network
`designer. First and foremost among them is the
`lack of an implicit trust relationship between the
`users and the public network. In contrast, home
`and enterprise networks have prearranged trust
`relationships with their users, so access to the
`network can be conveniently granted through a
`preconfigured common key. Public networks
`need to provide access to unknown users who
`may not have visited the network before. This
`necessitates the use of a formal authentication
`mechanism that enables users to identify them-
`selves to the network. Authentication also makes
`users accountable for the services they use in the
`network, thereby providing a convenient means
`of billing. Also, all users may not prefer the
`same mode of authentication. Hence, the net-
`work must have a provision to support multiple
`authentication options. Finally, the authentica-
`tion process must be end-to-end secure. In other
`words, no one except the user and the authenti-
`
`cating entity must be privy to personal informa-
`tion such as username, password, credit card
`numbers, and so on.
`Furthermore, public networks are exposed to
`malicious users and are thus vulnerable to many
`kinds of attacks. Therefore, in order to secure
`the host organization, there is a need to perform
`access control in addition to user authentication
`to prevent unauthorized users from accessing the
`network. The access control mechanism should
`guard against the most common modes of attack,
`like dictionary attacks on passwords, replay
`attacks, and IP and MAC address spoofing.
`A third aspect that differentiates PAWNs
`from private networks is that of service differen-
`tiation. In other words, since access is provided
`in an “individual-centric” manner, it is possible
`to offer enhanced services to users who are will-
`ing to pay extra to get better network service.
`For example, service providers may offer higher
`bandwidth connections and privileged access to a
`local music/entertainment repository for the
`savvy user willing to pay more for such service.
`Also, a new set of transactional and collabora-
`tive applications that exploit the knowledge of
`user locations can be deployed in the public set-
`ting according to the users’ needs and prefer-
`ences. In other words, users can “shop” for
`multiple levels of network services. We describe
`the aspects of service differentiation and loca-
`tion-based services in the next two subsections.
`ACCESS SERVICES WITHIN PAWNS
`A PAWN is built under the premise that as long
`as a user’s identity can be established by the host
`organization and he/she agrees to the payment
`options for the services received, the network
`should grant access to the user. However, treat-
`ing every individual independently offers new
`potential for the host organization to offer
`enhanced services to users who desire them. We
`describe these services in more detail below.
`
`Bandwidth Allocation — Bandwidth in the wireless
`domain is a scarce shared resource. This scarcity
`is accentuated by the fact that the demand for
`bandwidth is hard to predict in a public setting,
`which is characterized by a very transient user
`population. In order to satisfy the bandwidth
`demands of all users, the host organization will
`have to implement a quality of service (QoS)
`policy to manage and allocate the bandwidth in
`a scalable manner. Alternatively, bandwidth allo-
`cation could be handled through service policies
`that may have been prenegotiated between the
`host organization and other corporations, effec-
`tively dividing users into various service classes.
`
`Security Provisioning — In the above section, we
`stated that one of the issues in deploying
`PAWNs is securing the host organization against
`malicious attackers. Additionally, a PAWN may
`also provide security services to the user for the
`purposes of data integrity. Authorized users
`should be able to choose varying levels of securi-
`ty for their data. Again, as in the case of band-
`width, this could also be configured via a policy
`where users belonging to a particular organiza-
`tion would be ensured a certain level of encryp-
`tion of their data for a prenegotiated cost.
`
`IEEE Wireless Communications • Feburary 2002
`
`41
`
`STARWOOD Ex 1004, page 2
`
`

`

`cally configured to operate properly when switch-
`ing among public and private networks.
`
`CONTEXT AND LOCATION SERVICES
`WITHIN PAWNS
`A PAWN is typically characterized by users who
`are mobile but often crowd around areas of
`interest (restaurants, mall rest areas, airport ter-
`minals, etc.). This gives the potential to the host
`organization to offer users services that exploit
`knowledge of their geographic location. Such
`location-aware services enable users to interact
`with their immediate environment and the sys-
`tem to mirror the surrounding environment
`intelligently to user devices.
`
`Issues and Differences — Context- and location-
`aware applications have been well researched
`but generally in enterprise settings [5, 6]. Typi-
`cally, these systems have relied on technologies
`such as badges and emitters (based on IR tech-
`nology) attached to users, equipment, and build-
`ing walls that enable the system to create a
`“location map” of the environment using a net-
`work of IR sensors.
`PAWNs open up a new environment to sup-
`port location-aware applications for the follow-
`ing reasons. First, a PAWN is characterized by
`users who are previously unknown to the system.
`Therefore, we cannot often expect these users to
`be equipped with special devices for determining
`location information. Second, PAWNs generally
`span large areas where range-limited sensor
`technologies like IR scale poorly. Thus, provid-
`ing extensive coverage would involve high instal-
`lation and maintenance costs.
`Ideally, a PAWN would implement and
`deploy location-aware services that require limit-
`ed user intervention so that location services can
`be provided transparently. One way to do this is
`to complement the already useful data-network-
`ing capability provided by RF wireless LANs
`with a location capability so that the users
`require no extra hardware to use the service.
`Further, the granularity and accuracy of location
`information needed in a PAWN is very different
`from that in enterprise settings, where location
`information is typically used for indoor surveil-
`lance applications and online collaboration
`between users. Since PAWNs are characterized
`by frequently roaming users, the location infor-
`mation has to be updated at a corresponding
`higher rate. Also, some of these applications
`(see below) may involve financial transactions.
`Therefore security of location information and
`privacy of users is an essential consideration.
`
`Determining Location — As already mentioned, cen-
`tral to each location-aware application is the
`ability to determine user locations with a useful
`degree of accuracy. There are multiple ways one
`could use an RF data network to determine user
`location. Below we describe three algorithms
`that can compute location information with vary-
`ing levels of accuracy:
`Association with the Access Point — The
`naïve approach is to determine the access point
`(AP) in the wireless network that the user is
`associated with. Upon entering the network, the
`
`40
`
`35
`
`30
`
`25
`
`20
`
`15
`
`10
`
`05
`
`Signal strength (mW)
`
`0
`
`5
`
`10
`
`15
`
`20
`Distance (m)
`
`25
`
`30
`
`35
`
`40
`
`I Figure 1. An empirically recorded profile of signal strength as a function of
`distance between transmitter and receiver.
`
`Billing and Accounting — The goal of the billing and
`accounting service is to:
`• Enable the host organization to create flexible
`charging plans and bill users accurately for the
`amount of bandwidth they use
`• Estimate aggregate system demand from mem-
`bers of various organizations that have negotiat-
`ed service packages for their members, thereby
`segregating users into different service classes
`based on the extent of use of network resources
`If the demand from users of a certain organiza-
`tion is particularly high, it could change the
`users to a higher service level and negotiate a
`new agreement with the organization.
`
`Mobility Management — One of the inherent char-
`acteristics of a PAWN is that users are mobile.
`A user may set her mobile device to hibernate at
`home, and then move to a public area serviced
`by a PAWN. After such a migration, the user’s
`device may have to be reconfigured for network
`access in the PAWN. This is due, for example, to
`the changes in security and authentication mod-
`els in PAWNs vs. private networks. Although the
`user may use Mobile IP [4] to handle network-
`layer mobility, the host still needs to be dynami-
`
`Mean
`Median
`90th percentile
`
`20
`18
`16
`14
`12
`10
`
`468
`
`02
`
`Error distance (m)
`
`0
`
`1
`
`2
`3
`4
`Number of access points
`
`5
`
`I Figure 2. The effect of the number of access points on the error in the location
`estimate.
`
`42
`
`IEEE Wireless Communications • Feburary 2002
`
`STARWOOD Ex 1004, page 3
`
`

`

`user can detect the identity of this AP (IP or
`MAC address) from the MAC-level beacons
`periodically sent by all APs. In this approach,
`the wireless device of the user is programmed to
`associate with the AP from which the strongest
`signal is heard. However, knowledge of the AP-
`level association merely indicates that the user is
`within communication range of the AP, and at
`best gives the radius of the largest circle around
`the AP within which the user could be located.
`Using Signal Strength of AP Beacons — In
`order to improve the location estimate obtained
`from AP association, the identity of the AP can be
`used in conjunction with the strength of the beacon
`signal from the AP. The beacon signal strength can
`be used to estimate the user’s radial distance from
`the AP using a simple radio propagation model
`that characterizes how the signal strength varies
`with distance in a radio channel. Indoor signal
`propagation characteristics can be affected by the
`presence of walls and obstructions; consequently,
`the radio propagation model has to take these into
`account before estimating the user’s location. The
`location estimate could be obtained using either
`theoretically computed or empirically determined
`models [7]. As an example, Fig. 1 shows the varia-
`tion of signal strength as a function of the separa-
`tion between transmitter and receiver in an Aironet
`802.11 wireless LAN [8].
`Using Signal Strength From Multiple APs —
`The estimate from the above method can be fur-
`ther improved by using the signal strength values
`from a network of APs. The idea is that, as a user
`moves about the network, there is a clear trend in
`the observed signal strength of the beacons at the
`receiver, and this trend is independently observed
`for every AP within range. As the user moves, the
`location estimation algorithm computes a tuple
`(ss1, ss2, ss3) of the signal strength received
`from multiple APs. An algorithm then matches
`this set with the closest set in a precomputed sig-
`nal strength database that lists the measured sig-
`nal strengths at various fixed locations in the
`network. The coordinates corresponding to the
`closest matching set are guessed to be the user’s
`location. Figure 2 shows that the error distance
`between the actual and estimated locations
`improves considerably as more APs are consid-
`ered in the estimation process, but the effect
`tapers off beyond three APs. There are many
`enhancements to the above technique that
`account for dynamic user mobility and dynamic
`changes in the RF environment, which consider-
`ably reduce the error in the location estimate. For
`these enhancements we refer readers to [9].
`THE CHOICE NETWORK
`Over the past two years we have designed, imple-
`mented, and deployed a PAWN called CHOICE
`at a public mall. Figure 3 shows a user using the
`CHOICE network in the Crossroads Shopping
`Center in Bellevue, Washington.
`We are aware of some recent work in the
`areas of user registration [4], authentication and
`authorization [10], and security [11, 12] in for-
`eign networks. However, to the best of our
`knowledge, the CHOICE architecture is the first
`working system that integrates the tasks of
`authentication, access verification, policy-based
`
`I Figure 3. A user of the CHOICE network at a
`mall in Bellevue, Washington.
`
`Policy
`manager
`
`Global
`authenticator
`
`Internet
`
`Network
`admission
`server
`
`Local services
`
`Traffic
`control
`server
`
`Wireless subnet
`
`I Figure 4. The architecture of the CHOICE public area wireless network.
`
`service provisioning, and location services in a
`lightweight hardware- and protocol- agnostic
`manner. We describe the system components,
`access services, and location-aware services of
`the CHOICE network below.
`SYSTEM ARCHITECTURE AND COMPONENTS
`Figure 4 illustrates an organization of the
`CHOICE network, a wireless network we have
`proposed for large public areas such as airports,
`university campuses, shopping malls, and con-
`vention centers. This network consists of a glob-
`al authenticator, an admission server, one or
`more traffic control gateways, a client module,
`and a policy manager. We briefly describe the
`functions of each component below. For a more
`detailed system-level description of this public
`area network architecture and all of its compo-
`nents and interactions, we refer readers to [13].
`
`Global Authenticator — One way of authenticating
`unknown users in a public network is to use a
`trusted database that is globally available. The
`global authenticator maintains a database of all
`valid users who subscribe to its service, and is
`used to establish the identity of users in an end-
`to-end secure manner. Users can choose one of
`many available authenticators like e-cash sys-
`tems, credit card organizations (e.g., Master-
`Card), digital certificate agencies, or databases
`
`IEEE Wireless Communications • Feburary 2002
`
`43
`
`STARWOOD Ex 1004, page 4
`
`

`

`The policy manager
`maintains entries in
`its policy table to
`enable differentiated
`bandwidth allocation
`for each organization
`that has negotiated
`such a service.
`Alternatively, the
`policy manager can
`also maintain
`general policies
`that segregate users
`into different classes
`based on access cost.
`
`maintained by particular businesses and clubs
`(e.g., Gold Club Frequent Fliers).
`
`Network Admission Server — The network admis-
`sion server (NAS) restricts access to the public
`network until the user is authenticated and
`allows authorized access through the traffic con-
`trol gateway (described below) upon successful
`completion of authentication. When a user first
`enters a PAWN, the DHCP server running on
`the NAS provides an IP address, and the local
`Web server redirects the connection to the glob-
`al authentication service of her choice. The
`user’s client detects the existence of the
`CHOICE network service through service broad-
`casts (see a later section). If not already present,
`the client module needed to detect this service
`can be downloaded from the CHOICE Web
`server, which is always identified by the URL
`http://choice/. At this point, the NAS performs
`IP-address filtering on every incoming packet;
`any packet with a destination address other than
`the DHCP server, the Web server, or the authen-
`ticator is dropped.
`Upon authentication, the NAS provides the
`user and the traffic control gateway with a (key,
`token) pair and a key_id, which are valid for a
`finite amount of time and renewable afterward.
`The key_id is an index into an array of valid (key,
`token) pairs that have been handed out to users.
`The key is used for encryption/decryption and the
`token is the value that is tagged to every packet
`before encrypting it with the key. Thus, the
`encrypted tag provides a cryptographic binding
`between the user and the packet so that the net-
`work can identify the source of the packet and
`determine the packet’s access rights and privileges.
`After obtaining the (key, token) pair from the
`NAS, the user has authorized access to the net-
`work resources; the system then redirects all user
`communication through the traffic control gateway.
`
`Traffic Control Gateway and Client Module — The traf-
`fic control gateway (TCG) handles verification
`and enforces policies on a per-packet basis for
`users authorized by the NAS. In addition to
`checking whether each packet is encrypted with
`the correct key and tagged with the correspond-
`ing token, the TCG also interacts with the poli-
`cy manager (see below) to implement policies
`that may be negotiated between users and the
`host organization. The TCG may either be locat-
`ed one hop into the access network (at the bor-
`der router) or can be built into the wireless APs.
`The client module is a software component
`resident on user devices that tags all outgoing
`packets with the (key, token) pair obtained from
`the NAS. The client module can be downloaded
`from the host organization’s Web server. This fea-
`ture in our architecture enables users to freely
`access the Internet from any PAWN without
`requiring any additional support on their devices
`or any modifications to the protocol stack.
`
`Policy Manager — The goal of the policy manager is
`to enable service differentiation. The policy man-
`ager allows the host organization to set policies
`that may be prenegotiated with other corpora-
`tions. For example, a corporation may negotiate a
`service package with a PAWN deployed in a local
`
`airport such that, whenever any of its employees
`access the airport wireless LAN, the airport pro-
`vides a certain level of bandwidth at a fixed cost.
`The policy manager maintains entries in its policy
`table to enable differentiated bandwidth alloca-
`tion for each organization that has negotiated
`such a service. Alternatively, the policy manager
`can also maintain general policies that segregate
`users into different classes based on access cost.
`When users visit the PAWN, they may be able to
`choose the best available access package after
`assessing them against the criteria of security,
`bandwidth, and cost.
`ACCESS SERVICES WITHIN CHOICE
`We now describe how the CHOICE architecture
`enables the implementation of differentiated ser-
`vices introduced in an earlier section. These ser-
`vices are fulfilled at a cost to the user and are
`based on a differentiated charging model, which
`varies according to the level of service the user
`requires.
`
`Differentiated Bandwidth Allocation — We envision
`that each user who subscribes to the differentiat-
`ed bandwidth service in CHOICE indicates her
`range of bandwidth expectation (bmin, bmax) to
`the network. The resource allocation algorithm
`tries to provide every user with her bmin require-
`ment and shares the remaining available resource
`equally among all users. In order for the network
`to honor the data rate requirements of users, the
`host organization has to meet two requirements:
`• Ensure that users are provided with their
`negotiated data rate during their sessions
`• Ensure that no user consumes more than their
`allocated share of bandwidth
`To ensure the first requirement, the host organi-
`zation performs admission control on new con-
`nections and ideally implements a fair scheduling
`algorithm on admitted connections [14]. The lat-
`ter requirement is achieved at the TCG, which
`performs per-packet verification and thus keeps
`track of the bandwidth consumed by each user
`over time. Users can also change their band-
`width requirements during a session by renegoti-
`ating the service with the host organization.
`
`Security Provisioning — In CHOICE, we support
`multiple levels of security embodied in basic,
`medium, and enhanced modes of security. The
`basic mode provides minimum encryption of the
`security token that is tagged to every outgoing
`packet. Medium encryption encrypts packet
`headers as well, and full encryption encrypts the
`entire packet. The client module running on the
`user’s wireless device can dynamically change
`the encryption algorithm used to encrypt the
`packet. Our architecture does not preclude the
`use of alternative higher-layer security mecha-
`nisms like IPSec [12].
`
`Billing and Accounting — While the TCG imple-
`ments per-packet verification for purposes of
`security, it automatically incorporates per-packet
`accounting for each user. Accounting for the
`amount of bandwidth used by each user is
`achieved as a result of per-packet processing at
`the TCG. The accounting information gathered
`at the per-packet level can then be handed to
`
`44
`
`IEEE Wireless Communications • Feburary 2002
`
`STARWOOD Ex 1004, page 5
`
`

`

`third-party accounting and charging systems that
`would then be responsible for billing [15]. We
`note here that CHOICE does not advocate any
`particular pricing scheme; it only provides the
`mechanisms and flexibility to the host organiza-
`tion for implementing different policies.
`
`Mobility Management Service — We have mentioned
`that users need to be able to seamlessly manage
`and configure their devices when they enter and
`leave a PAWN (see an earlier section). In
`CHOICE, we implement this using a network dis-
`covery service, where the network broadcasts bea-
`cons that contain a unique network identifier, and
`the IP addresses of the NAS and TCG. Thus,
`when the user first enters the PAWN, the client
`module uses the information contained in the
`broadcast beacon to establish the initial connec-
`tion to the Web server and prompts the user to
`begin authentication [16]. After the authentica-
`tion succeeds, the client module receives and
`stores the (key, token) pair, enables packet tag-
`ging, and sets the default gateway to the adver-
`tised TCG. When the user returns to the home
`network, the client module no longer receives any
`beacons and, after a timeout, disables packet tag-
`ging and restores the host’s default network set-
`tings to gain access in the home network. Note
`that the client module still has the un-expired
`(key, token) pair stored in a table indexed by the
`advertised network identifier. Should the user
`decide to return to the same PAWN again, the
`client module can simply re-enable packet tagging
`and provide seamless network access without the
`need for another authentication.
`
`LOCATION-SENSITIVE AND
`CONTEXT-AWARE APPLICATIONS IN CHOICE
`In this section we describe some of the location
`applications built to use the CHOICE network.
`The applications use a combination of the tech-
`niques described earlier for determining user
`location. Our purpose in building, deploying, and
`describing these applications is to show how busi-
`nesses can use PAWNs to offer additional ser-
`vices over and beyond basic Internet access and
`how the CHOICE network enables such services.
`
`WISH (Where IS Harry) — WISH is an application
`deployed on the CHOICE network that enables
`CHOICE users to look for other people who are
`in their vicinity and have allowed their name and
`location to be made publicly available to the sys-
`tem. The URL http://wish/ always resolves to a
`Web page on the CHOICE Web server that
`includes the names of WISH users, their inter-
`ests, tag lines, and so on, and a map pointing out
`the location of each user. The idea is to encour-
`age social interaction between people who may
`not know each other but who may share several
`common interests. Subscription to this service is
`completely voluntary.
`The WISH system, shown in Fig. 5, consists
`of a client software module that sits on a library
`customized for wireless devices (WiLIB) and a
`stateless server module. The control of location
`information dissemination is left solely with the
`user. The WISH client software, running on the
`user’s handheld device, periodically extracts
`
`Graphical Statistics: Port 4
`File View Measurements
`
`MSR Wish Service
`
`File\
`
`Grap
`
`File\
`
`Grap
`
`File\
`
`Grap
`
`http://wish
`
`Eventing
`infrastructure
`
`WISH client
`
`Every 2 minutes
`
`Every 30 seconds
`
`WILIB
`
`Every
`30 seconds
`
`WISH server
`
`Device driver
`
`Every
`30 seconds
`
`Access point
`
`I Figure 5. The WISH service architecture.
`
`from its radio frequency (RF) wireless network
`card the identity of the AP with which the device
`is associated and the strength of the signals
`received from the AP (see an earlier section). It
`then sends this information along with the user’s
`name and activity status to a WISH server. The
`WISH server maintains an RF signal propaga-
`tion model and a table that maps APs to a physi-
`cal location. Using the information provided by
`the client, the WISH system is able to determine
`the user’s real-time location to within a few
`meters of where he/she is. A confidence percent-
`age is associated with each estimate. Note that
`for ease of deployment, we do not use the tech-
`nique of extracting signal strength from multiple
`APs in order to determine the user location (see
`an earlier section).
`
`Location-Based Buddy List — Buddy lists are fairly
`common these days. For example, both AOL
`and MSN messengers provide a buddy list ser-
`vice in their instant messaging software [17, 18].
`We have taken this concept a step further by
`including the notion of location into buddy lists.
`Location-based buddy lists are best explained
`with the help of an example. Say two friends liv-
`ing in different parts of the country arrive at a
`common airport the same time. They are sched-
`uled to take their connecting flights in a few
`hours. They are traveling on different airlines and
`arrive at different gates, so they are not initially in
`contact with each other. Normally, unless they
`had chatted earlier, they would have passed each
`other and not met. However, with CHOICE and
`the location-based buddy list software they get an
`alert that notifies them that their buddy is in the
`vicinity with directions on how to find him. Sever-
`al similar examples can be described, but suffice it
`to say that location is a fairly useful addition to an
`already popular buddy list service.
`Figure 6 shows the architecture for our loca-
`tion-based buddy list service. When a user first
`connects to the PAWN via CHOICE, her pre-
`configured buddy list is extracted and sent to a
`backend eventing serve