|
|
LUDDIDE - Location and User Dependent Information DeliveryJames Cutler, Charles Fraleigh, Devendra Jaisinghani, Dora Karali, Emre KicimanStanford University |
PDA devices with wireless Internet access such as the Palm VII, CDPD modem-equipped Palm V's, and WAP phones are beginning to become a reality. In order to recognize the potential of these devices, users must be able to identify services which are available at different locations. For example, if a user is stuck in traffic, she may want to be able to access traffic reports for that area. If a user is shopping in a store, he may want to query the store's server to determine if an item is in stock and in which aisle it is located. If a user is walking down University Avenue in Palo Alto, she may want to find out information about a nearby restaurant. To some extent, existing Internet search engines, such as Yahoo! and Google, or regional services such as City Search can be used to find services which are available at a particular location. However, finding information for a particular location involves a cumbersome search procedure and requires the users to have some a priori knowledge about the services they are looking for (e.g. they must know the appropriate regional server to use for their query, and they must know some keyword for which to search). In many cases the users will not have this information, all they know is that they need the traffic report for their current location or they want recommendations for nearby restaurants. To solve this problem, we developed the LUDDIDE (Location and User DepenDent Information DElivery) system. LUDDIDE can dynamically compose Internet services for wireless PDA devices using user location and user preference information. The LUDDIDE system receives an http request from a user which includes the user's location and the user's identity. Using this information, LUDDIDE determines what services are available at that location, contacts the services, and returns the data from the services to the user.
To demonstrate this system, we developed a set of services to be used in a traditional brick-and-mortar bookstore. The services include book reviews, top 10 lists, and the ability to purchase a book using the PDA. The bookstore example is compelling because it provides a benefit to both the service provider (bookstore) and the user. The bookstore benefits by being able to offer some of the advantages of on-line shopping to their customers. The bookstore is also able to give personalized offers to each customer. The customer benefits from a more pleasant shopping experience. The customer does not have to find a sales clerk to determine if a book is in stock, and the customer does not have to wait in line to check out with a cashier. Furthermore, the bookstore example provides a way to incrementally deploy location dependent services. Initially, many users will not have a wireless PDA. For these users, the store can provide PDAs which can only be used within their store.
Supporting location dependent services requires three elements:
The wireless network access will eventually be available to users on their cellular phones or PDAs. As an interim solution, individual stores can deploy local wireless networks (e.g. wireless Ethernet) and provide PDAs for their customers to use while shopping. To determine location information, wireless PDAs can use GPS receivers in the wide area. These receivers are currently available for about $100. Indoors, pseduo GPS satellites can be installed by the stores to provide location information or IR beacons can be used to transmit location codes directly to the PDAs [GPS]. If the PDAs use a local wireless network such as bluetooth or wireless Ethernet, the location of the device can be inferred from the characteristics of the signal received at the wireless base stations. Similar approaches are being developed for cellular phone-based devices in order to comply with an FCC regulation requiring wireless service providers to be able to determine the position of 911 callers to within 125 meters [94-102].
For this project we assume that the wireless network access and the location information are available, and we develop the software infrastructure needed to support location dependent services. Section 2 discusses the business model for this system. Section 3 presents the system architecture, and Section 4 describes our implementation. Section 5 is an evaluation of the LUDDIDE system, and Section 6 describes the user experience.
Wireless location services are predicted to become a $3.9 billion business by the year 2004 [W99]. The question is who is going to deploy these services. We believe that much of the infrastructure will be developed by wireless service providers. This is already happening to support Internet enabled cellular phones and wireless PDAs such as the Palm VII. We also believe brick-and-mortar stores will develop the actual location based services in order to compete with on-line retailers. As location based services become more prevalent, we also believe individual users will begin to develop their own services much in the same way users of the Palm Pilot have developed their own applications.
With brick-and-mortar stores, a possible conflict may arise since users could look up prices from other vendors for the same product and choose another vendor if the price is better. Unfortunately, there is nothing brick-and-mortar stores can do to prevent this. If a user brings in his own Palm VII, he can look at Amazon to see if the price is better. This will happen, regardless of whether the store implements its own location dependent services. All the store can do is try to provide a more pleasant experience for the user so that the user will want to shop in that store.
While designing the LUDDIDE system, we made heavy use of the principle of simplicity. We wanted to keep the individual modules, the interactions between the modules, and the architecture as a whole as simple as possible. We also attempted to limit hard problems such as persistent state, to only the necessary components of our architecture.
Early in our design, we identified four major goals of our architecture:
Issues that we did not explicitly address in our design, but nonetheless feel are very important, are the security and privacy of users and services, and end-to-end fault semantics of a request.
The core LUDDIDE architecture consists of four core components: the Front-End, the Dispatcher, the User and Location Directories, and the Paths composition system for services and transformers (Figure 1). These components are largely independent.
The Front-End component listens for client requests coming in on a client-specific protocol (e.g., HTTP, WTP). It parses the request into a list of arguments: the userid, the location, and a set of active services and service arguments. It then forwards this request to a dispatcher, and waits for a response. When the response arrives, it is forwarded to the client.
The Dispatcher receives requests from the Front-End. Based on the information contained in the request, it then looks up user- and location-specific services from the directories, and plans a composition of these services together with a set of transformers that will create a final document. This composition plan is sent to the Paths subsystem for implementation.
The User and Location Directories are distributed, global directory services, and could be implemented as a Globe directory service [SHT99] or Ninja Service Discovery Service [CZHJK]. The Location Directory tracks relationships between locations (for hierarchical location maps), tracks services available at a given location, and maps requests for abstract services (e.g., a weather service) to specific service instances (e.g., the KTVU weather service for Palo Alto). The User Directory is analogous to the Location Directory, mapping requests for abstract services in the context of individual users. Services in these directories are also marked as required and/or default services for given locales and users.
The Paths subsystem is a framework for composing services and data transformers [K]. In the paths vocabulary, services and data transformers are called operators. Connectors transport data between machines. The data-flow through these operators and connectors is called a path. Operators and connectors in a path are almost arbitrarily composable, limited only by the types of data that each can understand.
Given the composition plan for a path generated by the Dispatcher component, the Paths subsystem will initiate the data-flow, possibly over the wide-area. This path will generate the requested data, transform it into a client-specific format, and deliver it to the Front-End responsible for the client request.
The goal of our prototype system was to demonstrate an end-to-end LUDDIDE system supporting a small subset of possible services. We chose a book store environment for our prototype. Our example LUDDIDE services available to clients include retrieval of book review, top 10 lists and book purchasing. The client interface was through a Palm III with a serial line TCP/IP connection. Location information was obtained through IR beacons to the Palm III.
The core LUDDIDE components were implemented in Java, using JDK 1.2.2 for Linux. We used Ninja v1.5 [NINJA] as a base for implementing our architecture. We wrote an HTTP-Front-End to enable standard web browsers as clients of our architectures. Our directory services were single-node directories, and use XSet, an XML database, to provide flexible query capabilities. We used a prototype implementation of the Paths system.
All services were implemented as Paths operators. Each service generated output in XML format. To transform this to HTML, we implemented a template-based XML to HTML converter, and each service specified a set of templates to use to perform the conversion. This way, the actual service data and its presentation is separated allowing for the same service to be offered in many different devices and combined with a variety of other services.
For all of the services a book database was necessary to provide the book data. We used the XSet main memory XML database [XSET] and query engine, and stored all the book information as XML entities. The information stored in the database was prefetched. We implemented this by scraping book information from Amazon's web-site using a breadth-first algorithm and extracted the relevant information fields (e.g., title, author, reviews). The book rank (RANK1) was derived from and related to Amazon's Sales Rank for that book. The books in a particular section were then ranked (RANK2) according to RANK1.
Based on the user request - top 10 for the bookstore or top 10 for a particular section - an appropriate XSet query was made to the database which returned the books between the range 1 and 10 for RANK1 or RANK2 as appropriate.
The book search service allows a user to enter a keyword and returns all books matching this keyword. The comparison is performed against the author and title of the book.
At the time of our prototype, we did not have access to wireless Internet connections for the Palm III. We used a serial link from the Palm to a Linux machine that was running PPP and IP Masquerading [POSTPC]. Our serial speed was 38,400 bps.
During our demo, a visitor brought a Palm Pilot V with a wireless modem capable of 19,200 bps. Unfortunately, we did not get the chance to install the Palm software on his device and attempt to connect to the LUDDIDE system via his wireless connection!
Web browsing on the Palm was achieved through the services of Proxinet [PROX]. Their ProxiWeb is a graphical browser for Palm devices that interfaces to their proxy servers, which in turn intelligently transforms web content for Palm devices.
Location discovery was obtained through IR beaconing. A Linux desktop with a serial interface to an IR transponder periodically broadcast a beacon with location information. Software on the Palm received this beacon, composed a URL based on the location and previously recorded user identity information. The Palm user was then polled to determine if they wanted the new LUDDIDE URL to be automatically loaded into ProxiWeb and retrieved.
The beacon information was transmitted using IrOBEX, the object exchange protocol for IrDa [IrOBEX][IrDA]. Linux software from Open-OBEX project [Open OBEX] was used to broadcast the IR beacons. Custom software was written for the Palm.
Devoting a large percentage of effort in the design stage proved beneficial since we encountered no major problems while integrating the code. Use of Paths (and hence the Ninja framework) also allowed considerable ease in building and composing new services. Service composability was a key design goal and we were able to achieve it. In actual practice a service data (for example, book review) would be fetched on-the-fly. To do this effectively would require partnerships with service providers and since we didn't have one we prefetched the data and stored it locally. On the client side due to limitations in the Palm, the location and web interface for the Palm was not as streamlined as we would have liked. One difficulty was the Palm's limited serial capability. Both the RS-232 port and the IR port share the same UART within the Palm. This means that only one port can be active at a time. So, when we were connected to the web, we could not receive beacons. When we were receiving beacons, we could not be connected to the web. A possible solution to this is to perform the entire communication over IR. This was not explored for the prototype. Native wireless devices such as the Palm VII this should not encounter this problems.
The Paths subsystem is the underlying framework for service composition and can be shared by different service providers to implement services. However, this is not a deliverable component of our project, rather we leveraged it.
The design allows for a user to create his/her profile and the store to update the user's preferences. For the implementation however, we statically created user names and profiles.
For most part the data is mostly read-only and has BASE semantics. The exception to this is the user profile (which may also include his/her credit card number). This has ACID semantics and will be stored on a database server. The user preferences maintained by each service provider (for example, a bookstore) may or may not be stored on a database server depending on the value the service provider may derive from such information and the ease of reconstructing it should a loss occur. For our implementation both user profile and preference were pre-created and were static.
State management concerns with tracking the pages(services) viewed by the user and an indication of which service the user is currently perusing is displayed by a location bar on the PDA. This navigational aid also helps the user in reloading a page if due to some failure the page is not served. A failure (hard or soft) during a transaction, for example, buying a book, will lead to loss of data in our current implementation. However in actual production system the transactional services would be implemented on a database server.
The current implementation is a single node implementation. The potential bottlenecks are - Front-End, Dispatcher, User Directory, Location Directory, and the Service Provider Server itself. Adding more users and/or services can inundate any or all of these components. Further, geographical scaling even with a fixed number of users/services can also create bottlenecks or performance problems. To alleviate these, there would be multiple Front-Ends, each implemented on a node and geographically dispersed as required. The Dispatcher itself may be implemented in a distributed fashion with a set of Front-Ends statically bound to one Dispatcher node (or another as well for redundancy). The directories themselves would be hierarchical and distributed. At the Dispatcher level the user profile would be stored and the location would be at the granularity of a service provider, for example, a bookstore, a restaurant, a grocery, etc. The location at each service provider and hence the services provided therein would be stored by each service provider. As such, for example, a bookstore may store user preferences, locations in terms of book sections, and the services it may provide at such locations. This also decouples the modification or introduction of a new service from that at another service provider. Depending on the traffic at each service provider the services may be implemented on a cluster.
In our architecture, we provide location- and user-dependent information by using the location and user id of the user when resolving the names of the services to invoke. In practice, this turns out to be very flexible and useful. We can provide location- and user-specific information at any granularity we want to, simply by providing the appropriate mapping function between the location and user context and service instances.
One important note is that our architecture does not strictly depend on any particular method for discovering a client's location. The only requirement is that the location directory be able to understand the location information provided by the client. The source of the location information can be the client itself, or some other entity in the network infrastructure, as long as the Front-End has some way of discovering the location of individual clients.
We provide support for heterogeneous clients by separating the service-specific elements of our architecture from the client-specific ones. Only the Front-End communicates directly with the client. This insulates the rest of our architecture from the particular client protocol. Only a handful of transformers in the service composition know explicitly about the data format the client is expecting, additionally, none of these transformers are service-specific. This lets us add new services without writing any client-specific code. Similarly, we can add support for new clients without changing existing service code.
Complementing support for heterogeneous clients is support for heterogeneous services. Though we feel this is an important feature, we have not engineered our system to support service heterogeneity to the same degree that we have for client heterogeneity. To the extent that we support service heterogeneity, we do so by encapsulating services as simple operators in the Path system, and separating service-specific code from client-specific code.
The LUDDIDE system has to offer new opportunities to both the service providers and the users of hand-held devices. In general terms, the user creates a profile with LUDDIDE indicating the services that he is interested in. When the user connects to LUDDIDE, there is an authentication mechanism, using for example a login and password. After the authentication, the location dependent services combined with the user preferences are presented on the PDA screen. As the user changes location, walking on a street or walking around a store, the location dependent services that are displayed on his screen change too.
As an example, John has subscribed to the LUDDIDE services. Since he is interested in the daily news, he has asked as a personal service the daily headlines from New York Times. John is now at Palo Alto and he enters the Stanford BookStore. LUDDIDE identifies his location and presents on the PDA screen (i) location services: a Welcome message from the store, advertisements for the new releases and a navigation map and (ii) personal services: the daily news from NYT etc. John is very interested in history books, so he wants to find the history section. He uses the navigation map to find the location and moves directly there. LUDDIDE identifies the change of location and new information related to the history section is now sent to the PDA screen: The top 10 books of the section, a service to purchase a book, and a service to find out more information about a book. As John is searching on the shelves, he finds an interesting book, but he would like to have more information. He writes the book title on the PDA and he can receive detailed information about the book. Editorial and customer reviews, other related books, and other services similar to those available at on-line stores are now available at the Stanford BookStore. Since John is a very good customer of Stanford BookStore he also gets an offer of 15% off of all his purchases! John read excellent reviews about the book so he decides to buy it. He is running out of time though, and he cannot wait at the cashier's line. Using LUDDIDE, he can buy the book on-line using his PDA, just clicking on the "buy" button. As he exits the store, he can show his electronic receipt and leave right away.
There are may other services that could be made available to consumers. Notification of sales on items on your shopping list while being in a super market, related items at cooperating stores, nearby restaurants and gas stations, order notification in a restaurant etc. Users can also specify their global preferences describing how they want their PDAs to act on different events. Thus, they could also access personal services like their e-mail and calendar etc.
At the same time, service providers can easily and quickly deploy their electronic location services, to enhance their customers' experience and compete with e-commerce. More specifically, the service providers have to decide about the services they want to provide in different locations, and register them into the LUDDIDE Location Directory under some specific logical location. When a user is found in that location, the services will be presented automatically. The service creation and hosting could be handled either by the store/business itself or by a third party. Also, in case some customers do not have their personal PDA or for policy reasons, the store could provide some type of hand-held device for location information specific only to the store.
We believe that the above described user experience is very exciting, convenient and useful for customers and PDA users. At the same time, businesses could use it as a means to provide better customer services and compete with the on-line market. Therefore we believe that LUDDIDE could target to both PDA users and business market.
The LUDDIDE system is capable of dynamically composing services based on user preference and location information. Given a request from a mobile user indicating the user's identity and the user's location, LUDDIDE can discover what services are available at that location and the services in which the user is interested. Using the Paths subsystem, LUDDIDE will dynamically compose these services and deliver the data to the user.
We implemented a set of bookstore related services to demonstrate the capabilities of the LUDDIDE system. Future work would be to enhance these bookstore services with maps of the store, more sophisticated user profiling services (e.g. targeted advertising), and support for bar-code readers embedded in PDA devices. In addition, additional services such as city maps, traffic reports, and other store-based services, could be added to the LUDDIDE system. The major task would be to extend the location database to support wide-area distributed information. The system could also be extended to support coordinate based location information (i.e. latitude/longitude) rather than the logical locations (Stanford/Bookstore/Fiction). Another area of future research is to implement security and privacy policies in the LUDDIDE system.
We would like to acknowledge the help and advice we received from John Barton, Jean Tourrilhes, and John Schett, HP labs about the IR capabilities of the Palm Pilot, Kathy Richardson and David Cheriton for their suggestions on the system architecture, Extended Systems for providing IR transmitters, Puma Technologies for the ProxiNet web browser, Armando Fox and the rest of the SWIG team.