Middleware for a New Generation of Mobile Networks: The ACTS OnTheMove Project

Hans-Georg Baumgarten
Lothar Borrmann
Siemens AG, Germany

Torsten Köhler
Stephen Pink
SICS, Sweden

Gerard Lacoste
IBM, France

Frank Reichert <frank.reichert@era-t.ericsson.se>
Ericsson Radio Systems AB, Sweden

Abstract

The ACTS [2,3,6] OnTheMove project [1] designs and implements a Mobile Application Support Environment (MASE). The MASE includes a mobile application programming interface, Mobile API, that provides access to MASE services and hides the heterogeneity of underlying networks and user equipment. We give an overview of the MASE architecture followed by a more detailed description of disconnected operation and generic support for caching.

1. Introduction

Today's mobile networks provide only a small range of simple services, leaving multimedia out of reach. In stark contrast, the volume and richness of information services on fixed networks is growing at an accelerated pace. Soon, people, wherever they are, will want to use multimedia information services, whether global or local to a particular area, on fixed or mobile networks. Many different types of computers-including laptops, palmtops, and personal assistants as well as mobile telephones-will help users access networks and services.

OnTheMove[1] is a European project made up of a representative set of actors from the business information and communication technology sectors, as well as from the mobile network operator community. OnTheMove addresses the above issue by designing and implementing a Mobile Application Support Environment (MASE). The MASE middleware includes a mobile application programming interface, Mobile API, that provides access to MASE services and hides the heterogeneity of underlying networks and user equipment. New "mobile-aware" applications benefit from the Mobile API as it allows them to adapt, e.g., to changes in quality of service, connectivity, and user location. Legacy applications can also benefit from some of the services being developed for the MASE.

The OnTheMove architecture is based on the latest research advances in mobile multimedia information services, and from an evaluation of commercially available architectures and products. After an implementation period, a sequence of field trials is planned in cooperation with national hosts in Sweden and Germany to refine user requirements and validate the MASE architecture.

The structure of this paper is as follows. We first describe the architecture of our mobile middleware, the Mobile Application Support Environment (MASE). We then discuss the functionality available in the MASE through our application programming interface (Mobile API). After this, we provide some examples of this functionality such as the universal adaptivity layer, and session, system and generic cache managers. We then describe our implementation strategy and end with a summary and conclusions.

2. Mobile Application Support Environment (MASE)

2.1 MASE objectives

The main goal of the Mobile Application Support Environment (MASE) is to extend the reach of multimedia applications to mobile users, no matter which mobile network supports them. On the users' side, this means that users will be able to use applications whether they are connected to a wireless LAN, MAN or WAN or they are roaming across them. For example, one could use a mobile in a car to find a parking lot, based on the city MAN, and once in the parking lot, find an empty space, based on the parking lot LAN. On the applications side, it means that applications, made aware of the instantaneous quality of communication, could tailor their services to the best rendering to their users.

To achieve this goal, the MASE is building a standardized mobile environment to support multimedia applications across heterogeneous networks. The MASE is thus acting as a mediator between applications and their users on the one hand and the mobile terminals and the underlying networks on the other hand. It thus offers applications a set of application programming interfaces (APIs), the mobile API. It adapts to network diversity by means of the UMTS [5,7] adaptation layer (UAL).

2.2 An API for mobile-aware applications

Our mobile API provides access to a number of services in the MASE. Users with mobile-aware applications are provided with the ability to specify preferences that are organized into profiles. The MASE offers support for initiating, responding, maintaining, and closing communication in a two- or multi-party configuration. Communication may be connection-oriented or connectionless, depending upon the type of communication desired by the user. Information exchanges may be a mix of data, voice, graphics, or video.

A goal for our middleware is to hide the complexity of the network from the application wherever possible and desirable. Thus, the MASE attempts to make different wireless networks appear to the user and applications as a seamless and homogeneous communication medium. Differences between networks only surface as differences in communications Quality-of-Service (QoS). In order to enable mobile-aware applications to optimize their services, based on the characteristics of both the terminals and the networks, the MASE offers applications the capability to both control QoS and react to its variations.

The MASE provides applications with information on the location of the mobile so that application services can adjust accordingly. In addition to mobile-specific functions, the MASE offers support for multimedia conversion, transactions, agent technology, accounting, security, and system management. Various system managers embedded in the MASE can be accessed through the mobile API. These managers provide services to mobile-aware applications.


Figure 1. MASE (Mobile Application Support Environment).

Session manager. The session manager offers services to establish, close and exchange data in a communication session. Based on QoS (e.g., quality, cost, security, priority), user/terminal profiles, and available connectivity, the session manager selects and requests the appropriate UAL service. During data exchange, the session manager receives indications about connectivity/QoS changes and tries to keep the QoS at the requested level by switching to a different UAL service. In case of resource shortage, the session manager prioritizes sessions by their importance. If the session manager is not able to provide the requested QoS, it will notify the session user.

System adaptivity manager. The control of system resources and their usage is the function of the system adaptivity manager (SAM). The system adaptivity manager tunes the mobile system for best performance, given the current operating environment and the user's preferences.

The operating environment of a mobile device is dynamic, e.g., battery capacity and power consumption are constantly changing. The SAM will try to reconfigure the system automatically to fit the current situation before requiring user intervention.

The SAM will attempt to resolve resource conflicts based on the user-supplied priorities and possible negotiation with the user. To access user priorities and requirements, the SAM maintains a management information base (MIB) that can be updated with the current status of the mobile device. This MIB can be accessed in the same way as other management databases, through an SNMP-like interface, collecting information for performance tuning.

Location manager. The location manager is in charge of handling the mobile location information, of which the geographic position of the mobile is the most obvious one (but there may be some other types of location, e.g., administrative). The location manager locates the mobile terminal through the appropriate means available from the MASE, the network, the application, user inputs, etc.

Accounting manager. The accounting manager is responsible for charging and billing tasks. Both network and content charging information is accumulated. The transaction manager is responsible for providing distributed transaction support in coordination with other transaction managers taking part in the transaction.

All the above functional entities, including the general support functions, offer one or more APIs that collectively form the mobile API. Figure 1 depicts the functional decomposition of the MASE.

The UMTS adaptation layer. Since OnTheMove is chartered to provide middleware for the next generation mobile communication system, called UMTS, we have designed a software layer, the UMTS Adaptation Layer (UAL). The UAL encapsulates low-level mobile communication functionality. It establishes, maintains, and terminates network communication, alerting its users to incoming calls, field strength, fading, etc. Quality-of-service requests are made to the UAL as well as requests for charging and location information. Thus, the UAL shields its users from the complexity of mobile networks, offering instead a simpler communication abstraction. The communication adaptation layer is used by the session manager to establish communication.

2.3 Flexible distributed middleware

Because of the many types of mobile terminals, ranging from cellular phones, to palmtops, personal digital assistants and laptops, the MASE may not get all of its necessary resources from the mobile terminal itself. Thus, the MASE is also present on devices, which we call mobile gateways, that are attached to wired networks. Based on user and application profiles, and network and terminal capabilities, the MASE dynamically allocates resources from the mobile device and the mobility gateway to meet application requirements. For example, the transaction manager or multimedia conversion is likely to run in a mobility gateway rather than in the mobile terminal. Figure 2 shows an example of distribution of the MASE over mobile terminals and mobility gateways:


Figure 2. The distributed MASE.

3. Disconnected operation and generic support for caching

Disconnected operation is the ability of an application to operate as close to normal as possible when disconnected from network resources. In the case of a client/server application, for instance, the client should be able to operate for long periods of time after either voluntary or involuntary disconnection from its server. When the connection reappears, the client should be able, as transparently as possible, to reintegrate changes back onto the server. Generic support for disconnected operation includes client caching as well as mechanisms to preserve general consistency for distributed applications. Attempts to provide private caches for each distributed application could result in wasted resources such as unused memory and disk space for some applications while other applications suffer from lack of these resources.

A generic cache manager must be able to provide storage space as well as fast lookup and retrieval to many different applications ranging from traditional word processors and spreadsheets to new applications such as Web browsers and even audio/video conferencing tools. In the past, generic storage and retrieval requirements for most applications were met by distributed file systems, and support for disconnected operation for all applications could be built into a client/server file system such as Coda from Carnegie Mellon University [4].

However, new Web browser technology promises to generate new kinds of applications whose requirements for persistent object storage are somewhat different. Universal Resource Locators (URLs) constitute the primary namespace for Web browser technology, and these URLs are more generic than, for example, file system pathnames. Indeed, the file system namespace can be more easily coerced into a URL namespace than the opposite. Thus, the generic cache manager developed in OnTheMove converts secondary namespace identifiers such as file system pathnames for DOS, Windows NT, Unix, and other operating systems, as well as FTP name locations, etc, into URLs for generic storage and retrieval.

The generic cache manager provides its API to the application as an interface to the mobile middleware. An application that uses the OnTheMove API invokes methods to store, alter, etc., its data in the generic cache manager. The cache manager will coerce the application-specific name for the object to a URL that is easily retrievable when the application needs to use its data. In the case of a read/write distributed application, the data will then be given to the distributed application client agent for policy-based actions such as flushing across the network to the server, etc. For read-only applications such as many common Web browser-based functions, the data are stored for future use in the local generic cache. If the mobile host becomes disconnected and the application requests the data, the object, if cached, will be delivered to the user via the API. Only if the object is not cached and the server is unavailable will the application be informed that the data are missing. After reconnection, the cache manager will make necessary transactions across the network to servers according to policies consistent with cooperating distributed applications.

The cache manager is made up of two main parts with upper and lower interfaces. There is an object store that represents the cache's database and a pathname system that converts application-specific names such as file system pathnames, etc., to URLs. The upper interface of the cache manager is invoked by the application when an object needs to be stored, altered or retrieved. The lower interface is to the I/O functionality of the operating system such as the local file system, socket interface to the network, etc. The initial implementation of the cache manager is a C++ class library that can be dynamically linked to an application in a Windows 95/Windows NT or Unix environment.

4. Implementation goals

The MASE and its API will be implemented as a class library that will be available for major operating system platforms, including Unix, Windows 95, and Windows NT. Applications confirming to our Mobile API will be able to invoke services in the MASE through a set of public methods exported from the class library. The goal is that mobile-aware applications will only have to be recompiled to run on the various platforms that support our MASE. To provide maximum portability of applications, we will attempt to describe our mobile API in an Interface Definition Language such as IDL.

5. Summary and conclusions

The ACTS OnTheMove Project is defining and implementing an application programming interface (Mobile API) to a mobile application support environment (MASE). The services of the MASE accessible through the mobile API are location, session, and power management, support for disconnected operation, and system adaptivity management to support quality of service in a mobile environment. The mobile API and MASE are being implemented for various operating system platforms such as Unix, Windows 95, and Windows NT. The main goal of OnTheMove is to provide the mobile user with access to new multimedia applications, including Web browsers and real-time digital audio and video.

6. References

  1. OnTheMove home page: http://www.sics.se/~onthemove.
  2. ACTS home page: http://www.uni-stuttgart.de/SONAH/Acts/PRtit.html.
  3. ACTS Mobile Area home page: http://www.uni-stuttgart.de/SONAH/Acts/mobility/home_1.htm and http://www.uni-stuttgart.de/SONAH/Acts/mobility/domains.htm.
  4. James J. Kistler and M. Satyanarayanan, Disconnected Operation in the Coda File System, Operating Systems Review, volume 25, number 5, October 1991.
  5. UMTS Task Force Report, Brussels, 1 March 1996. Executive summary: http://www.uni-stuttgart.de/SONAH/Acts/mobility/tfreport.htm. Report: http://www.uni-stuttgart.de/SONAH/Acts/mobility/doc/tfreport.zip.
  6. ACTS 1995, Advanced Communications Technologies and Services: European RTS, European Commission DGXIIIB, Brussels, June 1995.
  7. R.S. Swain, RACE UMTS vision, Brussels, 1996, Abstract: http://www.uni-stuttgart.de/SONAH/Acts/mobility/umts_vi.htm. Microsoft Word document: http://www.uni-stuttgart.de/SONAH/Acts/mobility/doc/umts_vi.doc.

Acknowledgments

The OnTheMove project is sponsored in part by the European Commission in the ACTS program under contract AC034, and the project participants: Ericsson Radio Systems AB (S), Deutsche Telekom MobilNet GmbH, Ericsson Eurolab GmbH (D), Siemens AG (D), Rheinisch Westfälische Technische Hochschule (D) IBM France (F), GSI Tecsi (F), British Telecommunications (GB), Bonnier Business Press (S), Royal Institute of Technology, KTH (S), Sony Europe GmbH (D), Swedish Institute of Computer Science, SICS (S), Burda New Media GmbH.