a basic architecture for mobile information access

Pergamon Comput. & Graphics, Vol. 20, No. 5, pp. 683-691, 1996

Copyright 0 1996 Elsevier Science Ltd Printed in Great Britain. All rights reserved

0097-8493/96 $15.00 + 0.00

Pn: soo97-8493(96)ooo42-8 Mobile Computing

A BASIC ARCHITECTURE FOR MOBILE INFORMATION ACCESS

J6RG B&IGK’+ and ASTRID LUBINSKI’

‘Computer Graphics Center Restock (ZGDV), Joachim-Jungius-Str. 9, D-18059 Restock, Germany [email protected]

2University of Restock, D-18051 Restock, Germany

Abstract-The mobility of users, devices, and information produces new challenges for processing of globally distributed information. This fact requires a new architecture for the selection, access and exchange of information in a mobile computing environment. In our approach the basic component for such an architecture is the so-called Object Bus for the local and remote exchange of messages. Other main components are Message Handler processes for type dependent handling of messages, and an Object Manager for semantic pre- and post-processing of messages according to the current mobile context. These components all together are designed for the efficient use of the available and dynamically changing resources by adapting their behavior to the mobile environment, e.g. to the current location, to the quality of communication channels, or to user preferences. Copyright 0 1996 Elsevier Science Ltd

1. INTRODUCTION

The presented architecture is one main part of the project “Mobile Visualization”(MoV1) [l]. This project is focused on investigations which shall enable the graphic presentation of scientific and of other, even multimedia, data in a mobile environment. However, there are the well known problems with mobile computing [2-4] which should be considered when designing an architecture for this purpose, e.g. resource poor mobile terminals, limited bandwidth of the communication channels, location and time dependencies of data, variations in quality of transfer, and possible disconnections. The conflict of the user’s needs and the restricted circumstances can be solved or minimized with several techniques. These techniques minimize the needed bandwidth, save the resources of the mobile system, and enable a comfortable work environment on mobile devices. Our architecture is designed to combine these methods and to make the best use of them.

One typical mobile scenario for us is a person accessing very different public or private data stored at several globally distributed stationary data servers (SDS )---the infoverse for exampl-from a mobile end system (MES) using wireless networks, like GSM (Global System for Mobile Communication). The information contained in the infoverse could have multimedia character, e.g. WWW data including audios and videos or weather and traffic data with textual descriptions and images that are managed in files and different database systems. Therefore we need a suitable architecture which includes methods for the access, exchange, and presentation adapted to

+ Author for correspondence.

the mobile computing environment. We cover the different dynamic components characterizing this mobile environment in the context, which influences the functionality of all architectural components. This includes, how to locate, to access, to transfer, and to present information.

We distinguish between four classes of contexts. These classes are user contexts, resources, information contexts, and lastly location and time dependencies.

The remainder of this paper is structured as follows. In Section 2 we will give an introduction to the mobile information exchange process and a general description of our basic architecture. After that, in Sections 34, we will outline the components of our architecture and their main concepts that offer possible solutions for the named problems in more detail. Finally, in Sections 7 and 8, an overview of related work and a summary together with our plans for future work are given.

2. BASIC MOBILE SYSTEM ARCHITECTURE

2.1. Mobile message exchange The basic system architecture has to serve as a

flexible platform for the efficient exchange for all kinds of information in a mobile environment. The main concept of our model is an object oriented approach with the Object Bus (OB) as a central feature. This Object Bus serves as a transparent layer for mobile communication and is responsible for the delivery of messages on the mobile system and stationary systems. In the case of exchange of reply objects, Message Handlers (MH) act in place of the communicating processes. They notify each other about transfer procedures for a certain object and transfer it (see Fig. 1). The communication between

683

J. Biinigk and A. Lubinski

Fig. 1. Principal communication via the Object Bus.

two application processes 1 and 2 is divided into the following main steps:

1. Applications generate requests that are handed over to the local Object Bus for transportation [Fig. l(a)].

2. The following transfer inside the Object Bus is carried out by several components (Network Scheduler, Transfer Manager) which reside between the application and network layer on every computer [Fig. l(b)].

3. The receiver gets the message [Fig. l(c)] and generates reply objects.

4. The reply objects are handed over to appropriate Message Handler processes [Fig. l(d)]. The Message Handlers use knowledge about the context to enrich the request with additional information which is necessary for effective scheduling. Additionally they perform operations on the reply objects like data reduction that are influenced by the resources of the mobile host. These operations are necessary in order to save the limited bandwidth of wireless communication channels.

5. The Message Handlers on both sides transfer the object with suited methods via the Object Bus [Fig. 1 (e-dl.

5. The application receives the reply object [Fig. lth)l.

The third main component is an Object Manager

~..................................._....... ; MES

.

(OM) (see Fig. 2) which covers all trading aspects and the handling of data requests, their results and contexts as representation of the mobile environment with database techniques. It intervenes in the communication flow a, c, d and h between the components in Fig. 1. In addition, Message Handlers and the Object Bus will be provided with necessary context information by the Object Manager.

2.2. Architecture Besides the Object Bus components Network

Scheduler (NS), Request/Reply Cache (RRC), Trans- fer Manager (TM), and User Interface (III) there is an Object Manager on every host (see Fig. 2). It consists of some or all of the following components Resolver (Rslv), Context Manager (ContM) and the Cache, which includes Objects (OC) and Contexts (CC). The communication between applications and Object Bus and Message Handlers respectively is done via the Application Communication Manager (ACoM). The named components will be explained in the following sections. All components of bur architecture mentioned above build together the Information Agent (IA)---besides the Presentation Server and User Agent one main component of our overall system architecture of the MOVI project (see also [S]). That means that the classical client-server architecture is in our case replaced by a client-agent- server architecture. In contrast to other definitions of an agent our Information Agent is built as a stationary agent on every site.

., . . . . . . ..~...“..=....._...............~.._...._.( . I

: : SDS :

: : n I

Fig. 2. Object Bus architecture

Mobile information access 685

3.OBJECTBUS

In the context of mobile computing with slow and unreliable networks, asynchronous calls (messages) are preferred to synchronous calls. The aim of the Object Bus is to manage and efficiently transfer these messages on all kinds of networks. Components of the Object Bus are a Network Scheduler, a Request/ Reply Cache and its manager, a Transfer Manager, as well as a User Interface on mobile hosts. The Object Bus is linked with the local Object Manager where it can access information that is necessary for its work, e.g. the current context information or the address of a requested service.

3.1. Network scheduler The Network Scheduler is a unique component on

each computer (mobile and stationary host) and the main component of the Object Bus. It is responsible for the effective transfer of messages. To achieve this aim it manages a list of all requests that it has received and of all replies that have to be sent to other Network Scheduler’s together with their context information. On the basis of this list, the Network Scheduler determines which request or reply should be sent next in an existing connection with the best use of the channel and hands this message over to the Transfer Manager for transportation. The decision as to which message has to be sent next is not only based on information about the message, like priority, size, and requested QoS parameters, but also on information from the Transfer Manager about the state of connections and on general context information from the Object Manager, like available channels and their parameters. It depends on the intelligence of the Network Scheduler and on the existing resources as to what extent all this information is used to make the decision. It can range from simple scheduling with priorities up to a comprehensive planning logic.

Besides scheduling with priorities and with the influence of quality-of-service parameters, a compression of messages is also initiated by the Network Scheduler in order to save bandwidth (see Section 3.1.3).

For new incoming messages the Network Schedu- ler decides whether to start an appropriate Message Handler that has to handle the message or to deliver the message directly to the receiving ACoM. The latter case is true for messages that do not need a special treatment, e.g. error messages, acknowledgements, or messages where their content is negligible or does not support special techniques (see Section 5.

3.1.1. Priority controlled scheduling. All producers of messages, e.g. applications, Message Handlers, or the Object Manager, add different priorities to requests and their corresponding reply messages dependent on user preferences, on the type of messages, and on the methods that they are applying on them (see Section 4). These priorities are the base for the Network Scheduler in order to carry out an effective scheduling when transferring the requests or

their respective replies to another Network Schedu- ler. The Network Scheduler can act in different ways when interpreting these priorities and other information dependent on the intelligence provided by the Network Scheduler:

l The simplest case is to send the data according to their given priority. Context information will not be considered.

l Not only priorities but also all other relevant context information will be involved in planning of the transfer in case that the Network Scheduler is equipped with sufficient planning logic. This includes information that allows the Network Scheduler to decide whether to use additional techniques like data compression or to reschedule requests to make the best use of existing communication channels.

Due to the scalable design of the Network Schedulers’ intelligence, the way that priorities are interpreted can also be flexibly designed depending on mobile and stationary resources.

3.1.2. Scheduling influenced by QoS parameters. In order to have the possibility of guaranteeing quality- of-service parameters for the transfer of certain messages, and to achieve that way a higher reliability and to reduce costs, it is necessary that a single message contains only objects that have the same demands regarding QoS parameters. This requirement is met by splitting complex reply objects into appropriate subreplies which is performed by the Message Handler processes, by the mobile Applica- tion Interfaces or by the Object Manager. Another requirement is that QoS demands of the object to be transferred and of the concerned communication channel are known and that all transfers are monitored. The QoS values of the communication channels are stored in the local Context Manager.

Parameters that could be evaluated are for example throughput with minimum and maximum values, delay with minimum and maximum values, delay jitters of packets or frames, and bit error rate. Currently we focus on monitoring and evaluating the throughput of channels. Applications have the possibility-based on user preferences and type dependent default values-to define for certain data items thresholds like maximum throughput, maximum transfer time or maximum costs.

If more sophisticated Network Schedulers and Transfer Managers are used, and if adequate resources exist, statistics about the QoS values could be generated. These statistics can be evaluated and used as a base for selecting a communication channel.

Depending on the current values and on the messages that have to be transferred different actions can be carried out by the Network Scheduler:

l selecting a communication channel or switching to another communication channel which can guar-

686 J. BZinigk and A. Lubinslci

antee the demanded QoS values for a certain message and begin or continue the transfer;

l rejecting the transfer of messages if their QoS parameter can not be guaranteed by the given communication channels and no other channel is available;

l canceling a transfer if the required QoS parameters fall under a certain threshold and other channels are not available;

l tolerating higher error rates in messages of certain types (video, audio of lower quality) if no other possibilities exist and the user has set his preferences accordingly;

l communicating with message senders in order to arrange an adaptation of messages to the QoS parameters that could be guaranteed (e.g. increas- ing compression rate or decreasing frame rate when transferring video messages, reduction of resolution when transferring images). However, the tradeoffs that have to be made should be under control of the applications since different applications can have different needs even if they access the same data [6]. 3.1.3. Data compression. In addition to several data

reduction and selection strategies a reduction of delays and of used bandwidth can also be achieved by compression of messages before transferring them [7]. Compression can be carried out by different components of the transfer pipeline:

l by use of compressed data types, e.g. JPEG, MPEG, or GIF;

l by software or hardware components on the network layer;

l by the Network Scheduler. That means, in addition to the methods listed in points 1 and 2 the Network Scheduler should have the ability to perform compression of messages that have to be transferred and decompression of received messages respectively.

In order to plan this task the Network Scheduler needs a lot of information:

l Are the messages already in a compressed state (compressed image data, videos, archives)?

l Will a compression be carried out by the network layer?

l Is an appropriate decompressing function available at the receiving site?

l Mobile resources (processing power, tools for decompression);

l Costs for compression, decompression and transfer of messages (processing time on SDS and MES, energy consumption on the MES, transfer time, temporary storage space);

l Costs for transfer of uncompressed messages (transfer time, temporary storage space).

On the basis of this information the Network Scheduler decides whether and how to compress messages by invocation of compression services on

the SDS before the transfer. If a more sophisticated Network Scheduler is used, and if the system has possibilities for process migration, the transfer of compressed messages together with functions for decompression can also be considered when planning the transfer.

3.2. Request/reply cache In the Request/Reply Cache (Bus cache) requests

and replies are stored at the local host to facilitate immediate delivery to applications when receiving a following identical request. Since local applications also communicate via the Object Bus its Bus cache can also be employed for speeding up local communication.

Due to changing resources it is also necessary to hold additional information about the current contexts in the Bus cache. That means the contexts that were used to determine the reply value will be stored together with request and reply. The Request/Reply Cache Manager is responsible for managing the cached data, that means entering data, deietion and updates by means of given strategies and registration of accesses. In cooperation with the Network Scheduler, access to requests and assigned replies is organized. A combination of several methods serve as a base for minimizing inconsistencies and for decisions as to which cached items have to be deleted [8, 91. In our approach the time since the last modification as well as information about the last recently accessed cached items and information about the type of the items are used for cache management functions.

3.3. User Interface of the Object Bus On mobile end systems the Object Bus includes a

User Interface as an additional component. In addition to the functionality that is offered by applications, the User Interface of the Object Bus provides the user with information about the current state of all active requests and pending replies and allows the interactive control of exchange parameters. The user has for example the possibility to modify request priorities, to cancel transfers and to configure the handling of special message types.

3.4. Transfer Manager The Transfer Manager carries out the lower level

network functions like opening and closing of connections as well as the actual send and receive functions. In order to have the possibility to evaluate QoS parameters it is necessary that this component monitors the traffic at current connections. These traffic data are handed over to the Context Manager so that other components like the Network Scheduler can make use of information about the last connections to a special host as a basis for their decisions.

3 S. Message exchange over the Object Bus Our protocol that is used for the communication

over the Object Bus is a combination of an efficient


protocol for coding of header information and the possibility to express the contents of a message in an application dependent format, like SQL, HTTP, MIME, or KQML. Since the content of a message is not evaluated by the Network Scheduler, all data that are necessary for planning the transfer, e.g. priority, size, and QoS demands have to be part of the header. Currently we are using the eight message types defined in Table 1.

4. APPLICATION COMMUNICATION MANAGER

The Application Communication Manager (ACoM) is an application specific interface to the components of our architecture. It can be realized as a built-in interface in especially designed mobile applications or as a separate component that uses a defined interface of an existing application (see Fig. 2).

It performs the following tasks:

l Requests will be modified according to the contexts in cooperation with the Object Manager. In addition, the resolution of symbolic addresses is performed.

l The ACoM manages a list of all requests and related replies of an application together with applied contexts.

l An important task is the decomposition of complex compound replies. These replies are divided into several subreplies of certain defined types that are handed over to Message Handlers for type specific exchange.

l These Message Handlers have to be started by the Application Communication Manager. They transfer the subreplies to their counterpart at the receiving site (startet by ist Network Scheduler) and hand them over to the receiving ACoM that will reassemble the reply object.

5. MESSAGE HANDLER

Message Handlers serve to exchange requests and appropriate reply objects between processes and to enable access to single units of information. That means that they provide additional functionality to the application to enable a transparent access to remote objects. They are built as processes for the optimized exchange of structured information. They can be launched by the Application Communication

Manager of an application that has generated a reply as well as by the Network Scheduler that receives a suited reply. Due to their object specific design and their knowledge about type and structure of the data to be transferred they are able to use type and structure dependent methods for minimizing network traffic and response times like data reduction and detail-on-demand. The use of these methods is explained in the following subsections.

5.1. Level-of-detail At level-of-detail methods, parts of a structured

object are transmitted in the order of importance. It is necessary for these methods to define levels of detail for suited data types and to order them. In order to save bandwidth the Message Handlers exchange only a limited amount of levels-of-detail at every step. The user can decide to interrupt the transfer earlier if he receives the necessary and adequate information.

The aim of Successive Refinement is the reduction of used bandwidth. Similar to the following detail- on-demand method, the reply data objects are divided into several levels and subreplies are generated for every level or for every set of levels. Differences between both methods exist in the generation of subreplies. When using Successive Refinement, all subreplies will be generated immedi- ately with graded priorities (see Fig. 3, PR). If the user does not intervene, subreplies will be sent by the Message Handler until the entire object is transferred. That means that bandwidth will only be saved in the case that the user cancels the transfer when a certain fragment of the object or a certain level of detail is available.

The aim of detail-on-demand is also to save bandwidth by transferring first only an important and expressive part of the data object. The remai- ninder of the object will be only transferred by demand of the user. With this method subreplies with the first and most important level of detail get the highest priority (see Fig. 3, DOD) whereas subreplies with further, possibly not required levels, will not be generated for the time being or get a very low priority in conjunction with prefetch methods. More subreplies will be generated by the Message Handler or the priority of prefetch subrequests will be increased

Table 1. Message types

Message type

request-info request-context request-get request-modify request-cancel request-next-led

Ieply acknowledge-request acknowledge-reply

Meaning

request information about an object, like object ID, size, or type request information about context information of a special host request an object modify a request, e.g. increase the priority cancel a request request the next level-of-detail when using detail-on-demand send an object or an error message acknowledgement for a received request message acknowledgement for a received reply message

J. Biinigk and A. Lubinski

Fig. 3. Level-of-detail methods: cooperation of ACoM, MH, and NS on a SDS when replying to a request from a MES.

in case the application requests further levels. For the use of this method the message types request- cancel and especially request-next-lod have been defined in our system (see Section 3.5). The user has the possibility to define the method for every suited message type as part of the mobile context and the amount of levels-of-detail that should be transferred in one step.

5.2. Data reduction One important task of the Message Handlers and

the database component on the stationary site is to reduce the size of data objects before transferring them over low bandwidth or expensive connections in order to reduce delays and needed bandwidth.

Besides the reduction of data which is achieved by modification of database queries with contexts (see Section 6.3.2 and [lo]) a data reduction will also be zarried out by the Message Handler before the exchange. The use of data reduction is controlled by information about the mobile resources and user preferences that the requests are enriched with. Examples are:

reduction of color images the color depth of the mobile display; scaling of images to a reduced size or to the display resolution of the mobile display; no transfer of objects where there is no viewer configured for on the MES (e.g. no transfer of audio data to a MES without sound capabilities, no transfer of image data to a MES with an alphanumerical display) and no transfer of objects to a MES without sufficient resources (e.g. no transfer of a voluminous video to a mobile host with too low disk capacity); adaptation of data-to-user defined constraints regarding the network connection (maximum size for a specific object, maximum time for a transfer, maximum costs).

Three main requirements have to be met to employ :he object specific data reduction.

Firstly, the entire technique and single steps, respectively, have to be configurable by the user. The user may conceivably wish to receive audio data although his mobile system is not capable of playing back this kind of data.

Secondly, these methods can only be applied if the mobile host and its Network Scheduier are equipped. to a high extent with planning functionality that also contains possibilities of distributing functionality between mobile and stationary components (like the COPS converting pipeline, see [ 1 I]).

Thirdly, all relevant information about mobile and stationary contexts is needed in order to plan the reduction on a SDS. That means that the information has to be a part of the request. However, the transfer of this information leads to additional costs. It is therefore necessary to compromise between comprehensive information as an input for planning of reduction and bandwidth that has additionally to be provided. One solution is to transfer a comprehensive description of the mobile resources and contexts when first contacting a SDS and to submit during the following transfers only descriptions of those resources and contexts that have changed, e.g. free disk capacity. That reduces the bandwidth but leads to additional costs for the management of this context data both on MES and SDS. Another solution is to submit only the relevant information for a certain object together with a request. However, in this case applications have to be especially designed, the set of data types that they can handle is fixed, and it is difficult to react to changing resource parameters. The third method is to submit the relevant information on demand of the Message Handler. In order to reduce net traffic and to minimize response times we prefer a combination of the first and the third method.

The dynamics of resource information when the transfer of a reply object has begun is currently not considered in our research. It is planned to include this topic in our future work.


6. OBJECT MANAGER

Another main component of our basic architecture is the Object Manager. It is responsible for the adaptation of queries and requests to the mobile environment by evaluation of contexts in order to save the mobile resources. That includes finding the location of requested information as well as a context dependent adaptation of requests, entrusting them to the Object Bus, and taking over the replies. The context is the main concept for the description of the dynamic properties of the mobile components (user, resources, information, location and time).

6.1. Resolver The Resolver serves to deliver the address of the

desired information. A comfortable possibility for resolving addresses would be the use of meta information, e.g. a distributed meta scheme. This includes the creation of other requests to require the suitable parts of the meta scheme before sending the request. If no address information is available by the use of this technique, the request will be passed to the next Object Manager on a remote site that can in turn involve further Object Managers.

6.2. Caches The Object Manager is equipped with two caches.

They facilitate and accelerate the access to information and the decisions in the planning and execution of accesses.

6.2.1. Object Cache. In the Object Cache a history of requests and replies is stored, which have been processed on the mobile host. In contrast to the Request/Reply Cache of the Object Bus, the Object Manager offers the possibility of semantic dependent search in the requests to find out also parts of requests. That means that all suited objects that support this method are stored in the OC rather than in the Request/Reply Cache. The use of the OC avoids cost intensive transfers of requests or part of these and their results. Caching of requests and related replies is part of the request-reply process. Since the Object Manager exists on the mobile and on the stationary site, every request and reply will be multiple cached. This is useful for information accessed often but increases security problems.

6.2.2. Context Cache. The other cached information is the mobile context which is managed in the Context Cache. Contexts affect the semantics of information and the semantics of processing and transfer of this information in different ways. Since they represent the parameters of the mobile environment, contexts have an effect to all architectural components. This includes, how to locate, to access, to transfer and to present information.

We classify a context by its origination and by its use. The use is related to the architectural components. Contexts are parameters of the mobile environment, that means of mobile users, information, and resources, e.g. device and network re-

sources. All of them can depend on the current location and time (Fig. 4):

User contexts in mobile environments are the special user views resulting from the mobile environment, other persons, his goals and inten- tions but also his preferences, skills, etc. The resource category includes all information about the available resources of the device and network (for example the connection state and the bandwidth) and of the available software functionality in case of their distribution. Information contexts can be the importance of information for the user or the applications and will be applied as priorities. All of the three described categories are dependent on the location and on space, respectively, and the time.

Note, that the context should include current information as well as statistics of their history and heuristics as a basis for estimations for future usage.

6.2.3. Aspects of cached information. Especially in a mobile environment with frequent disconnections, there is an extremely high risk that cached information becomes inconsistent. Additionally, there are required efforts in access control.

The properties of all our caches are as well resource dependent as the other architectural components and different strategies have to be applied to manage them (see also Section 3.2).

6.3. The Context Manager Contexts are stored in the Context Cache. For

their management a Context Manager is necessary. Context information on the one hand will be

queried not only by the ACoM but also by all other components of the architecture. On the other hand, contexts will be inserted from all components of the architecture. Therefore, the Context Manager allows all components of the architecture to access the contexts in a specified manner. The Context Manager is able to influence all processes by the mobile context in different ways: active (extending or modifying

Fig. 4. The four categories of mobile contexts.

690 J. Bon@ and A. Lubinski

request, periodical information of other components) or passive (answering of context information inqui- ries). For this task, it uses the contexts from the CC or it uses built-in functionality to query them directly. For example, resource information with a high dynamic should always be requested directly, since their storage in a cache would consume too many resources for its continuous updating.

One important task of the ConM is the modification of requests according to current contexts. In the case of resource contexts, this transformation causes a reduction of information.

6.3.1. Data reduction. The data reduction performed by Message Handlers (see Section 5.2 reduces replies after accessing the information. In contrast to this method the data reduction which is performed by the Object Manager already influences the request by modifying it according to current contexts (see Section 6.3.2. Like the other method this strategy reduces not only the size of the reply, but reduces the response time, too. The data reduction affects the properties of the information, or the selection of special objects, or substitutes a reply for another reply which is better suited to the given contexts. For example, it is possible to reduce statistical data by selecting only important data or another specified selection of it. One advantage of this method is the possibility to control the reduction dependent on the semantics of data with minimal losses of semantics.

6.3.2. Request modjications. Besides data reduction the other kinds of contexts lead to a modification of requests, that can limit the size of a reply as a side effect. Due to the location and the user specific view the query can be limited.

Example: A database query to access theater information:

select t.titel, t-author, t .actors fromtheatert

will be extended automatically to the current location and date:

select t.titel, t.author, t.actors form theater t where t.location="Ro- stock"andt.date="05/05/96"

The influence of contexts reduces not only the properties or the selection of the information, but can also lead to a completely replaced request or a changed order of operation sequences. A very important aspect is that the user has to be informed about the new request in order to avoid incorrect interpretations.

A second transformation of requests is to attach the necessary resource contexts to support the work of other components of the architecture (see also Section 5.2).

The Object Manager should be realized as a database system because of its suited qualification for an effective storage and access of data and metadata. But there are more than database queries that should be handled by the Object Manager.

Therefore, a database system, which incorporates the functionality of an Object Manager, has to be extended for:

l the management of the contexts, l the management of an Object Cache, l the adaptation of the requests or database queries

to the mobile environment through the contexts, l the localization of information that is not only

handled by databases.

The Object Manager, and in this way the database system, can be distributed dependent of the resource restrictions. This requires dynamic changing database functionality. This is one of our main research issues.

7. RELATED WORK

There are some other projects that focus on some problems that arrive when mobile end systems access globally distributed information on stationary servers.

In the Oracle in Motion approach in [12] an agent accepts messages from a mobile node, executes programs, and makes data available for the transfer. In [7], an agent called intermediary is introduced to filter or delay all but the most essential data that would travel over the slow link. This agent works bandwidth-dependent. In [13], agents (here called station and domain managers) only exist on the server. These managers maintain information about available resources and services of all nodes in the given domain.

Mobisaic [14] is an information system for a mobile wireless computing environment which provides users with documents that are dependent on dynamic environment variables such as location. Other projects that address the problem of location dependencies are described in [2, 151. Other mobile contexts are considered in Mowser [16], a smart Web browsing application, which performs transactions based on the user’s available resources like display resolution and sound capabilities. The idea of context-aware applications is also being investigated at Xerox Part 117, 181 and Carnegie Mellon University [6]. Other projects try to find solutions for the message exchange with mobile hosts, e.g. the agent-mediated message passing of the Columbia University [19] or caching strategies for mobile environments [20].

8. SU-Y

We presented a basic system architecture for mobile information access and exchange. This architecture enables mobile applications to access globally distributed heterogeneous information in the infoverse and to exchange it effectively with respect to mobile resources and other parameters of the mobile environment. Ail these parameters are sum- marized in the context-a general way to represent


the mobile environment comprehensively which is extensively used to control the work of all components of our system. That can lead to special cases where the use of some components can even be excluded, e.g. in order to reduce processing costs.

Plans for our future work include evaluation and further development of our architecture when using it in special scenarios. One main focus of our research is the design of a universal planning component. This component should have more intelligence and functionality than the currently used Object Manager and Network Scheduler. It will evaluate not only context information but also the dependencies of context information and it will allow a dynamic reallocation of resources.

Acknowledgements-We would like to thank Thomas Kirste for valuable discussions regarding the basic system architecture presented. Additionally, we would like to thank Andreas Heuer for his support regarding the database aspects. The work of the project “Mobile Visualization” (MOVI) is supported by the German Research Association (DFG) under contract Schu 887/3-l.

1.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15. Dunham, M. H. and Helal, A., Mobile computing and databases: anything new?. SZGMOD Record, 1995, 24, 5-9.

REFERENCES 16. Heuer, A., Kehrer, B., Kirste, T., Schumann, H. and Urban, B., Concepts for mobile information visualization-the MoVi-project. In Proceedings of the Euro- graphics Workshop on ScientiJic Visualization 1995, May 17. 1995. Imielinski, T. and Badrinath, B. R., Data management for mobile computing. SZGMOD Record, 1993,22. Forman, G. H. and Zahorjan, J., The challenges of 18. mobile computing. IEEE Computer, 1994, 27. Weiser, M., Some computer science issues in ubiquitous computing. Communications of the ACM, 1993,36. Kirste, T., The MoVI project, introduction and model- 19. ing concepts. In Workshop on Information Visualization and Mobile Computing (ZMC ‘96), Restock, February 1996.

Joshi, A., Weerasinghe, R. McDermott, S. P., Tan, B. K., Bemhardt, G. and Weemawarna, S., Mowser, mobile platforms and web browsers, Purdue University, 1995. Adams, N., Gold, R., S&lit, B., Tso, M. and Want, R., An infrared network for mobile computers. In Proceed- ings of the 1st Usenix Symposium on Mobile & Location Independent Computing; August 1994. S&lit. B. N.. Adams. N. I. and Want. R.. Context- aware’computing applications. In Proceedings of the IEEE Workshop Mobile Computing Systems and Appli- cations, Santa Cmz, 1994. Athan, A. and Duchamp, D., Agent-mediated message passing for constraint environments. In Proceedings of Mobile and Location-independent Computing, VSENZX, Cambridge, August 1993.

Satyanarayanan, M., Noble, B., Kumar, P. and Price, 20. Barbara, D. and Imielinski, T., Sleepers and worka- M., Application-aware adaptation for mobile comput- holics caching strategies in mobile environments. The ing. Operating Systems Review, 1995, 29. VDLB Journal on Very Large Data Bases, 1995, 4.

Zenel, B. and Duchamp, D., Intelligent communication filtering for limited bandwidth environments. In Pro- ceedings of the 5th Workshop on Hot Topics in Operating Systems, IEEE, Rosario, WA, May 1995. Cate, V. and Alex, A., A global filesystem. In Proceedings of the USENZX File Systems Workshop, May 1992, pp. l-l 1. ftp://alex.sp.cs.cmu.edu/doc/in- tro.ps. Chankhunthod, A., Danzig, P. B., Neerdaels, C. Schwartz, M. F. and Worrell, K. F., A hierarchical intemet object cache. University of Southern Califor- ma, University of Colorado, Boulder. Heuer, A. and Lubinski, A., Mobile information access--challenges and possible solutions. In Workshop on Information Visualization and Mobile Computing (ZMC ‘96), Restock, February 1996. Kirste, T., Basisfunktionalitgt fti Mobile Visualisier- ung. Das COPS-Experiment, CG Topics, 1994, 61, 20- 23. Oracle in Motion Extends Database Access to Mobile Workers. Press Release, Oracle Corp., Redwood Shores, September 1994. Bellmann, B., Biihmak, W., Kiimmel, S. and S&ill, A., System support for mobile distributed applications. In IEEE Workshop on Services in Distributed and Net- worked Environments (SDNE), Vancouver, June 1995, pp. 124-131. Voelker, G. M. and Bershad, B. N., Mobisaic, an information system for a mobile wireless computing environment, University of Washington, September 1994.

a basic architecture for mobile information access

Documents