Mobile and Pervasive Computing - 6 Case Study – Oxygen Project

1. http://oxygen.lcs.mit.edu/ Hari Balakrishnan http://nms.lcs.mit.edu/ Mobile and Pervasive Computing - 6Case Study – Oxygen Project Presented by: Dr. Adeel Akram University of Engineering and Technology, Taxila,Pakistan http://web.uettaxila.edu.pk/CMS/SP2014/teMPCms

2. Vision & Goals • Pervasive, human-centered computing • Computation embedded into human life, like the Oxygen we breathe • 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 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!

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 don’t 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 • 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. Device Technologies • E21 Intelligent Spaces • Space centered computation, embedded in ordinary environment • Populated by cameras, microphones, displays, sound output • Controls for physical entities like curtains, lighting, door-locks • People interact in Intelligent Spaces naturally, using speech, gestures

13. Device Technologies • H21 Mobile Devices • Person centered devices also the Universal Personal Appliances • Equipped with perpetual transducers such as microphone, speakers • Auto reconfigurable, light weight, inexpensive • Anonymous generic devices

14. Device Technologies • N21 Network Devices • Networks make it easy to establish ad-hoc collaborating communities of computer devices

15. E21- Intelligent Spaces • Connected to sensors, suitably encapsulated into physical objects • Communicate with each other and nearby handheld devices (H21) through Dynamically Configured Networks (N21) • E21 provide computational power throughout the system to • Communicate with people • Support Oxygen User Technologies • Monitor and control their environment • E21 software is robust, and configurable among themselves

16. H21 – Mobile Devices • Generic devices also called Universal Personal Appliances • Do not carry large amount of permanent local state • They configure themselves according to the person using them • Being small and lightweight, they have few transducers • They have less computational power than E21 • Can be configured to be used as radio, cellphone or even TV • Power efficient, the software controls the power consumption

17. Intelligent Rooms • Capable of Detection motion • Recognize voice patterns • Identify a person by face sensors

18. H21 - Prototype

19. N21 – Network Technologies • Networks make it easy to establish ad-hoc collaborating communities of • computer devices • Through algorithms, protocols and middleware, they • Configure collaborative regions automatically • Create topologies and adapt them to change • Provide automatic resource and location discovery • Provide secure, authenticated and private access • N21 networks use intentional names rather than conventional static names • They support location discovery through proximity

20. Software Technologies • Software systems adapt - to user, to environment, to change, to failure • Project Oxygen's software architecture provides mechanisms for • Building applications using distributed components • Customizing, adapting and altering component behavior • Person-centric rather than device-centric security • Disconnected operation and nomadic code • Eternal Computation: The system must never shut down or reboot though components are upgraded, removed and reinstalled

21. Perceptual Techniques • Two types of Perceptual Techniques are used • Spoken Interaction • Users and Machines engage in interactive conversations • Highly efficient • Visual Interaction • Users interact with perceptual modalities • Use of body language and gestures

22. Spoken Interaction

23. Visual Interaction • It consists of • Visual perception Subsystem • It recognizes and classify objects and actions • Complements spoken language subsystem • Visual rendering Subsystem • Creates 3D scenes from 2D data • Provide macroscopic view of application supplied data

24. User Technologies • Knowledge Access • Access any time, anywhere, almost anything • Automation • Automate control of physical environment • Collaboration • Connecting people

25. Oxygen in action:Context-aware networking • “Spontaneous” networking • Context-aware speech-driven active maps (location-specific) • Resource discovery and secure information access • Vertical mobility

26. 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

27. 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 Edison’s radio

28. 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

29. Traditional approach Location DB ID = u? Networked sensor grid ID = u Responder Problems: privacy; administration; granularity; cost

30. space = “a2” space = “a1” 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

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

32. US pulse RF data (spacename) 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 >> 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

33. 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[R1,R2]; delay(r); xmit(RF,US); // takes time = S/b for data to reach • Can determine optimal R1 and R2 analytically

34. 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! RF t US received US from elsewhere

35. 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

36. Intentional Naming System (INS) Names are intentional; apps know what, not where Expressiveness Late bindingof 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

37. [service = lcs.mit.edu/thermo] [building = NE43 [floor = 5 [room = *]]] [temperature > 250C] data 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]

38. Intentional name [service = camera] [building = NE43 [room = 510]] INS architecture camera510.lcs.mit.edu Intentional name resolvers form an overlay network Lookup image Resolver self-configuration Late binding: integrate resolution and message routing

39. 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

40. DNS Migrate using Diffie-Hellman 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)

41. 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

42. 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

43. Questions???

44. References • 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

45. Assignment # 2 • Write Note on Spectrumware, Cricket, INS, and Migrate