Mobile and Pervasive Computing - 6 Case Study

1
Mobile and Pervasive Computing - 6Case Study
Oxygen Project
http//oxygen.lcs.mit.edu/
Hari Balakrishnan http//nms.lcs.mit.edu/

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

14
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

15
Device Technologies

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

16
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

17
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

18
Intelligent Rooms

• Capable of Detection motion
• Recognize voice patterns
• Identify a person by face

sensors
19
H21 - Prototype
20
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

21
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

22
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

23
Spoken Interaction
24
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

25
User Technologies

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

26
Oxygen in actionContext-aware networking

• Spontaneous networking

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

• Resource discovery and secure information access
• Vertical mobility

27
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

28
Software physical layers
Edisons radio
29
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
30
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

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

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

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

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

38
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
39
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
40
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
41
How does it work?
Name resolver network
Client
Overlay network of resolvers
Periodic advertisement
Service name
42
Routing protocol tracks changes
Triggered update
Client
Overlay network of resolvers
Service mobility
43
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
44
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
45
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

46
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)
47
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

48
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

49

• Questions???

50
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

51
Assignment 2

• Write Note on Spectrumware, Cricket, INS, and
  Migrate