Information about http://www.ics.uci.edu/~franz/Site/pubs-pdf/C18.pdf
A Fresh Look At Low-Power Mobile Computing …
Tags: advanced applications, client server architecture, component hardware, computational device, computer science university, critical server, dumb terminal, execution unit, extreme case, hostile networks, interface component, java mobile, level ms, michael franz, mobile base, mobile device, mobile station, personal sphere, station1, university of california irvine,Pages: 6
Language: english
Created: Mon Aug 27 11:43:44 2001
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
A Fresh Look At Low-Power Mobile Computing
Michael Franz
Department of Information and Computer Science
University of California, Irvine
Abstract We challenge the apparent consensus that We propose a solution based on off-loading the
next-generation mobile devices must necessarily resource-intensive parts of the client program to the
provide resource-intensive capabilities such as Java mobile base station1 or to an appropriate
interpreters to support advanced applications. computational device in the user's personal sphere,
Instead, we propose an architecture that exploits the such as a "home base station" or a more capable
high "last mile" bandwidth in third generation notebook/PDA computer carried on the user's body
wireless networks to enable the largest part of such and connected via a technology such as Bluetooth. In
applications to run inside a base station, effectively the most extreme case, the user's mobile device then
reducing the mobile device to a dumb terminal. We only needs the functionality of a dumb terminal,
discuss some implications of this architecture, with making use of a high available bandwidth between
respect to hand-off, confidentiality while roaming in the actual execution unit (XU) and the mobile station
potentially hostile networks, and the need for a (MS)--but the MS might also perform critical
server-transparent segmentation of applications into functions locally, perhaps utilizing reprogrammable
a computational and a user interface component. hardware. The original two-level client-server
architecture thereby becomes a three-level MS-XU-
server architecture.
1. Introduction A key characteristic of the proposed
architecture is that a remote server need not be aware
Latency and bandwidth continue to lag behind
of the fact that the client is not actually running on
demand, and this situation will continue even with
the mobile station. Further, the division of concerns
the availability of third generation mobile networks.
between MS and XU can be adjusted, potentially
In future wireless networks, available bandwidth
even at run-time, without notifying the server of this
between the mobile terminal and the base station
fact. Finally, local state is kept at the XU (albeit
increases significantly, but this doesn't solve the
possibly partially cached at the MS), increasing
problems of bandwidth contention further upstream
overall robustness in the event of power failure of the
or those relating to latency, especially when dealing
MS or intermittent communication breakdown.
with remote applications.
The following sections describe the proposed
The traditional solution of overcoming these
architecture in more detail and point to areas that
problems has been to place more local intelligence at
require more research. Among other facets, we
the user's site. The most successful approach to this
discuss the implications of handover and the resulting
so far has been that of downloadable "applets" or
need to transfer state between different XUs. Of
"mobile agents" that travel from a server to the user's
particular interest to service providers might be that
terminal device and conduct most of their
the provision of computational resources at the XU
computations locally, unhindered by bandwidth or
constitutes a possible source of revenue, and that
latency constraints.
control over such user state might tie users closer to
Unfortunately, downloading and executing
mobile code requires considerable resources, both providers and thus reduce churn. We discuss the
computationally as well as storage wise, with an issue of automated segmentation of functionality, by
immediate implication on power consumption. At
first sight, this might rule out mobile-code client 1
In a GSM system, the entity performing these
solutions targeted at low-cost low-power handheld
resource-intensive tasks would most probably be co-
devices such as next generation mobile voice/data
located with the MSC (or rather, be part of the
terminals and networked embedded processors in
Serving GPRS Support Node) while in cdma2000,
consumer products.
these functions would fit within the BSC node.
15-1
2
which a controller decides which parts of the client implementations are likely to be quite complex and
program should be downloaded to the MS and which consequently relatively expensive and power-hungry.
parts should run at the XU. In case of a MS that Hence, cost and battery-life considerations reduce the
includes reconfigurable FPGA hardware, historical appeal of increasingly "smart" mobile terminals.
usage profiles might be used to select an initial We propose an alternative architecture
configuration of the FPGA grid, but this could be (Figure 1) in which the client program is further
updated in real time (using dynamic recompilation) subdivided between an execution unit (XU) and a
under the remote control of an XU that constantly mobile station (MS). For example, and this is our
models the execution of the reconfigurable hardware main target scenario, the XU could be incorporated
in the MS. Lastly, we discuss the fact that certain into a mobile service provider's infrastructure and the
security applications such as banking might require MS could be a mobile terminal--but the XU might
dedicated functionality (such as encryption) to be also be a television set-top box (or network-
downloaded to the reconfigurable hardware in order connected games console) and the MS a remote
to guarantee end-to-end functionality, and how this control unit. The key characteristic of our model is
might be modeled in our architecture. that there is a direct (i.e., very low latency)
connection between XU and MS, and that this
connection has sufficient bandwidth. Given these
2. Architecture parameters, the MS in the most extreme case could
then act simply as a "dumb terminal".
A common approach to masking the latency and
In our model, the server is unaware of the fact
limited bandwidth of client-server applications has
that the client is actually composed of two distinct
been the addition of local processing power at the
parts, XU and MS. To the server, the XU-MS pair
client's site ("fatter" clients). The spectacularly
acts as an atomic entity that is physically located
successful Java platform is the current champion of
wherever the MS happens to be (for location-aware
this paradigm. Java's inventor, Sun Microsystems
services) and that has at least the computational
Inc., has been trying to extend the reach of the Java
resources of the XU (the MS may contribute to the
platform ever further down the performance spectrum
total). Hence, in the Java case, a JVM class file
to embedded consumer devices such as PDAs, smart-
would appear to be downloaded to the MS, but most
phones, or even household appliances, by introducing
of it would actually be executed on the XU, with the
a core (picoJava) for dedicated processors that can
segmentation between the two either being hard-
execute Java bytecode directly on the silicon.
coded into the libraries on the XU (simple case) or
Processors based on the picoJava core require
dynamically decided and adjusted using just-in-time
far less external memory than alternate solutions
code generation (a much more challenging case).
based on general-purpose processors for
interpretation (or even dynamic translation) of Java
bytecode. Unfortunately, however, picoJava's
Server Internet Client as seen by Server
XU MS
base station mobile phone
set-top box remote control
low-high bandwidth medium-high bandwidth
high latency low latency
Figure 1: System Architecture
15-2
3. Handover and the Quantization of A third scenario depicted in Figure 2 is that of a user
carrying his or her own mobile context that is
Computational Resources sufficiently capable computationally to carry out the
A cornerstone of our architecture is the provision of a functions required of an XU. This is not really all
low-latency connection between the XU and the MS. that far-fetched. For example, the user may be
In the case of a MS that is physically moving, this carrying a PDA or laptop in close proximity that is
implies moving the state of the computation that is sitting idle while the user is making a flight
running on the XU along with the MS to keep it reservation using his or her mobile phone. It might
"close" and the latency low. While one might also make sense off-loading the computation to the local
envisage a solution in which the computation remains device while the user is, for example, sitting on a
stationary on the initial XU and all traffic is routed train for several hours. The problem here is that the
via that XU, perhaps using a fixed-bandwidth device hosting the local context may itself run out of
reservation scheme, this would clearly be sub- battery power or else may be shut off at any time; this
optimal; only true mobility of the computations suggests that the signaling of the upload/download
themselves will result in fully scalable performance. actions would most probably have to be done by the
Hence, it becomes necessary to transfer state end-users themselves and that fault-tolerance
from one XU to another. This brings with it the considerations need to be incorporated into the final
potential to have XUs in different organizational design.
domains seamlessly working together: For example, This brings us to the issue of the actual transfer
while the user is physically at a home or office of the local state, which requires all of the following:
location, execution services might be provided more
1. The receiving XU must have sufficient resources
cheaply by a private server installed on those
to be able to add this computation to its existing
premises. As a user enters a locality that offers such
workload.
a (cryptographically authenticated) execution
environment, the whole active state is transferred 2 . The receiving XU must have the required
away from the service provider and is eventually libraries available locally to support the ongoing
restored there as the user leaves the locality; all of computation. Note that an XU that is underused
this completely transparently to the user. Figure 2 can prefetch libraries used at "neighboring"
shows some of the possible scenarios. Note that in MSCs in anticipation of future handovers.
such a transfer from service provider to local context
3. There must be sufficient network resources to
and back, the service provider can actually cache the
enable the transfer of state information between
local state, so that only the changes need to be
communicated as the MS re-enters the domain of the
service provider.
Execution Unit Scenario
Network service provider additionally also supplies computational infrastructure,
probably for a fee. Handover requires continuous transfer of computational state
"staying close to the mobile station" in order to preserve latency characteristics.
network/provider-based
Unlike voice calls, which are dropped when the current provider's network is left, it
would be desirable to provide continuous handover of computational state even when
roaming across different service providers' networks.
User carries an additional device such as a laptop or PDA that can provide
computational services to the MS and that is linked to the MS using some body-area
user's mobile context networking technology such as Bluetooth. Upload/Download of state both from/to
external service provider and/or home base station possible under user control; similar
to "synching" today's PDAs.
As user enters home or office, active computational state is transferred from network
home/office base provider's computers to a local execution unit installed on private premises, relieving
station the network provider of the obligation to host the computation and temporarily
suspending billing for these services.
Figure 2: Different Classes of Execution Units and Applicable Usage Scenarios
15-3
the two XUs within a useful time frame. But On the other hand, it would enable a greater range of
note that the timing constraints for this sort of services to be provided in the first place that might
handover are much less stringent than they are otherwise bypass mobile service providers
for voice connections, and that they need not completely. Furthermore, the available level of
even occur simultaneously with an ongoing network-based computation might turn into a key
voice handover. In fact, if one allows for a service distinction between competing providers.
slight temporary increase of latency, one may Of note is also that many of the envisioned
permit a nomadic user to move a certain applications are of the "always on" kind, i.e. the
number of "hops" away from its current XU application programs never "quit". These could be
and hand over the computation only when the structured in such a way that they increase customer
number of hops exceeds a certain threshold or "stickiness". For example, the user might have two
the user becomes stationary. This approach applications implementing an electronic organizer
may be particularly attractive when and an MP3 jukebox, both of which are permanently
complemented by the previously mentioned running on his MS, hosted by the actual service
idea of a "user-carried" XU that might be used, provider. Although these are in reality downloadable
e.g., on a longer high-speed train journey. applications like any other, they could be marketed as
a basic service (i.e., not count towards the allocated
"clicks" and "object space") and as far as the user is
3.1 Standardization of Execution
Environment's Parameters concerned might just as well be built into the MS
itself. As a consequence of this marketing strategy,
We believe that a general adoption of our architecture the user will not choose a competing service from an
would most probably lead to a standardization of the external source. But now, all user-defined
execution environment's parameters, not just in terms preferences and settings are "owned" by the network
of the libraries available (as in Sun's JavaOS project) service provider, reducing the users' propensity of
but in terms of quantifying actual processing and changing providers.
memory resources in a standardized way independent
of an actual processor platform. Such standardization
4. Segmentation of Functionality:
not only aids in allocating resources when
transferring computations between XUs, but might The XU-MS Split
also be useful for billing purposes. For example, a Client applications are jointly executed by the XU
user might subscribe to a guaranteed minimum and the MS, but creating the illusion to the server that
workspace of 25kObjects and a minimum throughput all of the processing happens at the geographic
of 50kTicks per minute, with specified penalties for location of the MS. This leads to the question how
going over those limits. A combination of paid-for- functionality is divided between the XU and the MS.
resource allocation and dynamic resource control is In the most simple case, the MS would simply
also an effective defense against denial of service be a dumb terminal. The XU would run a "virtual
attacks. terminal" that translates GUI commands coming
In our initial approach to exploring these issues, from the client application to remote-terminal
we are using the Pi calculus and the Pict instructions for the MS. Since all interaction with
programming language [PT97] for systematically physical I/O devices in Java is via well-established
modeling the connectivity, communication and libraries, this would be very simple to accomplish in
mobility (MS moving from one XU to another) the Java case. We also note that others have been
arising in our architecture. successful at building an architecture in which MS
Windows GUI commands are intercepted on a server
3.2 A Commercial Vision: Impact on Billing, and relayed to a client residing within a web browser
Customer Loyalty and Churn [Citrix], enabling the remote execution of local
desktop software from anywhere on the web--this is
Most likely, the provision of computational services essentially the exact same architecture as our
could be turned into a significant source of revenue proposed "dumb terminal" solution.
for service providers. On one hand, off-loading the A much more challenging objective would be
computations into the network makes for extremely to actually perform part of the processing on the MS
cheap mobile devices that can be distributed without itself. For the purpose of minimizing power
a subsidy--"disposable" devices are entirely feasible. consumption on the MS, one needs to include the
15-4
5
power used for communication in the overall cost The availability of an appropriate (non-virtual-
equation. Using a "dumb terminal" approach, the machine) intermediate representation makes this task
mobile station is likely to be receiving much more considerably simpler. For example, at UCI we have
data than it needs to send, but there may still be been experimenting with mobile-code representations
significant number of handshakes and other data based on the condensed graph model [Mor96].
exchanges that might be reduced using local Condensed graphs express Availability-Driven,
processing on the MS. Note that the XU will be able Coercion-Driven and Control-Driven Computing in a
to model current and future power consumption of single unified model of computation and have
the MS quite accurately as it gathers usage statistics transformations that allow you to "turn up or down"
on a per-application or even per-user basis. the amount of processing power required.
The task of partitioning the application between Essentially, this transforms the partitioning problem
a resource-constrained MS and a remote XU is not from a speculative, data driven model using a
unlike the task of partitioning an embedded system substantial amount resources to a lazy, demand
(between slow but flexible software, and fast but driven model that tries to minimize resource usage by
rigid hardware). There are also some similarities applying simple topological transformations.
with partitioning for parallel execution, particularly The availability of such a model in the mobile-
considering the fact that some partitionings may code representation itself significantly reduces the
require more communication among the participants burden on the XU (or appropriate controller) for
than others. Hence, it is quite likely that ideas from computing such a model, and makes it possible to
the embedded systems community and the even adjust these bindings on-the-fly in reaction to
parallel/distributed systems community can be changing user activities on the MS: based on a model
adapted to this problem domain. of what the MS is doing, the XU at regular intervals
It is also important to note that the current sends it an updated FPGA configuration.
version of JVM-code is unlikely to survive as the
dominant mobile-code interchange format in the
4.2 Special End-To-End Application
longer-range future. As we have demonstrated in
Requirements
previous research [FK97, ADF01, ADR01], there are
alternative formats not based on virtual machines that Lastly, we observe that there are applications that
provide much better performance than JVM does, require special care in partitioning. For example,
and more easily verifiable security. It is likely that communications with a banking application are
such future formats would include annotations that encrypted, with the assumption being that (1) the
would guide in the partitioning of functionality client program is actually (atomically) executed at a
between XU and MS. We are currently working on single terminal location and (2) that this terminal
mechanisms for integrating specific annotations location provides a trusted computing infrastructure,
describing programmer-specified parallelism and i.e., the data path between the mobile client program
compiler-derived parallelism into a mobile code and the user (through the OS, web browser, etc.) is
format in a manner that is useful to a parallelizing not corrupted by an interposed malicious agent.
compiler back-end at the code recipient's site. Obviously, condition (1) is violated in our
architecture, and indeed the data path between the
XU and the MS is potentially much longer and
4.1 Use of Field-Programmable Hardware in subject to eavesdropping and corruption. Worse still,
the Mobile Station
when roaming in foreign networks, any potential
The deployment of field-programmable hardware in secret would be readily available to the foreign
mobile stations then becomes an interesting entities running such networks simply by observing
possibility. Ideally, the same analysis process that the XU.
partitions functionality between the XU and the MS A solution to this problem lies in designing an
could be taken one step further, creating custom appropriate type system into the mobile-code
hardware on-the-fly on the MS where this is most transportation scheme itself that can directly express
beneficial. Such downloaded dedicated routines a notion of confidentiality and trust. The XU is then
might include encryption protocols, vocoders for under the obligation to partition the mobile client
speech (input, output, and telephony), and visual- program in such a manner that the trusted parts reside
object rendering (texture mapping etc.) capabilities on the MS. This property can be verified using
for gaming applications. proof-carrying authentication protocols [AF99]
incorporating the code being downloaded itself
15-5
6
--after download, the MS generates a response sent References
back to the server that vouches for the fact that the
[ADF01] W. Amme, N. Dalton, P. H. Fröhlich, V.
trusted subset of the computation is now running on a
Haldar, P. S. Housel, J. v. Ronne, Ch. H.
trusted host.
Stork, S. Zhenochin, and M. Franz;
"Project transPROse: Reconciling Mobile-
5. Status and Research Vision Code Security With Execution Efficiency";
in The Second DARPA Information
We are currently embarked on a substantial project Survivability Conference and Exhibition
(funded by NSF and DARPA) to design a new (DISCEX II), Anaheim, California;
mobile-code distribution architecture that reconciles IEEE Computer Society Press,
provable security with execution efficiency. ISBN 0-7695-1212-7, pp. II.196II.210;
A first major result of this project is our June 2001.
discovery of a class of mobile code representations
that can encode only programs that provably cannot [ADR01] W. Amme, N. Dalton, J. v. Ronne, and M.
harm the target machine--these mobile code formats Franz; "SafeTSA: A Type Safe and
therefore provide security "by construction" rather Referentially Secure Mobile-Code
than "by verification" as currently required by Java Representation Based on Static Single
[ADF01, ADR01]. Assignment Form"; in Proceedings of the
Our project also addresses some of the issues of ACM Sigplan Conference on Programming
functionality segmentation, as well as the required Language Design and Implementation
protocols to perform mobile-code verification, (PLDI 2 0 0 1 ) , Snowbird, Utah,
dynamic translation, and execution at perhaps pp. 137147; June 2001.
physically disjoint sites. However, it does not [AF99] A. W. Appel and E. W. Felten; "Proof-
currently address the handover issues we have Carrying Authentication"; in Proceedings
brought up here, nor does it currently address field of the 6th ACM Conference on Computer
programmable hardware. and Communications Security, Singapore;
Our vision is to elevate good power November 1999.
management into a system-wide quality of mobile-
code systems. We believe to have identified several [Citrix] Citrix, Inc.; Citrix® Independent
topics requiring further research and are already Computing Architecture and Citrix
embarked on the quest for solutions. MetaFrameTM; http://www.citrix.com.
[FK97] M. Franz and T. Kistler; "Slim Binaries";
Acknowledgement Communications of the ACM, 40:12,
pp. 8794; December 1997.
This paper was inspired by an afternoon that the
author spent at the TIK institute of ETH Zurich [Mor96] J. Morrison; Condensed Graphs: Unifying
talking to B. Plattner, L. Thiele, and their associates. Availability-Driven, Coercion-Driven and
The author would also like to thank the anonymous Control-Driven Computing; Technische
referees for their constructive comments. Universiteit Eindhoven, ISBN 90-386-
This research effor t is partially funded by the 0478-5; October 1996.
U.S. Department of Defense, Critical Infrastructure [PT97] B. C. Pierce and D. N. Turner; "Pict: A
Protection and High Confidence, Adaptable Software Programming Language Based on the Pi-
(CIP/SW) Research Program of the University Calculus", in G. Plotkin, C. Stirling, and
Research Initiative administered by the Office of M. Tofte (Eds.), Proof, Language and
Naval Research under agreement N00014-01-1-0854, Interaction: Essays in Honour of Robin
and by the National Science Foundation, Program in Milner, MIT Press; 2000.
Operating Systems and Compilers, under grant
CCR-9901689.
15-6