1. Implementing Context Aware Applications
Class 5

2. Steps to implement CA apps
Context Sensing
Contextual Resource Discovery
Food here at 12 noon
Contextual Adaptation
Contextual Augmentation

3. Example CA application
ECG monitoring
Sample at low rates to save energy
Detection of epilepsy onset
On detection of onset increase sampling rate
End of epilepsy seizure, revert to decreased sampling rate
Contextual Resource Discovery
Context Sensing
Contextual Adaptation
Contextual Augmentation
Sensing ECG
Detection of epilepsy onset
Increase sampling rate
Develop an epilepsy detection algorithm

4. Implementation Strategy
Contextual Sensing – Embedded sensors
Contextual Resource Discovery – Mobile phone (Location Services)
Contextual Adaptation – Context based decision algorithms in mobile devices
Contextual Augmentation – Annotation of events in data bases in a central server.
Contextual Adaptation
Context Sensing
Contextual Resource Discovery
Contextual Augmentation

5. Processing Requirements
Example: Determination of heart rate variability
Ratio of the high frequency to low frequency components of the heart rate variation is considered
Communicate to Mobile Phone
Sampling and storage of signals
Reduce sampling command
Peak Detection
Fast Fourier Transform
Onset of epilepsy

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

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

8. Processor + Communication + Memory
Embedded Sensor
Hardware
MSP 430 microcontroller
CC2420 radio (ZigBee)
10 KB RAM
256 KB flash
Software
Runs TinyOS
Program using nesC
USB interface to download code
Processor + Communication + Memory

9. Processors Atmega 128 8 bit microcontroller 4 KB RAM 4 KB ROM
128 KB programmable memory
133 fixed point single clock cycle execution instructions
16 MHz clock
IEEE compliant JTAG interface
MSP430
16 bit microcontroller
10 KB RAM
256 KB ROM
256 KB programmable memory
16-bit RISC architecture
32 MHz clock
IEEE compliant JTAG interface
Intel XScale
32 bit processor
256 KB RAM
32 MB ROM
32 MB programmable memory
IA 32 Instruction set
MHz clock
IEEE compliant JTAG interface

10. Processors - FPGA

11. FPGA Logic
Consider a matrix of NAND gates with connections between them
You can build an entire CPU using them
Example: Build a XOR circuit

12. Processor vs FPGA General purpose v.s. application specific
FPGAs allow form factor optimization
Hardware reconfiguration possible with FPGAs
Stringent programming paradigm
Develop from scratch

13. Miniaturized chip antenna
Communication
Radio protocol + Antenna
Protocols
ZigBEE – IEEE
Bluetooth – IEEE
Antenna
Miniaturized chip antenna
Bluetooth antenna
Surface mount antenna
Inverted F antenna

14. Physical Layer Electromagnetic Coupling
How to use electromagnetic coupling to transfer information ?
Basic Square Wave
Phase Shift Keying
= 1
= 0
= ?

15. Medium Access Control Layer
Access Policies
Collision avoidance
Wireless Channel (Restricted Bandwidth)

16. Network Layer Packet formation – a data structure Routing Management
Estimation of link quality based on metrics such as received signal strength
Security of transmission
Mesh Network
Master Slave

17. Application Layer Data Payload
Data structures supported
Video, Image, Sensed samples
Software interfaces to invoke a radio transfer
Radio sleep scheduler
Radio power control interface
Link quality estimator

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

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

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

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

22. So many dimensions to design
Application requirements
What is the sampling rate ?
Need to do 256 point FFT
Need to perform correlation of two signals
Need to store 500 seconds of data
………..
Non functional requirements
Lifetime
Low energy
Thermally safe
Reliable
Processor
Which instruction set ?
Clock frequency
How much RAM, ROM, Flash ?
Fixed point or floating point ?
How much power ?
Size ?
Communication
Which radio to use ?
Which antenna ?
What is the range ?
Which communication protocol ?
How much power to input ?
What is the antenna range ?

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

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

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

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

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

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

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

30. 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 =

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

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

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

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

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

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

37. 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)

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

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

40. 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)

41. TinyOS Demo Tutorial

42. Hardware Abstraction Architecture for TinyOS 2.x
Combine the component model with a flexible, three-tier organization of the hardware abstraction
HW platform 2
HPL 2
HAL 2
HIL 2
HW platform 3
HPL 3
HAL 3
HIL 3
HW platform 1
HPL 1
HAL 1
HIL 1
HW platform 4
HPL 4
HAL 4
HIL 4
Platform-specific
applications
Cross-platform applications
Platform-independent hardware interface
HW/SW
boundary
Hardware independence