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

Phone

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

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

Software adaptation
C2. Expose resource availability and constraints to software & applications Energy: compiler techniques; application-specific, lowenergy 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 applicationpartitioning

Context-awareness
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

User-empowerment
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

Engineering methods
C7. Develop design techniques to engineer, model, and debug pervasive systems Systematically model correctness, robustness, performance Compiler techniques to help software development in distributed, embedded systems Communication modes between loosely-coupled component systems
Diversity of languages, object models, philosophy

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

Ad hoc topology formation

Static configuration impossible DHCP-like configuration undesirable
Pre-configured subnets and broadcasts are problematic over wireless

Solution: Distributed, randomized addressing

[ar:mr] addr = ar mask = mr addr = br mask = mr Coalesce? Route?

addr = cr mask = n

Location-awareness
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

Cricket

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

Listener

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

Problems
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 (spacename) US 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

Listener

More opportunities
Interference
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

Technology
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 = *]]] [temperature > 250C] data

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

Lookup
image

Resolver self-configuration

Intentional name resolvers form an overlay network

Late binding: integrate resolution and message routing

How does it work?

Name resolver network

Query Client

Periodic advertisement Service name

Overlay network of resolvers

[service = camera] [building = 10 [room = 510]]

Routing protocol tracks changes

Triggered update

Client
[service = camera] [building = ne-43 [room = 510]]

Overlay network of resolvers

[service = camera] [building = ne-43 [room = 510]]

Service mobility

Late binding handles mobility

[service = camera] [building = ne-43 [room = 504]]

Forward to best location

[service = camera] [building = ne-43 [room = *]] flag = ANY

data

Intentional anycast

[service = camera] [building = ne-43 [room = 510]]

Intentional multicast for group communication

[service = camera] [building = ne-43 [room = 504]]

Forward along spanning tree

[service = camera] [building = ne-43 [room = *]] flag = ALL

data

[service = camera] [building = ne-43 [room = 510]]

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

How to pick best network at any time, per-application? 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

vmobiled (picks best network for connections)

Migrate using Diffie-Hellman

DNS

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

Links
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?