Project Oxygen MIT Hari Balakrishnan
-
Upload
silas-linder -
Category
Documents
-
view
217 -
download
0
Transcript of Project Oxygen MIT Hari Balakrishnan
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?