Project Oxygen http://oxygen.lcs.mit.edu/ 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 isnt

• 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 dont 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
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

13
Oxygen in actionContext-aware networking

• Spontaneous networking

• Context-aware speech-driven active maps
  (location-specific)

• Resource discovery and secure information access
• Vertical mobility

14
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

15
Software physical layers
Edisons radio
16
Ad hoc topology formation

• Static configuration impossible
• DHCP-like configuration undesirable
• Pre-configured subnets and broadcasts are
  problematic over wireless
• Solution Distributed, randomized addressing

Coalesce? Route?
addr ar mask mr
addr br mask mr
addr cr mask n
17
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

18
Traditional approach
Location DB
ID u?
Networked sensor grid
ID u
Responder
Problems privacy administration granularity
cost
19
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
20
Problems

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

21
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 gtgt 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
22
More opportunities

• Interference
• Lack of coordination hampers RF-US correlation
• US has tremendous multipath effects
• Multiple millisecond reflections
• Randomized transmission schedule
• loop
• pick r UR1,R2
• delay(r)
• xmit(RF,US) // takes time S/b for data to
  reach
• Can determine optimal R1 and R2 analytically

23
Technology

• Beacon 418 MHz AM RF and 40KHz US
• Listener correlates RF and US samples
• Interference from another beacons 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
24
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 todays naming system name by
  (network) locations
• Names should refer to what, not where

25
Intentional Naming System (INS)
Names are intentional apps know what, not where
Expressiveness
Late binding of 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
26
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 resolution800x600 access
public status ready
27
INS architecture
camera510.lcs.mit.edu
Lookup
image
Resolver self-configuration

• Intentional name resolvers
• form an overlay network

Late binding integrate resolution and message
routing
28
How does it work?
Name resolver network
Client
Periodic advertisement
Overlay network of resolvers
Service name
29
Routing protocol tracks changes
Triggered update
Client
Overlay network of resolvers
Service mobility
30
Late binding handles mobility
service camera building ne-43 room 504
Forward to best location
service camera building ne-43 room
flag ANY
service camera building ne-43 room 510
data
Intentional anycast
31
Intentional multicast for group communication
service camera building ne-43 room 504
Forward along spanning tree
service camera building ne-43 room
flag ALL
service camera building ne-43 room 510
data
32
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 dont work well
• Per-application choices impossible
• Inefficient routing
• Deployment is hard
• Not all mobile applications are equal

33
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)
34
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

35
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

36
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?