Escolar Documentos
Profissional Documentos
Cultura Documentos
edu/ MIT
Hari Balakrishnan http://nms.lcs.mit.edu/
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
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!
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
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, lowenergy routing Network bandwidth, latency: monitor network conditions and export via API Gates (computation)
Configure gates using smart compilers (RAW) Application-partitioning in situated computing
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)
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
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
Edisons radio
Spectrumware radio
addr = cr mask = n
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
Traditional approach
ID = u
Cricket
Listener
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
Listener
More opportunities
Interference
Lack of coordination hampers RF-US correlation US has tremendous multipath effects
Multiple millisecond reflections
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
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
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]
[service = lcs.mit.edu/thermo] [building = NE43 [floor = 5 [room = *]]] [temperature > 250C] data
INS architecture
camera510.lcs.mit.edu Intentional name
[service = camera] [building = NE43 [room = 510]]
Lookup
image
Resolver self-configuration
Query Client
Triggered update
Client
[service = camera] [building = ne-43 [room = 510]]
Service mobility
data
Intentional anycast
data
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
DNS
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?