1 / 30

Project Oxygen http://oxygen.lcs.mit.edu/ MIT

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

stevie
Download Presentation

Project Oxygen http://oxygen.lcs.mit.edu/ MIT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project Oxygenhttp://oxygen.lcs.mit.edu/MIT Hari Balakrishnan http://nms.lcs.mit.edu/

  2. 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

  3. The Oxygen Environment “Situated” computing Camera array Speech & vision Projector 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!

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

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

  6. 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. 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. 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. 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. 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. 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. Oxygen in action:Context-aware networking • “Spontaneous” networking • Context-aware speech-driven active maps (location-specific) • Resource discovery and secure information access • Vertical mobility

  13. 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

  14. 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 Edison’s radio

  15. 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

  16. Traditional approach Location DB ID = u? Networked sensor grid ID = u Responder Problems: privacy; administration; granularity; cost

  17. space = “a2” space = “a1” Cricket Beacon Pick nearest to infer space Listener No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability

  18. Problems • Location granularity • Interference • Lack of explicit beacon coordination • Energy consumption • Listener inference algorithms

  19. RF data (spacename) US pulse 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 • 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

  20. 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

  21. 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

  22. 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

  23. Intentional Naming System (INS) Names are intentional; apps know what, not where Expressiveness Late bindingof name to location to handle failover, mobility Responsiveness Decentralized, cooperating resolvers Robustness Name resolvers self-configure into overlay network Easy configuration Aggressive partitioning of namespace and delegation Scalability

  24. [service = lcs.mit.edu/thermo] [building = NE43 [floor = 5 [room = *]]] [temperature > 250C] data 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]

  25. Intentional name • [service = camera] • [building = NE43 • [room = 510]] INS architecture camera510.lcs.mit.edu Intentional name resolvers form an overlay network Lookup image Resolver self-configuration Late binding: integrate resolution and message routing

  26. 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

  27. DNS Migrate using Diffie-Hellman 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)

  28. 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

  29. 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

  30. 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?

More Related