The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.03 - July-September (2004 vol.3)
pp: 4-5
Published by the IEEE Computer Society
M. Satyanarayanan , Carnegie Mellon and Intel Research
ABSTRACT
Adaptive behavior is a recurring theme in pervasive computing. The need for adaptation arises when a significant mismatch exists between a resource?s supply and demand. Learn what causes this mismatch and read about three strategies for dealing with it in pervasive computing.
Adaptive behavior is a recurring theme in pervasive computing. The need for adaptation arises when a significant mismatch exists between a resource's supply and demand. Often, the mismatch is in a low-level system resource such as network bandwidth, residual energy in a battery, CPU cycles, or memory. Sometimes it is a resource related to interaction such as display size or input modality. Or, in a context-aware system, it might be a high-level resource such as user attention or short-term memory.
Origin
Why does the mismatch arise? Most frequently, it is due to mobility. For example, a user might move from one location where certain resources are plentiful to another location where they are scarce, or vice versa. Wireless network bandwidth is perhaps the resource most sensitive to physical location, since coverage is rarely uniform over a large area. The availability of nearby compute servers or data-staging servers is also location-dependent and therefore affects techniques such as cyber foraging. 1 In the case of code mobility, it is the application rather than the user that moves. In that case, both low-level resources and interactive resources such as display quality might vary widely between the source and destination systems. Resource variation can arise even when the user and code are static. Network bandwidth, for example, can vary widely depending on the actions of other users in the neighborhood. Sometimes just the passage of time causes a change in resource level. For example, energy becomes less plentiful for a laptop as its battery drains.
Regardless of cause, we can't simply ignore a gross mismatch between resource supply and demand. Doing so will result in an unsatisfactory user experience, usually because of sluggish system performance. Severe performance degradation can raise user frustration so much that it leads to increased human error, further increasing frustration. Sometimes, attributes other than system performance are affected. For example, a desktop application that has migrated to a handheld computer might present output that is unreadable on a small screen. As another example, ignoring the device's battery level could result in the user having to stop work prematurely. In all these examples, a system's proactive behavior—or "adaptation"—could improve the total user experience.
Adaptation is also important in the other direction, when resource levels improve. Otherwise, the user will be paying an opportunity cost by working in a "lean and mean" computing environment rather than a rich environment that is better able to bring his or her cognitive skills to bear on a particular task.
Adaptation Strategies
Three strategies exist for adaptation in pervasive computing. First, a client can guide applications in changing their behavior so that they use less of a scarce resource. This change usually reduces the user-perceived quality, or fidelity, of an application. Armando Fox and his colleagues' work on image transcoding is one of the earliest examples of this technique. 2 Work by Brian Noble 3 and Jason Flinn 4 and their colleagues shows how we can broaden this approach across diverse applications and resources. We also can view changing the displayed output to match a small screen size as a form of fidelity change.
Second, a client can ask the environment to guarantee a certain level of a resource. This is the approach that reservation-based, quality-of-service (QoS) systems typically use. 5 From the client's viewpoint, this effectively increases a scarce resource's supply to meet the client's demand. To be viable in the real world, this approach must be combined with a framework of incentives for resource providers (such as a billing system) that encourages differential treatment of users.
Third, a client can suggest a corrective action to the user. 1 If the user acts on this suggestion, it is likely (but not certain) that the resource supply will become adequate to meet demand. We can view a corrective action as an executable hint, a concept now widely used in distributed systems. 6 Aura is an example of a system that is exploring this technique. 7
All three strategies are important in pervasive computing. In a well-conditioned environment, a reservation-based approach might be feasible. At the same time, a user who travels extensively cannot assume that resource reservations will be supported everywhere. At some locations, reduced fidelity might be the only feasible form of adaptation. Using corrective actions broadens the range of possibilities for adaptation by involving the user. This approach could be particularly useful when lowered fidelity is unacceptable for a particular task.
Impact on Layering
The need for adaptation complicates the decomposition of software into layers. Successful adaptation often requires merging information from diverse system layers. Unfortunately, layering can obstruct the visibility of critical information needed for adaptation. For example, suggesting a corrective action such as a short walk to a location with better wireless bandwidth is a high-level interaction with the user. However, wireless bandwidth is a low-level resource that is rarely visible to a system's upper layers.
Layering cleanly separates abstraction from implementation and is thus consistent with sound software engineering. Layering is also conducive to standardization since it encourages the creation of modular software components. Deciding how to decompose a complex system into layers or modules is nontrivial and remains very much an art rather than a science. The two most widely used guidelines for layering are David Parnas's principle of information hiding 8 and Jerry Saltzer and his colleagues' end-to-end principle. 9 However, these date back to the early 1970s and early 1980s, respectively, long before pervasive computing was conceived.
It therefore remains an open question whether layering and adaptation are truly compatible. We need sound design principles and well-validated implementation guidelines to help us structure software systems for pervasive computing. Until then, we will remain in the position of the ancient mariners who ventured into the vast unknown with maps of dubious accuracy.
To help us in this exploration, the current issue focuses on "Building and Evaluating Ubiquitous System Software." The guest editors, Vinny Cahill, Armando Fox, Tim Kindberg, and Brian Noble, all have extensive experience in designing and implementing software systems for pervasive computing. Their Guest Editors' Introduction describes the articles selected for this issue.

References

21 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool