Moby Dick - The Mobile Digital Companion
LTR 20422
Final Report
Section I: Results of the first phaseJuly 1997
Several factors have hampered the advance of the use of electronic information in everyday life. One of the most important has been that the information cannot always be made available where it is needed; electronic information was never very mobile. This is now about to change. Digital wireless telephony can now be used to connect very small portable computers to the internet so that, wherever one is, one's data can be accessed and interaction with others is possible. Mobile computing, assisted by wireless networking, is an essential step in making electronic document exchange, electronic communication, and electronic commerce replace at least some portion of their non-electronic counterparts. This development will have to be supported by much better infrastructures for securing the privacy of one's personal data and the integrity and authenticity of financial and other transactions.
The combination of networking and mobility will engender new applications and services. Not only does it provide a means for users to stay in touch while on the move and to receive notifications of important events, it also gives people a complete new way to interact with the infrastructure of large public institutions, such as airports, supermarkets, or even whole cities. This interaction can be used for information about services, access to these and transactions with them. Standing in line for ticket or teller windows may become a thing of the past. Instead offices and public places will be equipped with access points, through which hand- held computer users will be able to communicate with the existing infrastructure.
What makes a Pocket Companion different from a desktop machine? First of all its size and weight are small: a pocket companion has to fit into one's shirt pocket. Secondly, it is a truly personal machine: it might, for instance, contain sensitive information or store the owner's private keys or electronic money. And finally, it is a resource-poor device: there is a limited amount of energy in its batteries, there is only a small amount of memory, the CPU processing power is restricted and the communication bandwidth is moderate.
The Pocket Companion is more than just a small machine to be used by one person at a time like the traditional organizers. The Pocket Companion extends the notion of a so called `desktop companion'. A desktop companion is a hand-held machine that is designed to give roaming users access to their business data and applications while on the road (like a WindowsCE system). Desktop companions are designed and optimized for compatibility and communication with the user's desktop machine(s), e.g. via modem, infrared or a docking station.
The Pocket Companion will run applications typically found in desktop companions, but it is designed to run other applications using external public services as well. A Pocket Companion interacts with the environment and as such is part of an open distributed system. It needs to communicate with - possibly hostile - external services under varying communication and operating conditions, and not only to its desktop `master'. When Pocket Companions are incorporated into a global distributed system, their owners must be confident that the system is trustworthy.
We use a modified notion of Quality of service (QoS) as a foundation to express and manage adaptation. Unlike the approach for statically connected systems, where QoS is used to provide resource reservation guarantees, we use QoS to manage the behaviour of the Pocket Companion. The behaviour is guided by user policies, available internal resources and what is provided by the hosting environment.
In the MobyDick architecture for adaptive mobile systems, software modules that invoke operations in other modules may be informed about relevant events, mutual resources and states concerning the ongoing service operations. The access to invokee-intrinsic information is predetermined in scope and form by the QoS contracts in such a way that the available information is exactly what the invoker expects.
The architecture integrates QoS management into every software module, and all modules are responsible for the collection of the QoS management information they require. In the design of a module, it is important to express both the mutual need of resources from other modules and the adaptation that is required based on what resources the module has agreed upon and on what it actually gets. The design of software modules for the Pocket Companion therefore focuses on co-operation and adaptation issues rather than performance.
The Project Programme stated the following objective for phase I:
In the first phase we will determine whether our use of QoS is feasible. We will establish this by ensuring that we can realise the main building blocks in our QoS notion.We are able to demonstrate applications in which our QoS notion is an integral part (e.g. Diary demonstrator deliverable II.3.4). The architecture of Moby Dick (deliverable II.3.1) describes our QoS approach in more general context. We believe that the QoS objectives have been met because:
Although it is possible to access all information via a wireless link, we assume that most users will access their data from the type of network that is available or most convenient at any particular place and time. Mobile computers need to be able to move seamlessly from one communication medium to another, for example from a GSM network to an in-door network, without rebooting or restarting applications. The system must even be prepared to deal with complete disconnection from the network. Even then applications might continue, but are notified when inconsistencies occur. The Moby Dick objective is:
to find out whether we can switch seamlessly between radically different networking technologies in resource poor machines like the Pocket Companion.The objective has been met since we have build an implementation that allows all applications to keep their connections, while the computer switches from one network to another. Deliverable II.3.2 presents the implementation of the Software Network, which enables multi-homed mobile computers to switch dynamically and seamlessly from one network to another.
The Moby Dick objective is to find out whether our solution to consistency control, where the user is part of the decision loop, is suitable for the Pocket Companion, both in terms of the requirements of user involvement and resource consumption.To give users reasonable performance over slow networks and reasonable service during network outages, storage systems must be distributed and do extensive caching. To give optimum service, distributed storage systems must be aware of the bandwidth and communication costs of the links that connect their parts. Storage systems will be a vital guardian of consistency for most applications.
Partitions are possible and are expected primarily in wireless networks. When a partition occurs, file replicas (cached files) are accessible, but applications are notified if a possibility exists that inconsistencies occur. Applications must be prepared to deal with inconsistency. Simple applications, such as editors, can delegate the decision to edit a file under threat of inconsistency to the user. More complicated applications, such as a distributed diary application must implement protocols to deal with inconsistencies and resolve them later, when the partition has been fixed.
The behaviour of an application may have to be adapted as a consequence of network outages. The QoS manager must be aware, when making an appointment, that there is such an outage and that updates from the secretary may not have been able to reach it for a day. The user interface of a diary application must reflect such information.
In chapter 5 of deliverable II.3.1 we describe the consistency architecture of Moby Dick. The consistency objective for the first phase has been met as we have made a demonstrator (deliverable II.3.4) that shows the suitability of such an architecture in which the user is part of the decision loop. Our user may decide what to do with conflicting updates, the use of resources and the propagation of updates across the cache hierarchy. The consistency architecture extends this scheme to a more general scenario (see chapter 5 of Deliverable II.3.1).
General-purpose operating systems have a poor track record where security is concerned. If it is at all likely that, on some systems, software containing Trojan horses or viruses will be installed, then it is not a good idea to use such systems for carrying out operations involving secret keys. Secret keys must not merely be kept secret for the obvious reason that, if one's keys are stolen, one's information is no longer secure. Most keys must be kept 'blatantly secure' for purposes of non-repudiation. A modern notebook computer with a meticulously designed and implemented secure operating system may provide a sufficiently secure environment for carrying out financial transactions.
The objective of the first phase is:
to find out whether our solution, based on smart-card technology, can provide a plausible and integrated solution for implementing fully secure mechanisms in very personal and relatively resource poor machines like the Pocket Companion.The security objective for the first phase has been met as we have devised a hardware architecture where the Trusted Computing Base (TCB) is limited to a security module and supported hardware (i.e., explicitly excluding software). The architecture has been designed specifically to support signing of contracts in a (possible) hostile environment, a feature we believe will be crucial for a Pocket Companion. This solution is described in chapter 4, `The security architecture' and chapter 6 `The system architecture of the Pocket Companion' of deliverable II.3.1.
Furthermore, one of the research items mentioned in the programme stated is the following:
a user will not allow any foreign service on his very personal machine unless security is handled well enough. Vice versa, his machine should not provide services to guest machines either, unless security is guaranteed.Execution of foreign code on your personal computer is not a new phenomenon, but additional work and experimenting is required to make it secure. We have built an experimental security framework for executing foreign programs, called helpers, on a Pocket Companion. Helper programs have a profile associated with it, that specifies what files and resources will be accessed, in what way they are accessed, and the capabilities of the helper. This mechanism uses a two phase approach: first it checks the profile in order to make the decision whether to run the application or not, and secondly it monitors the behaviour of an application. The Inferno operating system is used as prototyping vehicle, which turns out to be a proper choice not only because it already offers some security mechanisms against erroneous or malicious applications, but also because it allows us to put the required security mechanisms at user level.
The project programme stated:
The objective is to find out whether our approach to power management, based on operating system detection and user level control, significantly saves battery power.The typical use of the Pocket Companion induces a number of requirements concerning energy consumption, communication, security, performance, and size. Research has shown that there is no single solution to reduce energy in the Pocket Companion. In our architecture we propose several supplementary approaches to reduce energy consumption as described in deliverable II.3.1 chapter 6. The power management system is based on three issues: system decomposition, integration of QoS management and communication.
First of all, because the system architecture is decomposed of dedicated application specific subsystems that are connected with each other, energy consumption is reduced. It was shown in the assessment criterion 3 of power management that application specific co-processors can reduce energy consumption considerable.
Secondly, one of the key aspects of our QoS approach is to move power management policy decisions to the user and coordination of operations into the operating system. The operating system will control the power states of devices in the system and share this information with applications and users. Each module has its own - dedicated - local power management. Only the module is able to, and has the knowledge to implement the necessary power management fine-tuning of the internal functions. However, the overall power management control of the modules is done by the operating system and the user.
Finally, as the wireless network interface of a mobile computer consumes a significant fraction of the total power, we put considerable effort in reducing energy consumption of communica- tion interfaces. There are several ways to achieve this: 1) by system decomposition, 2) by using hybrid networking, and 3) by applying power aware MAC protocols. We have developed a MAC protocol that is suitable for real-time multimedia applications and that has low-power characteristics. Power management assessment criterion 3 describes this in more detail.
We have successfully identified one of the key principles -- namely the use of Forward Error Correction (FEC) techniques -- to be used in multicast/broadcast communication protocols. These techniques can be used to reduce power consumption on the mobile devices by reducing the number of expensive transmissions operations in exchange of an increased amount of processing, and also to reduce transfer times and improve the efficiency of protocols.
We believe that with our architecture the power consumption and communication objectives have been met. This is described in the power management assessment chapter and in chapter 6 of the Moby Dick architecture (deliverable II.3.1).
The motivation behind our aspiration to design the Moby Dick architecture has become even more relevant in the past year. Some of the key building blocks of the Pocket Companion have become technically mature, but what is still missing is a sound overall architecture so that the Pocket Companions can be used as means to participate in an on-line information community. Mobile computing, assisted by wireless networking, is an essential step in making electronic document exchange, electronic communication, and electronic commerce. It should replace at least some portion of their non-electronic counterparts. However, this development will have to be accompanied by much better infrastructures for securing the privacy of one's personal data and the integrity and authenticity of financial and other transactions. In the first phase of the project we have designed an architecture that looks promising for these transactions. In the second phase we will continue with our work and make a prototype.
Besides the security aspects, the system architecture of the Pocket Companion will also reflect the need for communication and a low energy usage. Although the power management assessment criteria were met, the results also showed that power management and a modest use of energy will stay an important issue. In a second phase of the project we definitively address these issues more profoundly.
The work within hybrid networks has shown a promising solution to the problem of switching between network interfaces. This service is important for providing a functional interface to mobile computers in general, and the Pocket Companion in particular. This activity will be continued as an part of the QoS-based network architecture, and not as a stand-alone subproject.
In the first phase of the project we have identified the use of Forward Error Correction (FEC) techniques to achieve a reliable multicast protocol to reduce power consumption and transfer times and to improve the efficiency of protocols. Because of the relatively novel application of such techniques in the field of computer communications, much work remains to be done.
The consistency architecture devised in the first phase is a promising tool also for those applications in which the consistency of data items accessed through the Pocket Companion, and possibly shared among multiple users, is an issue. A crucial aspect of the architecture consists in localizing the state information about a Pocket Companion in a dedicated entity (the proxy) whose lifetime spans across disconnections and reconnections. The necessity of this mechanism ultimately follows from the fact that users can move unpredictably. This appears to be of general importance, and does not depend on the particular consistency model employed at the application level. Consequently, it is important to determine how the above approach fits in everyday scenarios. Examples are applications that must survive across failure and recoveries on a fixed network as well as accommodating a highly changing set of participants, coming from possibly foreign sites. We shall model these applications as long-lived services, to emphasize that they constitute a sort of localized facilities that are offered to a Pocket Companion that happens to be in their neighbourhood. In a second phase of the project we will emphasize this aspect.
The success of devices like the Pocket Companion as an important personal tool, depends on the ability for applications and system services to be adaptive. During the first phase, we have developed an architecture for adaptive software systems that is based on a modified notion of Quality of Service (QoS). The architecture does not emphasize on the provision of QoS guarantees. Instead, QoS is used to convey relevant and timely information between service users and providers. The architecture handles adaptability pertinent to non-functional and management issues in many areas, and we have demonstrated that adaptability in diverse areas like power management, network services, consistency and security can be handled. This makes us confident that our method to the handling of adaptability is sound and feasible, and that the work should be continued in the second phase. In the second phase our QoS architecture will be developed further, and evaluated experimentally. The following research areas are of particular importance:
For phase II we have established an industrial advisory board consisting of researchers and managers from industry that have expressed their interest in Moby Dick. Via this board we are in direct contact with relevant industries and expect that the industry can take-up the results. Furthermore, we hope that with the establishment of the board we can ensure that our solution is coherent with the future trends in the industry.
The work of the first phase already resulted in a fruitful collaboration with Nedap N.V., Groenlo with which a subproject was started. In this sub-project we investigate a short-range wireless network. As a first result we already have a wireless interface that can transceive ATM packets at a speed of 1 Mbps. For the second phase of the project we will continue the collaboration, and the company will become a member of the advisory board.
Further contacts have been made with Lucent Technologies Wireless Communication and Networking Division (WCND) business unit in Nieuwegein and Bell Labs in Utrecht, the Netherlands. WCND will sponsor the Moby Dick project with equipment (like WaveLAN-II). Bell Labs will become a new partner dealing with QoS in relation to MAC protocols. We plan to elaborate on wireless networks in the second phase and stress research on QoS and power aware communication.
Another valuable partner and also member of the advisory board is the research department of Ericsson Mobile Networks (EMN). Their combined expertise in fixed and mobile networks, mobile phones and infocom systems makes Ericsson the world-leading supplier in telecommunications. Ericsson performs leading-edge research in several areas that are essential to telecommunications: transmission for optical fibre cables, microwave technology, optical switching matrices, very-high-capacity processors, digital mobile telephony, broadband communication for rapid data transfer rates.
With IBM Nederland N.V. we have contacts regarding to security protocols and smartcard technology. This department of IBM has a long experience with electronic payment. Currently they are involved in several smartcard projects, among which the Dutch national student chipcard project. They have shown interest in the secure transaction protocol of the Moby Dick project. They will become a member of the advisory board and will join the project in a second phase as a subcontractor of the University of Twente.
In the Moby Dick project we have looked at several operating systems that could be used for the Pocket Companion. We have done some experiments with the operating system Inferno from Lucent Technologies. It is a flexible and modular operating system for handling interactive media. It is under development within the Computing Sciences Research Centre of Bell Labs Innovations at Lucent Technologies, at Murray Hill, New Jersey. This contact has lead to a fertile cooperation. The head of Lucent's Inferno development team will become a member of the advisory board.
The Pocket Companion will rely on third party infrastructure. In particular, there will be a need to interact with service providers, as for instance internet providers, as well as providers of the public communications infrastructure. To reflect this, we have on the advisory board a member from the by far largest Internet Provider in Norway, Scandinavia Online AS, and a member from an infrastructure and service provider at all levels, the Norwegian Telecom, Telenor AS. From the former we will be provided with valuable insight into the dynamic market that this industry represents. Scandinavia Online will receive information about the special requirements that systems like the Pocket Companion have, and in particular get faced with the security problems of these systems. The latter, Telenor, has strategic and technical competence from both research and operation of a wide range of both infrastructure and enduser services that are relevant for the project. Their participation in the advisory board will give us better insight in the European telecommunications arena, and will give them information about the infrastructure requirements put forward by the Pocket Companion.
Another infrastructure that may become important is cable TV networking. In this context DeltaKabel TeleCom cv, in Gouda the Netherlands, is interested in the Moby Dick project. Their focus is on the interaction with new functionalities of cable TV. They are highly interested in devices like the Pocket Companion and the functionalities of the Moby Dick architecture. This company will become a member of the advisory board.
