Implementing Context Aware Applications Class 5

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

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

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

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

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

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

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

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 1149.1 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 1149.1 compliant JTAG interface Intel XScale 32 bit processor 256 KB RAM 32 MB ROM 32 MB programmable memory IA 32 Instruction set 13 - 400 MHz clock IEEE 1149.1 compliant JTAG interface

Processors - FPGA

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

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

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

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

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

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

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

Zigbee Low power mesh networking IEEE 802.15.4 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

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

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

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

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 ?

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

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

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

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

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

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

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.

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 =

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 * 10 + 0.95 * 0.1 = 0.595 mW Fraction of time in state S * Power consumed in state S EPC = ∑ all states

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

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

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.

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 = 5.625 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

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

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)

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

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

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

TinyOS Demo Tutorial

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