Project Oxygen oxygen.lcs.mit/ MIT

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?