Project Oxygen MIT Hari Balakrishnan

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

Engineering methods C7. Develop design techniques to engineer, model, and debug pervasive systems Systematically model correctness, robustness, performance Compiler techniques to help software development in distributed, embedded systems Communication modes between loosely- coupled component systems –Diversity of languages, object models, philosophy

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 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 radio Software physical layers

addr = a r mask = m r addr = b r mask = m r [a r :m r ] addr = c r mask = n Coalesce? Route? Ad hoc topology formation Static configuration impossible DHCP-like configuration undesirable –Pre-configured subnets and broadcasts are problematic over wireless Solution: Distributed, randomized addressing

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; cost

Cricket Beacon Listener No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward 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 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 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! t RF US receivedUS 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 > 25 0 C] data [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]] Intentional name Intentional name resolvers form an overlay network Late binding: integrate resolution and message routing image Lookup camera510.lcs.mit.edu Resolver self-configuration

How does it work? Name resolver network Overlay network of resolvers Client Servicename [service = camera] [building = 10 [room = 510]] Query Periodic advertisement

Routing protocol tracks changes Overlay network of resolvers Client [service = camera] [building = ne-43 [room = 510]] Triggered update Service mobility [service = camera] [building = ne-43 [room = 510]]

Late binding handles mobility [service = camera] [building = ne-43 [room = *]] flag = ANY data [service = camera] [building = ne-43 [room = 510]] [service = camera] [building = ne-43 [room = 504]] Forward to best location Intentional anycast

Intentional multicast for group communication [service = camera] [building = ne-43 [room = *]] flag = ALL data [service = camera] [building = ne-43 [room = 510]] [service = camera] [building = ne-43 [room = 504]] Forward along spanning tree

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-Hellman vmobiled (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 for Oxygen vision, technologies, and research agenda for details on Spectrumware, Cricket, INS, and Migrate Questions?