Transcript Project Oxygen - Massachusetts Institute of Technology

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
Phone
“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 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; 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
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
• “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]);
...
Edison’s radio
Spectrumware radio
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
ID = u
Responder
Problems: privacy; administration; granularity; cost
Cricket
space = “a2”
Beacon
space = “a1”
Listener
Pick nearest to
infer space
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
US
(spacename) pulse
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
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 beacon’s 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 today’s naming system name by
(network) locations
– Names should refer to what, not where
Intentional Naming System (INS)
Expressiveness
Names are intentional; apps know
what, not where
Responsiveness
Late binding of name to location
to handle failover, mobility
Robustness
Decentralized, cooperating
resolvers
Easy configuration
Name resolvers self-configure into
overlay network
Scalability
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]]
Lookup
image
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 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
Migrate using Diffie-Hellman
vmobiled
(picks best network
for connections)
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?