cs 6910 – pervasive computing section 0.a: introduction to pervasive computing dr. leszek lilien...

CS 6910 – Pervasive Computing

Section 0.A:

Introduction to Pervasive ComputingDr. Leszek Lilien

Department of Computer ScienceWestern Michigan University

Slides based on the article “Pervasive Computing: Vision and Challenges”

by Prof. M. Satyanarayanan, Carnegie Mellon University,IEEE Personal Communications, 2001

[Possible mistakes and omissions are all mine. – LTL]

Slides are © 2007 by Leszek T. LilienRequests to use original slides for non-profit purposes will be gladly granted upon a written

request.

2© 2007 by Leszek T. LilienBased on: M. Satyanarayanan, “Pervasive Computing: Vision and Challenges,” IEEE Personal Communications, 2001

1. Introduction

Vision of pervasive computing /ubiquitous computing [Mark Weiser, 1991] ‘‘The most profound technologies are those that

disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.’’

The essence of that vision: Creation of environments saturated with computing and

communication capabilities, yet gracefully integrated with human users

A vision too far ahead of its time (1991) The required hardware technology simply did not

exist The implementation attempted by Weiser and his

colleagues at Xerox PARC fell short


Introduction (2)

Critical hardware elements of pervasive computing are now (2001) available

Are now viable commercial products Examples:

Handheld computers / wearable computers Wireless LANs Sensing devices Control appliances

We can begin the quest for pervasive computing vision.

Examples of pervasive computing projects At universities:

Project Aura at Carnegie Mellon / Endeavour at UC Berkeley Oxygen at MIT / Portolano at Washington

In the industry: AT&T Research in Cambridge, U.K. IBM TJ Watson Research Center


Introduction (3)

The goal of this paper:Understand the challenges in computer systems research posed by pervasive computing

Outline: Relationship of pervasive computing to the

closely-related fields of distributed systems and mobile computing

Two pervasive computing scenarios Why they are fiction rather than fact today.

Selected key research problems With focus on computer systems issues

Avoiding other areas important to pervasive computing E.g., human-computer interaction, expert systems,

software agents


2. Related Fields:Pervasive Computing vs.

Distributed Systems & Mobile Computing Evolutionary history of pervasive computing

Distributed systems (DIST) Mobile computing (MOBI)

[LL:] Ad hoc systems is MOBI’s superset, VANs – its subset Pervasive computing (PERV)

Technical problems in PC “Old” problems - already studied & solved at earlier

evolution steps Some earlier solutions apply directly for pervasive

computing Some earlier solutions are inadequate for pervasive

computing

New problems - no obvious mapping to problems studied at earlier evolution steps


Pervasive Computing vs. Distributed Systems & Mobile Computing (2)

Next: Sort out complex intellectual relationship

Between problems/solutions for DIST, MOBI, PERV

Develop a taxonomy of research issues for each phase of the evolution (DIST -> MOBI -> PERV)



2.1. Distributed Systems Distributed Systems

Any computers connected by any networks [The paper: Intersection of personal computers and

LANs] Research from the mid-1970’s through the early

1990’s Created a conceptual framework and algorithmic base

Enduring value in all work involving >= 2 computers connected by a network — whether mobile or static, wired or wireless, sparse or pervasive

Solutions from DIST Span many areas that are foundational to

pervasive computing Well codified in textbooks (e.g.,: [8, 19, 20])


Pervasive Computing vs. Distributed Systems & Mobile Computing (4)Distributed Systems (2)

Specific subarea solutions for DIST Remote communication

Incl. protocol layering, remote procedure call [3], use of timeouts, use of end-to-end arguments in placement of functionality [28]

Fault tolerance Incl. atomic transactions, distributed and nested

transactions, two-phase commit [13] High availability

Incl. optimistic and pessimistic replica control [9], mirrored execution [4], optimistic recovery [37]

Remote information access Incl. caching, function shipping, distributed file systems,

distributed databases [30] Security

Incl. encryption-based mutual authentication and privacy [23]



2.2. Mobile Computing Mobile Computing

The early 1990s - full-function laptops + wireless LANs Early mobile computing systems:

A distributed system with mobile clients [LL:] Current mobile computing systems:

Any nodes can be mobile

Solutions from MOBI Many basic principles of DIST design continued to apply to MOBIBUT Four key constraints of mobility required specialized techniques

[31] for MOBI: Unpredictable variation in network quality Lowered trust and robustness of mobile elements Limitations on local resources imposed by weight and size

constraints Concern for battery power consumption

Mobile computing - still a very active and evolving field of research

Awaits codification in textbooks (as of 2000)


Pervasive Computing vs. Distributed Systems & Mobile Computing (6)Mobile Computing (2)

Specific subarea solutions for MOBI Mobile networking

Incl. mobile IP [2], ad hoc protocols [27], techniques for improving TCP performance in wireless networks [1, 5]

Mobile information access Incl. disconnected operation [17], bandwidth-adaptive

file access [21], selective control of data consistency [38, 39]

Support for adaptive applications Incl. transcoding by proxies [12], adaptive resource

management [24] System-level energy saving techniques

Incl. energy-aware adaptation [11], variable-speed processor scheduling [45], energy-sensitive (=adaptive) memory management [18].

Location sensitivity Incl. location sensing [42, 43], location-aware (=adaptive)

system behavior [32, 35, 41]



2.3. Pervasive Computing Pervasive Computing

Recall: Pervasive computing environment - one saturated with computing & communication capability, yet so gracefully integrated with users that it becomes a ‘‘technology that disappears’’

Since motion is an integral part of everyday life, PERV must support mobility

Otherwise, a user will be acutely aware of the technology by its absence when she moves

Hence, research in pervasive computing subsumes that of mobile computing

BUT …


Pervasive Computing vs. Distributed Systems & Mobile Computing (8)Pervasive Computing (2)

… Research in pervasive computing goes

much further PERV includes four additional research thrusts

Effective Use of Smart Spaces Invisibility Localized Scalability Masking Uneven Conditioning

See Figure 1 (next slide)



Figure 1: Taxonomy of Computer Systems Research Problems in PERV

1) New problems are encountered as one moves from left to right in this figure.

2) Solution of many previously-encountered problems becomes more complex.

As the modulation symbols suggest, this increase in complexity is multiplicative rather than additive

it is very much more difficult to design and implement a pervasive computing system than a simple distributed system of comparable robustness and maturity.

Note:This figure describes logical relationships, not temporal ones.

The evolution of research effort over time has loosely followed this pictureBUTThere have been cases where research effort on some aspect of pervasive computing began relatively early. E.g., work on smart spaces began in the early 1990’s and proceeded relatively independently of work in MOBI



2.3.1) Effective Use of Smart Spaces A space:

An enclosed area E.g., a meeting room or corridor

OR: A well-defined open area

E.g., a courtyard or a city square

Smart space = space with embedding computing infrastructure

E.g., smart space within buildings Created by embedding computing infrastructure within

building infrastructure Smart space brings together two worlds disjoint

until now [16]: Physical space (physical world) Cyberspace



1) Effective Use of Smart Spaces – cont.

The fusion of physical world (PHYS) and cyber-world (CYB) enables sensing and control of one world by the other

Example of sensing and control of PHYS by CYB Automatic adjustment of heating, cooling and lighting

levels in a room based on an occupant’s electronic profile (incl. presence patterns)

Example of sensing and control of CYB by PHYS (the other direction)

Software on a user’s computer may behave differently depending on where the user is currently located

Note:Smartness may extend to individual objects, whether located in a smart space or not



2.3.2) Invisibility The ideal expressed by Weiser: complete

disappearance of pervasive computing technology from a user’s consciousness = invisible computing

A reasonable approximation: minimal user distraction ([LTL:] = minimal visibility)

If a PERV environment continuously meets user expectations and rarely presents him with surprises, it allows him to interact almost at a subconscious level [46]

BUT: Getting too close to the ideal might not be perfect:

A (small) degree of visibility might be needed ([LTL:] I hope that abobe I correctly interpret the following

text:“At the same time, a modicum of anticipation may be essential to avoiding a large unpleasant surprise later — much as pain alerts a person to a potentially serious future problem in a normally-unnoticed body part.”)



2.3.3) Localized Scalability Basic model of pervasive computing interactions:

User’s personal computing space (UPCS) User’s surroundings (US) Interactions between UPCS & US

Scalability problems in pervasive computing The smarter is the space, the larger is interaction

intensity This has severe bandwidth, energy and distraction

implications for a wireless mobile user. The more users in the smart space the more interactions



3) Localized Scalability – cont.

Scalability research Previous work typically ignored physical distance

A web server or file server should ignore distance Handle as many clients as possible, regardless of

whether they are located next door or overseas

Scalability in PERV must consider physical distance Interaction density has to fall off with distance

Otherwise both the user and his computing system will be overwhelmed by distant interactions that are of little relevance

A mobile user far from home will still generate some distant interactions with sites relevant to him

But the preponderance of his interactions will be local



3) Localized Scalability – cont.

Good PERV design: scalability achieved by severely reducing distant interactions

Like the inverse square laws of nature .g., the inverse square law for gravitation)

This directly contradicts the current ‘‘death of distance’’ ethos of the Internet



2.3.4) Masking Uneven Conditioning ‘‘Smartness’’ of different spaces varies significantly

(“The rate of penetration of pervasive computing technology into the infrastructure will vary considerably […]”)

Well-equipped conference room, office, or classroom smarter than other locations

Space smartness depends on: Technical factors

How well the space is saturated with smart devices Non-technical factors

Organizational structure, economics and business models, …

Uniform ‘‘smartness’’ of spaces is years or decades away (if ever achieved)



4) Masking Uneven Conditioning – cont. Differences in ‘‘smartness’’ can be distracting

Can detract from the goal of invisible pervasive computing

One idea: Reduce the amount of variation in smartness seen by a user

Example implementation of the idea: User’s personal computing space (UPCS) compensates for ‘‘dumbness’’ of its environments

E.g., a laptop masks the absence of wireless coverage The laptop notices me leaving the CEAS building and

downloads my mail as I leave the area covered by CEAS hot spots

I can read my new mail at a restaurant without a hot spot Complete compensation (achieving complete invisibility)

may be impossible But reduced variability of space smartness within reach



3. Example Scenarios

What would it be like to live in a world with pervasive computing?

Two hypothetical ‘‘look and feel’’ scenarios follow Deliberately chosen simple scenarios that appear

feasible soon (in just a few years)

Examples use [CMU’s] Aura (http://www.cs.cmu.edu/~aura/) as the pervasive computing system

But the illustrated concepts are of broad relevance


Pervasive Computing vs. Distributed Systems & Mobile Computing (19)Example Scenarios (2)

3.1) Scenario 1 Jane is at Gate 23 in the Pittsburgh airport, waiting for her

flight. She has edited many large documents, and would like to use

her wireless connection to e-mail them. Unfortunately, bandwidth is miserable since many passengers at Gate 23 and nearby gates are surfing the web.

Aura observes that at the current bandwidth Jane won’t be able to finish sending her documents before her flight departs.

Consulting the airport network’s flight schedule service, Aura discovers that wireless bandwidth is excellent at Gate 15, and that there are no departing or arriving flights at nearby gates for 30 min.

Aura displays a dialog box on Jane’s screen suggesting that she goes to Gate 15, which is only three minutes away. It also asks her to prioritize her e-mail, so that the most critical messages are transmitted first.

Jane accepts Aura’s advice and walks to Gate 15. She watches CNN on the TV there until Aura informs her that it is close to being done with her messages, and that she can start walking back.

Jane starts walking back to Gate 23. The last message is transmitted during her walk, and she is

back at Gate 23 in time for her boarding call.



3.2) Scenario 2 Fred is in his office, frantically preparing for a meeting at which

he will give a presentation and a software demonstration. The meeting room is a 10-minute walk across campus.

It is time to leave, but Fred is not quite ready. He grabs his PalmXXII wireless handheld computer & walks out of the door.

Aura transfers the state of his work from his desktop to his handheld, & allows him to make edits using voice commands during his walk.

Aura infers where Fred is going from his calendar & the campus location tracking service. It downloads the presentation & the demonstration software to the projection computer, & warms up the projector.

Fred finishes his edits just before he enters the meeting room. As he walks in, Aura transfers his final changes to the projection

computer. As the presentation proceeds, Fred is about to display a slide

with highly sensitive budget information. Aura senses that this might be a mistake: the room’s face detection and recognition capability indicates that there are some unfamiliar faces present. It therefore warns Fred.

Realizing that Aura is right, Fred skips the slide. He moves on to other topics and ends on a high note, leaving the audience impressed by his polished presentation.



3.3) Missing capabilities needed for implementing PERV Scenarios embody many key ideas in PERV Scenario 1 shows importance of:

Proactivity Jane able to e-mail her work only because Aura predicts

(estimates) how long the whole process would take Jane able to begin walking back to her departure gate

before transmission completes because Aura looks ahead on her behalf

Combining knowledge from different layers of the system Information on wireless congestion comes from a low level

of the system Knowledge of boarding time is a high-level (application- or

user-level) information Aura helps Jane only by combining these disparate pieces of

knowledge Smart space

Aura is able to obtain from the smart environment information on wireless conditions at other gates, flight arrival/departure times at different gates, and distances between gates



Missing capabilities needed for implementing PERV – cont. 1

Scenario 2 illustrates importance of: Moving execution state effortlessly across diverse platforms

Moving from a desktop to a handheld machine Moving from the handheld to a projection computer

Self-tuning (=automatically adjusting behavior to fit circumstances) Ability to edit on the handheld using speech input rather than

keyboard and mouse. Proactivity

Inferring that Fred is headed for the room across campus, warming up the projector, transferring the presentation and demonstration

Anticipating that the budget slide might be displayed next, and sensing danger by combining this knowledge with the inferred presence of strangers in the room.

Smart space The location tracking and online calendar services are what

enable Aura to infer where Fred is heading The software-controlled projector enables warmup ahead of

time The camera-equipped room with continuous face recognition

is key to warning Fred about the anticipated privacy violation



Missing capabilities needed for implementing PERV – cont. 2

Perhaps the biggest surprise:How simple and basic are all the component technologies in these scenarios

The hardware technologies are available (in 2001!) Laptops, handhelds, wireless communication, software-

controlled appliances, room cameras, … Software technologies have also available (in 2001!)

Location tracking, face recognition, speech recognition, online calendars, ...

So why then do these scenarios seem like science fiction today? (in 2001 and still in 2006)

The answer: The whole is much greater than the sum of its parts

The real challenge is in the seamless integration of h/w s/w technologies into a PERV system

Difficult problems to solve: Architecture / Component synthesis / System-level

engineering



4. Solving Difficult Problems (“Drilling Down”) Drilling down – solving the above difficult problems

Practical realization of PERV requires solving many difficult design & implementation problems

Let’s look at some of these problems at the next level of detail (“Our goal is only to convey an impressionistic picture of the road ahead.”)

No claim of completeness or exclusiveness Set of topics is merely a sampling of the problem space:

4.1. User Intent / 4.2. Cyber Foraging 4.3. Adaptation Strategy / 4.4. High-level Energy

Management 4.5. Client Thickness / 4.6. Context Awareness 4.7. Balancing Proactivity and Transparency 4.8. Privacy and Trust / 4.9. Impact on Layering


Pervasive Computing vs. Distributed Systems & Mobile Computing (25)Drilling Down - The Difficult Problems (2)

Drilling down - The difficult problems – cont. 1

Assumed: Each user immersed in a user’s personal computing space (UPCS) that accompanies him everywhere and mediates all interactions with the pervasive computing elements in her surroundings

UPCS likely implemented on a body-worn or handheld computer (or a collection of these acting as a single entity)

UPCS is a ‘‘client’’ of its PERV environment Even though many of its interactions may be peer-to-

peer rather than strictly client-server Client needs to be quite sophisticated hence complex

As indicated by the discussion below

Figure 2, illustrating the structure of an Aura client, gives a concrete example of this complexity



Figure 2: Structure of an Aura Client This figure shows the components of an Aura client and their logical relationships.

The text in italics indicates the role played by each component

Coda and Odyssey were created prior to Aura, but are being modified substantially to meet the demands of pervasive computing

In the case of Odyssey, these changes are sufficiently extensive that they will result in Chroma, a replacement

Other components are being created specifically for use in Aura

Such as Prism and SpectraAdditional components are likely to be added over time

Since Aura is relatively early in its design at the time of this writing (2001)

Server and infrastructure support for Aura are not shown



4.1) User Intent Proactivity requires that a PERV system tracks user intent

Otherwise, almost impossible to determine which system actions help rather than hinder the user.

E.g., suppose a user is viewing video over a network connection whose bandwidth suddenly drops

System choices: a) reduce the fidelity of the video, b) pause briefly to find another higher-bandwidth

connection, or c) terminate the task?

Correct choice depends on what the user is trying to accomplish

Today’s systems are poor at capturing and exploiting user intent

On the one hand: generic applications that have no idea what the user is attempting to do

Offer little support for adaptation and proactivity On the other hand: applications that try to anticipate user

intent but do so very badly Gimmicks like the Microsoft ‘‘paperclip’’ often more annoying

than helpful



User intent - some important research questions: Can user intent be inferred, or does it have to be

explicitly specified? In the latter case, is it statically specified (e.g., from a file)

or obtained on demand through dynamic interactions?

How is user intent represented internally? How is it used?

How rich must this information be for it to be useful? When and how is it updated? How do different layers of a system access this knowledge?

How does one characterize accuracy of user intent knowledge?

Is incomplete or imprecise knowledge of user intent still useful? At what level of uncertainty is it better to ignore such knowledge in making decisions?

Will the attempt to obtain intent to burdensome on the user?

Will it hurt usability and performance unacceptably? Is the benefit [of using user intent] worth the cost? How

does one quantify this benefit?



4.2) Cyber Foraging Two contradictory requirements for mobile devices:

Must be lightweight = small, light, with small and light battery Compromises computing capabilities

Must have powerful comp/comm capabilities Ever-growing expectations of mobile users

Well beyond capabilities of a lightweight mobile computer

How to reconcile contradictory requirements? Difficult to reconcile Idea: use cyber foraging

forage [fawr-ij] … 3. the act of searching for provisions of any kind.

[cf. Dictionary.com]

Cyber foraging:Dynamically augment the computing resources of a wireless mobile computer by exploiting wired hardware infrastructure [LTL: of the surrounding smart space]



4.2. Cyber Foraging – cont.1

Need infrastructure facilitating cyber foraging Need smart public spaces

Equipped with compute servers or data staging servers Much as table lamps [or power outlets] are today

Connected to the wired Internet through high-bandwidth networks

‘‘Wasting’’ smart infrastructure when not in use We can afford this ‘‘waste’’ to improve user experience Could ensure that never wasted - always in use

E.g., run SETI program / sell time slices to others

Surrogate of a mobile computer:Hardware in the wired infrastructure temporarily supporting cyber foraging for the mobile computer

[LTL:] Compare this limited cyber foraging with more extensive foraging (by employing helpers) in opportunistic networks (oppnets). After we discuss oppnets (soon), see how oppnets’ approach differs.



4.2. Cyber Foraging – cont.2

A typical foraging scenario Mobile computer (MC) enters a smart space MC detects surrogates and negotiates their use

Communication with a surrogate via short-range wireless P2P (peer-to-peer) technology

Surrogate is MC’s networking gateway to the Internet When MC needs to perform an intensive computation

accessing a large volume of data, MC uses the surrogate Surrogate performs computations for MCOR Surrogate services cache misses for MC

Lower latency, avoiding Internet delays

Surrogate caches data from the Internet on its local disk during performing the computation

OR Surrogate may have staged data ahead of time in

anticipation of the user’s arrival in the neighborhood MC leaves the space

Its surrogate bindings are broken Any data cached or staged for MC are discarded



Cyber foraging – some important research questions: How does one discover the presence of

surrogates? Of the many proposed service discovery mechanisms

such as JINI, UPnP, and BlueTooth proximity detection, which is best suited for this purpose? Can one build a discovery mechanism that subsumes all of them for greatest flexibility?

How to handle the issue of trust? How does one establish an appropriate level of trust in a

surrogate? What are useful levels of trust in practice? How applicable and useful is the concept of caching trust [29]? Can one amortize the cost of establishing trust across many surrogates in a neighborhood?

How is load balancing on surrogates done? Is surrogate allocation based on an admission control

approach, or a best-effort approach? How relevant is previous work on load balancing on networks of workstations?



Cyber foraging – some important research questions – cont.

How to handle the issue of staging? In typical situations, how much advance notice does a

surrogate need for effective staging with minimal delay? Is this on the order of seconds, minutes or tens of

minutes? What implications does this requirement have for the other components of a pervasive computing system?

What are the implications of cyber foraging for scalability of smart fixed infrastructure?

How dense does the fixed infrastructure have to be to avoid overloads during periods of peak demand?

What is the system support needed for seamless and minimally intrusive surrogate experience for a user?

Which are the components of this support that must be provided by MC, and which by the smart space?



4.3) Adaptation Strategy Adaptation is necessary when there is a significant

mismatch between the supply and demand of a resource

Examples of resources: wireless network bandwidth, energy, computing cycles, memory, …

Three alternative adaptation strategies for adaptation in PERV

Recall: UPCS is a client of a smart space (3 interacting entities) UPCS = user’s personal computing space

Strategy 1 (reservation): Client can ask the environment for guarantee of a certain level of a resource

Typically used by reservation-based QoS systems [22] QoS – quality of service This effectively increases the supply of a scarce resource to

meet the client’s demand [LTL: Client able to reserve is privileged in some sense]

Strategy 2 (reduction): 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

E.g., Odyssey [11, 24] uses this strategy



4.3. Adaptation Strategy –cont. Three alternative strategies for adaptation in PERV – cont.

Strategy 3 (correction): Client can suggest a corrective action to its user

If the user complies with it, resource supply will likely (but without certainty) become adequate to meet demand

E.g.., in Scenario 1, Aura advised Jane to walk to Gate 15 in order to obtain adequate wireless bandwidth.

Conceptually promising, but not implemented by any real system yet (2001)

All three strategies are important in pervasive computing Some smart spaces capable of accepting resource

reservations (Strategy 1 - reservation) In some smart spaces [some] clients can’t reserve

resources — must ask applications to reduce their fidelities (Strategy 2 - reduction)

Happens when space is uncooperative or resource-impoverished

Corrective actions may be particularly useful when reduction of fidelity is unacceptable (Strategy 3 - correction)

Broaden the range of possibilities for adaptation by involving the user



Adaptation Strategy – some research questions How does a client choose the best adaptation

strategy? What factors should a good decision procedure take into

account? How should different factors be weighted? What role, if any, should the user play in making this decision? How can smooth and seamless transitions between strategies be ensured as a user moves between different spaces?

Reservation strategy might appear superior for a user User neither required to accept lower fidelity nor perform a

corrective actionIs this true in all circumstances?

What are the hidden costs and ‘‘gotchas,’’ if any, in a widely-deployed system using Strategy 2?

How will the implementation of a smart space honor resource reservations?

What are the most appropriate admission control policies when there are competing requests from multiple clients? What resources, beside wireless network bandwidth, is it meaningful and useful for a smart space to reserve? What are the APIs and protocols necessary to negotiate these reservations?



Adaptation Strategy – some research questions – cont.

Issues for corrective strategy Is corrective adaptation practically feasible? Do users find it

intrusive or annoying? What is the best way to communicate potential corrective actions to users? What are the programming models and APIs necessary to support corrective actions?

Legacy problem: Can existing applications use this approach? If so, how substantial are the modifications to them?

Issues for reduction strategy What are the different ways in which fidelity can be lowered

for a broad range of applications? Are existing APIs, such as that of Odyssey [24], adequate?

How should those APIs and programming models be revised based on extensive usage experience?

What is the negative impact of lowered fidelity on users and how can this be minimized?



4.4) High-level Energy Management Sophisticated software capabilities increase the

energy demand of an MC (= mobile computer) Examples of sophisticated capabilities: as proactivity / self-

tuning

At the same time: pressure to make MCs lighter and more compact places severe restrictions on battery capacity

Growing consensus: Advances in battery technology and low-power circuit design

cannot, by themselves, reconcile these opposing constraints The higher levels of the system must also be involved [10,

25]

How does one involve the higher levels of a system in energy management?

Example 1: Energy-aware memory management [18] OS dynamically controls the amount of physical memory

that has to be refreshed Example 2: Energy-aware adaptation [11]

Under OS control, individual applications switch to modes of operation with lower fidelity and energy demand



High-level Energy Management – some research questions

In what ways can the higher levels of a system contribute to managing energy?

What are the relative strengths and weaknesses of these approaches? When should one method be used in preference to another?

How does high-level energy management impact the goal of invisibility in pervasive computing?

How intrusive or distracting to users are such techniques? Can knowledge of user intent be exploited in energy

management? If so, how robust is this approach in the face of imperfection in this

knowledge? Can smart spaces and surrogates be used to reduce energy

demand on a mobile computer? What are possible approaches, and what are their relative merits?

What is the role of remote execution in extending battery life? Under what circumstances does its energy savings exceed the

energy cost of wireless communication? Can a system predict these savings and costs accurately enough in practice to make a significant difference?



4.5) Client Thickness Types of clients

Thick client = a powerful client Thin client = a minimal client

Thick clients have many negative features from the user’s viewpoint

Larger / heavier / with bigger & heavier battery / dissipate more heat

Over time, physical size and weight of a thick client are reduced

Due to improvements in VLSI and packaging technology

The same improvements shrinking thick clients produce even smaller and lighter thin clients

Q: How powerful MC is needed for a pervasive computing environment?

How much CPU power, memory, disk capacity, … does it need?

The answer determines many of the key constraints imposed on the hardware design of the client

A: For a user, a client can never be too powerful, too small, too light or have too long battery life!



4.5. Client Thickness – cont.1 A wide range of client designs

One extreme: Ultra-thin clients Bare-bones devices

E.g., Infopad [6, 40], SLIM [33] Can’t operate in isolation

Little more than high-resolution displays connected through high-bandwidth wireless links to nearby compute servers

In-between: Midsize clients Handheld computers

E.g., PalmPilot Can operate in isolation But run a limited range of applications

Other apps run on compute servers of smart spaces

The other extreme: Full-function clients Wearable computers and laptops

E.g., the Navigator family of wearable computers [34], laptops running as clients of the Coda File System [17]

Capable of standalone or disconnected operation Make use of wireless connectivity when available

Not critically dependent on it



4.5. Client Thickness – cont.2

The minimum acceptable thickness of a client for a given app:Determined by the worst-case conditions under which the app must run satisfactorily

A very thin client suffices if it has assured high-bandwidth, low-latency wireless communication to nearby computing infrastructure, and if batteries recharged/replaced easily

If in even a single location visited by a user these assumptions do not hold, the client must be thick enough to compensate at that location

This is especially true for interactive applications where crisp response is important

… continued...



4.5. Client Thickness – cont.3 With a client of modest thickness, it may be possible to

preserve responsiveness by: Handling simple cases locally & relying on remote

infrastructure only for more compute-intensive situationsOR: Execute part of the application locally & ship a much-

reduced intermediate state over a weak wireless link to a remote compute server for completion

The hybrid mode of speech recognition in Odyssey [24] is an example of this approach.

OR: Client recognizes that a key assumption is not being met,

and alerts its user with a message Client could also suggest possible corrective actions

E.g., moving to a nearby location known “help” the application

An extremely thin-client will be unsatisfactory for pervasive computing in the foreseeable future

Due to uneven conditioning of environmentsAt the same time, considerable merit in not having to carry or wear a client thicker than absolutely necessary



4.5. Client Thickness – some research questions: Can the concepts of client thickness and

environmental conditioning be quantified? Are there ‘‘sweet spots’’ in the design space where a modest increase in client thickness yields considerable improvement in performance and usability?

Can a proactive system alert a user in a timely manner before he leaves a benign environment for a less hospitable one?

In that context, can an application be transparently migrated between a thinner and a thicker client whenever needed

What are the kinds of applications for which such migration is feasible and useful? What is the impact on usability?



4.5. Client Thickness – some research questions – cont. Is it possible to build cost-effective modular

computers that can be physically reconfigured to serve as the optimal mobile clients under diverse environmental conditions?

Can a proactive system advise a user to reconfigure when appropriate?

E.g., knowing her travel plans, can such a system guide her in configuring her system so that it is of adequate thickness at all times?

Can semi-portable infrastructure be carried with a user to augment less hospitable environments?

E.g., in a poorly conditioned environment, can a thin body-worn computer extend its capabilities by wireless access to a full-function laptop brought by the user?

This is analogous to carrying both a briefcase and a wallet when you travel; the briefcase is not physically on your person at all times, but it is close enough to provide easy access to things too large to fit in your wallet

Is this a usable and practical strategy to cope with uneven conditioning?



4.6) Context Awareness Context-awareness is necessary for PERV to be minimally

intrusive Context aware = cognizant of its user’s state and surroundings, and

modifying its behavior based on this information A user’s context

Can be quite rich Some user’s attributes in user’s context:

Physical location / Physiological state (e.g., body temperature and heart rate) /Emotional state (e.g., angry, distraught, or calm) / Personal history /Daily behavioral patterns / …

A human assistant given such context would make decisions proactively

Anticipating user needs The assistant would typically not disturb the user at inopportune

moments except in an emergency Can a pervasive computing system emulate such a human assistant?

Key challenge: obtaining information needed to function in a context-aware manner

Desired information may be part of UPCS (user’s personal computing space)

E.g., UPCS has schedules, calendars, address books, to-do lists, … More dynamic information has to be sensed in real time from the

user’s environment E.g., position, orientation, the identities of people nearby, locally

observable objects and actions, emotional and physiological state, …



4.6. Context Awareness – cont.

Context Awareness – some research issues: How is context represented internally? How is this

information combined with system and application state? Where is context stored?

Does it reside locally, in the network, or both?

What are the relevant data structures and algorithms? How frequently does context information have to be

consulted? What is the overhead of using context? How to keep this overhead low?

What are the minimal services from an environment to provide to make context-awareness feasible? What are reasonable fallback positions if an environment does not provide such services? Is historical context useful?

What are the relative merits of different location-sensing technologies?

Under what circumstances should one be used in preference to another?

Should location information be treated just like any other context information, or should it be handled differently?

Is historical context useful?



4.7) [LTL:] Proper Level of Transparency in Proactivity [Paper: Balancing Proactivity and Transparency]

Transparency = invisibility

[LTL:] Proactivity can be visible or transparent (invisible )

Visible when system asks user for specific behavior to perform a proactive task

E.g., Aura asking Jane to go to Gate 15 or warning Fred not to show slides with sensitive data (in Scenario 1)

Transparent when there is no system interaction with user when system performs a proactive task

E.g., Aura warms up projector without asking Fred (in Scenario 2)



4.7) [LTL:] Proactivity and Its Transparency [Paper: Balancing Proactivity and Transparency] – cont.1

[LTL:] Visible system proactivity can annoy a user … … if system gives a bad advice

Or the user just thinks that the advice is bad … if system interrupts a user too often with advice

Annoyed even with the best advice And prone to ignore it

[LTL:] Transparent system proactivity can annoy a user too

E.g., if Aura warms up a projector in a wrong room, and Fred has to wait for warm up in the right room

If Aura told Fred in which room it watms up the projectoir (visible), Fred would notice mistake &correct Aura’s action



4.7) [LTL:] Proactivity and Its Transparency [Paper: Balancing Proactivity and Transparency] – cont.2

[LTL:] Hypothesis: Talking about “balancing proactivity and transparency” (see the paper) seems author’s mistake

Balancing of X an Y is needed only when: More X can be obtained by reducing Y AND More Y can be

obtained by reducing X Here can have 100% proactivity with either 0% or 100%

transparency [LTL:] Finding (“balancing”) proper level of

transparency for proactivity If too little or too much of proactivity transparency annoys

a user => The goal of proactivity transparency is defeated

Need careful PERV design Finding the proper transparency level by:

System’s self-tuning A mobile user’s need & tolerance for proactivity (UNTP)

are likely to be closely related to his level of expertise on a task & his familiarity with his environment

A system that can infer UNTP by observing user behavior & context is better positioned to find the proper balance



4.7) [LTL:] Proactivity and Its Transparency [Paper: Balancing Proactivity and Transparency] – cont3

Historically, transparency (not just for proactivity) was the ideal in system design

E.g., caching is attractive in distributed file systems because it is completely transparent

Ironically, sometimes users are hurt/annoyed by complete transparency

E.g., servicing a cache miss on a large file over a low-bandwidth wireless network — so slow that most users would rather be asked first by the system if they really need the file

However, too many questions from file system can annoy the userThat is, again annoyed by too low level of transparency

A solution to this dilemma (suggested by Coda File System [21])

On a cache miss, Coda consults an internally-maintained user patience model to predict whether the user will not be annoyed by a transparent fetch request

If so, the fetch is handled transparently (user interaction is suppressed)

Many subtle problems arise in designing a system that walks the fine line between annoying visibility & inscrutable (hard to understand) transparency



4.7. Balancing Transparency in Proactivity – some research problems:

How are individual user preferences and tolerances specified and taken into account?

Are these static or do they change dynamically?

What cues can such a system use to determine if [LTL:] transparency level is too low/high?

Is explicit interaction with the user to obtain this information acceptable?

Or, would such explicit interaction to obtain be an annoyance too?

Can one provide systematic design guidelines to application designers to help in this task?

Can one retrofit [transparency] balancing mechanisms into existing applications?



4.8) Privacy and Trust Privacy is greatly complicated by PERV

Was already a thorny problem in DISTR and MOBI

Some PERV mechanisms “spy” on user actions on an almost continuous basis

E.g., location tracking, smart spaces, use of surrogates As a user becomes more dependent on PERV =>

PERV obtains more information about the user I.e., about user’s movements, behavior patterns, habit, …

Exploiting this information is critical to successful proactivity & self-tuning

Unless use of information is strictly controlled, it can hurt the user

Illegitimate uses ranging from targeted spam to blackmail.

Potential for serious loss of privacy may deter knowledgeable users from using a PERV system



4.8) Privacy and Trust - cont.

Mutual trust between infrastructure & users in PERV

Greater reliance on infrastructure => users must trust infrastructure to a considerable extent

Conversely, the infrastructure needs to be confident of the users’ identity and authorization levels before responding to their requests

It is a difficult challenge to establish this mutual trust with minimal intrusiveness (= mimnimal visibility & thus maximum transparency)

System identifies/authorizes users in intrusive (visible) way



4.8. Privacy and Trust - cont

Privacy and trust are likely to be enduring problems in pervasive computing

Privacy and trust – some research questions: How does one strike the right balance between seamless

system behavior and the need to alert users to potential loss of privacy?

What are the mechanisms, techniques and design principles relevant to this problem? How often should the system remind a user that his actions are being recorded? When and how can a user turn off monitoring in a smart space?

What are the authentication techniques best suited to PERV? Are password-based challenge-response protocols such as

Kerberos [36] adequate or are more exotic techniques such as biometric authentication [15] necessary?

What role, if any, can smart cards [14] play? How does one express generic identities in access control?

E.g., how does one express security constraints such as ‘‘Only the person currently using the projector in this room can set its lighting level?’’ Or: ‘‘Only employees of our partner companies can negotiate QoS properties in this smart space?’’



4.9) Impact on Layering [of the System] A recurring theme in this paper: the merging of

information from diverse layers of a PERV system to produce an effective response

E.g., Scenario 1 shows the value of combining low-level resource information (network bandwidth) with high-level context information (airport gate information)

Proactivity and adaptation based on corrective actions => exposure of much more information across layers

Much more than is typical in systems today We want layering – it has benefits

Cleanly separates abstraction from implementation Thus consistent with sound software engineering

Conducive to standardization Encourages the creation of modular software components



4.9) Impact on Layering [of the System] – cont.

Deciding how to decompose a complex system into layers or modules is nontrivial

Remains very much an art rather than a science

The two most widely-used guidelines for layering Parnas’ principle of information hiding [26] Saltzer et al.’s end-to-end principle[28]

Both developed long before pervasive computing was conceived

Parnas’ - early 1970’s Saltzer et al.’s - early 1980’s



Impact on System Layering – some research questions: How can the benefits of layering be preserved while

accommodating the needs of pervasive computing? What is the impact of these accommodations on efficiency

and maintainability?

Are existing layers best extended for pervasive computing by broadening their primary interfaces or by creating secondary interfaces?

Such as the SNMP network management interface [7]?

When creating a new layer, are there systematic guidelines we can offer to ensure compatibility with the needs of pervasive computing?

How much harder is it to design and implement such a layer?



5. Conclusion Pervasive computing will be a fertile source of

challenging research problems in computer systems for many years to come Solving these problems will require us:

To broaden our discourse on some topics, and To revisit long-standing design assumptions in

others To address research challenges in areas outside

computer systems, including: Human-computer interaction

Esp. multi-modal interactions & human-centric h/w designs

Software agents Specific relevance to high-level proactive behavior

Expert systems and artificial intelligence Esp. in the areas of decision making and planning

Capabilities from these areas will need to be integrated with the PERV systems capabilities

Pervasive computing will thus be the crucible in which many disjoint areas of research are fused


Pervasive Computing vs. Distributed Systems & Mobile Computing (60)Conclusion – cont.

When describing his vision, Weiser was fully aware that attaining it would require tremendous creativity and effort by many people, sustained over many years

The early decades of the 21st century will be a period of excitement and ferment in PERV research

New h/w technologies converge with research progress on the many fundamental problems discussed in this paper

Like the Frontier of the American West in the early 19th century, pervasive computing offers new beginnings for the adventurous and the restless

A rich open space where the rules have yet to be written and the borders yet to be drawn



References

See the original paper: M. Satyanarayanan, “Pervasive Computing: Vision

and Challenges,” IEEE Personal Communications, 2001

Available at: http://www.cs.cmu.edu/~aura/docdir/pcs01.pdf

End of Lecture 0:Introduction to Pervasive

Computing

cs 6910 – pervasive computing section 0.a: introduction to pervasive computing dr. leszek lilien...

Documents