Vous êtes sur la page 1sur 30

Project Oxygen http://oxygen.lcs.mit.

edu/ MIT
Hari Balakrishnan http://nms.lcs.mit.edu/

Vision & Goals

Pervasive, human-centered computing Improve human productivity and comfort
Move computation into the mainstream of our lives Improve ease-of-use and accessibility

Develop a deep understanding of how to develop, deploy, and manage systems of systems in dynamic settings Build to use; use to build

The Oxygen Environment

Speech & vision
Camera array Projector

Situated computing


Microphone array

- Natural, peceptual interfaces (speech, vision) - Handheld, mobile computers (e.g., Handy21) - Situated computing resources & sensors (e.g, Enviro21) - Numerous other networked devices ... - And tons of software making all this work together!

What Oxygen is and isnt

A system of systems
Several diverse component systems designed by different minds

A computing environment A philosophy for developing and deploying future computing environments It is not:
Designed by committee A panacea for all computing ills!

This talk
Cross-cutting systems design and implementation issues for Oxygen Design considerations and goals
Six considerations to keep in mind Annotated using specific examples

Context-aware networking walkthrough

Distributed systems and networking slant

We dont have all the answers (yet!)

Configuration and management

C1. Take the human out of the configuration and maintenance loop Cause of much frustration today
Setting up a network, device support, software versions Deploying distributed network services

Self-configuring networks Self-updating software Run-time introspection

Software adaptation
C2. Expose resource availability and constraints to software & applications Energy: compiler techniques; applicationspecific, low-energy routing Network bandwidth, latency: monitor network conditions and export via API Gates (computation)
Configure gates using smart compilers (RAW) Application-partitioning in situated computing

Mobility and nomadicity

C3. Design software for mobility and nomadicity Services will join, move, fail, recover, disappear: dynamic resource discovery Data will move: access to files from anywhere Users will move across multiple networks: vertical mobility based on performance Software will move: updates/upgrades Running programs will move: on-the-fly application-partitioning

C4. Develop infrastructure to expose environmental context to applications Understand user and application intent Location-awareness Information management for individuals and communities: context-sensitive query handling Speech interfaces across domains Semantic web of information in documents and service descriptions (synonyms)

Security and privacy

C5. Address user privacy and security from the beginning Context-awareness raises many privacy concerns
Location-tracking is problematic; a private location-support system is better

Security concerns abound

File system access Resource discovery system Anonymous, personalizable devices

C6. Empower users to program Oxygen Allow users to compose functionality and express requirements Gentle-slope language
Scale from novices to over-eager high-school kids and undergraduates Robustness via introspective operation

Oxygen in action: Context-aware networking

Spontaneous networking

Context-aware speech-driven active maps (location-specific)

Resource discovery and secure information access Vertical mobility

Self-configuring networks
Software physical layer allows flexible (de)modulation, parameter adaptation Self-updating software to overcome compatibility problems Topology creation using decentralized protocols in ad hoc networks Network monitoring across multiple networks for better routing decisions

Software physical layers

pages = (BlockSize/4096) +1; if ((guppi_open("guppi0",pages)) < 0 ) exit(0); guppi_start_rec(); for ( i=0 ; i< NumBlocks ; i++) { pdata = (char *)guppi_rec_buf(); for ( j=0 ; j< IntsPerBlock ; j++) { RealTap_ptr=RealTap; ImagTap_ptr=ImagTap; OutputDataReal = 0.0; OutputDataImag = 0.0; a=cos(TwoPi * CenterFreq / (float)SampleFreqIn * index); b=sin(TwoPi * CenterFreq / (float)SampleFreqIn * index); index += DecFactor; for ( k=0; k< FilterLength ; k++, pdata++) { OutputDataReal += ((float)*pdata * RealTap[k]); OutputDataImag += ((float)*pdata * ImagTap[k]); ...

Edisons radio

Spectrumware radio

Goal: System that provides information about physical location; must work indoors too Several goals must be met
User privacy Decentralized administration Cost-effectiveness Portion-of-a-room granularity Network heterogeneity

GPS-oriented solutions do not provide required accuracy, reliability, or cost-effectiveness

Traditional approach

Location DB ID = u? Networked sensor grid Responder

ID = u

Problems: privacy; administration; granularity; cost


space = a2 Beacon space = a1 Pick nearest to infer space


No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability

Location granularity Interference
Lack of explicit beacon coordination

Energy consumption Listener inference algorithms

Every problem is an opportunity

Pure RF is problematic
Too imprecise (large granularity) In-building propagation is hard to model

Solution: use RF + ultrasound (US)

Beacon RF data US (spacename) pulse
Speed of light >> speed of sound! (c = 1 foot/ns vs v = 1 foot/ns) When first RF bit arrives, note time When US pulse detected, check time difference (dt) Distance estimate = v * dt


More opportunities
Lack of coordination hampers RF-US correlation US has tremendous multipath effects
Multiple millisecond reflections

Randomized transmission schedule

loop: pick r ~ U[R1,R2]; delay(r); xmit(RF,US); // takes time = S/b for data to reach

Can determine optimal R1 and R2 analytically

Beacon: 418 MHz AM RF and 40KHz US Listener correlates RF and US samples
Interference from another beacons US Reflections (multipath) are problematic

Maximum-likelihood estimator at listener that picks minimum distance of all modes LOW bandwidth RF is good!
RF t
US received US from elsewhere

Resource discovery
Services advertise/register resources Consumers make queries for services System matches services and consumers This is really a naming problem
Name services and treat queries are resolution requests Problem: most of todays naming system name by (network) locations Names should refer to what, not where

Intentional Naming System (INS)

Expressiveness Responsiveness Robustness Easy configuration Scalability Names are intentional; apps know what, not where Late binding of name to location to handle failover, mobility

Decentralized, cooperating resolvers

Name resolvers self-configure into overlay network Aggressive partitioning of namespace and delegation

Intentional names
Expressive name language (like XML) Providers announce attributes Clients make queries
Attribute-value matches Wildcard matches Ranges
[service = mit.edu/camera] [building = NE43 [room = 510]] [resolution=800x600] [access = public] [status = ready]
[service = lcs.mit.edu/thermo] [building = NE43 [floor = 5 [room = *]]] 0 [temperature > 25 C] data

INS architecture
camera510.lcs.mit.edu Intentional name
[service = camera] [building = NE43 [room = 510]]


Resolver self-configuration

Intentional name resolvers form an overlay network

Late binding: integrate resolution and message routing

Vertical mobility
Devices with multiple network choices
Software physical layers enhance this capability

How to pick best network at any time, perapplication? Mobile-IP-like approaches dont work well
Per-application choices impossible Inefficient routing Deployment is hard Not all mobile applications are equal

Mobility is an end-to-end issue!

Use secure updates to DNS to track host IP End-nodes negotiate connection migration in a secure way

Migrate using Diffie-Hellman vmobiled (picks best network for connections)


Oxygen is a system of systems

Pervasive, human-centered, dynamic environment Perceptual, intentional interfaces using speech, vision, and writing Programmable and composable architecture General approaches to handling a variety of contexts (e.g., location, information, speech) Networking software and services Novel hardware (and associated software)
RAW-based configurable, energy-efficient handhelds Situated computing architectures

Summary: How might we cope?

C1. Eliminate human involvement in configuration C2. Expose resources to software C3. Design for mobility and nomadicity C4. Expose and exploit environmental context C5. Pay close attention to privacy and security C6. Enable user programmability

http://oxygen.lcs.mit.edu/ for Oxygen vision, technologies, and research agenda http://nms.lcs.mit.edu/ for details on Spectrumware, Cricket, INS, and Migrate Questions?