Lecture xvi mobile and ubiquitous computing
Sponsored Links
This presentation is the property of its rightful owner.
1 / 43

Lecture XVI: Mobile and Ubiquitous Computing PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Lecture XVI: Mobile and Ubiquitous Computing. CMPT 401 Summer 2007 Dr. Alexandra Fedorova. Mobile and Ubiquitous Computing. Mobile computing – computers that users can carry Laptops, handhelds, cell phones Wearable computers

Download Presentation

Lecture XVI: Mobile and Ubiquitous Computing

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

Lecture XVI: Mobile and Ubiquitous Computing

CMPT 401 Summer 2007

Dr. Alexandra Fedorova

Mobile and Ubiquitous Computing

  • Mobile computing – computers that users can carry

    • Laptops, handhelds, cell phones

    • Wearable computers

      • Heart monitors used by athletes (Tour de France: team manager monitors heart rates, give recommendations on tactics)

      • Health monitors used by elderly

  • Ubiquitous computing

    • Computers are everywhere

    • Each person uses more than one computer

    • PC, laptop, cell phone, watch, car computer (100+ microprocessors in some cars)

Enables New Cool Applications

  • Object tracking

    • Track location of a child, parent, dog, car (lojack)

    • Parents watch their babies in the daycare

  • Health monitoring

    • Monitor child breathing (prevent SIDS – sudden infant death syndrome)

    • Heart stimulation: embed hearth sensors in the elderly. If pulse goes too low, stimulate the pulse

  • Replace physicians visits (Neuromancer project at Sun Microsystems, Jim Waldo)

    • People wear health monitors

    • They collect health data normally measured by doctors/nurses

    • Eliminates the need for doctor visits – sensors can alert of dangerous health conditions

    • Massive data available – a chance to carry out longitudinal studies in medicine

Some Challenges

  • Limited power

    • Wearable devices and sensors have low battery power

    • To be interesting, sensors must transmit data

    • Data transmission uses power

    • How to minimize power consumption and maximize transmission of useful data?

  • Limited network bandwidth

    • Applications must communicate to sensors exactly what data they need, so sensors don’t transmit useless data

  • Limited connectivity

    • Mobile devices often operate in disconnected mode

    • How to associate to a new network seamlessly?

    • How to form a network without an infrastructure (ad-hoc networking)?

More Challenges

  • Sensor deployment

    • Sensors have limited lifetime, at some point they become useless

    • In ecologically sensitive environments – this means a bunch of silicon scattered around

    • Example: deploy sensors for forest fire detection. Scatter sensors around the forest (from a helicopter)

    • After a while you have a whole lot of improperly disposed batteries

  • Handling data

    • Once all these super-apps get implemented, we’ll have massive amounts of data collected by all imaginable sensors

    • Much of this data will be kept around for historical analysis

    • Where do we store this data? (P2P? – addressed by Neuromancer)

    • How do we make sure it’s safe (replication?)

    • How do we make sure it’s secure?

Case Studies of Sensor Networks

  • Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea, Krishnamurthy et al.

  • IrisNet: An Architecture for a Worldwide Sensor Web, Gibbons et al.

Industrial Sensor Networks

  • Sensor networks used for predictive equipment maintenance

    • Monitor industrial equipment

    • Detect oncoming failures

    • Alert humans of potential failures

  • We will talk about

    • Motivation

    • System architecture

    • System issues specific to wireless sensor networks

  • Two case studies

    • Semiconductor fabrication plan

    • Oil tanker in the North Sea

Predictive Equipment Maintenance (PdM)

  • Monitor and assess the health status of a piece of equipment (e.g., a motor, chiller, or cooler)

  • PdM allows to detect most failures in advance

  • But analysis has to be performed with sufficient frequency

  • Equipment has sensors attached to it

  • Sensors monitor conditions of the equipment

  • Report results to the operator’s computer

  • Operator analyses data, detects any unusual patterns, decides if failure is imminent

  • Takes action to replace the equipment

Types of Sensor Data

  • Vibration (used in this study) – analyze frequency and amplitude of vibrations over time

    • Identify unexpected changes – suggest repair or replacement

    • Source of vibrations must be identified and assigned to a specific component

  • Oil analysis – analysis of wear particles, viscosity, acidity and raw elements

    • Capture a small sample, compare to baseline samples – detect potential problems

  • Infrared Thermography– sense heat at frequencies below visible light

    • Detect abnormal heat sources, cold areas, liquid levels in vessels, escaping gases

  • Ultrasonic detection – detect wall thickness, corrosion, erosion, flow dynaics, wear patterns

    • Compare data to standard change rates, project equipment lifeime

Importance of PdM

  • Reduce catastrophic equipment failures

  • Save human lives

  • Reduce associated repair and replacement cost

  • Save money – switch from calendar-based maintenance to indicator driven maintenance

    • Calendar-based maintenance: may do maintenance when you don’t need to

    • May fail to do the maintenance when you really have to

  • Quantify the value of a new system within the warranty period

  • Meet factory uptime and reliability requirements

Existing PdM Technologies: Manual Data Collection

Data is collected into a hand-held device

A human operator visits the equipment under surveillance

Sensors are installed in the equipment or brought by the operator

Data is transported to the lab for analysis

Existing PdM Technologies: Online Surveillance

Data acquisition unit


Central repository

Sensors are connected to equipment, hardwired to data acquisition unit

Data acquisition unit processes the data and delivers it across a wired network to a central repository

Disadvantages of Existing Technologies

  • Manual data collection:

    • Potential for user error

    • High cost to train and keep experts

    • Cost of manpower for frequent data collection

    • Most users of manual data collection are not happy with the level of prediction and correlation

  • Online systems:

    • Cost of hardware and network infrastructure

    • Only appropriate for equipment with cost impact of over $250K in case of failure

    • Online systems are used in only 10% of the market (due to cost)

Wireless Sensor Networks for PdM

  • Provide frequency of monitoring comparable to online systems

  • Lower cost of deployment – network is wireless

    • Just drop the sensors and you are ready to go

  • Data acquisition unit needs not be specialized hardware

    • Just any computer that can listen for radio signals from sensors

Challenges in Deployment of Wireless Sensor Networks

  • Determine requirements for industrial environments:

    • How often does data need to be sampled?

    • In what form to transmit and organize the data?

    • How long will the sensor battery survive?

  • Effect of environment on deployment

    • What is the signal quality in the current environment? Lots of thick walls is bad for the signal

    • How often will the network be disconnected – i.e., in the ship the compartment containing sensors is periodically shut off

  • How to ensure the required quality

    • Sensors will fail, how do you ensure that sufficient data collection rates are achieved?

Setup for Vibration Analysis

  • Accelerometer – a device used to measure vibrations or accelerations due to gravity change or inclination

  • Measures its own acceleration,

    so it must be hard-mounted to the

    monitored equipment

  • In the experiment, an off-the-shelf accelerometer was used; it interfaces with the rest of the sensor board (radio, etc.)

  • Sensor network interfaces with an off-the-shelf software application – provides long term data storage, trend analysis, fault alarms

Site Planning

  • How/where to install the sensors given the particularities of a given site?

  • Sensors must be safe for the equipment they monitor

  • Radio Frequency (RF) coverage – are there walls and equipment preventing good RF coverage? Must relay nodes or gateways be installed?

  • RF interference – is there RF noise that will prevent good transmission? RF interference may come from other radios used on the site.

  • To assess these factors, a site survey is needed

Site Survey

  • Place test sensors near sensing points (where actual sensors will be mounted in the future)

  • Place test gateways (the machines that will receive data from sensors and transmit it further) at locations where actual gateways would be placed

    • Near power outlets and Ethernet jacks

  • Using test setup, evaluate wireless connectivity, RF coverage and interference

Site Survey Results

  • Sensor nodes with more powerful radios worked better in conditions with RF interference

  • Less powerful radios were not able to transmit through a door on the oil tanker

  • It had to be ensured that sensor node frequencies did not overlap with critical radio frequencies used on the oil tanker

  • Witnessed better RF performance on the oil tanker than was initially expected:

    • Attributed to use of steel materials on the ship

    • Steel materials reflect, rather than attenuate RF energy (unlike office and home environments)

Application Specific Requirements

  • Data must be accurate, acquired and transmitted in a timely manner

    • Challenge: sensors and data acquisition units will fail due to operation in a harsh environment

    • Solution: system must be designed with expectation for failure and with ability to quickly recover from failures

  • Long-lived battery powered operation

    • Sensor networks should not use plant power

    • Should be battery operated: must operate for a long time on one set of batteries, to avoid the need for frequent redeployment

Hardware Architecture

Sensor node (Mica2 mote)

  • Two types of sensor nodes :

    • Mica2 Mote

    • Intel Mote

  • Mote:

    • Composed of a small, low powered computer

    • Radio transmitter

    • Connected to several sensors

  • The node’s sensor board is connected to vibration sensors

Hardware Architecture Comparison

  • Mica2

    • Less powerful radio

    • No on-board storage for sensor data, so you need to attach additional storage to it

  • Intel

    • Very powerful radio: 10x throughput of the Mica2 mote

    • Uses more power

Network Architecture

  • Hierarchical architecture

    • Sensor clusters (sensor mesh)

    • Cluster head (connected to the gateway)

    • Stargate Gateway

      • mote radio

      • 802.11 radio

    • 802.11 backbone

    • Root Stargate

    • Bridge Stargate

    • Enterprise server

Data Collection and Transfer

  • Cluster head schedules data capture/transfer for every sensor connected to each node

  • When a node has captured data it initiates a connection to the Stargate gateway

  • Data is transferred using a reliable transport protocol

  • Sensor data is time-stamped and put in a file

  • There is a separate file for each collection of a sensor channel

  • Each Stargate gateway periodically copies file to the root gateway

  • Root gateway transfers data to Bridge gateway via serial cable – this is done to isolate wireless network from the corporate network

  • Bridge gateway transfers data to the enterprise server

Hierarchical Network Structure

  • Tier 1 – lowest level

    • Networks of sensor nodes

    • They form clusters: may be pre-assigned to a cluster or choose the cluster dynamically

    • Lowest compute capability, limitations on bandwidth and battery capaciry

  • Tier 2 – middle level

    • Sensor network backbone

    • Individual cluster gateways

    • Higher compute and power capacity – offload computational burden from Tier 1

  • Tier 3 – highest level

    • Interface to the enterprise

    • Abstracts application needs from the sensor network

Sleep/Wakeup Schedule

  • Sensor nodes form a cluster around a gateway

  • Nodes in a cluster follow a sleep/wakeup protocol

  • When nodes wake up they acquire data from sensors and transmit it to the gateway

  • Then they go to sleep until the next data collection is scheduled

  • Sleep/wake-up operation saves battery power

  • Sleep/wake-up schedule is coordinated by a cluster head – a device connected to the gateway via a serial port

Power Management Protocol

  • Cluster head schedules sleep periods based on application-level sampling requirement

  • Upon initial discovery of nodes in the cluster, cluster head sends the first request for data collection

  • At the end of each data collection it sends a message indicating start time and duration of next sleep phase

  • Sensor nodes go to sleep and then wake up all together

  • When nodes are asleep they are not completely turned off, but they operate in a low power mode

  • Nodes’ clocks are not perfectly synchronized, so the cluster head waits for some “skew” period until beginning next data collection

  • Sleep periods in the oil tanker installation were set to 7 and 18 hours

Fault Tolerance

  • Sensor networks must operate in harsh environments for long periods of time

  • Failures are common and should be expected

Fault Tolerant Design

  • Four design features to increase fault tolerance:

    • Watchdog timers – a node resets itself upon encountering unexpected behavior

    • Cluster heads store network state – nodes can return to operation quickly after being reset

    • Intentional re-initialization of sensor nodes after each collection period

    • Non-volatile storage of critical state at cluster head – cluster head could be (and was) reset after each wake-up period

Watchdog Timers

  • Each node monitors events:

    • How much time has passed since last packet reception (in the wake state)

    • Events signifying radio lockups

    • Protocol events – e.g., receipt of new data send request before the previous one was finished

  • The node resets itself if any of these unexpected events was detected

Comparing Power Consumption

  • Active power – power when the network is awake

    • Similar usage of active power per unit of time

    • But Intel motes spent less time being awake, because they had faster radios

    • So Intel-based network used less power overall

  • Power during the sleep phase

    • Intel network implemented a connected sleep mode

    • You can still access the network while the nodes are asleep, albeit at a higher latency

    • So it used more power in the sleep mode

    • If Intel-based network were completely disconnected, it would use only slightly more power as Mica2-based network

    • Using an external real-time clock can enable completely turning off the network during the sleep mode – even more power would be saved

Battery Life

  • On the oil tanker, two lengths of sleep mode were used:

    • 18 hour sleep period

    • 5 hour sleep period

  • Resultant battery lives are:

    • 18-hour period: 82 days

    • 5-hour period: 21 days

Case Studies of Sensor Networks

  • Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea, Krishnamurthy et al.

  • IrisNet: An Architecture for a Worldwide Sensor Web, Gibbons et al.


  • A slightly different environment than conventional sensor networks

  • Many devices: PCs, hand-helds, cameras

  • Good connectivity, no power limitations

  • Provide useful data

  • Question:

    • How do we access and integrate this data to enable interesting applications?

  • Solution:

    • Architecture for a Worldwide Sensor Web

IrisNet Vision

  • A user will query, as a single unit, vast quantities of data from thousands of widely distributed sensors

  • Many possible uses:

    • Epidemic Early Warning System - monitor water quality, oil spills

    • Homeland Security

    • Computer Network Monitoring – gather (sense) data on bandwidth/CPU usage; answer queries such as “What’s the least loaded node at SFU?”

    • Traffic / Parking Assistance – help me find hockey game parking in Vancouver

IrisNet Goals

  • Planet-wide local data collection and storage

    • Massive amounts of data

    • Retain data near its source, transmit to the Internet only as needed

  • Ease of service authorship

    • Vision: when sensors are deployed, we don’t know all potential users

    • Different service providers might want to collect different data and different rates and apply different filters depending on the service

  • Real-time adaptation of collection and processing

    • Reconfigure data collection and data filtering processes, change sampling rates

  • Data as a single queriable unit

    • Global sensing device network is a single unit that supports a high-level query language

    • Users make complex queries: “Tell me the location of my grandmother at the time when the oil spill in the Baltic sea was first detected”.

  • Data integrity and privacy

    • No one should be able to query my health data except my doctor




XML database


XML database


XML database

. . .




. . .











IrisNet Architecture

Two components:

SAs: sensor feed processing

OAs: distributed database

Web Server

for the url

. . .

From slides of P. Gibbons

IrisNet Architecture

  • Sensing Agents (SA)

    • Generic data acquisition interface: ask sensor to collect data X at frequency Y, filter data according to parameter Z

    • A service configures sensing agent according to its needs

    • Configuration is done via execution of service-specific code senslet

    • A single SA can execute one or more senslets

  • Organizing Agents (OA)

    • Service specific sensing data is stored in a database

    • This database is queried by users

Organization of SA

OA Architecture

  • XML-based database

  • Hard to design rich schema for all possible service

  • XML allows the use of self-describing tags

  • Database is partitioned and distributed

  • Replicate parts of the database

  • Primary replicas: strong consistency

  • Secondary replicas: weak consistency

Querying the IrisNet

  • Each node has a human readable name

  • Each such name is registered in the DNS with associated IP address

  • Query is routed to the IP address


Example Services

  • Parking space finder

    • Uses cameras throughout a metropolitan area to track parking space availability

    • Users fill out a Web form to specify destination and any constraints on a desired parking space

    • Parking space finder identifies the parking space satisfying constraints

  • Network and host monitor (IrisLog)

    • Collects data from computer and network monitoring tools

    • Those tools act like sensors

    • They report data, such as CPU and memory load, network bandwidth

    • Answer queries such as “find the least loaded node on the network”

  • Coastal imaging service

    • Uses camera installed at Oregon coastline

    • Uses live feed from cameras to identify signatures of phenomena such as riptides and sandbar formations


  • Variety and quantity of small computers is exploding

  • These computers are mobile, wearable, provide a variety of cool functions/sensing abilities, and are affordable!

  • One can imagine a multitude of useful “killer apps” using those devices

  • Many challenges need to be overcome to make these applications really work:

    • Limited power and network bandwidth

    • Formation of ad-hoc networks

    • Querying the available data

    • Handling and storing massive amounts of data

  • Login