1. CSE494/598 Mobile Computing Systems and Applications (Fa2011)
Class 4

2. Agenda Context-Aware App (cont.) Intro to Wireless Sensor Networking
Implementation of adaptive applications
Mapping adaptive application requirements to hardware constraints
Adaptation in hardware

3. Context-aware Computing
Beyond application-aware adaptation
Instead of adapting only to resource levels, adapt to contexts
Context:
Enumeration-based (categories)
Role-based (roles of context in building mobile applications)

4. Types of Context
Computing context includes network connectivity, communication costs, communication bandwidth, and local resources, such as printers, displays, and workstations
User context includes user profiles, location, and people in the vicinity of the user
Physical context includes lighting and noise levels, traffic conditions, and temperature
Temporal context includes time of day, week, month, and season of the year
Context history is the recording of computing, user, and physical context over time

5. The 5 W’s…
Who is the user? Who are the people with which the user is interacting, or who is nearby?
What is the user doing?
Where is the user? Home? Work? Bathroom? Familiar coffee shop?
When? What time is it?
Why? Why is the user performing a certain task? What is the task’s priority in the “grand scheme”?
Low-level vs. High-level details

6. Context Overview

7. Context-aware Requirements
Contextual sensing
detection of environmental states
Contextual adaptation
capability of the system to adapt its behavior by using contextual information
Contextual resource discovery
capability to discover available resources in an environment
Contextual augmentation
capability to associate contextual information with some digital data
Example: association of a particular meeting place and attendees with a set of minutes
Example: association of a digital photo with a specific location

8. Designing CA Applications
Build list of relevant contexts
e.g., “home”, “office”, “traveling”, “sleeping”, …
Specify context-aware behaviors
Presentation of context-sensitive information
Automatic discovery of relevant objects (e.g., nearby people for transmission of business cards)
Modification of the physical and digital environments
Integration of application with methods for sensing context

9. Simple Example: stick-e notes
Context-aware Post-it notes
Build list of relevant contexts
Based on location (latitude/longitude via GPS)
Temperature, whatever else can be sensed
Specify context-aware behaviors
stick-e notes “pop up” on a PDA when contextual info is appropriate
Reminder to return a library book when near the library
Reminder to buy a new winter jacket when temperature drops below 60F
Integration of application with methods for sensing context
Most difficult part
Ubiquitous sensing of environmental characteristics, such as location, temperature, number of human beings nearby, the cat is near, not widespread

10. Where Does Context Come From?
Returning to the “difficulty” point on the previous slide
Environmental sensors
Temperature, humidity, location, noise, motion
Cat sensor
Potential need for multiple types of sensors
GPS vs. indoor location sensors
History
Recording user actions and previous contexts
User’s personal computing environment
Schedules, notes, address books, financial info
Need real-time analysis to provide context

11. Example: Location Indoor locating systems
e.g., infrared or ultrasound
Wireless nanocell communication activity
Association with short-range base stations
GPS
Associations with nearby computers
Motion sensors and cameras, computer vision
Ask the user!

12. Service-oriented Architecture
Provide services to context-aware applications
Context subscription and delivery service
Delivers contextual information as available
Context query service
Delivers contextual information on-demand
Context transformation and synthesis services
Transforms low-level contextual information (location, temperature, lighting levels) into high-level (“YOU’RE IN THE CLOSET IN YOUR BEDROOM”)
Service discovery
Discovery of nearby services
We’ll examine service discovery protocols next!

13. Paper: Out of Context: computer systems that adapt to, and learn from, context (authors H. Lieberman & T. Selker)

14. Key Points
Context-Sensitive (Aware) computing is antithetical to traditional computer science (search for context-independent abstractions)
Black box approach
Model of Context Aware application: Context as implicit input
System boundary decides what’s implicit and what’s explicit
Context-Abstraction trade-off

15. Key Points (Cont.) Models of context:
System model: description of the system
User model: User’s state, history and preferences
Task model: goals and actions intended to be performed by the user
To create context-aware applications these models should be dynamic and have ability to explain themselves.

16. Context from other fields
Mathematics and AI
Statistical data mining techniques: knowledge discovery by analyzing large amount of data
HCI
Ambient interfaces
Sociology and Behavior Studies
Situated action – stresses the effect of shared social context on human behavior
Activity Theory: agent strategies for successful behaviour
Nass and Reeves work on understanding how context affects human interaction with computers

17. In Summary
Context awareness requires adaptation to changes in the environment
How to adapt applications?
Detection of changes
sensors, e.g. physiological and environmental sensors, network connectivity sensor, battery capacity sensors
Detection-driven behavior
State-based approach, i.e. chose an operating state according what is sensed.
Employment of compensating mechanisms
Profiling, Caching, Prefetching

18. Implementation of Adaptive applications
Two pronged approach
Adapt in hardware
Use reconfigurable hardware such as FPGA, Atom + FPGA (Tunnel Creek)
Design configurations for different adaptation cases
Develop a reconfiguration logic
Design hardware given worst case system requirements
Develop system requirements for the worst case scenario in adaptation
Map the system requirements to requirements on the hardware
Develop the hardware to meet the requirements
Write the software for the adaptive application keeping in mind the resource constraints of the hardware

19. Hardware Adaptation

20. Field Programmable Gate Arrays
Basic idea: two-dimensional array of logic blocks and flip-flops with a means for the user to configure:
1. the interconnection between the logic blocks,
2. the function of each block.
Select interconnects and logic blocks to have different hardware functionalities with the same FPGA
Simplified version of FPGA internal architecture:

21. How do you program an FPGA?
Create a circuit design
Graphic circuit tool
Verilog
VHDL
AHDL
Compile the design for the selected device
Download the compiled configuration

22. Reconfigurable heterogeneous architecture
Tunnel creek
Altera
FPGA
Intel
Atom

23. Application driven hardware design

24. Gap between application and hardware
Application Designer
Hardware Designers
Knows contexts to be sensed
Knows adaptation requirements
Need to map to platform specifications
Need to quantify platform performance
Provide datasheet
Need to improve design based on new, emerging applications
Need to objectively compare performance of multiple platforms
A STANDARD EVALUATION METHODOLOGY IS CURRENTLY LACKING
NEW PLATFORM DESIGNER – UNDERSTAND CORRELATION BETWEEN PERFORMANCE AND INDIVIDUAL DESIGN CHOICES. AND THESE CHOICES MUST BE QUANTITATIVE FOR YOU TO SPECIFY THE PLATFORM DESIGN.
Require standard evaluation method and
performance metrics

25. Challenges Mapping diverse platforms to common evaluation ground
Design Coordinate: A feature of a hardware platform that determines its performance, e.g. Available Memory.
Design Space: The space defined by the design coordinates
Quantify design coordinates, performance parameters
Evaluation Metrics, e.g. kB of RAM, W of power consumed
Measure performance in real application scenarios
Develop benchmarks based on building block context aware applications
Search design space for suitable platform
EVALUATION GROUND…
THIS EVALUATION GROUND IS COMPOSED OF DESIGN COORDINATES. DEFINE …
FOR OBJECTIVE COMPARISON, WE NEED TO QUANTIFY THE COORDINATES AS WELL AS THE PERFORMANCE OF THE PLATFORM. FOR THIS, WE NEED EVALUATION METRICS

26. Solution Methodology Design Space Determination
DESIGN COORDINATES
EVALUATION METRICS
DESIRABLE DESIGN SUBSPACE
APPLICATION REQUIREMENTS
CHOOSE SUITABLE PLATFORM
DESIGN NEW PLATFORMS
BSNBENCH
TASKS
MEASUREMENTS
Design Space Determination
Design Space Exploration
DESIGN SPACE REPRESENTATION
SET OF BSN PLATFORMS
Platform requirements of typical BSN applications

27. Example Healthcare applications using Body Sensor Network
How to choose the best suited platform for a given BSN application ?

28. Nano-scale Blood Glucose level detector @ UIUC
Pervasive Health Monitoring Applications
Components Used
Miniature sensors, gateway device
Services Enabled
Continuous, remote patient monitoring: No time & space restrictions
Utilize wearable and in-vivo medical sensors
Reduced medical errors
Early detection of ailments and actuation through automated health data analysis
Nano-scale Blood Glucose level UIUC
Temperature Tele-sensor
@ Oak Ridge National Lab
Vivometrics
WIRELESS MEDICAL SENSORS AND SMARTPHONE,PDA OR LAPTOP
THIS SIMPLE DESIGN ENABLES SEVERAL SERVICES SUCH AS ….
FALL DETECTION FOR ELDERLY, CONTINUOUS MONITORING OF HOSPITAL PATIENTS WITHOUT STRESSING STAFF
Applications
Sports Health
Management
Home-based care
Computer Assisted
Rehabilitation
Medical Facility
Diverse types of adaptive applications with various requirements

29. Diversity in available platforms- How to choose?
BSN Platforms
Components: Microprocessor, radio, onboard memory, power supply interface, etc.
Applications: Used for BSN research experiments and clinical trials.
BSN node v3
Imote2
TelosB
Shimmer
Radio – CC2420+ miniaturized chip antenna
Processor – MSP430
Size – 26mm x 16mm x 2mm
Radio – CC2420 ( ) + RN-42 (Bluetooth)
Size – 53mm x 32mm x 15mm
Radio – CC2420 +
Inverted-F antenna
Processor –
MSP430
Size – 65mm x 31mm x 6mm
Radio – CC Surface mount antenna
Intel Xscale
Size – 36mm x 48mm x 9mm
INTEGRATED CIRCUIT BOARD
DIFFERENT PLATFORMS DESIGNED WITH DIFFERENT DESIGN GOALS
Diversity in available platforms- How to choose?

30. Processing Requirements
Example: Determination of heart rate variability
Ratio of the high frequency to low frequency components of the heart rate variation is considered
Sampling and storage of signals
Peak Detection
Fast Fourier Transform

31. Wireless communication requirements
Packet delivery ratio
The percentage of packets correctly received amongst the number of packets sent
Depends on the antenna design, power input to the antenna, and the properties of the wireless medium
Average radio power consumption
Depends on the radio duty cycle
Duty cycle is the percentage of time the radio is in “ON” state actively transmitting data

32. Energy and Form Factor Requirements
Battery is the primary source of energy which has a definite capacity
Applications have specific life time requirements
Lifetime is the number of hours the application should run without interruption
This imposes upper limit on the power consumption
Form factor has to be small so that it is wearable
This imposes constraint on the battery size and hence battery capacity

33. Design Space Determination
Set of available platforms
Design
Coordinates
Average Radio Power Consumption
Form Factor
On-board data memory mW
mm3
kB of RAM
Metrics
Evaluation
Method
BSNBench
Datasheet
Datasheet

34. WIRELESS COMMUNICATION
Design Coordinates
Based on typical BSN application requirements
Decompose platform functionality into individual modules
(Processor, data and program memory, signal processing capability)
COMPUTATION
(Radio reliability, average power consumption, interoperability)
WIRELESS COMMUNICATION
DESIGN COORDINATES
(Battery, energy scavenging support)
ENERGY SOURCE
(Form factor, thermal safety, sensor integration)
PHYSICAL ASPECTS

35. Design Space Exploration
Average Radio Power Consumption (mW)
Form Factor (mm3) P1 P2 P4 P3
Design coordinate axis
Constraints on design coordinates
RAM Availability (KB)
Sensor platforms
Appropriate region in the design space

36. Capacity (mAh), size (mm3)
Evaluation Metrics
Use suitable metrics to quantify design coordinates:
Some traditional metrics are independent of the target applications. e.g. MIPS, MIPS/W
Consider BSN application characteristics to develop more suitable metrics.
For example, processor speed measured in units of samples processed per second
Design Coordinate
Metric
Radio Reliability
On-body PDR [1]
Battery
Capacity (mAh), size (mm3)
[1] A. Natarajan, B. Silva, K. Yap, and M. Motani. To hop or not to hop: Network architecture for body sensor networks. In IEEE SECON, 2009.

37. SPSW Metric for Processor
SPSW (Samples Processed per Second per Watt) is defined as:
Captures tradeoff between processor speed and power consumption.
“Processing a sample” is application-specific.
For example, a platform motes calculates mean of 1000 data samples in 100 ms and consume 25 mW power. Then,
SPSW = 1000/(100 X 25) = 400 samples/mJ
(Time taken) (Power consumed)
(No. of Samples Processed)
SPSW =

38. EPC Metric for Radio
Radio power consumption depends on radio specifications as well as duty cycle.
EPC (Expected Power Consumption) is defined as:
For example, if radio transmits for 5% time, with power draw 10 mW and is in SLEEP state for remaining 95% time, with power 0.1 mW,
EPC = 0.05 * * 0.1 = mW
Fraction of time in state S *
Power consumed in state S
EPC = ∑
all states

39. BSNBench: A BSN-specific benchmark
Key Observation: In spite of diversity in BSN applications, some basic tasks are common.
Type of benchmark: Microbenchmark
Composition:
Data Operations (Statistics, Differential Encoding)
Signal Processing (FFT, Peak detection)
Radio Communication (Duty-cycled handshake, PDR)
Sensor Interface (Sensed Data Query)
Implemented in TinyOS 2.0

40. Design Space Exploration
Application Requirements
Constraints on Design Coordinates
Define subspace of
design space
We look at the given application. The application requirements are first characterized in terms of constraints on design coordinates. If the application has constraints on multiple design coordinates then we can represent them as a surface in the design space. From the constraints thus we can derive a subspace bounded by these surfaces, The set of platforms that lie within the subspace obey all the constraints and are hence possible candidates for use, In case multiple platforms the design coordinates can be prioritized to make the choice.
Tie prioritizing design coordinates to application requirements.
Prioritize design coordinates
Set of suitable platforms
Identify most suitable platform

41. Case Study We consider two typical BSN applications:
Epileptic Seizure Detection (ESD):
Detect onset of epileptic seizures using an ECG sensor.
Perform peak detection on ECG signal to calculate RR intervals.
Intervals are converted to FFT coefficients and sent to the gateway device.
Continuous Glucose Monitoring (CGM):
Long term monitoring application
Sensor measures the blood glucose level and transmits this data to a gateway device.
As an illustration of the design space exploration procedure we show two case studies. The first one concerns with a continuous long term glucose monitoring system which senses the blood glucose level and transmits them to a gateway device. The next one is an epileptic seizure detection system, which senses ECG signals and performs signal processing tasks such as peak detection, FFT computation and sends the processed signals to the gateway device. Our set of platforms include TelosB. BSN node v3, Mica 2 and iMote2.

42. Mapping application requirements to design coordinates (ESD)
Requirement 1: store 5 seconds of data at 256 samples per second and perform FFT
Constraint on the RAM = at least (3×256×5×12)/8 = KB of RAM required assuming 3 channel ECG
256 point FFT computation requiring at least 6 KB of RAM.
Requirement 2: power consumption should be limited to 5 mW
Compound constraint: Processing power + communication power < 5 mW
Processing Power = number of samples per second / SPSW = 3 × 256/SPSW
Communication power = EPC at the required duty cycle
Duty Cycle = transmit time / total time
Transmit time = 3 × 256 × 12/22000 assuming 22 kbps bit rate and 12 bit representation of data
Hence, duty cycle = (3 × 256 × 12/22000)/5 = 4.1 %
Compound constraint
Requirement 3: On body PDR greater than 0.7

43. Mapping platforms into design space
Data sheets for RAM
FFT signal processing task for RAM requirements
EPC – communication task in BSNBench
PDR – BSNBench on body and off body PDR

44. Mapping contd …. SPSW characterization
Sensor query task, peak detection, and FFT computation task in BSNBench
Combination of SPSW
Application 2 (app2) B
bpB N1 N2
Application 1 (app1) A IF
(PB, tB)
(PA, tA) NA
(1-bpB) C NB NC A B C
(PC, tC)
(PA, tA)
(PB, tB)
(PC, tC)

45. Constraints and platform mappings
Constraints on signal processing capability and communication reliability (on-body PDR)
Imote2
BSN node v3
TelosB
256 - point FFT
Available RAM
Signal processing is the core computation in this application. In order to detect epileptic seizures successfully, the platforms need to perform 256 point FFT. FFT processing hogs up a lot of RAM in the processor. Hence, there are constraints on the RAM availability.
For Mica2, just say “it has insufficient RAM for 256 point FFT”
128 – point FFT
Mica2
0.7
On-body PDR

46. Compound constraint Map
Forms a complex contour in the design space
Can be modeled as an optimization objective
100
200
300
400
500
600
700 1 2 3 4 5 6 7 8 9 10
Sensor Query SPSW (samples/mJ)
EPC at 4.21 % duty cycle (mW)
112
BSN v3
TelosB
Mica 2
Imote 2
(104 MHz)
(13 MHz)
Suitable Subspace
Constraint
Shimmer

47. Case Study: CGM Set of platforms: TelosB, Mica2, Imote2 and BSN v3
Constraints on EPC and Form Factor coordinates
iMote2
35.62 mW
In the first application the communication was an important aspect and consumed the most amount of energy. Further, since the platform has to be worn 24/7 so wearability was important. Thus constraints were imposed on the form factor of the platforms. We wanted to last the application on 2 alkaline AAA batteries continuously for 4 days. This requirement demanded an EPC less than mW. Further, we restricted the form factor to a 50 cubic volume.
Platforms are mapped to design space through experiments we conducted.
Mica2
EPC (W)
BSN node v3
TelosB
(50 X 50 X 50)
Form Factor (mm3)

48. Design New Platforms
Obtain the optimal point in the design space solving an optimization problem
Calculate the distance of your platform from the optimal points in terms of evaluation metrics
Choose which one to improve
Problem ???
Design coordinates may not be orthogonal

49. Ad hoc / sensor networks (Ch 8)

50. Mobile Ad Hoc Networks
May need to traverse multiple links to reach a destination

51. Mobile Ad Hoc Networks
Mobility causes route changes

52. Mobile Ad Hoc Networks Formed by wireless hosts which may be mobile
Don’t need a pre-existing infrastructure
ie, don’t need a backbone network, routers, etc.
Routes between nodes potentially contain multiple hops
Why MANET?
Ease, speed of deployment
Decreased dependence on infrastructure
Can use in many scenarios where deployment of a wired network is impractical or impossible
Lots of military applications, but there are others… ,

53. Many Applications Personal area networking Civilian environments
cell phone, laptop, ear phone, wrist watch
Civilian environments
meeting rooms
sports stadiums
groups of boats, small aircraft (wired REALLY impractical!!)
Emergency operations
search-and-rescue
policing and fire fighting
Sensor networks
Groups of sensors embedded in the environment or scattered over a target area

54. Many Variations Fully Symmetric Environment Asymmetric Capabilities
all nodes have identical capabilities and responsibilities
Asymmetric Capabilities
transmission ranges and radios may differ
battery life at different nodes may differ
processing capacity may be different at different nodes
speed of movement different
Asymmetric Responsibilities
only some nodes may route packets
some nodes may act as leaders of nearby nodes (e.g., “cluster head”)

55. Many Variations Traffic characteristics may differ
bandwidth
timeliness constraints
reliability requirements
unicast / broadcast / multicast / geocast
May co-exist (and co-operate) with an infrastructure-based network

56. Many Variations Mobility patterns may be different
people sitting at an airport lounge (little mobility)
taxi cabs (highly mobile)
military movements (mostly clustered?)
personal area network (again, mostly clustered?)
Mobility characteristics
speed
predictability
direction of movement
pattern of movement
uniformity (or lack thereof) of mobility characteristics among different nodes

57. Challenges Limited wireless transmission range
Broadcast nature of the wireless medium
Packet losses due to transmission errors
Environmental issues (“chop that tree!!”)
Mobility-induced route changes
Mobility-induced packet losses
Battery constraints
Potentially frequent network partitions
Ease of snooping on wireless transmissions (security hazard)
Sensor networks: very resource-constrained!

58. Hidden Terminal ProblemC A
Nodes A and C cannot hear each other
Transmissions by nodes A and C can collide at node B
On collision, both transmissions are lost
Nodes A and C are hidden from each other

59. First Issue: Routing Host mobility
Why is Ad hoc Routing Different?
Host mobility
link failure/repair due to mobility may have different characteristics than those due to other causes
traditional routing algorithms assume relatively stable network topology, few router failures
Rate of link failure/repair may be high when nodes move fast
New performance criteria may be used
route stability despite mobility
energy consumption

60. Routing Protocols Proactive protocols Reactive protocols
Determine routes independent of traffic pattern
Traditional routing protocols for wired networks are proactive
Reactive protocols
Discover/maintain routes only if needed

61. Trade-Off: Proactive vs. Reactive
Latency of route discovery
Proactive protocols may have lower latency since routes are maintained at all times
Reactive protocols may have higher latency because a route from X to Y will be found only when X attempts to send to Y
Overhead of route discovery/maintenance
Reactive protocols may have lower overhead since routes are determined only if needed
Proactive protocols can (but not necessarily) result in higher overhead due to continuous route updating
Which approach achieves a better tradeoff depends on the traffic and mobility patterns, but most ad hoc routing protocols are reactive

62. Sensing and Communication Technology

63. Sensing Technology
To be useful, systems must interact with their environment. To do this they use sensors and actuators
Sensors and actuators are examples of transducers
A transducer is a device that converts one physical quantity into another
examples include:
An ECG sensor (digitizes the electrical pulses from the heart)
A microphone (converts sound into an electrical signal).

64. Example Sensors Environmental Sensors Physiological Sensors Thermistor
Light Dependent Resistor (LDR)
Inductive Proximity Sensor
Accelerometer
ECG sensor
PPG sensor
GSR sensor
Glucosemeter

65. Sensor Performance Range Resolution or discrimination Error
maximum and minimum values that can be measured
Resolution or discrimination
smallest discernible change in the measured value
Error
difference between the measured and actual values
random errors
systematic errors
Accuracy, inaccuracy, uncertainty
accuracy is a measure of the maximum expected error

66. Precision vs Accuracy Precision
a measure of the lack of random errors (scatter)

67. Sensor Platform Hardware Software MSP 430 microcontroller
CC2420 radio (ZigBee)
10 KB RAM
256 KB flash
Software
Runs TinyOS
Program using nesC
USB interface to download code

68. Wireless communication
A radio module to implement MAC layer protocols + An antenna to transmit
Two of the most common protocols are ZigBee ( ) and Bluetooth ( )
Both operate on the unlicensed 2.4 GHz ISM band

69. Zigbee Low power mesh networking
IEEE Standard, based on Motorola’s proposal
“Low power”, “Networked”, “Open standard”
Personal Operating Space (POS) of 10m radius, or greater range
Mesh self-healing network

70. Bluetooth Alternatives to cables IEEE 802.15.1 standard (2002)
“Short range” and “Mobile products”
POS of 10m radius, with mobility
Ad-hoc connections between devices

71. But ZigBee is Better Bluetooth is Best IF : For :
The Network is static
Lots of devices
Infrequently used
Small Data Packets
For :
Ad-hoc networks between capable devices
Handsfree audio
Screen graphics, pictures…
File transfer

72. Air Interface: Bluetooth ZigBee
FHSS (Frequency-hopping spread spectrum)
1 M Symbol / second
Peak Information Rate
~720 Kbit/second
ZigBee
DSSS (direct-sequence spread spectrum)
11 chips/ symbol
62.5 K symbols/s
4 Bits/ symbol
Peak Information Rate
~128 Kbit/second

73. ZigBee Protocol Stack Size/Complexity
Application
Application Interface
Network Layer
Data Link Layer
MAC Layer
MAC Layer
PHY Layer
Silicon
ZigBee Stack
Application

74. Bluetooth Protocol Stack Size/Complexity
User Interface
Voice
Intercom
Headset
Cordless
Group Call
vCard
vCal
vNote
vMessage
Networking
Dial-up
Fax
Service
Discovery
Protocol
Telephony
Control
Protocol
OBEX
HOST
RFCOMM
(Serial Port)
L2CAP
Host Control Interface
Link Manager
MODULE
Link Controller
Baseband RF
Silicon
Bluetooth Stack
Applications

75. Timing Considerations
ZigBee:
New slave enumeration = 30ms typically
Sleeping slave changing to active = 15ms typically
Active slave channel access time = 15ms typically
Bluetooth:
New slave enumeration = >3s
Sleeping slave changing to active = 3s typically
Active slave channel access time = 2ms typically
ZigBee protocol is optimized for timing critical applications

76. Power Considerations Bluetooth ZigBee
Power model as a mobile phone (regular charging)
Designed to maximise ad-hoc functionality
ZigBee
2+ years from ‘normal’ batteries
Designed to optimise slave power requirements

77. To reduce latency, Bluetooth would:
The two devices must stay within 60 us (~1/10 of a hop)
30ppm crystals => could increase at 60us per second.
Devices communicate once a second to track each other's clocks.
Possibly could be improved by a factor of 100.
The devices would then need to communicate once every 100 seconds to maintain synchronisation.
=> 900 communications / day with no information transfer
+ perhaps 4 communications on demand
99.5% Battery Power wasted

78. To reduce power consumption, Bluetooth would
Undertake Bluetooth inquiry procedure to find out which part of the spectrum is used
May typically take 10 seconds using Bluetooth 1.1 ?
Much Better In Bluetooth 1.2
possibly reduced to tens of ms BUT
Not all requirements have been adopted yet

79. Conclusion
ZigBee radio using DSSS need only perform CSMA before transmitting, a delay of only 200 us (Radio wake up time)
ZigBee offers longer battery life and lower latency than a Bluetooth equivalent.

80. Two different solutions optimised for different applications…...
Solution Prices
Bluetooth:
Price Now - $10
Price $5
ZigBee:
Price $6
Price $
Two different solutions optimised for different applications…...

81. Conclusion
ZigBee and Bluetooth are two solutions for two application areas

82. Reference