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; 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
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
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
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 = *]]] 0 [temperature > 25 C] data
INS architecture
camera510.lcs.mit.edu Intentional name
[service = camera] [building = NE43 [room = 510]]
Lookup
image
Resolver self-configuration
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 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?