Mobile and pervasive computing 6 case study oxygen project
1 / 45

Mobile and Pervasive Computing - 6 Case Study – Oxygen Project - PowerPoint PPT Presentation

  • Uploaded on Hari Balakrishnan Mobile and Pervasive Computing - 6 Case Study – Oxygen Project. Presented by: Dr. Adeel Akram University of Engineering and Technology, Taxila,Pakistan Vision & Goals.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Mobile and Pervasive Computing - 6 Case Study – Oxygen Project' - hiram-hurley

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Mobile and pervasive computing 6 case study oxygen project

Hari Balakrishnan

Mobile and Pervasive Computing - 6Case Study – Oxygen Project

Presented by: Dr. Adeel Akram

University of Engineering and Technology, Taxila,Pakistan

Vision goals
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

The oxygen environment
The Oxygen Environment



Camera array

Speech &




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!

What oxygen is and isn t
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!

This talk
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!)

Configuration and management
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

Software adaptation
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

Mobility and nomadicity
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

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”)

Security and privacy
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

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

Device technologies
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

Device technologies1
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

Device technologies2
Device Technologies

  • N21 Network Devices

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

E21 intelligent spaces
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

H21 mobile devices
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

Intelligent rooms
Intelligent Rooms

  • Capable of Detection motion

  • Recognize voice patterns

  • Identify a person by face


N21 network technologies
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

Software technologies
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

Perceptual techniques
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

Visual interaction
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

User technologies
User Technologies

  • Knowledge Access

    • Access any time, anywhere, almost anything

  • Automation

    • Automate control of physical environment

  • Collaboration

    • Connecting people

Oxygen in action context aware networking
Oxygen in action:Context-aware networking

  • “Spontaneous” networking

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

  • Resource discovery and secure information access

  • Vertical mobility

Self configuring networks
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

Software physical layers

pages = (BlockSize/4096) +1;

if ((guppi_open("guppi0",pages)) < 0 )



for ( i=0 ; i< NumBlocks ; i++) {

pdata = (char *)guppi_rec_buf();

for ( j=0 ; j< IntsPerBlock ; j++) {



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

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

Traditional approach
Traditional approach

Location DB

ID = u?


sensor grid

ID = u


Problems: privacy; administration; granularity; cost


space = “a2”

space = “a1”



Pick nearest to

infer space


No central beacon control or location database

Passive listeners + active beacons preserves privacy

Straightforward deployment and programmability


  • Location granularity

  • Interference

    • Lack of explicit beacon coordination

  • Energy consumption

  • Listener inference algorithms

Every problem is an opportunity



RF data


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)


  • 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


More opportunities
More opportunities

  • Interference

    • Lack of coordination hampers RF-US correlation

    • US has tremendous multipath effects

      • Multiple millisecond reflections

  • Randomized transmission schedule


    pick r ~ U[R1,R2];


    xmit(RF,US); // takes time = S/b for data to reach

  • Can determine optimal R1 and R2 analytically


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



US received

US from elsewhere

Resource discovery
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

Intentional naming system ins
Intentional Naming System (INS)

Names are intentional; apps know what, not where


Late bindingof name to location to handle failover, mobility


Decentralized, cooperating resolvers


Name resolvers self-configure into overlay network

Easy configuration

Aggressive partitioning of namespace and delegation


Intentional names

[service =]

[building = NE43

[floor = 5

[room = *]]]

[temperature > 250C]


Intentional names

  • Expressive name language (like XML)

  • Providers announce attributes

  • Clients make queries

    • Attribute-value matches

    • Wildcard matches

    • Ranges

  • [service =]

  • [building = NE43

    • [room = 510]]

  • [resolution=800x600]

  • [access = public]

  • [status = ready]

Ins architecture

Intentional name

[service = camera]

[building = NE43

[room = 510]]

INS architecture

Intentional name resolvers

form an overlay network





Late binding: integrate resolution and message routing

Vertical mobility
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

Mobility is an end to end issue


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


(picks best network

for connections)

Oxygen is a system of systems
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

Summary how might we cope
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


  • for Oxygen vision, technologies, and research agenda

  • for details on Spectrumware, Cricket, INS, and Migrate

Assignment 2
Assignment # 2

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