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 • 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. , Handy 21) - Situated computing resources & sensors (e. g, Enviro 21) - 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 C 1. 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 C 2. 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 C 3. 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 C 4. 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 C 5. Address user privacy and security from the beginning • Context-awareness raises many privacy concerns – Location-tracking is problematic; a private locationsupport system is better • Security concerns abound – File system access – Resource discovery system – Anonymous, personalizable devices

User-empowerment C 6. 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 = (Block. Size/4096) +1; if ((guppi_open("guppi 0", pages)) < 0 ) exit(0); guppi_start_rec(); for ( i=0 ; i< Num. Blocks ; i++) { pdata = (char *)guppi_rec_buf(); for ( j=0 ; j< Ints. Per. Block ; j++) { Real. Tap_ptr=Real. Tap; Imag. Tap_ptr=Imag. Tap; Output. Data. Real = 0. 0; Output. Data. Imag = 0. 0; a=cos(Two. Pi * Center. Freq / (float)Sample. Freq. In * index); b=sin(Two. Pi * Center. Freq / (float)Sample. Freq. In * index); index += Dec. Factor; for ( k=0; k< Filter. Length ; k++, pdata++) { Output. Data. Real += ((float)*pdata * Real. Tap[k]); Output. Data. Imag += ((float)*pdata * Imag. Tap[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 = “a 2” Beacon space = “a 1” 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[R 1, R 2]; delay(r); xmit(RF, US); // takes time = S/b for data to reach • Can determine optimal R 1 and R 2 analytically

Technology • Beacon: 418 MHz AM RF and 40 KHz 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 = NE 43 [room = 510]] [resolution=800 x 600] [access = public] [status = ready] [service = lcs. mit. edu/thermo] [building = NE 43 [floor = 5 [room = *]]] [temperature > 250 C] data

INS architecture camera 510. lcs. mit. edu Intentional name [service = camera] [building = NE 43 [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 vmobiled (picks best network for connections) Migrate using Diffie-Hellman 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? • C 1. Eliminate human involvement in configuration • C 2. Expose resources to software • C 3. Design for mobility and nomadicity • C 4. Expose and exploit environmental context • C 5. Pay close attention to privacy and security • C 6. 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?