Oxygen Fdis

8/3/2019 Oxygen Fdis

1/36

Project Oxygenhttp://oxygen.lcs.mit.edu/

MIT

Hari Balakrishnanhttp://nms.lcs.mit.edu/


2/36

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 dynamicsettings

Build to use; use to build


3/36

Situated

computingProjector

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!

The Oxygen Environment


4/36

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!


5/36

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


6/36

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


7/36

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


8/36

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


9/36

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)


10/36

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


11/36

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


12/36

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


13/36

Oxygen in action:

Context-aware networking

Resource discovery and secure

information access

Vertical mobility

Spontaneous networking

Context-aware speech-driven active

maps (location-specific)


14/36

Self-configuring networks

Software physical layer allows flexible (de)modulation,

parameter adaptation

Self-updating software to overcome compatibilityproblems

Topology creation using decentralized protocols in ad

hoc networks

Network monitoring across multiple networks for better

routing decisions


15/36

Edisons 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 radio

Software physical layers


16/36

addr = armask = mr

addr = brmask = mr

[ar:mr]

addr = cr

mask = n

Coalesce?

Route?

Ad hoc topology formation

Static configuration impossible

DHCP-like configuration undesirable

Pre-configured subnets and broadcasts are problematic overwireless

Solution: Distributed, randomized addressing


17/36

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


18/36

Traditional approach

Networked

sensor grid

Location DB

ID = u

ID = u?

Responder

Problems: privacy; administration; granularity; cost


19/36

Cricket

Beacon

Listener

No central beacon control or location database

Passive listeners + active beacons preserves privacy

Straightforward deployment and programmability

space = a1

space = a2

Pick nearest toinfer space


20/36

Problems

Location granularity

Interference

Lack of explicit beacon coordination

Energy consumption

Listener inference algorithms


21/36

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

RFdata

(spacename)

US

pulse


22/36


23/36

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!

t

RF

US received US from elsewhere


24/36

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


25/36

ResponsivenessLate binding of name to location to

handle failover, mobility

Robustness

Easy configurationName 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


26/36

Intentional names

[service = lcs.mit.edu/thermo][building = NE43

[floor = 5[room = *]]]

[temperature > 250C]

data

[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


27/36

INS architecture

[service = camera][building = NE43

[room = 510]]

Intentional name

Intentional name resolvers

form an overlay network

Late binding: integrate resolution and message routing

image

Lookup

camera510.lcs.mit.edu

Resolverself-configuration


28/36

How does it work?

Name resolver networkName resolver network

Overlay network ofresolvers

ClientClient

ServiceService

namename

[service = camera][building = 10

[room = 510]]

QueryPeriodic

advertisement


29/36

Routing protocol tracks changes

Overlay network ofresolvers

ClientClient

[service = camera][building = ne-43

[room = 510]]

Triggeredupdate

Service mobility


[room = 510]]


30/36

Late binding handles mobility


[room = *]]

flag = ANY

data[service = camera][building = ne-43

[room = 510]]


[room = 504]]

Forward tobest location

Intentional anycast


31/36

Intentional multicast for group communication


[room = *]]

flag = ALL

data[service = camera][building = ne-43

[room = 510]]


[room = 504]]

Forward alongspanning tree


32/36

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


33/36

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 networkfor connections)


34/36

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


35/36

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


36/36

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?

Documents

Oxygen Fdis