CSE494/598 Mobile Computing Systems and Applications (Fa2011)

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 historyis 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 Altera FPGA Intel Atom Tunnel creek

23. Application driven hardware design

24. Gap between application and hardware Application Designer Hardware Designers • Provide datasheet • Need to improve design based on new, emerging applications • Need to objectively compare performance of multiple platforms • Knows contexts to be sensed • Knows adaptation requirements • Need to map to platform specifications • Need to quantify platform performance 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

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

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

28. Temperature Tele-sensor @ Oak Ridge National Lab Nano-scale Blood Glucose level detector @ UIUC L:ifeshirt @ Vivometrics Pervasive Health Monitoring Applications • 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 Components Used Miniature sensors, gateway device Applications Computer Assisted Rehabilitation Medical Facility Management Sports Health Management Home-based care Diverse types of adaptive applications with various requirements

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

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

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 P1 Set of available platforms P2 P3 P4 Design Coordinates Average Radio Power Consumption Form Factor On-board data memory mW mm3 kB of RAM Metrics BSNBench Datasheet Datasheet Evaluation Method

34. Design Coordinates (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 Based on typical BSN application requirements Decompose platform functionality into individual modules

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

36. Evaluation Metrics [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. • Use suitable metrics to quantify design coordinates: • Some traditional metrics are independent of the target applications. e.g. MIPS, MIPS/W • Consider BSN application characteristicsto develop more suitable metrics. • For example, processor speed measured in units of samples processed per second

37. SPSW Metric for Processor (No. of Samples Processed) SPSW = (Time taken) (Power consumed) • 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 mWpower. Then, SPSW = 1000/(100 X 25) = 400 samples/mJ

38. EPC Metric for Radio Fraction of time in state S * Power consumed in state S EPC = ∑ all states • 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

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 Constraints on Design Coordinates Application Requirements Define subspace of design space 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.

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

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 …. Application 2 (app2) B bpB N1 N2 A IF (PB, tB) Application 1 (app1) (PA, tA) C (1-bpB) NA NB NC A B C (PC, tC) (PC, tC) (PA, tA) (PB, tB) • SPSW characterization • Sensor query task, peak detection, and FFT computation task in BSNBench • Combination of SPSW

45. Constraints and platform mappings Imote2 BSN node v3 TelosB 256 - point FFT Available RAM Mica2 128 – point FFT 0.7 Constraints on signal processing capability and communication reliability (on-body PDR) On-body PDR

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

47. Case Study: CGM iMote2 35.62 mW Mica2 EPC (W) BSN node v3 TelosB (50 X 50 X 50) Form Factor (mm3) Set of platforms: TelosB, Mica2, Imote2 and BSN v3 Constraints on EPC and Form Factor coordinates

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