GUIDE II - Context-Sensitive Mobile Services for Residents in a Networked City
GUIDE II - Context-Sensitive Mobile Services for Residents in a Networked CityOur experiences within the GUIDE project have led us to hypothesise that the combination of mobile context-sensitive information and, critically, context-sensitive services may together prove a major catalyst in the development of the mobile data market. The EPSRC funded GUIDE II project will design and develop such a prototype system that will enable us to test this hypothesis.
The foundation for our work is the current GUIDE architecture and infrastructure. In GUIDE II, we will extend this system to reflect recent advances in networking technologies and then to use this state-of-the-art infrastructure to investigate the provision of context-sensitive services. In order to provide an effective demonstration environment the project will thus be required to address the issue of interfacing with existing service providers in the city (we use the term service provider to identify local traders, café owners, taxi services etc. rather than communications providers). This will be achieved using a generic gateway component which will liase with service providers using a range of communications techniques including synthesised speech.
The prototype developed in this project will be evaluated using a series of field trials which will take place within an on-going initiative involving Lancaster University and Lancaster City Council to offer members of the public access to futuristic context-sensitive applications.
Recent advances in high-bandwidth wireless communication and location technologies have led to significant interest in the field of location-aware applications. Such applications exploit location information to provide services that are tailored to a user's location. Between 1997 and 1999, we designed, developed, and deployed the GUIDE system, which allows visitors to the city of Lancaster to receive context-sensitive tourist information as they navigate the city. The GUIDE system had been evaluated through a series of expert walkthroughs and field trials involving members of the public. The findings make us believe that in the future there will be significant interest in wireless applications that are both location-based and oriented toward supporting user community.
In the GUIDE II project, we are exploring the issues raised by these findings in details. The key aim of Guide II project is to investigate the provision of context-sensitive services to visitors to, and residents of, the city of Lancaster. Access to these services will be via mobile end-systems and heterogeneous wireless communications technologies. We believe that the provision of context-sensitive services and information will together form the "killer application" for mobile data access, and the GUIDE II project are aimed at developing a prototype system to investigate this hypothesis. More specifically, we are attempting to answer the following questions in the second phase of the project:
The existing GUIDE network infrastructure is designed to support only the GUIDE application. In order to offer services and applications to the members of public, it is clear that we need to "open up" the existing network infrastructure to support full network layer routing without compromising the integrity and robustness of the system. In addition, in GUIDE II we envisage using a richer set of communication technologies, such as Bluetooth, thus creating a heterogeneous networking infrastructure.
The deployment of the network infrastructure for GUIDE II and the development of innovative mobile services for the general public will directly interact with the recently formed Mobile IPv6 Testbed collaboration between Cisco Systems, Microsoft Research, Orange and Lancaster University. This will provide us with a more realistic test environment for future mobile applications since it is widely anticipated that there will be engineered using IPv6.
The components of the GUIDE II public access wireless network are illustrated in the following diagram. Each wireless cell in the diagram is controlled by a Base Station (BS), which is a link layer entity that operates transparently from the perspective of IP layer. Every BS is associated with an Access Router (AR) that controls the access to the campus network and the Internet. They block traffic originating from unauthorised end-terminals based on network-level packet filtering. Every AR forms a single routable IP subnetwork, named it a District. In order to gain access to the services in our public access wireless network, mobile hosts (such as handheld devices, laptops) need to authenticate themselves with the Authentication Server (AS) first and then perform the packet marking for outbound traffic. AS is responsible for the authentication and authorisation of clients. Upon successful authentication and authorisation of a user, the AS issues a limited lifetime access token to the user, which provides the basis for the client to do the packet marking. We also put a Gateway Router between public network and campus intranet in order to prevent someone masquerading our ARs, . This gateway will only accept traffic originating from the access routers whose MAC addresses are registered in its access control list.
For further information about the GUIDE II network infrastructure, please refer to the publications section.
There are significant numbers of services (such as restaurants, cafes and taxi services) that people wish to have access to electronically that have no on-line presence. Moreover, it seems probable that such services are unlikely to be in a position to accept on-line reservations, bookings and orders for some time to come. In deploying GUIDE II we do not wish to contribute to the creation of a “digital divide” in the city between those services that have an online presence and those that do not.
To address this issue we have constructed an ‘Interactive Services Gateway’ system that aims to broker electronic requests for services with ‘legacy’ human-centric services that currently provide no Internet access to their facilities. In essence, GUIDE users interact with the gateway via a set of web pages while traditional service providers interact with the gateway via a conventional phone interface. The gateway utilises pre-recorded messages and text-to-speech to relay requests for service via a standard telephone line to each client organisation. The recipient of the call uses DTMF (or ‘touch’) tones to navigate the booking options and choose whether or not to accept each request.
Each interactive service that a GUIDE user has access to is comprised of the following elements.
1. An ‘interactive service logic’ (ISL) state machine that denotes the sequence of
options, DTMF tones and recorded messages that realise the booking of a particular service.
2. The set of hypertext pages presented to the GUIDE user. These pages contain special mark-up tags that represent the
parameters of the specific request (such as number of people, time of booking etc.).
3. A corresponding set of ‘check objects’ that perform client-side validation of the
parameters entered by a user to make sure they fall within the acceptable bounds for a given request (e.g. ensuring
that the date and time entered corresponds to the opening hours of the restaurant and so on).
The components of the interactive services gateway that execute service requests are illustrated in the following diagram.
Further information about the GUIDE II interactive service gateway is introduced in the paper named "Future Wireless Applications for a Networked City: Services for Visitors and Residents". You can download it from the publications section.
We are in the process of exploring these ideas further under the auspices of the GUIDE II and Equator projects.
Further details of these services are described in publication [4].
[1] A Wireless Public Access Infrastructure for Supporting Mobile Context-aware IPv6 Applications.
[2] An Access Control Architecture for Metropolitan Area Wireless Networks.
[3] An Access Control Architecture for Microcellular Wireless IPv6 Networks.
For further details, please check back here periodically or contact the key personnel.
Dr. Keith Cheverst (kc@comp.lancs.ac.uk)
Professor Nigel Davies (nigel@comp.lancs.ac.uk or nigel@cs.arizona.edu)
Dr. Adrian Friday (adrian@comp.lancs.ac.uk)
Dr. Keith Mitchell (km@comp.lancs.ac.uk)
Mr. Maomao Wu (maomao@comp.lancs.ac.uk)
