A Location-aware Prefetching Mechanism Holger Kirchner1, Reto Krummenacher1, David Edwards-May2 and Thomas Risse1 1
Fraunhofer IPSI, Darmstadt, Germany e-mail: {kirchner, krumm, risse}@ipsi.fraunhofer.de 2
Euromapping, Seyssinet, France e-mail:
[email protected]
Abstract Mobile devices are becoming smaller and smaller, ubiquitous, and connectable to various networks. Access to data while on the move provides for constant updates anytime and anywhere. Nowadays the relevance of information depends to a large extent on a user’s position. In consequence location-awareness becomes more and more important for delivering relevant data. The way users request information can be described as ‘burst-like’, whereby the availability of seamless access to information and communication is a major concern for mobile users. The latter is a challenging task when dealing with unstable and low-bandwidth wireless networks, especially in areas that are not or only poorly covered. Prefetching is an elegant technique to handle information provisioning for users under these circumstances. In this paper, new strategies for prefetching in a location-aware surrounding are investigated.
Keywords Mobile data management, location-awareness, prefetching, eureauweb.
1
Introduction
With the advances in hardware technology, computing devices are getting smaller and smaller while achieving higher performances. At the same time users can, through wireless communication and hand-held computers, access information anytime, anywhere, even while on the move. Compared to a wired network, the performance of a wireless link will always be considerably lower. The networks deployed today (e.g. GSM, GPRS and soon UMTS) are generally providing data transmissions of very limited bandwidth, when compared to the data that is transmitted. Major additional drawbacks of wireless networks are high delays, occasional poor or totally absent coverage and frequent disconnections. Prefetching is a potential technology to overcome these problems. The idea is to transfer information, which the user might need in the future, so that it is already stored on the user’s mobile device when it is accessed. This technique entails two major advantages. First, the system has lower response times because more data is available in the cache. Second, there is less “burst” load placed on the network because prefetching is done only when there is sufficient bandwidth available rather than on demand. In that way the system is able to provide seamless communication and information access and creates the illusion of a link with a considerably higher bandwidth than is actually the case. On the other hand there are two main costs involved in prefetching. The first one is the CPU cycles expended by the prefetching mechanism in determining which data to prefetch at which moment. Cycles are spent both on overhead in gathering the information necessary to make prefetch decisions, and on actually carrying out the prefetch. The second cost is the network bandwidth and
server capacity that is wasted when prefetch decisions inevitably prove less than perfect. At the same time the financial costs increase when dealing with packet switched networks. The remainder of this paper is organized as follows. Section 2 gives a short introduction to the eureauweb system and the motivation for this work. Section 3 provides an overview of related activities in the fields of prefetching and location-awareness in mobile information systems. Section 4 is a discussion of new location-aware prefetching strategies. The paper is finalized with Section 5 containing a conclusion and an outlook over future work.
2
Motivation: The eureauweb™ system
In order to describe the problem of location-aware prefetching, it is helpful to have a look at eureauweb (Kirchner et al., 2004), the system in whose context the work is developed, and to consider a simple example.
Internet GPS
3G e bil Mo
eureauweb Portal
mm Co tio ica un
eureauweb Mobile
n
synchronize
service provider content provider
eureauweb Cradle
end user
eureauweb Mobile
At home
On the boat
Fig. 1: eureauweb system (a) global view, (b) user view eureauweb is a European waterways networked information system. It grants access to a defined set of distributed information services providing travellers with information relevant to their waterway experience. Services are distributed all over Europe (Fig. 1a) and offer e.g. water level data, hotel reservation services or mapping information. The various services differ not only in functionality but also in priority and locality. Services providing emergency and warning functionalities are more important and thus have a higher priority than services providing information about tourist sights. Managing and providing the access points of these services is a function of the service discovery service (SDS). They can be accessed from the eureauweb Portal at home or from the eureauweb Mobile service (Fig. 1b) whilst on the move. The portal offers the possibility to gain access to the eureauweb services and the Internet over wired networks. In that way data relevant to an upcoming trip can be pre-loaded and stored locally. The definition of user and boat profiles to compute the services relevant to a user may also be done via the portal. Before taking the mobile device on the boat it is synchronized with the portal. All information that is not present on the mobile device when leaving for a trip has to be gathered over low-bandwidth 2.5/3G-wireless links. Features such as locks, marinas but also restaurants and museums that are relevant to eureauweb users are tightly bound to waterways and physically distributed along these. A
major requirement expressed by waterway users is the need for up-to-date information about these features, weather forecasts and warnings (Kirchner et al., 2004). Unfortunately, network coverage along waterways cannot be guaranteed. Hence providing seamless access to updated information, even in poorly connected areas, constitutes a major challenge.
3
Related Work
Prefetching is not at all a new concept. Since the very early days of microcomputer technology (Feiertag & Organick, 1972) caching and soon thereafter prefetching or preloading were integral parts of processors and file systems. With the arrival of mobile computing, the anticipation of data or file access is getting more and more crucial. (Tait et al., 1995) were among the first to work out an intelligent file-hoarding tool. The tool automatically detects a user’s file access pattern and hoards the files to present them in a convenient form at disconnection time. Hoarding provides only data that is stored while connected to the network. Hence it is a scheme designed to increase the likelihood that a mobile client is able to continue working during periods of total disconnection from file servers. Prefetching on the other hand is mainly concerned with improving performance. The file server is assumed to be still accessible, although the network connectivity may be weak. Although prefetching attempts to avoid cache misses, some misses may reasonably be expected to occur. A simple consequence of a cache miss is a user based reactive information query and thus slower data access. Many of today’s mobile information systems count on prefetching to improve the quality of their service. Projects like the ones described in (Imai et al., 2001; Kubach & Rothermel, 2001; Ye et al., 1998) are partially or entirely based on WLAN or other high-bandwidth data access. Their approaches are based on so-called info-stations or hot-spotted areas. The idea is to provide the mobile clients with data at specific locations that provide access to WLAN or other high-bandwidth infrastructure. The difficulty lies in the prediction of the data needed on the way from one info-station to another, i.e. on the way to the next WLAN access point. The drawback of these algorithms is related to the hoarding problem. Data that is not present on the mobile devices can either not be accessed at all or has to be downloaded from scratch over WAN (Kubach & Rothermel, 2001). The prefetching mechanism presented in this paper is based on ideas proposed by (Personè et al., 1998; Cho, 2002). (Personè et al., 1998) introduced prefetching by applying a nonuniform one-dimensional movement pattern. This, however, does not match the structure of a more complex waterway network. (Cho, 2002) provides an interesting approach by considering the speed and moving direction of the mobile user. The area taken into account depends on these parameters. Their way to address the problem is nonetheless not suitable enough for a waterways networked information system. As already mentioned the movement pattern of waterway users shows very distinct characteristics. These predicates are addressed in more detail in the next section. A second possibility is applying user-defined itineraries, as is done in (Ye et al., 1998).
4
Prefetching strategies
Prefetching is a technique that is mainly concerned with improving the system performance. It is in general used as an extension or support to the most basic data management method: caching. Caching alone is generally not enough to improve the performance of mobile systems. Moreover, prefetching has a broader application range than simply storing already
used data in a cache. The location-aware prefetching mechanism is designed to address the various user requirements (Kirchner et al. 2004) of mobile systems like eureauweb: ! Up-to-date Information: Service content, e.g. weather forecast or water level data as well as the service availability, e.g. due to maintenance or breakdowns, may change over time. Thus, each time a user wants to access some information the registered services must be detected and the information content fetched from scratch. It makes therefore sense to use prefetching to automatically update the pre-loaded data. ! Response Time: Prefetching allows the gathering of information about up-coming features in advance. This concerns mainly tourist information, e.g. parks, restaurants, shopping facilities. The application is able to store data about these features locally before the user requires it. A second benefit is the possibility to make data available even if there is no access to the information provider. ! Travel Safety: Prefetching allows downloading information that was not requested by the users, but is of high interest to them. This includes information about emergencies, environment changes, like closed locks and marinas, or hazard warnings, like upcoming storms or sudden shoals. Such messages can greatly influence a user’s behaviour and journey. Prefetching puts the users on the safer side by preventing them from running into unexpected troubles. As mentioned earlier the eureauweb system provides access to various services all over Europe providing extensive and diverse services and content. To avoid excessive network traffic and prefetching cycles, the mechanism has to consider different strategies to increase the efficiency of the algorithm and the relevance of the fetched data. The data is defined by a multi-dimensional parameter space. Two dimensions define the geographical area of interest to the user and its current location, while the others are used to represent the user interests, i.e. the service functionalities taken into account. Prefetching is thus filtering all the possible services within the multi-dimensional information space. The prefetching mechanism takes the following filter parameters into account ! a user’s interests through user profiling, ! the priority of services defined by the user or boating expert advisories. ! a user’s movement pattern (location, speed, direction and itineraries). The following sections explain the different aspects and their impact on the prefetching mechanism. 4.1 User profiling Knowledge about a user’s habits, preferences, interests and about a boat’s dimensions, speed and type, is a very important aspect of prefetching. The users therefore need to influence the prefetching mechanism explicitly by defining profiles. The profiles contain records about the itinerary, intermediate stops or final destinations, as well as features of interest that a user likes to be informed about (a survey with waterways experts has resulted in a set of main categories of information (Kirchner et al., 2004)). The latter records are used to determine the set of services relevant to a user. The prefetching mechanism addresses only these and can thus limit the number of services contacted and the data fetched. Assume that a boat user wants to be informed about warning messages but is not interested in theatres and cinemas. In this case the prefetching mechanism contacts only messaging services but no services that provide data about theatres and cinemas.
4.2 Service priorities Some services are more important to users than others, i.e. they must be kept up-to-date and available. Priorities are assigned to the different service categories with respect to service type and user preferences. Sorting the services with respect to the priorities allows the definition of a prefetching schedule. Services with a high priority are addressed more often than lowpriority services, i.e. they appear more often in the schedule and are thus more frequently contacted for updates. Information from warning services for example has a high priority while the content of tourist information providers that is not changing very often, has a lower priority. Strategies related to radio link quality are another application area for service priorities. During periods of channel discontinuity and high interference only limited and unsteady throughput is available. For this reason the prefetching mechanism uses the priorities to decide which data to prefetch. (Gitzenis & Bambos, 2002) propose solutions for channel fluctuation handling. During periods of high link quality, lots of data can be prefetched incurring only minor owner cost. During periods of high channel interferences, however, the mobile device has a motivation to reason about querying data, as otherwise high power costs would be incurred with little chance of a successful reception. It might be practical to only prefetch data with a high or medium priority or to even wait for the interference to subside and then transmit. 4.3 Location-awareness East Sea
Emden
rth No
Demmin
a Se
Lübeck Hamburg
Schwerin
Berlin
Hanover
Magdeburg
Kassel Duisburg Trier
Dresden
Koblenz Frankfurt
Stuttgart Regensburg Basel
Passau
Ulm
Fig.2: (a) German waterways network map, (b) corresponding vector map Due to the fact that eureauweb users generally travel along waterways, mainly rivers, the prefetching mechanism is constantly aware of a user's possible movements. The users are forced to follow a waterway and have only a limited degree of freedom in their actions. Apart from river confluences and lakes, the user can only travel in two directions, upstream and
downstream. Hence, by exploiting the information about the waterway, boat speed and direction the area of interest to the user (target area) can be defined. It is not necessary to consider all the services but only those providing information about features in this area. Before discussing the computation of the target areas, it is necessary to introduce another concept: the eureauweb river coordinate system. The idea is to transform a rather complex waterway network (Fig. 2a) into a vector map (Fig. 2b). Every waterway is defined in a simple and abstract way by its name and a vector. The vector has its origin at river km-point zero and a length equal to the river length. The km-point system is an internationally recognized measure to define distances from point zero along waterways. Every feature can be mapped onto a vector at a given km-point. Besides the waterway vector an orthogonal vector is used to specify the distance in kilometres to the waterway. It is necessary to indicate whether the feature is on the left or on the right side in flow direction (orientation=both, left or right) to ensure bijection. Depending on the location of a feature there are three different possibilities to represent it: ! A feature on the river: LOC = , e.g. the position of a boat: LOC = Rhine, 123.4 ! A feature next to a waterway: LOC = , , e.g. a marina LOC = Rhine, 123.4, right ! Any other feature: LOC = , , , e.g. a medieval castle: LOC =Rhine, 123.4, left, 5.6 4.4 Target areas defined by prefetch zones The user’s current location, his speed and moving direction are applied to define prefetching areas. This algorithm is based on ideas published by (Ren & Dunham, 2000; Cho, 2002). They use a predefined cell plan, as e.g. in GSM networks, and define the area relevant for prefetching by combinations of cells. The areas addressed here are not predefined cells but rather zones that are calculated at runtime by using an adaptive computation (Fig. 3) and the river coordinate system. A fast traveler, with respect to the average speed given by the boat profile, concentrates generally more on the waterway, while slow travelers increasingly consider the direct environment. For the former type of traveler the mechanism provides longer prefetch zones, while for the latter wider zones are proposed. The adaptive algorithm uses the average speed (V) to describe a fixed default prefetch zone (pzL x pzW). From this zone the mechanism computes the dimensions of the current target area with respect to the travel speed. The shape of the zone is therefore directly related to the user’s velocity. pzL, pzW = fixed default prefetch zone length and width V = avg. speed as given by boat profile v = current user speed pzL pzL ⋅ pzW pzLength = ⋅v pzWidth = V pzLength Fig.3: Calculation of the prefetching zone depending on user speed
The prefetching mechanism has to provide the prefetching area (an interval along a waterway and the zone width) and the service category, when querying relevant service access points from an SDS. An interval is a waterway segment defined by two points of the location model
(e.g. =[(Rhine, 123.4); (Rhine, 134.5)]) and covers a range equal to the prefetch zone length. The prefetching mechanism then contacts the services through the access points returned by the SDS and downloads the content to store it in the local cache. 4.5 Target areas defined by an itinerary The previously mentioned approach for defining relevant areas is shown in Fig. 4a. The adaptation of the area with respect to the current user position, his speed and moving direction can be observed through letters A and B. The larger zone A is computed for a slow traveller, while zone B is much longer and thus covering the area relevant to a fast boater. a)
b) 1
G F
D
E
B D C U
U
A eureauweb service
waypoint
U
currentposition
Fig. 4: The definition of target areas with (a) zones, (b) itinerary The mechanism gains additional information about a user’s movement pattern in case the destination of a trip is specified. A route is given by the waterway segments specifying the shortest way from the current location to the destination (Fig. 4b – segments C, D and E). Segments are the waterway stretches between two river crossings or confluences. In addition to the destination a user can define an itinerary by indicating waypoints (Fig. 4b – waypoint 1). Waypoints are harbours, marinas, or other locations where the user plans to stop. In this setting the route is given by the segments passing through all the waypoints (Fig. 4b – segments C, F and G). The segments (Fig. 4b – segments C, D, E, F and G) define intervals along a waterway just as the prefetch zones (Fig. 4a – areas A and B) did. There is basically no difference between the prefetch zone approach and the one based on itineraries with respect to the target areas that are considered when querying service access points from an SDS. For the itinerary approach the prefetching mechanism demands mainly access points for services providing information that needs to be known for a whole trip, e.g. emergency messages and warnings, but also navigation and weather information that could influence the trip. Depending on the length of an itinerary, the mechanism may only consider parts of the defined segments to reduce the amount of information relevant at the time.
5
Conclusion and Outlook
In this paper a location-aware prefetching mechanism is introduced that is independent of any additional infrastructure and that gathers information solely over deployed, low-bandwidth wireless links. The mechanism is originally designed for eureauweb and is adapted to the special characteristics of waterway users’ movements. The mechanism, as well as the underlying location model, could however also be transferred to other application areas such as railway networks and highways. A user’s momentary position, his moving direction and speed, and, if given, the itinerary are applied to compute the area relevant to the traveller. User and boat profiles are used to determine the users’ needs and the ensuing services that assist them best. The target areas and service types are used to obtain the service access points and to prefetch the desired data. Future efforts will be put into dynamic service priority allocation and the development of location-aware cache invalidation algorithms. Caching and prefetching are very closely related. A prefetching mechanism can only improve the system performance successfully if it is combined with an appropriate caching mechanism and subsidiary memory management.
References Cho, G. (2002). Using Predictive Prefetching to Improve Location Awareness of Mobile Information Service. Lecture Notes in Computer Science Vol. 2331/2002 (Int’l Conf. Computational Science (ICCS 2002), Amsterdam, The Netherlands), Springer Verlag: 1128-1136. Feiertag, R. J. & E. I. Organick (1972). The Multics Input/Output System. Proc. Third Symp. Operating Systems Principles, Palo Alto, CA, USA: 35-41. Gitzenis, S., & N. Bambos (2002). Power-Controlled Data Prefetching/Caching in Wireless Packet Networks. Proc. IEEE INFOCOM 2002, 21st Ann. Joint Conf. IEEE Computer and Communications Societies, New York, USA: 1405-1414. Imai, N., H. Morikawa & T. Aoyama (2001). Prefetching Architecture for Hot-Spotted Network. Proc. IEEE Int’l Conf. on Communications (ICC2001), Helsinki, Finland: 2006-2010. Kirchner, H., B. Mahleko, M. Kelly, R. Krummenacher & Z. Wang (2004). eureauweb – An Architecture for a European Waterways Networked Information System. Eleventh Int’l Conf. Information Technology and Travel & Tourism (ENTER’04), Cairo, Egypt: 65-76 (to be published). Kubach, U. & K. Rothermel (2001). Exploiting Location Information for Infostation-Based Hoarding. Proc. Seventh Ann. Int’l Conf. Mobile Computing and Networking (MobiCom’01), Rome, Italy: 15-27. Personè, V. d. N., V. Grassi & A. Morlupi (1998). Modeling and Evaluation of Prefetching Policies for ContextAware Information Services. Proc. Fourth Ann. ACM/IEEE Int’l Conf. Mobile Computing and Networking (MobiCom’98): 55-65. Ren Q. & M.H. Dunham (2000). Using Semantic Caching to Manage Location Dependent Data in Mobile Computing. Proc. Sixth Ann. Int’l Conf. Mobile Computing and Networking (MobiCom’00), Boston, MA, USA: 210-221. Tait, C., H. Lei, S. Acharya & H. Chang (1995). Intelligent file hoarding for mobile computers. Proc. First Int’l Conf. Mobile Computing and Networking (MobiCom’95), Berkeley, California, United States: 119 – 125. Ye, T., H.-A. Jacobsen & R. Katz (1998). Mobile awareness in a wide area wireless network of info-stations. Proc. Fourth Int’l Conf. Mobile Computing and Networking (MobiCom’98), Dallas, TX, USA: 109-120.
