S. Kang, et al.Computer Science, KAIST

MobiSys 2008

SeeMon: Scalable and Energy-efficient Context Monitoring Framework for Sensor-

rich Mobile Environments

Outline• Introduction

– Bi-directional Approach to Context Monitoring Problem– Implementation and Evaluation

• Related Work• Context Monitoring Framework Overview

– Motivating Environment– Content Monitoring Query– Architecture

• Processing-Efficient CMQ Evaluation– CMQ Translation– CMQ-Index and CMQ-Table– CMQ Evaluation Mechanism– Analysis of Processing and Storage costs

• Energy-Efficient Sensor Control– ESS Problem– ESS Calculation and Sensor Control– Sensor Control Policy

• Implementation– Prototype Hardware– SeeMon Implementation– Application Development

• Experiments– Experimental Setup– Scalability– Energy Efficiency– Processing-Energy Efficiency Tradeoff

• Conclusion

Introduction

• Motivation– Providing proactive services to mobile individuals for ubiquitous applica-

tions• Situational provision of services without user intervention• Requirement of acquiring individuals' contexts

– Different service requirements and preferences for individual users• Ex) system’s level of proactiveness and users’ privacy concerns

– Different types of contexts for applications– Heterogeneous sensors with diverse capabilities– Requirement of future services

• Much broader coverage and higher accuracy in recognized contexts• Continuously processing a large volume of contexts• Supporting a number of concurrent applications

• SeeMon– A scalable and energy-efficient context monitoring framework– Monitoring their contexts continuously– Context monitoring in a sensor-rich environment

• Heavy workloads on personal mobile devices such as PDAs and mobile phones– Limitation in computing and battery power

Introduction

• SeeMon– Effective context monitoring involving numerous sensors and applica-

tions– Supporting multiple applications operating on the device

• Two keys of the proposed framework– Context monitoring for the continuous detection of context changes

• Difference from conventional context recognition for identification of the cur-rent context

• No redundant recognition and notification of the same context– Bi-directional context monitoring

• Feedback path in the protocol• Opportunity to achieve a high degree of efficiency in computation and energy

consumption• Careful reflection of the high-level application requirements such as monitoring

requests and the low-level status of sensor resources• Making a monitoring decision at an earlier stage for saving computational

overhead• Intelligent resource allocation to save energy or increase utilization

Bi-directional Approach to Context Moni-toring

• Conventional context monitoring process

• Bi-directional approach to context monitoring– Removal of unnecessary expensive computation and communication

Bi-directional Approach to Context Moni-toring

• Computational efficiency– Identification of context change at an early stage

• Detection of context change after inferring in conventional way– Avoidance of such costly operation for a high level application query

• Ex) Skipping the costly decision tree logic using feature value changes

• Continuous observation and exploitation of context– Continuously capturing context to notice its changes– Continuity of context in two levels

• Context level • Source or feature data level

– Consecutive readings from a data source change gradually

• Reduction of the processing cost using locality of the feature data

– Effective data updates in context changes– Quick search and evaluation using registered query

Bi-directional Approach to Context Moni-toring

• Using a small subset of sensors for query– Ex) “studying in the library” query

• When the user is not in the library, activity information is not useful• Answering the query using only location information

– Finding the most efficient subset of sensors• A complex problem because of numerous queries and many possible sensors

– Development of a novel method for computing a reduced set of sensors

• Three methods for context monitoring– CMQ (Context Monitoring Query) translation

• Only one translation for each query– Shared and incremental CMQ evaluation

• Maximization of utility of the context continuity– ESS (Essential Sensor Set) selection

• Energy saving and dynamically controlling sensors• NP-complete problem → using practical heuristic algorithm

Implementation and Evaluation

• Prototype implementation– Core components for scalable and energy-efficient context monitoring – Two ubiquitous computing applications using SeeMon– Testing the prototype system on various types of mobile devices– Demonstration of the developed system with an example application,

SympaThings• Enabling interactive objects to sympathize with user’s affective state, in a pub-

lic exhibition

• Experimental results– High level of scalability and energy efficiency of SeeMon– 4.6 times better throughput than an alternative context monitoring

method• Under a workload of 2,100 data samples per second

– Reduction of the number of wireless data transmissions by more than 60%

• While evaluating 4,000 CMQs

Related Work

• Context-aware applications and application-specific systems– Healthcare and medical applications [4][5]– Reminder applications [6]– Activity recognition [7][8]– Mainly utilizing an application-specific context

• Such as location, activity or biomedical information

• Some existing middleware to support context-aware applica-tions

– Hiding the complicated issues related to context-awareness– Running in a centralized server environment [9][10][11]– Running in a distributed environment [12][13]

• Requirement of infrastructural support to deal with sensor data collection and context processing

• Privacy issues of individual users using server– Context-aware middleware for mobile devices [14][15][16]

• Not considering devices with tens/hundreds of BAN/PAN sensors or devices• Not focusing on continuously detecting context changes

Related Work

• MyExperience [41]– Collecting quantitative and qualitative usage data on personal mobile

devices– Using an efficient event-driven architecture of Sensors, Triggers, and Ac-

tions

• Limited battery power – A critical problem in the field of mobile computing– Improvement of energy efficiency by reducing the wireless communica-

tion cost• Delaying the communication based on GPS-based movement prediction [20]• Reducing the Wi-Fi connection establishment and maintenance cost based on a

low-power radio interface [17], a Wi-Fi detector [18], or Wi-Fi network condition estimation [19]

• Energy saving in wireless sensor networks at the physical layer

– MIMO systems [21]– MAC protocols [22]– Routing mechanisms [23]– Integrated solutions optimizing the energy consumption of all radio

states [26]

Related Work

• Continuous query processing in Data Stream Management Systems [38][39][40]

– Supporting query semantics over continuously streaming data and effi-cient processing mechanisms for the queries [40][27]

– Not directly applicable to the context monitoring

Context Monitoring Framework Overview

Motivating Environment

• Rapid advance of device and mobile service technologies– New mobile environment in personal sensor networks and personal con-

text-aware applications

• Diverse sensors and sensor networks in personal areas– Acceleration sensors– Biomedical sensors (e.g., ECG, BVP, GSR, and EMG sensors)– Environment sensors (e.g., temperature, humidity, light sensors, RFIDs,

and GPS)

• Many new personal context-aware applications– Healthcare, personal assistance, dietary monitoring [2]– Interactive art [3], gaming, and education– An important characteristic of these applications

• Monitoring individuals’ context and surroundings• Understanding the user’s activity such as running, walking, or sitting• Near future applications to understand finer movements

– Such as delicate hand motions and individual fingers’ movements

Motivating Environment

• Many new personal context-aware applications– Long-standing context monitoring requests from the applications

• Possibly for 24 hours per day 7 days per week. – Continuously processing a high number of context monitoring requests

Content Monitoring Query

• Context Monitoring Query (CMQ)– An intuitive monitoring query language

• Supporting rich semantics for monitoring a wide range of contexts• Catching changes in users’ context proactively

– CMQ template

• Three conditions of CMQ– Context

• Description of the context of interest• Presentation as a Conjunctive Normal Form (CNF) • Two types of operators: equality (==, !=) and inequality ( ＜ , ≤, ＞ , ≥) oper-

ators– Alarm– Duration

Content Monitoring Query

• Three conditions of CMQ– Context– Alarm

• Determination of delivery of an alarm event to applications• Supporting two types of conditions: T → F and F → T• F → T

– A notification when the state of the context condition changes from false to true

– Duration• Specification of how long a registered CMQ should run• Maintaining a CMQ for the specified duration

Architecture

• SeeMon– A middle-tier framework between personal context aware applications

and a personal sensor network

Architecture

• SeeMon– Providing programming APIs and a run-time environment for applications– Receiving and processing sensor data– Controling the sensors in the personal sensor network– Wireless communication protocols such as ZigBee, Bluetooth, or 6LoW-

PAN

• Direct context monitoring on mobile devices– No server-based context monitoring– Two advantages of mobile device based approach

• Privacy : avoidance of the exposure of private context• Network cost : No continuous mobile networking costs

• Four components of SeeMon– CMQ Processor– Sensor Manager– Application Broker– Sensor Broker

Architecture

• CMQ Processor– Scalable context monitoring– Efficient evaluation of numerous CMQs over a continuous stream of sen-

sor data– Context monitoring by evaluating CMQs over data delivered by the Sen-

sor Broker– Monitoring results are then forwarded to applications

• Sensor Manager – Enabling SeeMon to achieve a high level of energy efficiency– Dynamic control of sensors to avoid unnecessary data transmissions– Finding a minimal set of sensors that is necessary to evaluate all regis-

tered CMQs

• Application Broker– Managing interactions with applications

• Sensor Broker– Dealing with communication with various heterogeneous sensors

Architecture

• Application Broker– Application Interface, Access Controller, and Context Translator– Application Interface

• Providing an interface to applications

– Access Controller • Managing privacy and security parameters

Architecture

• Application Broker– Access Controller

• Managing privacy and security parameters• Providing an appropriate control mechanism for privacy and security• Utilizing an ACL-based approach [37]• Checking whether a requesting application is registered in an access control list

(ACL)– Context Translator

• Translation of a CMQ issued by a permitted application into a feature data-level CMQ

• Translated data-level CMQ is registered with the CMQ Processor

• CMQ Processor– CMQ-Table

• Storing registered CMQs and evaluation results– CMQIndex

• Quick evaluation of context elements for each feature data• Evaluation of a CMQ by state changes in context elements of the CMQ

– Detection of satisfaction of a certain CMQ • → Forwarding an alarm event to corresponding applications

Architecture

• Sensor Broker – Input Handler

• Managing communication with sensors• Receiving data from sensors

– Preprocessor • Removing noise and error from input data• Performing simple computation such as data format conversion

– Feature Generator• Performing complex computation on data from the Preprocessor to derive fea-

ture data– Delivery of derived feature data into the CMQ Processor

• Sensor Manager– ESS Calculator

• Discovering an Essential Sensor Set (ESS) necessary to evaluate CMQs• Identifying unnecessary sensors based on the evaluation results of the CMQ

Processor• Using a practical heuristic solution.

– Sensor Controller• Sending selected sensors control messages

– Reconfiguration the sensors, or stopping data transmission• Performing whenever the result of any CMQ changes

Processing-Efficient CMQ Evaluation

• Too much cost to evaluate all CMQs upon every data arrival

• A novel methods to improve evaluation performance

• CMQ translation into feature data-level queries– Avoiding the expensive context recognition process

• Such as decision tree traversal and Bayesian network evaluation – Reducing processing overhead by pruning out unnecessary context

recognition

• Shared processing method – Efficiently processing a large number of data-level CMQs using a query

index called the CMQ Index– After building the index for all registered CMQs

• Only relevant queries will be searched upon a data arrival– Providing significant performance benefit

• Incremental processing method– Utilizing the locality of feature data streams

Processing-Efficient CMQ Evaluation

• Incremental processing method– Development of a stateful query index for incremental evaluation– Consecutive updates from a data stream with gradual changes– Ex) a query to monitor accleration value with a range [70 < energy < 75]

• Feature values [72, 71, 73, 74] → query (true and unchanged)– Remembering the previous states of all queries– Pre-computing the queries whose states change at each value range– CMQ-Index

• Partitioning domain space of a feature into consecutive range segments• Computing the difference of sets of queries across consecutive segments• Memory efficient because of only storing the differences between queries

• New evaluation by computing union of pre-computed differ-ences

– No complex computations other than the union of differences– Outperforming state-of-the-art query indexing mechanisms [27][28]

• CMQ evaluation approach– Shared and incremental processing based on our previous work [29]– Extension of the work for efficient CMQ evaluation

CMQ Translation

• First step to enable scalable CMQ evaluation

• Converting CMQs into range predicates over continuous fea-ture data

• Avoiding the overhead of continuous context recognition

• Two major steps for translation– Mapping a context type to one or more features

• A feature : data generated via preprocessing and feature extraction from sen-sor data

• Ex) DC and energy features are derived from an accelerometer [7]– Transformation of a context value to numerical ranges for corresponding

features• Ex) (noise == Quiet) → (20dB ≤ sound pressure level ≤ 30dB)

• Maintaining a context translation map for effective CMQ translation

CMQ Translation

• Maintaining a context translation map for effective CMQ translation

• Building context translation map through a machine learning process

– Such as building a C4.5 decision tree [7][24]

• Supporting two types of maps– Generic and customized maps

CMQ Translation

• Supporting two types of maps– Generic map

• Maintaining mapping information generally usable to many applications• Fixed and not modified

– Customized map• Custom mappings between context-level semantics and data-level semantics• Modification and creation by application developers

CMQ-Index and CMQ-Table

• Two important data structures for CMQ Processor– CMQ-Table and CMQ-Index

• CMQ-Table – Storing CMQs using a hash structure, providing O(1) lookup time– Containing three attributes

• Query id, state (evaluation result), and context element list

– Context element• Specification with three attributes: feature id, range condition, and state

CMQ-Index and CMQ-Table

• CMQ-Table – Context element

• Specification with three attributes: feature id, range condition, and state– Feature id

• Indication of a feature associated with the context element– Range condition

• A data value range for the feature– State

• One of three states: true, false and undecided• Undecided states : feature data is unavailable due to dynamic sensor control• Rules for state determination

CMQ-Index and CMQ-Table

• CMQ-Index– A query index to quickly access context elements relevant to incoming

data– Easy identification of context elements within range of data value– RS (Region Segment) list

• A set of RS nodes, partitioning the domain space of feature values• Each RS node including a set of context elements covered by its range• Storing into only two RS nodes (range starts and ends)• Maintaining the value ranges of the context elements for corresponding feature

– Feature table • Maintaining a pointer to the value range of the last data value

• RS list formal definition–

• A set of context elements associated with a feature where has the range –

• Set of lower and upper bounds of the range of each – Minimum and maximum values of domain space, and – Ex)

• RS list : a list of RS nodes,• Each RS node : a tuple

CMQ-Index and CMQ-Table

• RS list formal definition

CMQ-Index and CMQ-Table

• CMQs can be dynamically registered and deregistered. A CMQ Qin is registered as follows. First, an entry for Qin is added to the CMQ-Table. Since the states of Qin and its con-text elements are not determined yet, the CMQ Processor evaluates the states of Qin and context elements through current data values. Then, the CMQ-Index is updated. That is, the CMQ Processor updates the RS lists associated with fea-tures of context elements of Qin. Consider a context element of Qin, CEi, whose range condition is (li, ui). First, the CMQ Processor locates the RS node, Ni, which contains li, i.e., bi–1 ≤ li < bi. If li is equal to bi–1, Qin is inserted into the +DQSeti of Ni. Otherwise, Ni is split into two RS nodes: the left node with the range of (bi–1, li) and the right node with the range of (li, bi). The left node has the ±DQSet of Ni and the right node contains Qin in its +DQSet. Second, the CMQ Processor locates and processes the RS node, Nj containing ui in a simi-lar way. CMQs can be deregistered similarly.

CMQ Evaluation Mechanism

Energy-Efficient Sensor Control

• A novel sensor control method to enhance the energy effi-ciency

• Using only a small number of necessary sensors– Essential Sensor Set (ESS)– Dynamic change of ESS depending on current context and registered

CMQs

ESS Problem

• Calculating ESS– Few sensors as possible to save energy without correct CMQ evaluation

• A false state of a context element in a CMQ → a false state of the CMQ itself• For false-state CMQs, monitoring only a single context element in a false state

– Core of CMQ evaluation → detection whether the states of CMQs change or not

• Two sub-problems of ESS problem– Finding essential sensors for true-state and undecided-state CMQs – Finding essential sensors for false-state CMQs

• Minimum Cost False-query covering Sensor Selection Prob-lem

– MCFSS is NP-complete

ESS Calculation and Sensor Control

• Two steps for ESS computation– Computing sensors for CMQs in a true or undecided state – Computing sensors for CMQs in a false state

• Pre-computation before MCFSS– TQCover

• Sensors required for true-state CMQs– UQCover

• Sensors required for undecided state CMQs

• Greedy-MCFSS– Reducing the energy cost as much as possible while simplifying the com-

putation– Iteratively selection of the most cost-effective sensor until all false-state

CMQs are covered

Sensor Control Policy

• Considering ESS computation overhead– Calculation whenever the evaluation result of any CMQ changes– Frequent ESS computation → burdensome

• Two different policies for sensor control– An aggressive policy

• Maximization of energy saving– A conservative policy

• Reducing processing cost while sacrificing some energy efficiency• Delaying ESS computation to reduce the processing overhead

• Using a metric called the Sensor Turn-on Level (STL)

Implementation

• Implementation of SeeMon architecture prototype– Applying CMQ evaluation and energy-efficient sensor control mechanisms– Building two example applications using SeeMon– Implemented in C++ on a Linux– Application demo called SympaThings at the Nextcom Show 2007 [35]

Prototype Hardware

• Two important hardware sets– Mobile devices and sensors– Two different mobile devices

• (1) an Ultra Mobile PC (UMPC), SONY VAIO UX27LN with Intel® U1500 1.33 GHz CPU and 1GB RAM (powerful future mobile device)

• (2) a custom-designed wearable device with Intel® PXA270 processor 3 and 128MB RAM (a relatively resource-limited current mobile device)

Prototype Hardware

• Sensors used in prototype

Application Development

• Prototype two applications– Running Bomber and SympaThings

• Running Bomber – Reflecting their physical actions from their everyday activities– A player holding a bomb should pass the bomb to others within 3 sec-

onds– Bomb passing is signaled by shaking an arm wearing an acceleration

sensor

• SympaThings– Control of nearby smart objects to sympathize with a person’s affective

context– Red color : the high degree of strain, yellow color : for the low degree of

strain– Using high-rate data from BVP and GSR sensors

Experimental Setup

• Evaluation of the scalability and energy efficiency

• Data collection from the daily activities of a person– A student carried a UMPC with eight sensors for 12 hours in campus

• Eight sensors : a light sensor, a temperature/humidity sensor, three 2-axial ac-celeration sensors, a GPS sensor, and two software sensors for time and indoor location

– Total data rate : 291.74 Hz– Feature generation rate : 68.06 Hz

• CMQ workloads simulation– Different sets of CMQs with four parameters

• the number of CMQs, the number of context elements per CMQ, the distribu-tions of context types and values in context elements

• Constraints for UX27LN UMPC– CPU : 200MHz – Less than 5 MB even with 2,000 registered CMQs

Scalability

• Comparison with context recognition-based monitoring method

– Pre-processing and recognizing all data from sensors– Measurement of the scalability in terms of input data scale from 1 to 7– Data scale k

• the number of sensors and data rate becomes k times larger than the initial sensor setting

Energy Efficiency

• Evaluation of the energy efficiency of SeeMon– Transmission Reduction Ratio (TRR)– Quantifying the amount of reduction in wireless transmission (the main

factor of sensors’ energy consumption [36][25])

Energy Efficiency

• Evaluation of the energy efficiency of SeeMon

• Stat distribution – A common querying pattern in which users are interested in frequently

occurring context values

• Inverse stat distribution– Opposite case

Processing-Energy Efficiency Tradeoff

• A tradeoff between processing efficiency and energy effi-ciency

– A processing efficiency and TRR as an energy efficiency• In terms of varying STL threshold values

• Aggressive policy (threshold 0) – Highest TRR, but lowest throughput

• Increase of STL threshold value– TRR linearly decreases, but the throughput increases

Conclusion

• SeeMon– A scalable and energy-efficient context monitoring framework– Context monitoring for continuous detection of context changes– Applying the bi-directional approach

• High degree of efficiency in computation and energy consumption

• Implementation of the prototype of SeeMon system– Scalable CMQ processing– Energy-efficient sensor control mechanisms