Project Oxygenhttp://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

“Situated”computing Projector

Phone

Camera array

Microphone array

Speech & vision

- 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!

- 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!

The Oxygen Environment

What Oxygen is… and isn’t

• 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 don’t 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, 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

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

Oxygen in action:Context-aware networking

• Resource discovery and secure information access

• Vertical mobility

• “Spontaneous” networking

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

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

Edison’s radioEdison’s radio

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]); ...

Spectrumware radioSpectrumware radio

Software physical layers

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

Networked sensor grid

Location DB

ID = u

ID = u?

Responder

Problems: privacy; administration; granularity; costProblems: privacy; administration; granularity; cost

Cricket

Beacon

Listener

No central beacon control or location databasePassive listeners + active beacons preserves privacyStraightforward deployment and programmability

No central beacon control or location databasePassive listeners + active beacons preserves privacyStraightforward deployment and programmability

space = “a1”

space = “a2”

Pick nearest to infer space

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

Listener

• 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

RF data(spacename)

US pulse

More opportunities

• Interference– Lack of coordination hampers RF-US correlation– US has tremendous multipath effects

• Multiple millisecond reflections

• Randomized transmission scheduleloop:

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 beacon’s US– Reflections (multipath) are problematic

• Maximum-likelihood estimator at listener that picks minimum distance of all modes

• LOW bandwidth RF is good!

tRF

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 today’s naming system name by (network) locations

– Names should refer to what, not where

Responsiveness Late binding of name to location to handle failover, mobility

Robustness

Easy configuration Name resolvers self-configure into overlay network

Expressiveness

Decentralized, cooperating resolvers

Intentional Naming System (INS)

Names are intentional; apps know what, not where

Scalability Aggressive partitioning of namespace and delegation

Intentional names

[service = lcs.mit.edu/thermo][building = NE43 [floor = 5 [room = *]]][temperature > 250C]

[service = lcs.mit.edu/thermo][building = NE43 [floor = 5 [room = *]]][temperature > 250C]datadata

[service = mit.edu/camera][building = NE43

[room = 510]][resolution=800x600][access = public][status = ready]

[service = mit.edu/camera][building = NE43

[room = 510]][resolution=800x600][access = public][status = ready]

• Expressive name language (like XML)• Providers announce attributes• Clients make queries

– Attribute-value matches– Wildcard matches– Ranges

INS architecture

[service = camera][building = NE43

[room = 510]]

[service = camera][building = NE43

[room = 510]]

Intentional name

Intentional name resolvers

form an overlay network

Late binding: integrate resolution and message routingLate binding: integrate resolution and message routing

image

Lookup

camera510.lcs.mit.edu

Resolver self-configuration

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 don’t 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

DNS

Migrate using Diffie-Hellmanvmobiled

(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

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?