An Architecture for Adaptive Mobile Applications

Thomas Kunz

Systems and Computer Engineering

Carleton University

and

James P. Black

Computer Science

University of Waterloo

The convergence of two technological developments has made mobile computing a reality [16]. In the last few years, Canada and other developed countries have spent large amounts of money to install and deploy wireless communication facilities. Originally aimed at telephone services (which still account for the majority of usage), the same infrastructure is increasingly used to transfer data. The second development is the continuing reduction in size of computer hardware, leading to portable computation devices such as laptops, palmtops, or functionally enhanced cell phones. With existing technology, a scenario such as the one depicted in Figure 1 is fast becoming a realistic possibility.

In this scenario, a user runs a set of applications on a portable device, such as a laptop, communicating over a variety of communication links, depending on his/her current location. Working in the office, the user uses a docking station, gaining access to the wired corporate LAN at a nominal bandwidth of 10 Mbps or more. Roaming within the office building (attending meetings or dropping in on a colleague), connectivity is provided by an indoor wireless LAN product such as WaveLAN, which operates at 1-2 Mbps. Working from home or during trips to a downtown shopping mall, connectivity is provided by cellular wireless networks such as CDPD, that cover a metropolitan area and provide bandwidths of a few tens of kbps. This scenario indicates that applications executing in such an environment face radically different bandwidths and network qualities. Similarly, the set of available services will also vary depending on a user’s location. These variations in bandwidth and services, depending on a user's location, will also exit in future wireless environments. Figure 2 depicts the UMTS vision (see [1]) for third-generation cellular networks.

Unlike second-generation cellular networks, future cellular systems will cover an area with a variety of non-homogeneous cells that may overlap. This allows the network operators to tune the system layout to subscriber density and subscribed services. Cells of different sizes will offer widely varying bandwidths: very high bandwidths with low error rates in pico-cells, very low bandwidths with higher error rates in macro-cells. Depending on the current location, the set of available services might also differ. It is generally argued that applications should "adapt" to the current environment, for example by filtering and compressing data or by changing the functionality offered to the user, see [2,9,12,20,29,30,32]. This paper describes the architecture we propose to facilitate the development of such adaptive mobile applications.

To define a suitable architecture, we first identify categories of applications a mobile user is most likely to execute on his mobile device. Due to the existing limitations of portable devices (limited computational power, disk space, screen size, etc.), we claim that portable devices should not be considered general-purpose computers. For example, we do not expect a user to run complex simulations or compile and link huge software systems on these devices. Even though portable devices will become increasingly powerful, they will never match the computational power and facilities available on typical desktop machines. Similarly, while the wireless technology will improve, providing more and more bandwidth to the end user, wired network technology will advance as well, with the result that wireless networks will remain, in the near to medium future, orders of magnitudes slower. Therefore, mobile computing will always be characterized by a scarcity of resources, relatively speaking. In our opinion, an end-user will execute applications in one of the following five categories in such an environment:

• Standalone applications such as games or utilities;
• Personal productivity software (word processors, presentation software, calendars);
• Internet applications such as e-mail, WWW browsers, multi-user calendars, or telnet;
• New "location-aware" applications: tour planners, interactive guides;
• Ad-hoc network and groupware applications.

The first category is of little interest to us, since it does not involve communication. Applications in the second category will be used on multiple platforms: a user will have a version of his/her favorite word processor executing on a laptop as well as on the more powerful desktop in the office. This requires the exchange and synchronization of documents between the machines. Depending on the prevailing view of available network connectivity, two possible approaches are imaginable. Windows CE and MS Office exemplify a first solution. A user works on a document at either the laptop or the desktop, synchronizing multiple versions only infrequently and in a controlled environment. Proprietary solutions exist and are probably sufficient. A second solution assumes that connectivity is more pervasive, allowing access to "authoritative" copies of a document on demand. This solution will require client-server applications to allow access to remote documents in the presence of highly variable communication links.

The Internet applications constitute a very interesting and challenging category. Mobile devices, according to the Industry Canada vision for mobile computing and the new PCS services (see [13]), are the "on-ramp" to the Internet. Consequently, a user will want to execute the client side of typical Internet applications on his portable device, communicating with servers in the existing Internet infrastructure. This is not as straightforward as it may seem at first glance. The Internet developed as a wired network, connecting powerful computers over relatively high-speed communication links. The assumptions underlying the design of many Internet clients reflect this view of the world. They are therefore not particularly well suited to a mobile environment. For example, the communication protocol of choice is TCP, which is known to behave poorly in the presence of wireless links with their corresponding high bit-error rates. Client applications typically assume that they have sufficient bandwidth, memory, and computational power at their disposal, which is equally questionable. Given the huge amount of money invested in the current infrastructure, it is unrealistic to expect that the whole Internet will change to accommodate mobile users overnight. In particular, servers deployed worldwide will not change in the near future. To facilitate access to the Internet, only the client side of the application can be adapted to function well in the dynamic and resource-constrained mobile environment. The architecture proposed below is intended for applications in this category.

The location-aware applications exploit the fact that a user is mobile. Possible examples include travel guides, which might display the shortest path from a user’s current location to the closest/cheapest/best Italian restaurant, or applications that allow a user to print a document on the closest color postscript laser printer. To the extent that these applications utilize the existing Internet (discovering and accessing nearby resources, for example), the architecture described below is also helpful in designing them.

Applications in the final category arise out of the mobility of a number of users, for example the meeting of a number of researchers or managers, each equipped with a portable device. Users might want to establish ad-hoc networks to exchange documents (the newest version of the transparencies for the invited talk) or to execute groupware applications to update a shared business plan. Since these applications will not, to a large extent, be limited by the need to interact with an existing infrastructure, the proposed architecture is probably not directly relevant to them.

The mobile devices execute the client, which provides the user interface and some part of the application logic. In all wireless technologies, a mobile device communicates with the fixed network through a base station, which is the access point for all devices in a certain geographical area. In WaveLAN, for example, this functionality is part of the WavePOINTs. The area covered by a base station is typically called a "cell" in cellular systems. Through some switching fabric, the base station provides connectivity with other hosts in the network, such as a WWW server or an SMTP server. The third component of our model is the proxy, a component of the application that executes in the wired network and supports the client. One possible location for the proxy would be the base station, but this is not the only possibility. Any computer on the communication path between client and server can host the proxy. Logically, the proxy hides the "mobile" client from the server, who thinks it communicates with a standard client (i.e., a client that executes on a powerful desktop directly connected to the wired network). The application logic of the "standard client" is split between the mobile client and the proxy to adapt to the dynamic wireless environment and to address the limitations of the portable device. For example, the proxy could execute on a powerful workstation with large amounts of memory and disk space. This would make the proxy an ideal candidate to manage large caches or to perform computationally intensive tasks such as interpreting an MPEG video stream and turning it into a pixmap. Where bandwidth limitations over the wireless link are of major concern, the proxy could provide filtering and compression functions.

Mobile users pose additional challenges, as indicated in Figure 4. The proxy must be in the path between client and server, so unless the proxy executes at the base station, special routing provisions have to be made. As the user moves from cell to cell, his/her point of attachment to the wired network changes over time.

To avoid suboptimal communication paths, the proxy must migrate within the fixed network, following the user. "Migrating" the proxy can mean either that the proxy moves physically from machine to machine, or that a system of proxies exists, and only relevant state information is passed during a hand-over. The two approaches are complementary, and the best choice depends upon the details of a given situation. There are some other issues raised by user mobility.

• How should the proxy migration decision be made (based on what information, using what algorithm)?
• Given that we expect a large number of mobile users, how does the approach scale? For example, what happens if a sizeable subset of users decides to head to the same shopping mall at noon, checking stock options over the WWW while having lunch?

The idea of using a proxy in the wired network to support a mobile device is well known. In fact, most wireless WWW browsers, among others, use one or more proxies to support their operation in a low-bandwidth environment [6,7,8,10,15,26,29]. However, our approach is more concerned with adaptability, flexibility, and mobility than work published in the literature, as explained below.

Existing proposals typically install a proxy that filters and/or compresses data for a specific application. This filter is either enabled or disabled. Examples are filters to turn color inline images into lower-resolution grayscale images or to convert postscript into ASCII text, or e-mail readers that provide the "subject" line of a mail message only, avoiding the transmission of the main message body over a slow link. In the scenario of Figure 1, the environment changes dynamically, depending on the user’s behavior and that of others. We therefore foresee the need to make the proxies more dynamic, to adapt more closely to changes in the environment. Examples are changing the resolution and/or color of an inline image only when necessary, and changing the resolution incrementally. Another example could be to allow an e-mail reader to read the body of small e-mail messages but to avoid reading large messages. To enable this more fine-grained adaptation, a mechanism is needed that provides the mobile application with information about the environment. We identify the following groups of relevant information:

• device information: display size and capabilities (color?), battery power status, memory, CPU;
• information about the wireless link: bandwidth, latency, error rates;
• infrastructure information: reachable servers/services; and
• location-related information: physical location, logical location (e.g.: what IP subnet am I attached to?).

Adaptation decisions need to take information from all categories into consideration. For example, high available bandwidth might favor a shift from the proxy to the mobile. However, the mobile might be running low on power, arguing for a shift from the mobile to the proxy. Similarly, certain adaptation options might not be feasible in environments that lack the appropriate infrastructure. Previous research focused on one category only: [21,23] focus on power consumption, [19] on location information, [11] on local services, [29,32] on the network characteristics.

A completely different approach would be to design the division of labor between mobile client and proxy for the worst case only, which would allow a user to get consistent functionality across all environments. We consider such a solution less than desirable, for at least two reasons. First, whenever possible, a user should experience the best service achievable. Normalizing everything to the lowest common denominator deprives the user of full service and functionality. For example, inline images will always be displayed in low-resolution grayscale, even in the presence of enough bandwidth to download full-resolution color images. A user will be prevented from viewing the body of an e-mail message, even if it would take only seconds to download it over the wireless link. If a cache is maintained at the proxy, rather than at the mobile, all cache accesses will be over the wireless link, slowing the perceived performance of the application.

Second, a proxy server will, in general, support many mobile users. To the extent that the individual portable devices can contribute to better client functionality, they should be encouraged to do so. Otherwise, even a powerful proxy server might be overloaded, resulting in poor performance for all applications.

Most existing proxy solutions operate at the protocol level. They intercept messages and reduce the data sent over the wireless link by filtering less important data and utilizing compression algorithms (see [12, 29, 32]). As discussed in [7], while data compression and filtering improve the perceived performance of web browsers, they are not sufficient. Support for new types of operations, such as browsing while disconnected and/or asynchronous browsing, is needed in a mobile environment. The research in [7,15] is based on a static client-proxy-server architecture, where the division of labor between client and proxy is determined and fixed at design time. Both papers, however, emphasize that a more flexible, dynamic, adaptation based on mobile code should be explored in future work to address issue such as operating under disconnections.

Our approach is aimed at more general proxy solutions. As mentioned above, we envision mobile applications where the proxy can overcome some of the limitations of the portable device by maintaining a cache or performing CPU-intensive interpretation of the data stream. Offloading some of the application logic to a proxy comes at a cost. We therefore want to shift parts of the client logic only when necessary (to conserve battery power or reduce network bandwidth, for example). This again argues for a dynamic adaptive proxy design, with the added complexity of moving not only data, but also code.

A third major difference from previous work is that we plan to address issues of mobility. Nearly without exception, existing solutions address the situation depicted in Figure 3, where a mobile host interacts with a fixed host over the same wireless link forever. In fact, [32] claims that the issue of proxy migration is beyond the current state-of-the-art. Given that "migrating" the proxy does not necessarily mean that we transmit the proxy code through the Internet, we disagree with this statement. We will investigate how to create a proxy infrastructure, perhaps connected with or related to the concept of Intelligent Networks [25] in telephony, which was devised for fast deployment of new services in a network. "Migrating" the proxy would then take the form of a handoff between two proxies. There are three salient issues to be addressed here.

• What information should be collected (and how to collect it) to make "migration" decisions?
• What are good decision algorithms, based in this information?
• How does the solution scale to a metropolitan or provincial coverage area?

Mobile computing is characterized by a number of difficult challenges. Previous research isolated and solved individual pieces of the overall puzzle. The architecture proposed in the next section is our suggestion for an execution environment that allows the integration of previous work as well as the exploration of new ideas. To support this claim, we include a brief description of various adaptive mobile applications based on the architecture later in this document. By cooperating with a cellular operator, we hope to achieve the following goals.

• Obtain information that will help to validate the scalability of our ideas in real-life networks. In previous work [24], we built a simulation model based on trip-survey data for the Kitchener-Waterloo-Cambridge region. This serves as an important basis for building simulation models, which we would like to expand for larger coverage areas. Another important component is a model of user behavior. By instrumenting services offered through a commercial service provider, we can analyze and model relevant wireless data characteristics. Both components together will allow us to build simulation environments to evaluate the scalability of our work.
• Provide a reality check for our ideas. The current architecture was developed based on the experience we collected by running a wireless LAN in our research lab. Commercial wireless and backbone networks are more sophisticated than the experimental networks we typically work with. In particular, we need to identify places within the network to execute the various components of our architecture. Depending on these locations, certain overheads might turn out to be unacceptable, potentially resulting in a refinement/modification of our initial ideas. Also, integrating our ideas into a non-trivial network might highlight new problems and opportunities, such as integrating CDPD and Mobile IP, or leveraging existing non-IP networks like ARDIS.
• Collect feedback about the relevance of our work and ideas for further research. Wireless data services and mobile computing are technologies that are evolving rapidly. Some of the driving forces are wireless operators, developing and implementing relevant standards. Furthermore, the applications, devices, and services available in these networks are heavily influenced by the strategic plans of the network operator.

The wireless operator will benefit from such an arrangement as well. It will provide opportunities for technology transfer, access to tools and results developed in our research labs, and the potential to offer enhanced wireless data services to the customers.

To achieve truly adaptive applications, we need to design and implement a number of components. Figure 5 gives an overview of the relevant pieces and how they interact. In this architecture, we distinguish two proxies, a high-level proxy and a low-level proxy. They play distinctive roles and require different mechanisms for their implementation.

A central piece of infrastructure is the environment monitor. The client application needs to be informed of changes in the environment. This can be achieved by a daemon process on the mobile device, monitoring relevant environment parameters and notifying the application through registered call-back functions. To avoid interruptions of the client logic, these call-back functions could execute in a separate thread, for example, communicating with the rest of the mobile client through shared state. An application must register with this daemon, inform it of environment parameters it is interested in and the conditions under which it wants to be notified, and provide appropriate call-back functions. To obtain reliable information about the wireless link, the client-side daemon might interact with a similar daemon on the other end of the wireless link.

The mobile device will execute the user interface and parts of the client application logic. Other parts of the client logic execute on a dedicated proxy server, which is a powerful machine in the fixed network. Ideally, the proxy server should be close to the base station. The client and high-level proxy will communicate following either a standard protocol such as HTTP or an application-specific protocol. The high-level proxy communicates with the server, transparently hiding the fact that the server communicates with a mobile client. We believe it reasonable to execute this software in user space on the proxy server.

The application logic is divided between the mobile client and the high-level proxy. This division of labor changes over time, depending on the current environment. In previous work, we designed and implemented a number of applications that registered with the monitor and made decisions about the most appropriate adaptation, based on the feedback received from the monitor, see for example [18,31]. To facilitate the development of adaptive mobile applications, we plan to factor the partition algorithms out into the runtime system. Each client application will be designed concentrating on the functional aspect only. To enable dynamic partitioning, the application registers certain information with the runtime system. It is up to the runtime system to connect with the monitor and to use the information available at runtime, the information registered by the application, and the feedback received from the monitor, to make partitioning decisions.

One concrete example could be as follows. The mobile device and the proxy server both execute a Java virtual machine. The client application consists of a number of objects, communicating via remote method invocation. Upon creation, each object registers with the runtime system. The registration could be of the form "execute on mobile if bandwidth greater than X" or "execute in same location as object A." A default policy would handle objects that did not provide additional registration. For example, a default policy could link object size to bandwidth and/or available memory. Objects exceeding a threshold size execute on the proxy server, otherwise they execute on the mobile host. The runtime system monitors the relevant parameters and initiates object migration if necessary. In the example, object migration could be achieved by a mechanism similar to mobile code based on Java (for example, applets).

A low-level proxy supports the communication between client and high-level proxy. Examples of existing low-level proxies are described in [3] (I-TCP), [4] (Snoop), and [5]. These approaches attempt to improve the performance of TCP over a wireless link transparently. The low-level proxy operates at the data, network, and/or transport layers. Protocols at these layers are typically provided as part of the operating system protocol stack, so for maximal efficiency we expect the low-level proxy to become part of the operating system. The low-level proxy supports communication over the wireless link, so we envision that the low-level proxy will execute on a host that directly connects to the wireless link. There are only two choices: the mobile device and the base station. Given the restrictions of the mobile device, the logical place for the low-level proxy is the base station. However, there a low-level proxy might actually be split between the mobile device and base station, to provide symmetric support for communication to and from the mobile device.

The above paragraph assumes that the low-level proxy is transparent to higher-level communication. Another useful extension of the proxy approach is to extend the capabilities of the higher-level protocols. In previous work [17], we identified services such as prioritizing competing TCP connections or keeping TCP connections alive in the presence of spurious disconnections. In this case, the existence of the low-level proxy cannot be kept transparent to the client. In fact, the client needs an interface to request such enhanced services, and to provide the proxy with necessary information. One example is security, where the low-level proxy denies/approves access to a network to authorized users, based on tickets obtained by an application and presented to the proxy when requesting services, similar to the system described in [22]. As far as possible, this functionality should be hidden in the runtime system, invisible to the application logic implemented by the programmer.

To give an indication of how the architecture will support adaptive mobile applications, this section briefly describes a number of potential applications. The descriptions assume that we have a monitoring system available that provides notifications about changes in the environment. The user will roam in an environment similar to the one illustrated in Figure 1. A low-level proxy exists and, unless further specified, supports TCP connections transparently.

In a telnet or rlogin client, it is important to not delay the interactive user traffic by any concurrent background bulk data transfer, resulting from downloading HTML documents or inline images. Similarly, the control connection in an FTP client should be more responsive than the data connection. To distinguish such connections, the low-level proxy can provide facilities to effectively prioritize competing TCP connections. Due to the simplicity of the client logic, the high-level proxy will not be utilized. A preliminary version of this was described in [17].

A possible design for a WWW browser uses the high-level proxy as a data filter. The client registers with the monitor, asking to be informed of changes in the bandwidth. In a high-bandwidth environment (for example, when the user is working in the office), the high-level proxy forwards HTTP requests to the servers and forwards the replies to the client. In addition, the high-level proxy can maintain a cache of documents, potentially sharing this cache with other clients executing in the same cell. For medium-bandwidth environments (for example, when the user is within an area covered by WaveLAN), the high-level proxy filters the incoming inline images to reduce the resolution. In a low-bandwidth environment, the high-level proxy filters inline images to reduce both the resolution and the color. In this example, client and proxy communicate with the standard HTTP protocol.

Based on information about the mobile device, routines to process and format the HTTP replies could also be assigned to the high-level proxy. The high-level proxy would send pixmaps representing the webpage to the client, who displays them and returns information about user actions. Full-color high-resolution pixmaps will increase the bandwidth requirement, but reduce the computational load on the client, preserving his battery. Grayscale and/or low-resolution pixmaps can help to both preserve battery power and bandwidth. In this scenario, client and proxy communicate following an application-specific protocol. In both scenarios, the proxy communicates with the server with HTTP, hiding the mobile client and the current division of labor between client and proxy from the other servers.

An alternative for the design of a WW W proxy is as follows. The proxy receives HTML pages from the WWW servers and converts them into HDML [28], a markup language designed for limited mobile devices such as functionally enhanced cell phones. These HDML decks are transferred to the mobile device via HDTP [27], an optimized and secure transfer protocol for wireless communication. Converting the data stream from HTML to HDML documents and translating between HTTP and HDTP should be done at the high-level proxy, rather than the low-level proxy. The low-level proxy sees individual data packets at the network and/or transport layer. Most applications of the low-level proxy deal with these individual data packets, potentially caching a limited number of them. Requiring the low-level proxy to reconstruct the higher-level protocol data units and modify them or translate between application-layer protocols violates the idea behind splitting the proxy server. The low-level proxy is part of the protocol stack within the operating system for maximum efficiency, which argues for keeping it simple. Furthermore, a low-level proxy will have to work with potentially many data streams from/to mobile hosts in the same cell, which again argues for keeping the processing overhead per data packet low.

If the user roams over a large enough physical area (or simply crosses a boundary cell), the high-level proxy must migrate eventually. Due to the nature of the application, we do not need to transfer cached data. However, the client needs to inform the new high-level proxy server of the current division of labor, potentially downloading the required software into that server.

A mobile mail reader can use the monitor to inquire about locally available SMTP servers. It establishes connections to the closest SMTP server (potentially based on security and/or cost considerations) to send e-mail messages composed by the user. To read e-mail, the client must connect to the "home" message store. Typically, a user will have many different folders with many messages in each. Copies of these folders are downloaded to the high-level proxy server. Depending on the network conditions and the available space (memory, disk) at the mobile device, copies of the smaller folders can be downloaded to the mobile. The application will dynamically determine whether a mail folder exists locally or at the proxy server, processing requests for listing all messages or displaying certain messages at the appropriate location. Depending on the functionality of the "home" message store (POP or IMAP4), certain functions (such as rearranging the mail folders or deleting individual mails) might have to be disabled. A prototype of such a mail reader is described in [18].

Upon migration, the high-level proxy has to request copies of the user’s mail folders. These can be downloaded from either the previous proxy server or the "home" message store, whichever location is deemed more appropriate.

A final application is an interactive museum guide. A visitor wanders through a museum with a palmtop in his/her hands. Information about each exhibit is displayed as the visitor approaches an object. The application also provides the visitor with the option to inquire about a specific exhibit and to display the best path from his/her current location to that object.

To enable this application, the monitor has to provide location information. This could be achieved either directly, with a system such as GPS, or indirectly, by deducing the current location from the base station with which the device communicates. Computing the shortest path is potentially rather complex and is therefore done at the high-level proxy. This proxy also provides a cache for previous information and the query routines to fetch information from the central database, based on the current location. The portable device executes only the interface component. The available bandwidth will vary, depending on the number of people crowding in front of the more popular exhibits, and whether the object is indoors or outdoors. The application can adapt to these changes by offloading the graphical processing to the proxy, allowing the proxy to filter the amount of data (similar to the WWW browser). In this case, the backend (the database that provides the information about exhibits) can serve for other applications as well, for example to generate dynamic web pages.

Since a museum is a relatively confined space, migration of the proxy due to visitor mobility is not a direct concern. However, the number of potential visitors may require multiple proxy servers. To avoid migration issues, visitors (and their devices) should be assigned to a proxy server on a basis different from physical location.

[2] B. R. Badrinath, A. Acharya, and T. Imielinski, Structuring Distributed Algorithms for Mobile Hosts, Proceedings of the 14th International Conference on Distributed Computing Systems, Poznan, Poland, June 1994, pages 21-28

[3] A. Bakre and B. R. Badrinath, I-TCP: Indirect TCP for Mobile Hosts, Proceedings of the 15th International Conference on Distributed Computing Systems, Vancouver, Canada, May 1995, pages 136-143

[4] H. Balakrishnan, S. Seshan, E. Amir, and R. H. Katz, Improving TCP/IP Performance over Wireless Networks, Proceedings of the First Annual International Conference on Mobile Computing and Communications, Berkeley, USA, November 1995, pages 2-11

[5] H. Balakrishnan, V. N. Padmanabhan, and R. H. Katz, The Effects of Asymmetry on TCP Performance, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 77-89 [5] G. H. Forman and J. Zahorjan, The Challenges of Mobile Computing, University of Washington, Department of Computer Science, Technical Report #93-11-03, March 1994

[6] J. Bartlett, W4 – The Wireless Word Wide Web, Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994, pages 176-178

[7] H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni, R. Floyd, B. Housel, and D. Lindquist, Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 260-269

[8] W. Citrin, P. Hamill, M. D. Gross, and A. Warmack, Support for Mobile Pen-Based Applications, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 241-247

[9] G. H. Forman and J. Zahorjan, The Challenges of Mobile Computing, University of Washington, Department of Computer Science, Technical Report #93-11-03, March 1994

[11] T. D. Hodes, R. H. Katz, E. Servan-Schreiber, and L. Rowe, Composable Ad-hoc Mobile Services for Universal Interaction, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 1-12

[12] T. Imielinski and B. R. Badrinath, Wireless Computing: Challenges in Data Management, Communications of the ACM, October 1994, pages 19-28

[15] M. T. Le, S. Seshan, F. Burghardt, et al., Software Architecture of the InfoPad System, Proceedings of the Mobidata Workshop on Mobile and Wireless Information Systems, Rutgers, NY, USA, 1994

[16] Y. Li and V. C. M. Leung, Supporting Personal Mobility for Nomadic Computing over the Internet, Mobile Computing and Communications Review, 1(1), April 1997, pages 22-31

[17] M. Lioy, Providing TCP-level Services to Mobile Computers in a Wireless Environment, Master’s Thesis, Department of Computer Science, University of Waterloo, September 1997

[18] H.-Y. Lo, M-Mail: A Case Study of Dynamic Application Partitioning in Mobile Computing, Master’s Thesis, Department of Computer Science, University of Waterloo, May 1997

[19] H. Maass, Location-Aware Mobile Applications based on Directory Services, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 23-33

[20] B. Marsh, F. Douglis, and R. Caceres, Systems Issues in Mobile Computing, Matsushita Information Technology Laboratory, Princeton, NJ, USA, Technical Report MITL-TR-50-93, February 1993

[21] M. Othman and S. Hailes, Power Conservation Strategy for Mobile Computers Using Load Sharing, Mobile Computing and Communications Review, 2(1), January 1998, pages 44-51

[22] B. Patel and J. Crowcroft, Ticket Based Service Access for the Mobile User, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 223-233

[23] A. Rudenko, P. Reiher, G. J. Popek, and G. H. Kuenning, Saving Portable Computer Battery Power through Remote Process Execution, Mobile Computing and Communications Review, 2(1), January 1998, pages 19-26

[24] J. Scourias, Dynamic Location Management and Activity-based Mobility Modelling for Cellular Networks, Master’s Thesis, Department of Computer Science, University of Waterloo, April 1997

[29] T. Watson, Application Design for Wireless Computing, Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, USA, December 1994, pages 91-94

[30] G. Welling and B. R. Badrinath, A Framework for Environment Aware Mobile Applications, 17th International Conference on Distributed Computing Systems, Baltimore, Maryland, USA, May 1997, pages 384-391

[31] T. J. Whalen, Design Issues for an Adaptive Mobile Group Editor, Master’s Thesis, Department of Computer Science, University of Waterloo, September 1997

[32] B. Zenel and D. Duchamp, A General Purpose Proxy Filtering Mechanism Applied to the Mobile Environment, Proceedings of the Third Annual ACM/IEEE Conference on Mobile Computing and Networking, Budapest, Hungary, September 1997, pages 238-259