A Context Provisioning Middleware with Support for ...

Faculty of Environment and Technology University of the West of England

A Context Provisioning Middleware with Support for Evolving Awareness

Michael Knappmeyer

A thesis submitted in partial fulfilment of the requirements of the University of the West of England, Bristol for the degree of

Doctor of Philosophy

March 2012

Dedicated to Karin.

Acknowledgements

Working towards a PhD degree has been one of the most exciting and challenging periods of my life. During this time I have been accompanied by a lot of people who supported me either directly or indirectly. First, I would like to thank my supervisor, Nigel Baker, who provided me the opportunity to conduct research in a deeply interesting field. His encouraging feedback and our inspiring discussions did not only help to advance my study progress but also my personal development. The same applies to my advisor Ralf T¨ onjes. Being the head of the research group for Mobile Communication at the University of Applied Sciences Osnabr¨ uck (UASO) – my employer –, I owe him cordial thanks for making one of my dreams come true and supporting my career by offering freedom for my personal research while sharing his valuable experiences openly. I am thankful for his guidance, the trust and delegated responsibilities that I have been provided. A special thank you is directed to Saad Liaquat Kiani and Eike Steffen Reetz for our productive collaboration and their assistance in every department. In this context, I am very grateful for the possibility to meet kind colleagues and make new friends all over the world during numerous business trips to conferences and project meetings. The last couple of years have significantly broaden my horizon in a way I had not expected before. The research group at UASO provided me a very pleasant environment day after day. I thank my colleagues, i.e. Daniel Brettschneider, Marten Fischer, G¨ unter H¨ udepohl, Thorben Iggena, Rolf Lasch, Daniel K¨ umper and Frank Nordemann, especially for their help in the review process. Finally I would like to thank my fiancée Karin, my parents and my friends for their patience and for believing in me. They helped me to re-align the work life balance in stressful situations.

Abstract

This thesis contributes to the research domain of Ubiquitous and Contextaware Computing. It presents a novel middleware (entitled Context Provisioning Middleware with Support for Evolving Awareness; C-ProMiSE) that applies a consumer-producer role model as architectural basis. The middleware aims at supporting diverse applications and services to easily and coherently acquire relevant context information. A mediating Context Broker facilitates the coordination between distributed Context Provider, Context Source and Context Consumer components. The chosen design principles support self-management capabilities and modular extendibility during run-time. Communication is based on the Representational State Transfer (REST) approach. Context is represented in ContextML, an XML-based modelling schema, enabling a structured generally applicable basis for various context domains, e.g. spatial, temporal, device-specific and user-centric properties. This combination of context management and context representation model allows for gradual and distributed context processing and reasoning. Context is abstracted in various layers from primitive data up to high-level interpretation, e.g. users’ activities. Specific emphasis is put on probabilistic reasoning of data originating from physical, virtual and logical sensors. In addition to the conceptualisation, a specific prototype implementation is presented and utilised as experimentation testbed. Its functional evaluation covers field tests and context emulation. With regard to quantitative evaluation, the C-ProMiSE performance is finally assessed by applying both black-box tests of specific prototype components and Discrete Event Simulation at system level. Focus of the experimentation is to estimate the responsive context provisioning behaviour realistically. The obtained results lend weight to the argument that a consumer-producerbroker based framework can serve as basis to realise a distributed multi-domain context provisioning middleware that does not only scale physically but also functionally with regard to context processing capabilities. Furthermore, the context management, context representation and context processing concepts allow for supporting a variety of emerging and evolving context-aware applications and services.

Table of Contents Table of Contents

iv

List of Figures

vii

List of Tables

ix

Nomenclature

xiii

1 Introduction

1

1.1

Motivation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Research Objectives and Questions . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.4

Thesis Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2 Background and Related Work

6

2.1

Ubiquitous Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Context-Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

Context Modelling & Representation . . . . . . . . . . . . . . . . . . . . . .

9

2.5

Context Management & Provisioning . . . . . . . . . . . . . . . . . . . . . . 12

2.6

2.7

2.5.1

Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.2

Existing Classifications

2.5.3

Architectural Principles . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.4

Technological Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.5

Communication Paradigms . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.6

Overview of Related Frameworks and Middleware . . . . . . . . . . 16

. . . . . . . . . . . . . . . . . . . . . . . . . 13

Context Processing & Reasoning . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6.1

Rule-based Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6.2

Description Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6.3

Probabilistic Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6.4

Other Reasoning Mechanisms . . . . . . . . . . . . . . . . . . . . . . 24

2.6.5

Overview of Reasoning Mechanisms . . . . . . . . . . . . . . . . . . 25

Evaluation of Ubiquitous Middleware . . . . . . . . . . . . . . . . . . . . . . 25 2.7.1

Challenges of Middleware Evaluation . . . . . . . . . . . . . . . . . . 25

2.7.2

Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iv

TABLE OF CONTENTS

2.7.3

Field Trials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7.4

Emulation & Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.7.5

Comparison of Methodologies . . . . . . . . . . . . . . . . . . . . . . 35

3 Research Scope

37

3.1

Research Challenges & Objectives . . . . . . . . . . . . . . . . . . . . . . . 37

3.2

Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3

Scientific Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.1

Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.2

Individual and Collaborative Research . . . . . . . . . . . . . . . . . 41

4 Context Representation & Management of C-ProMiSE

43

4.1

Targets and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2

Context Representation Model . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3

4.4

4.5

4.2.1

Fundamental Context Representation Concept . . . . . . . . . . . . 44

4.2.2

Context Meta Representation . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3

Formal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.4

Implementation of Context Representation . . . . . . . . . . . . . . 45

Context Management Concept . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.1

Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.2

Architectural Management Model

4.3.3

Component Coordination – Middleware Functionalities . . . . . . . . 50

4.3.4

Broker Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

. . . . . . . . . . . . . . . . . . . 48

Implementation Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4.1

Context Broker Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4.2

Implementation of Coordination Messages . . . . . . . . . . . . . . . 60

4.4.3

Context Broker Implementation . . . . . . . . . . . . . . . . . . . . . 61

Summary of Context Representation & Management . . . . . . . . . . . . . 62

5 Context Processing & Reasoning of C-ProMiSE

65

5.1

Objectives and Methodology

5.2

Context Processing and Reasoning Design Issues . . . . . . . . . . . . . . . 65

5.3

. . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1

Layered and Distributed Processing . . . . . . . . . . . . . . . . . . 65

5.2.2

Acquisition and Preprocessing of Sensor Data . . . . . . . . . . . . . 66

5.2.3

Context Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.4

Probabilistic Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . 67

Design and Implementations of Context Providers and Context Sources . . 68 5.3.1

Overview of Implemented Providers and Sources . . . . . . . . . . . 68

5.3.2

Sensor Data Acquisition Processing

5.3.3

Database Centric CxPs and CxSs . . . . . . . . . . . . . . . . . . . . 77

5.3.4

Mid-level Context Processing . . . . . . . . . . . . . . . . . . . . . . 78

5.3.5

High-level Context Processing . . . . . . . . . . . . . . . . . . . . . . 84

v

. . . . . . . . . . . . . . . . . . 70

TABLE OF CONTENTS

5.4

Summary of Context Processing & Reasoning . . . . . . . . . . . . . . . . . 89

6 Evaluation & Experimentation of C-ProMiSE 6.1

Targets and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2

Functional Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.3

6.4

6.5

6.2.1

Prototype Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.2.2

Prototype Applications and Services . . . . . . . . . . . . . . . . . . 93

6.2.3

Context Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.2.4

Results of Functional Evaluation . . . . . . . . . . . . . . . . . . . . 104

Performance Evaluation of Prototype Testbed . . . . . . . . . . . . . . . . . 104 6.3.1

Measurement Methodology and Setup . . . . . . . . . . . . . . . . . 105

6.3.2

Hardware and Software Environment . . . . . . . . . . . . . . . . . . 107

6.3.3

Broker Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.3.4

Provider Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.3.5

Conclusion of Performance Measurements . . . . . . . . . . . . . . . 125

System-level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.1

Simulation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.4.2

Simulation Environment and Terminology . . . . . . . . . . . . . . . 129

6.4.3

Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6.4.4

Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Analysis and Discussion of Evaluation Results . . . . . . . . . . . . . . . . . 144

7 Conclusions

8

91

146

7.1

Summary of Contributions and Findings . . . . . . . . . . . . . . . . . . . . 146

7.2

Future Work Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 7.2.1

Privacy and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

7.2.2

Demand-driven Sensor Data Acquisition and Context Processing . . 149

7.2.3

Systematic Evaluation and Comparable Results . . . . . . . . . . . . 150

7.2.4

Extension of Performance Assessments and Simulation Model . . . . 150

References

151

Appendix

166

A.1 ContextML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 A.1.1 ContextML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 A.1.2 Examples of Context Instances . . . . . . . . . . . . . . . . . . . . . 172 A.1.3 Examples of Coordination Messages . . . . . . . . . . . . . . . . . . 179 A.2 ContextQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 A.2.1 ContextQL Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 A.2.2 Examples of ContextQL messages . . . . . . . . . . . . . . . . . . . 183 A.3 BayesNetworkCxP Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

vi

List of Figures 1.1

Evolution Chain and Origins of Ubiquitous Computing . . . . . . . . . . . .

1

1.2

The Context-aware System Cycle . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1

Middleware Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2

Context Processing Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3

Probabilistic Reasoning Models . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1

Context Representation Schema . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2

3-dimensional Context Feature Space . . . . . . . . . . . . . . . . . . . . . . 46

4.3

Architectural Components, High-level Overview . . . . . . . . . . . . . . . . 48

4.4

Context Provider Functionalities and Interaction . . . . . . . . . . . . . . . 49

4.5

Context Broker Functionalities and Interaction . . . . . . . . . . . . . . . . 51

4.6

ContextML Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7

CxP Advertisement Procedure (Message Sequence Chart) . . . . . . . . . . 53

4.8

Context Query Language (CQL) Schema . . . . . . . . . . . . . . . . . . . . 56

4.9

Scope Dependency Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.10 Message Sequence Chart of basic Proxy Query Mechanism . . . . . . . . . . 58 4.11 Domain Concept of Federated CxB Components (Example) . . . . . . . . . 60 4.12 Selected C-ProMiSE Component Interfaces . . . . . . . . . . . . . . . . . . 61 4.13 ContextML Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.14 Composition of CxB Java Enterprise Application . . . . . . . . . . . . . . . 62 5.1

Context Scopes: A Processing Chain Example . . . . . . . . . . . . . . . . . 68

5.2

Design of Smartphone Context Source . . . . . . . . . . . . . . . . . . . . . 71

5.3

Screenshots of Android-based Smartphone Context Source . . . . . . . . . . 73

5.4

Concepts and Implementation of EnvironmentCxP . . . . . . . . . . . . . . 74

5.5

Membership Functions of Daytime (Example) . . . . . . . . . . . . . . . . . 76

5.6

Concept and Implementation of UserProfileCxP . . . . . . . . . . . . . . . . 78

5.7

Design and Implementation of Place Context Provider . . . . . . . . . . . . 81

5.8

Screenshot of Place Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.9

Interface Design of GroupCxP . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.10 Interface Design of BayesNetworkCxP . . . . . . . . . . . . . . . . . . . . . 86 5.11 XML Bayes Net Meta Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.12 Bayesian Network Model for Activity Inference . . . . . . . . . . . . . . . . 88

vii

LIST OF FIGURES

6.1

Prototype Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2

Deployment of C-ProMiSE components on physical network servers . . . . . 94

6.3

Screenshots of Campus Positioning System . . . . . . . . . . . . . . . . . . 96

6.4

Screenshot of UserTracer – Map Overview . . . . . . . . . . . . . . . . . . . 97

6.5

Concept Overview of Communication Engine . . . . . . . . . . . . . . . . . 97

6.6

Group Catcher Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.7

Screenshots of the Android GroupCatcher Application . . . . . . . . . . . . 98

6.8

Chronological Sequence of Installations according to Android Market . . . . 101

6.9

C-ProMiSE Context Emulation Concept . . . . . . . . . . . . . . . . . . . . 102

6.10 Screenshots of the C-ProMiSE Context Emulation Components . . . . . . . 103 6.11 Measurement Setup – Assessment of Prototype Components . . . . . . . . . 107 6.12 Activity Diagram of PACS – Evaluation Use Case: CxB Update Cache . . . 109 6.13 Measured Median Response Time of the CxB Update Cache Functionality . 110 6.14 Frequency of Measured Response Times of CxB Update Cache Functionality112 6.15 Activity Diagram of PACS – Evaluation Use Case: CxB Query Cache . . . 113 6.16 Measured Median Response Times of the CxB Query Cache Functionality (simple query model) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.17 Measured Frequency of Response Times of the CxB Query Cache Functionality (simple query model) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.18 Measured Median Response Times of the CxB Query Cache Functionality (advanced query model) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.19 Measured Frequency of Response Times of the CxB Query Cache Functionality (advanced query model) . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.20 Measurement Setup – Assessment of Publish/Subscribe Functionality . . . . 119 6.21 Measured Frequency of Notification Arrival Delay of the CxB Publish/ Subscribe Functionality

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.22 Measured Frequency of Query Response Delay of Web-based CxPs . . . . . 122 6.23 Measured Median Response Delay of Processing-intensive CxPs . . . . . . . 123 6.24 Measured Median Response Times of the User Profile CxP . . . . . . . . . 123 6.25 Measured Frequency of Query Response Delay of Database-centred CxPs . 124 6.26 Measured Frequency of Query Response Delay of Processing-intensive CxPs 126 6.27 Measured Median Response Delay of Processing-intensive CxPs . . . . . . . 127 6.28 Categories of Systems and Models used for Evaluation . . . . . . . . . . . . 129 6.29 Overview of the C-ProMiSE Simulation Model . . . . . . . . . . . . . . . . 131 6.30 CxC Simulation Module – UML State Diagram . . . . . . . . . . . . . . . . 133 6.31 Probability Density Functions of CxC Default Distributions . . . . . . . . . 134 6.32 CxP Simulation Module – UML Activity Diagram . . . . . . . . . . . . . . 136 6.33 Empirical and Measured CxP Processing Time . . . . . . . . . . . . . . . . 137 6.34 CxB Simulation Module – OMNeT++ Screenshot . . . . . . . . . . . . . . 139 6.35 Simulation Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.36 Simulated Effect of Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

viii

List of Tables 2.1

Context Management & Provisioning Frameworks

. . . . . . . . . . . . . . 19

2.2

Context Processing & Reasoning Approaches . . . . . . . . . . . . . . . . . 25

2.3

Overview of Evaluation Strategies

3.1

List of Scientific Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1

ContextML Response Status Codes and Messages . . . . . . . . . . . . . . . 62

5.1

Details of Context Scopes shown in Figure 5.1 . . . . . . . . . . . . . . . . . 69

6.1

Context-aware Prototype Applications/Services . . . . . . . . . . . . . . . . 94

6.2

Characteristics of Prototype Applications and Services . . . . . . . . . . . . 100

6.3

Hardware Configuration for Prototype Measurements . . . . . . . . . . . . . 108

6.4

Software Configuration for Prototype Measurements . . . . . . . . . . . . . 108

6.5

Notification Arrival Delay of Publish/Subscribe Functionality . . . . . . . . 119

6.6

Query Response Times of Web Service based Context Providers . . . . . . . 121

6.7

Query Response Times of Database-centred Context Providers . . . . . . . 125

6.8

Query Response Times of Processing-intensive Context Providers . . . . . . 125

6.9

Default Parameters of CxP Simulation Modules . . . . . . . . . . . . . . . . 138

. . . . . . . . . . . . . . . . . . . . . . . 36

6.10 Default Parameters of CxP Processing Delay Distributions . . . . . . . . . . 138 6.11 Default Parameters of CxS Simulation Modules . . . . . . . . . . . . . . . . 139 6.12 Overview of Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . 142 6.13 Overview of Simulation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 144

ix

Nomenclature Abbreviations and Acronyms 3G . . . . . . . . . . . . . . . . Third Generation 3GPP . . . . . . . . . . . . . Third Generation Partnership Project ab . . . . . . . . . . . . . . . . . Apache Benchmark ACK . . . . . . . . . . . . . . Acknowledgement (ContextML message type) API . . . . . . . . . . . . . . . Application Programming Interface BN . . . . . . . . . . . . . . . . Bayesian Network C-ProMiSE . . . . . . . . Context Provisioning Middleware with Support for Evolving Awareness CA-SOA . . . . . . . . . . . Context-aware Service Oriented Architecture CASS . . . . . . . . . . . . . . Context Awareness Sub-Structure CDF . . . . . . . . . . . . . . . Cumulative Distribution Function CoBra . . . . . . . . . . . . . Context Broker Architecture ContextML . . . . . . . . Context Meta Language CORBA . . . . . . . . . . . Common Object Request Broker Architecture CoSWAMI . . . . . . . . . Interface-Aware Context Gathering in Ambient Intelligence Environments CPU . . . . . . . . . . . . . . . Central Processing Unit CQL . . . . . . . . . . . . . . . Context Query Language CRF . . . . . . . . . . . . . . . Conditional Random Fields CSV . . . . . . . . . . . . . . . Comma Separated Values Ctx . . . . . . . . . . . . . . . . Context CxB . . . . . . . . . . . . . . . Context Broker CxC . . . . . . . . . . . . . . . Context Consumer CxP . . . . . . . . . . . . . . . Context Provider CxS . . . . . . . . . . . . . . . Context Source DBN . . . . . . . . . . . . . . Dynamic Belief Networks DIMM . . . . . . . . . . . . . Dual Inline Memory Module DL . . . . . . . . . . . . . . . . Description Logic DNS . . . . . . . . . . . . . . . Domain Name System EAR . . . . . . . . . . . . . . (Java) Enterprise Application Archive EJB . . . . . . . . . . . . . . . (Java) Enterprise Java Beans ERM . . . . . . . . . . . . . . Entity Relationship Model ESM . . . . . . . . . . . . . . . Experience Sampling Method FSB . . . . . . . . . . . . . . . Front Side Bus x

NOMENCLATURE

FSM . . . . . . . . . . . . . . . Finite State Machine GPS . . . . . . . . . . . . . . . Global Positioning System GUI . . . . . . . . . . . . . . . Graphical User Interface HCI . . . . . . . . . . . . . . . Human Computer Interaction HMM . . . . . . . . . . . . . . Hidden Markov Model HTTP . . . . . . . . . . . . . Hypertext Transfer Protocol ICMP . . . . . . . . . . . . . Internet Control Message Protocol ID . . . . . . . . . . . . . . . . . Identifier IDE . . . . . . . . . . . . . . . Integrated Development Environment IDL . . . . . . . . . . . . . . . Interface Description Language IEEE . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers IETF . . . . . . . . . . . . . . Internet Engineering Task Force IP . . . . . . . . . . . . . . . . . Internet Protocol ITS . . . . . . . . . . . . . . . . Inverse Transform Sampling JADE . . . . . . . . . . . . . Java Agent DEvelopment Framework JavaEE . . . . . . . . . . . . Java Enterprise Edition JCAF . . . . . . . . . . . . . Java Context Awareness Framework JDBC . . . . . . . . . . . . . Java DataBase Connectivity JDT . . . . . . . . . . . . . . . Joint Probability Distribution Table JPA . . . . . . . . . . . . . . . Java Persistence API JSF . . . . . . . . . . . . . . . Java Server Faces JSON . . . . . . . . . . . . . . JavaScript Object Notation LDS . . . . . . . . . . . . . . . Linear Dynamical Systems LSA . . . . . . . . . . . . . . . Lag Sequential Analysis LTE . . . . . . . . . . . . . . . Long Term Evolution MAS . . . . . . . . . . . . . . Multiagent Systems MNO . . . . . . . . . . . . . . Mobile Network Operator MQTT . . . . . . . . . . . . MQ Telemetry Transport MSrch . . . . . . . . . . . . . Mobile Search (OMA group) MVC . . . . . . . . . . . . . . Model View Controller NACK . . . . . . . . . . . . . Negative Acknowledgement (ContextML message type) NAT . . . . . . . . . . . . . . . Network Address Translation NB . . . . . . . . . . . . . . . . Na¨ıve Bayes NGSI . . . . . . . . . . . . . . Next Generation Service Interface (OMA group) OMA . . . . . . . . . . . . . . Open Mobile Alliance OMG . . . . . . . . . . . . . . Object Management Group ORB . . . . . . . . . . . . . . Object Request Broker OSGI . . . . . . . . . . . . . . Open Services Gateway Initiative OSI . . . . . . . . . . . . . . . . Open Systems Interconnection OSM . . . . . . . . . . . . . . Open Street Map OWL . . . . . . . . . . . . . . Web Ontology Language

xi

NOMENCLATURE

P2P . . . . . . . . . . . . . . . Peer-to-Peer PDA . . . . . . . . . . . . . . Personal Digital Assistant PDF . . . . . . . . . . . . . . . Probability Density Function QoC . . . . . . . . . . . . . . . Quality of Context QoS . . . . . . . . . . . . . . . Quality of Service RDF . . . . . . . . . . . . . . . Resource Description Framework RDF-S . . . . . . . . . . . . Resource Description Framework-Schema REST . . . . . . . . . . . . . Representational State Transfer RFC . . . . . . . . . . . . . . . Request for Comments RMI . . . . . . . . . . . . . . . Java Remote Method Invocation RPC . . . . . . . . . . . . . . . Remote Procedure Call RPM . . . . . . . . . . . . . . Rounds Per Minute RSE . . . . . . . . . . . . . . . Residual Standard Error RSSI . . . . . . . . . . . . . . Received Signal Strength Indication SATA . . . . . . . . . . . . . Serial Advanced Technology Attachment SDK . . . . . . . . . . . . . . . Software Development Kit SMTP . . . . . . . . . . . . . Simple Mail Transfer Protocol SOAP . . . . . . . . . . . . . Simple Object Access Protocol SOCAM . . . . . . . . . . . Service-Oriented Context-Aware Middleware SQL . . . . . . . . . . . . . . . Structured Query Language SSL . . . . . . . . . . . . . . . Secure Socket Layer SUT . . . . . . . . . . . . . . . System Under Test TCP . . . . . . . . . . . . . . . Transmission Control Protocol UbiComp . . . . . . . . . . Ubiquitous Computing W3C . . . . . . . . . . . . . . World Wide Web Consortium WAR . . . . . . . . . . . . . . (Java) Web Archive WLAN . . . . . . . . . . . . Wireless Local Area Network WSDL . . . . . . . . . . . . . Web Services Description Language WSN . . . . . . . . . . . . . . Wireless Sensor Node XML . . . . . . . . . . . . . . Extensible Meta Language XMLBIF . . . . . . . . . . XML-based Interchange Format for Bayesian Networks Notations used in Equations ∆tQ . . . . . . . . . . . . . . . Mean time between two consecutive context queries λ . . . . . . . . . . . . . . . . . . Inter-arrival rate of poisson process θ . . . . . . . . . . . . . . . . . . Screw of Zipf distribution CE,t . . . . . . . . . . . . . . . Set of context data of entity E at time t e = (vi , vj , wi,j ) ∈ E Graph edge connecting vertex vi and vertex vj and having weight w ei . . . . . . . . . . . . . . . . . . Unique entity identifier Ei,j . . . . . . . . . . . . . . . . Entity with unique identifier i and of type j etype . . . . . . . . . . . . . . . Entity type G = (V, E) . . . . . . . . . General graph notation; graph consists of edges E and vertices V

xii

NOMENCLATURE

pexp (x) . . . . . . . . . . . . Exponential Distribution of Variable x puni (x) . . . . . . . . . . . . Uniform Distribution of Variable x pzipf (k) . . . . . . . . . . . . Zipf Distribution of Variable k Sj,t . . . . . . . . . . . . . . . . Set of context parameters belonging to scope j at time t proc wi,j ∈ R>0 . . . . . . . Graph Weight: context processing time qocGain wi,j ∈ (0, 1] . . . . Graph Weight: quality of context gain req wi,j ∈ {0, 1} . . . . . . . Graph Weight: mandatory or optional dependency between two con-

text scopes

xiii

1 Introduction This chapter motivates the conducted research by briefly introducing its background and discussing open issues; concrete research questions are formulated. It finally develops and presents the methodology to be followed throughout the rest of the thesis.

1.1 Motivation Ubiquitous Computing (UbiComp) paraphrases the paradigm of hardware and software components being transparently interwoven by means of wireless communication. Value added computer intelligence does not originate from a single device but results from the smart and autonomous networking of multiple devices. A key objective of these systems is to significantly simplify Human Computer Interaction (HCI) by deploying sensors, processors and actuators in the fabric of everyday life, such that their presence and complexity is hidden from users [Weiser, 1995]. UbiComp is commonly understood as the third wave of an evolution chain having its roots in distributed computing (first wave) and comprising mobile computing (second wave), cp. Figure 1.1 [Strang and Linnhoff-Popien, 2004]. Context-Awareness is one of the key enablers to facilitate proactive support of users in their current situation. Users do not have to define their situation explicitly by utilising time consuming and counter-intuitive input devices but it is implicitly recognised by the “smart” environment instead.

+

Mobile Computing

+

Ubiquitous Computing

Mo

Sm art

Co n te A xt-A Se d-hoc ware nso n rs & Netwo ess De rks v ic es

bile Mo b I Ad nform ile Ne ap t a ive tion A twork s Ap plic ccess atio ns

Distributed Computing

Figure 1.1: Evolution Chain and Origins of Ubiquitous Computing (adapted from Strang and Linnhoff-Popien [2004]) User identity and location are the most prominent context parameters widely utilised in various location-based services. Beyond that, as defined by Dey [2001], context may comprise any information relevant for describing the users’ interaction with each other and with context-aware services and applications. In our digital world there is a large amount of distributed information available describing such interaction in a diverse way. To fully exploit awareness, context has to be acquired from heterogeneous sources, be processed

1

1. Introduction

and aggregated, as well as associated to users, devices and smart artefacts. Finally, it needs to be made available for any service, application or actuator that intends to assist users. Context-Awareness is an interdisciplinary field of research involving communication engineering and computer science, more precisely mobile communication, HCI design, sensor data processing, feature extraction and artificial intelligence. In these communities a large set of application domains benefiting from contextual awareness has been proposed. Use cases of high potential include health care and well-being [Helal et al., 2003; Kara and Dragoi, 2007; Varshney, 2007], e-learning and campus life [Huang et al., 2008; Wu et al., 2008], tourism and travelling [Choi et al., 2007], office and other business applications [Chen et al., 2004; Mikic et al., 2002], advertising and e-commerce [Kurkovsky and Harihar, 2006; Simoes and Magedanz, 2010; Xu et al., 2008], entertainment [Adams et al., 2006], gaming [Bj¨ ork et al., 2002] and social community applications [Gupta et al., 2007]. Moreover, smart places – an emerging research field in itself – heavily rely on contextawareness. A smart place is a geographically bounded area providing smart interaction between computational devices and users located in the space. Smart offices, smart labs and smart homes are examples [Cook and Das, 2005]. Context is not only to be fetched from physical sensors but also from virtual and logical sensors, e.g. from databases or web services. This diversity and general applicability of context-awareness substantiate the need for architectural and functional support of ubiquitous services. Albeit the modelling and processing of context depends on the targeted application domain, the contribution described in this thesis aims at developing a middleware allowing applications, services and actuators to coherently access manifold context information. The middleware has to provide both context management and context processing functionalities. Coordination, communication and fusion of context are to be separated from the application/service logic. In addition, current trends and innovations facilitate rapid development and deployment of new (smartphone) applications and services through the use of Service Creation Environments and specific Software Development Kits (SDK). Their context demands are unexpected and not easily predictable. The support of both existing context-aware applications/services and those emerging in the future requires functional scalability and gradual extendibility of the middleware with regard to new context and new context processing capabilities. With their increasing processing, storage and communication capabilities smartphones can be considered as personalised companion for interfacing the digital world. Focussing on them as main source of interaction allows for increasing the physical size of a smart space to urban or even global extent. Therefore physical scalability is another prerequisite of the middleware. A context-aware system typically follows the autonomic communication cycle depicted in Figure 1.2. The middleware presented in this thesis focuses on the collection, analysis/aggregation and provisioning of context. Decision taking will not be covered, whilst actuation and adaptation will be briefly addressed and utilised in the evaluation.

2

1. Introduction

Logical Sensors

Virtual Sensors

Physical Sensors

Mobile Device Actuation

User Profiles

Probabilistic Reasoning

Collect

Environment Actuation Adapt Context Collection

Act & Adapt

Analyse & Aggregate Decide

Adapt Context Detection

Feature Extraction

Logic Reasoning Activity Recognition Goal Recognition Situation Calculus

Risk Analysis

Hypothesis generation

Decision Theory

Figure 1.2: The Context-aware System Cycle (adapted from Dobson et al. [2006]). Dotted arrows and boxes refer to functionalities that are out of scope of this thesis.

1.2 Research Objectives and Questions Despite significant research progress in the last two decades, the support and realisation of context-aware services and applications is still a challenging endeavour. Most related work focuses on a particular application domain and on a very narrow set of context parameters. Collecting and fusing manifold context data with a single middleware is essential to support a variety of application domains and across a large geographical space. This thesis aims at developing a Context Provisioning Middleware with Support for Evolving Awareness (C-ProMiSE). The middleware facilitates the collection of manifold context from diverse sources, its aggregation and provisioning to context-aware services, applications and actuators. Special emphasis is put on gradual extendibility, with functional scalability supported by utilising self-management capabilities and allocating subtasks to distributed components. As highlighted by Bettini et al. [2010] there is urgent need to support the development of evolvable context-aware applications and maintenance of common context information and its management and processing needs to be outsourced for increasing re-usability. The middleware concept comprises three different scientific contributions: (1) the development of an architectural framework for context management, (2) an adequate context modelling and representation scheme and (3) support for distributed context processing and reasoning. The following major research questions are addressed: • The number of context sources and sinks can be safely estimated to increase tremendously in the near future. This applies not only to physical sensors embedded in the environment or in smart devices but also to virtual sensors. Advancements and inno3

1. Introduction

vations in the digital information society will allow for acquisition of useful context from diverse web services. Which architectural design model can serve as basis for a physically scalable context management? How can sensor heterogeneity be hidden from and access be facilitated for context-aware applications and services? How can functional, spatial and temporal decoupling be supported? • Rapid development of new context-aware applications results in new context demands. Mobile devices are typically constrained as far as processing, memory and battery consumption are concerned. Which context modelling scheme allows for extendibility and addition of new context types? How can primitive and high-level context be modelled? Which scheme is able to be processed on mobile devices? • Context fusion and reasoning mechanisms allow to infer users’ high-level situations. Their applicability depends on the target context. How can resource intense reasoning be distributed amongst several components? How can architectural support for gradual extendibility with regard to the incorporation of context processing techniques be supported? • The evaluation of a context provisioning framework or middleware is challenging due to the complexity, variety and distribution of functional logic. Which evaluation methodology can be applied to cover both functional (i.e. qualitative) and performance (i.e. quantitative) assessment of context provisioning middleware? A more detailed analysis of the research objectives is conducted in chapter 3.

1.3 Research Methodology The chosen research methodology comprises a scientific experiment as well as qualitative and quantitative analysis. This approach classically covers an observation, modelling, analysis and evaluation phase. The research is initialised and driven by a problem identification based on revisiting related work and identifying limitations in current systems. The hypothesis and specific research questions are then defined in the observation phase. Afterwards, in the modelling phase, the requirements of the middleware are defined and taken into consideration when modelling the management and representation of context. The analysis of these models necessitates an adequate experiment design, in this specific case, the derivation of an evaluation methodology. Therefore, realistic parameters and meaningful metrics have to be determined before the experiment can be conducted and analysed. Finally, the evaluation phase comprises the interpretation of the results gained in the analysis phase and drawing the conclusions.

4

1. Introduction

1.4 Thesis Organisation The remainder of this thesis is structured according to the chosen methodology. In chapter 2 related work is reviewed, mainly based on journal and high quality conference publications. The limitations of existing approaches and systems are thoroughly discussed and required extensions proposed. Surveys are mainly driven by classifying concurring solutions and rating them with regard to the identified targets. Furthermore, fundamental terminology is defined to provide a common understanding. Chapter 3 presents a more detailed specification of addressed research objectives after having conveyed the required background knowledge. The main scientific contribution is split into chapters 4 and 5. Chapter 4 presents the developed context modelling and representation scheme as well as the architectural middleware design. The coordination and communication flows are presented for each high-level middleware functionality. Context processing and reasoning are addressed in chapter 5. Fundamental deliberations of distributing the processing amongst several network components are explained before applying high-level reasoning for activity recognition. Moreover, an approach of feedback-based learning is presented. Both chapters finally present specific implementation details of the theoretic concepts and models. Since the evaluation of context-aware functionality (chapter 6) is a complex challenge in itself, the middleware assessment comprises two major elements. In section 6.2 the middleware is evaluated functionally and qualitatively by presenting applications and services utilising the middleware. Sections 6.3 and 6.4 concentrate on performance evaluation by measuring prototype components and emulating/simulating at system level. Finally, chapter 7 summarises and concludes both the developed concepts and their evaluation.

5

2 Background and Related Work The purpose of this chapter is to describe previous work in the field of context-aware and ubiquitous computing. Background knowledge and terminology required for the understanding of the subsequent chapters are introduced.

2.1 Ubiquitous Computing Ubiquitous Computing (UbiComp) evolved from mobile communication and relies on context-awareness as one of its key features. The term has been shaped by Mark Weiser [1995]. Weiser’s vision encompasses a new view and a paradigm shift with regard to the interaction of human beings with computational resources distributed pervasively across the environment and becoming part of the fabric of everyday life. Interaction includes both novel input mechanisms (e.g. gesture recognition based on accelerometers) and output devices (displays embedded in furniture). The use of processing resources is facilitated and refreshing as a “walk in the woods” [Weiser, 1995]. Computers are pushed into the background. Ambient intelligence [Aarts et al., 2001] arises from interweaving small embedded devices by means of mostly wireless communication. Overall, the human computer interaction is simplified by autonomous adaptation to users’ situation and demands – and not vice versa. UbiComp systems aid in overcoming the problem of information overload. When introduced these UbiComp concepts appeared as a science fictional long-term target. However, due to the intermediate technological progress in increased processing, sensing, memory and communication capabilities, the vision has already become true to a certain extent. The size of handheld devices, environmental sensors and smart-its1 decreased continuously due to the advancements in solid-state technology. Numerous protocols and radio access technologies have been developed for supporting wireless communication in various ranges (e.g. WiFi, IEEE 802.11; Zigbee, IEEE 802.15.4; Bluetooth, IEEE 802.15.1; 3GPP 3G/LTE). Today, smartphones, wireless sensors and networked desktop computers can easily be interwoven by always-on connectivity. However, there are a number of barriers to be overcome before truly context-aware applications and services can be deployed and made widely available.

1

A smart-it refers to an object, e.g. a tea cup or a chair, that is equipped with sensing and processing capabilities. It autonomously interacts with its surrounding by means of wireless communication [Gellersen, 2005].

6

2. Background and Related Work

2.2 Context According to Dey context can be any information that can be used to characterise the situation of an entity (person, place, physical or computational object) that is considered relevant to the interaction between entity and application [Dey, 2000, 2001]. This definition is by far the most cited in the literature. Zimmermann proposes five fundamental categories of context information: time, location, activity, relations and individuality [Zimmermann, 2007]. Regarding the definition of a situation in context-aware systems, different views exist in the research community. Zimmermann defines it as “the state of a context at a certain point (or region) in space at a certain point (or interval) in time, identified by a name”. Being a structured representation of a part of the context it can be compared to a snapshot taken by a camera. Location and time can be used as spatio-temporal coordinates. In his view context information is in general composed of the categories: entity, activity, location, time, individuality and relations. Giunchiglia follows a more philosophical approach and sees context as a “subset of the complete state of an individual that is used for reasoning about a given goal” [Giunchiglia, 1993]. Situation is then “the complete state of the universe at an instant of time”. With regard to situation-awareness Billings [1995] defines a situation as “an abstraction that exists within our minds, describing phenomena that we observe in humans performing work in a rich and usually dynamic environment”. In conclusion, a situation may contain an infinite variety of contextual information. Context can be classified into the following incomplete list of elements: • Spatial context: information about the location, e.g. absolute geographic coordinates, relative physical proximity (distance), street, city, main business of places in proximity (e.g. shopping mall, university campus); • Temporal context: information about the absolute time, relative time, day time (e.g. morning, afternoon, evening), weekend vs. business day, season; • Device context: information about the users’ interaction device(s), i.e. processing capabilities, input sensors, visualisation capabilities (e.g. supported codecs, screen size); • Network and communication context: information about network characteristics, e.g. WiFi access points in proximity, available bandwidth and throughput, delay, transmission costs, supported Quality of Service (QoS) class; • Environmental context: information referring to the physical environment of an entity, e.g. noise level, air pressure, light intensity, pollution; • Individuality and user profile context: information about the preferences, interests and habits associated to uniquely identified users; • Activity context: information about what an entity does, which task it is currently involved in and what it intends to do next; 7


• Mental context: information about internal states of mind, e.g. a user’s feelings and mood, level of stress; • Interaction context: interaction may comprise both social interaction between several users and interaction between users and an application or service. Interestingly, some of these context categories are directly or indirectly related to each other. For instance, the spatial context influences the temporal context since time of day directly depend on the current time zone. Please also note the various abstraction levels within most of the presented context types. Some of the context elements associate information to any type of entity (user, device, room) whereas other elements are only applicable to selected sets of entities. Location, identity, time and activity are considered being the most important [Dey, 2000]. In the scope of this thesis context is defined as follows.

Definition 2.1 (Context) Context may be any information providing knowledge and characteristics about an entity (a user, an application/service, a device, or a spatially bound smart place) which is relevant for the interaction between the entities themselves and with the digital world. Context can be categorised as being static, dynamic and rapidly changing. Low-level and primitive context refer to context that can be directly acquired from sensors, e.g. geographic coordinates acquired from GPS sensors. Mid-level and high-level context require further aggregation and abstraction functionalities.

This generic definition supports a wide range of context-aware services and applications as explained below.

2.3 Context-Awareness The ability of a service, application or actuator to adapt to a specific context is referred to as context-awareness. Given the classification of context types (cp. section 2.2), awareness can be categorised accordingly to define the specific focus, e.g. locationawareness, network-awareness. The term context-awareness was first introduced by Schilit and Theimer [1994]. Typically, a context-aware system follows the autonomic communication feedback loop presented in Figure 1.2 and comprises the following tasks [Burghardt and Kirste, 2007; Dobson et al., 2006; Zimmermann, 2007]: 1. Perception/Acquisition, i.e. collection of relevant data allowing conclusion to the context; 2. Reasoning/Inference, i.e. deduce more meaningful information from the raw data;

8


3. Learning from historic context information and actions; 4. Context Representation, i.e. representation and modelling of context information in a machine interpretable way; 5. Management and Diffusion of context information; 6. Actuation, i.e. Triggering/Adapting the service execution or application behaviour based on the available context information. Moreover, three different categories of adaptation can be identified [Dey, 2000]: 1. presentation of information and services to a user, i.e. information is filtered and services are selected based on users’ context; 2. automatic execution of a service and adaptation of an actuator, i.e. the service execution logic and actuation behaviour depend on users’ context; 3. tagging of context to information, i.e. context is associated to information in order to retrieve it more easily later on. In order to take various levels of complexity into account the following definition of context-awareness is proposed.

Definition 2.2 (Context Awareness) The adaptive behaviour of services, applications and actuators according to the detected context depends on the degree of consciousness and context complexity. It can be subdivided into three different stages: Context-based adaptation refers to applications querying context on-demand synchronously and changing the execution based on current context parameters. Context-aware adaptation requires an event-based asynchronous context diffusion in order to allow the execution logic to adapt on sensed and propagated events of interest. Situation-aware adaptation is more complex and requires (primitive) context to be further aggregated and high-level context to be inferred.

2.4 Context Modelling & Representation Context Modelling techniques and requirements have been surveyed by Strang and LinnhoffPopien [2004] and Bettini et al. [2010]. Context information needs to be represented and modelled for being machine interpretable and exchangeable using well-defined interfaces. The goals are to support easy manipulation (low overhead in keeping the model up-todate), easy extension (cheap and simple mechanism for adding new types of information), efficient search and query access as well as scalability. In the literature different approaches 9


for representing contextual knowledge and semantic information can be found. On the one hand the representation is tightly coupled to the inference mechanism, e.g. probabilistic logic requires the modelling of probabilities. On the other hand the representation is often tailored to the problem domain and to the specific goal of the system. Strang and Linnhoff-Popien [2004] identify generic requirements: The modelling approach should (1) be able to cope with high dynamics and distributed processing and composition, (2) allow for partial validation independently of complex interrelationships, (3) enable rich expressiveness and formalism for a shared understanding, (4) indicate richness and quality of information, (5) must not assume completeness and unambiguousness, (6) be applicable to existing infrastructures and frameworks. Context models can be classified into six different model categories, namely key-value models, markup scheme models, graphical models, object oriented models, logic based models and ontology based models [Baldauf et al., 2007]. Key-value pairs form a simple tuple of information. The context information is assigned to a unique key in order to allow for easy lookup by applying a matching algorithm. These pairs are easy to manage but lack structuring and therefore do not allow for efficient context retrieval. Markup scheme models incorporate a hierarchical data structure of markup tags, attributes and content. Well known examples are the User Agent Profile and the Composite Capabilities/Preference Profile1 based on XML (Extendible Markup Language) and standardised by the World Wide Web Consortium (W3C). Graphical models (e.g. based on the Unified Modelling Language) allow for a picturesque description of a context model [Sheng and Benatallah, 2005] and for deriving an Entity Relationship model as required in rational databases. An extension is proposed by Henricksen and Indulska [2004a], introducing Object-Role Modelling (ORM). Object oriented models offer powerful capabilities of inheritance, reusability and encapsulation. Access of contextual information is provided by well defined interfaces [Hofer et al., 2003]. Logic based models offer a high degree of formalism and typically comprise facts, expressions and rules. They enable formal inference, e.g. by means of general probability logic, description logic, functional logic or first-order predicate logic. Ontological modelling refers to an abstract conceptual vision of the world. The relations within could also be described by object oriented methods. However, an ontology is commonly described by using languages standardised by the W3C in the context of the semantic web. Most relevant are the Resource Description Framework Schema (RDF-S)2 and the Web Ontology Language (OWL)3 . Korpip¨ a¨ a and M¨ antyj¨ arvi [2003] enumerate the following goals for designing a context ontology: simplicity, flexibility, extensibility, generality and expressiveness. Many researchers have come to the conclusion that ontologies are theoretically the best way to represent and model context due to the extendibility and unambiguousness [Anagnos1

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0, W3C Recommendation, 15 January 2004. http://www.w3.org/TR/CCPP-struct-vocab 2 RDF Vocabulary Description Language 1.0: RDF Schema – W3C Recommendation. http://www.w3.org/TR/rdf-schema, accessed 09.05.2011. 3 OWL Web Ontology Language Overview – W3C Recommendation. http://www.w3.org/TR/owlfeatures, accessed 09.05.2011.

10


topoulos and Hadjiefthymiades, 2008; Baldauf et al., 2007; Strang and Linnhoff-Popien, 2004; Wang et al., 2004b]. However, they come with certain drawbacks. Ontology engineering is a challenging and interminable matter. With the size of the ontology, querying and processing the information embedded within become slow, in particular if performed on resource constrained mobile devices. The context model can be arranged in layers to cushion this effect. Wang et al. [2004b] propose ontology modularisation, i.e. a generic upper ontology on top and domain specific ontologies below. Still full featured ontological representations tend to decrease the inference performance and are not suited for highly dynamic systems. Especially if resource constraint mobile devices are envisaged as the main source and consumer of context an appropriate alternative must be chosen. Another argument for not applying ontological representation is its limited support for modelling uncertain and unavailable data. Beside the context information itself a model for representing related meta data (cp. Definition 2.3) appears crucial. Such context meta information may include a quality of information quantifier, the degree of uncertainty, possibility, measurement accuracy, resolution or confidence interval. These attributes are especially helpful for certain inference and reasoning mechanisms (cp. section 2.6). When taking historic context into account, it is important to embed data related to the temporal domain such as time of detection and expiry time. Rapidly changing information can be differentiated from rather static information (such as gender, year of birth). In addition, if tracing back context inference processes is required, both context sources and context processing entities may be captured and stored in meta data. Important in a real life system – but out of scope of this work – is privacy and security information [Castro and Munz, 2002; Ranganathan et al., 2004]. In their work Chang et al. [2008] propose the modelling of a lifecycle for contextual information and an appropriate representation in meta data. The state of contextual information (e.g. ready, running, expired, suspended) enables flexible and fast transitions when the context changes temporarily. However, in this work there are only two states of context information and transitions only occur unidirectionally and ultimately from valid to historic context. Definition 2.4 clarifies this differentiation.

Definition 2.3 (Context Meta Data) Context meta data refers to information explicitly attached to the context data. Meta data may be subdivided into mandatory and optional parameters and may comprise the detection time, validity period, source of information, quality of context, probability or uncertainty, associated entity, applied processing, etc.

11


Definition 2.4 (Context Instance and Historic Context) A context instance refers to an instanced and specific object of contextual information, including meta data. Due to limited validity of context, each context instance only remains valid for a specific period of time. Any expired context instance is considered to be historic context.

2.5 Context Management & Provisioning The management and provisioning of context information are essential elements for realising context-aware services and applications. A notable number of context management approaches have been presented; surveys of which have been published for instance in [Baldauf et al., 2007; Hong et al., 2009; Truong and Dustdar, 2009a].

2.5.1 Functionalities The overall management is usually subdivided into several functional tasks as illustrated in the core layer of Figure 2.1. The access to contextual information is typically aided by a context management system, toolbox, framework or middleware enabling services and applications to acquire and utilise context. Physical Actuators Sensor Data Acquisition

Sensor Gateways

Media Tagging Context Storage

Service Adaptation Context Lookup & Discovery Physical Sensors

Service Composition Context Diffusion & Distribution

Context-Aware Mobile Applications

Privacy, Security and Access Control Virtual Sensors

Context Processing & Reasoning Logical Sensors

APPLICATION LAYER MIDDLEWARE LAYER (C-PROMISE) SENSOR LAYER

Figure 2.1: Middleware Functionalities. The dotted box refers to a functionality that is out of scope of this thesis. Sensor Data Acquisition deals with how raw information about any context is fetched and used as input to the middleware. It is important that the system can cope with a variety of heterogeneous sources and sensors simultaneously. Sensors may be physical, virtual, or logical in nature1 . Depending on the intelligence and computational power, preprocessing and filtering may be performed by the sensor nodes themselves or as part of the middleware functionality. Both synchronous and asynchronous sources are generally 1 Baldauf et al. [2007] differentiate between physical, virtual and logical sensors as follows: Physical sensors “are capable of capturing almost any physical data”. Virtual sensors “source context data from software applications or services”. Logical sensors “make use of a couple of information sources, and combine physical and virtual sensors with additional information from databases or various other sources in order to solve higher tasks”.

12


supported. The benefit of Context Storage is twofold. Caching strategies allow for faster provisioning of the required context since repeated processing stages may be omitted. The storage of expired context in a history database moreover enables the analysis of previous situations. Such information can be used to determine habits and long-term intentions taking successive sequences of activities towards the desired goal into account. Context Lookup & Discovery provide means for an application, service or actuator to identify the available context and how to acquire and query for it. Commonly used approaches include lookup tables, semantic queries or Web Service mechanisms such as SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). Context Diffusion & Distribution are related to the output of a middleware system, that is how context information is made available to the consumers. This encompasses not only the definition of query models (e.g. key-value based or SQL based) but also the mode of communication. Protocols may support event-driven asynchronous publish/subscribe mechanisms to notify the application layer about context changes of interest. Additionally, synchronous on-demand queries may be supported by the middleware. Since context reveals private information about users, Privacy, Security and Access Control are crucial tasks in every middleware. However, due to the selected scientific focus, they are not considered to any great depth in this thesis. Context Processing & Reasoning refer to the capability of inferring context from raw sensor data or from existing primitive low-level context. The middleware may apply feature extraction, description logic, rule-based reasoning or probabilistic inference on behalf of the application layer, hence saving battery consumption on mobile resource constraint devices. A powerful middleware has to support modularity so that numerous processing mechanisms and algorithms can be plugged in. Details are discussed in section 2.6. Functional, spatial, synchronisation and temporal decoupling of these elementary tasks is targeted in most of the architectural principles as further discussed below. Functional decoupling is achieved whenever functionalities can be invoked independently from each other. Spatial decoupling foresees a sender being unaware of the receivers’ address or presence. Synchronisation decoupling prevents blocking in sender and receiver when exchanging context so that their main flow of execution can continue to be carried out. Temporal decoupling requires senders and receivers of context not to be involved at the same time.

2.5.2 Existing Classifications Hong et al. [2009] classify context middleware approaches into the following six categories: (1) agent-based, (2) reflective, (3) metadata based, (4) tuple space based, (5) adaptive and objective based and (6) Open Services Gateway Initiative (OSGI) based. However, this grouping mixes up architectural approaches, context representation and applied technologies. Baldauf et al. [2007] differentiate between (1) direct sensor access, (2) middleware infrastructure and (3) context server as architectural models. Hence architectural design is focused without going into detail about technological details. Winograd [2001] proposes 13


a distinction between (1) widgets providing interfaces for hardware sensors, (2) networked services resembling the context server architecture and a (3) blackboard model representing a data-centric view. Regarding the overall system design, Hong et al. [2009] recommend four layers (bottomup): (1) Network Infrastructure Layer, (2) Middleware Layer, (3) Application Layer and (4) User Infrastructure Layer. Baldauf et al. [2007] identify five layers focussing on functional stages: (1) Sensors, (2) Raw data retrieval, (3) Preprocessing, (4) Storage/Management and (5) Application. Zimmermann [2007] derives a layered framework comprising (1) Sensor Layer, (2) Semantic Layer, (3) Control Layer and (4) Actuation Layer where only the first two layers are directly related to context management and provisioning and the latter two deal with decision logic and service adaptation. Based on these existing classifications, the following subsections discuss concrete categories of architectural principles, applied technologies and communication paradigms. Finally, an overview of selected context management frameworks and middleware solutions is provided by associating these categories respectively.

2.5.3 Architectural Principles From an architectural perspective a middleware can be realised centrally, fully distributed, or by applying a balanced mixture of these two extremes. For instance, CASS (Context Awareness Sub-Structure) [Fahy and Clarke, 2004] represents a completely central middleware. In other related work, various frameworks rely on central components mostly for storage, lookup and discovery of context and partly for reasoning. In the Context Managing Framework [Korpip¨ a¨ a et al., 2003b] the so-called context manager centrally manages distributed resource servers and context recognition services. In SOCAM (ServiceOriented Context-Aware Middleware) [Gu et al., 2005b] a central context interpreter facilitates access to distributed context providers. CoBra (Context Broker Architecture) [Chen et al., 2003a,b] foresees a single central broker while offering the conceptual possibility of creating broker federations to overcome bottleneck and single point of failure problems. The Context Toolkit [Dey, 2000; Salber et al., 1999] utilises widgets for supporting the heterogeneity of context sources/sensors and context sinks. Another well known approach is the role model comprising producers and consumers of context. Optionally a broker is introduced for simplified coordination between these elements. To some degree, the broker can be interpreted as an access point to a context bus. Both producers and consumers can connect to this context bus. Furthermore, the design of data-centric architectures depends on the applied data models, specifically on the context query model. The blackboard approach, also known as tuple space, is for instance based on key-value pairs for context lookup and querying.

2.5.4 Technological Basis Network based frameworks have utilised RMI (Java Remote Method Invocation) or CORBA (Common Object Request Broker Architecture) standards as technological basis for 14


interaction. Examples for RMI comprise JCAF (Java Context Awareness Framework) [Bardram, 2005] and SOCAM [Gu et al., 2005b]. CORBA has been used in Gaia [Rom´ an et al., 2002]. Both CORBA and RMI can be considered as rudimentary technologies for realising distributed networked applications. Because of the relatively low abstraction level, they may outperform newer technologies as far as speed and a low footprint are concerned. However, development is more complex and the interoperability limited. The OSGI framework is an open modular service platform based on Java that implements a dynamic component model as extension to the standalone runtime environment. OSGI interface principles have been applied in [Gu et al., 2005a] and [Yu et al., 2006] for instance. Multiagent systems (MAS) evolved from Distributed Artificial Intelligence and are comprised of individual agents. Each is considered a locus of problem-solving activity. By operating asynchronously it has a certain level of autonomy and intelligence. Cooperative agents collaborate towards achieving common goals [Lesser, 2002]. Hence, agent-based systems have also been successfully adopted in context provisioning middleware designs, for instance in CoBra [Chen et al., 2003a,b], EgoSpaces [Julien and Roman, 2006] and in untitled frameworks (e.g. [Bellavista et al., 2003a,b; Soldatos et al., 2007]. Agent based systems apply concepts and principles that are technology neutral. However, the current well known state of the art implementation standard is JADE (Java Agent DEvelopment Framework)1 . Moreover, web service technologies received much attention with regard to context middleware recently. They utilise standard protocols, such as HTTP (Hypertext Transfer Protocol) and SOAP (Simple Object Access Protocol). In addition WSDL (Web Services Description Language) may be applied for describing the interfaces of architectural components semantically. In the traditional client-server view, interacting services invoke each other, the requesting one becomes a client of the invoked one [Truong and Dustdar, 2009b]. A full level of web service implementation has been used in CA-SOA (Context-aware Service Oriented Architecture) [Chen et al., 2006], CoSWAMI [Athanasopoulos et al., 2008], ESCAPE [Truong et al., 2007], inContext [Truong et al., 2008] and Omnipresent [De Almeida et al., 2006]. Partially web service concepts have been adopted in Akogrimo [Osland et al., 2006] and Anyserver [Han et al., 2005] for instance. A crucial advantage of web service technologies is their wide interoperability across networks and devices. Representational State Transfer (REST) [Fielding, 2000] compliance allows for stateless information exchange, e.g. based on XML. These concepts are not only applicable for context-aware web services but also for other types of actuators or ubiquitous applications.

1

JADE – an open source platform for peer-to-peer agent based applications complying with the Foundation for Intelligent Physical Agents (FIPA) specifications. http://jade.tilab.com, accessed 06.04.2011.

15


2.5.5 Communication Paradigms This subsection discusses basic communication paradigms without going into detail about their implementations and specific protocols. Communication is of particular importance for the context diffusion functionality. As basic interaction paradigms, synchronous on-demand communication can be differentiated from asynchronous event-based notifications. The latter is based on explicit or implicit subscriptions. The subject of interest (for example channel) must be subscribed. Event-based communication necessitates a subscription management and asynchronously reachable consumers. Event and subscription matching is another functional prerequisite. Gaia [Rom´ an et al., 2002] is an example for such an event-based middleware. Peer-to-Peer (P2P) communication has been utilised e.g. in JCAF [Bardram, 2005] and by Kaneko et al. [2006]. P2P systems often implement an abstract overlay network on top of the native or physical network topology. Such overlays are used for indexing and peer discovery, hence making the P2P system independent from the physical network topology. P2P can be an adequate means for increasing the scalability, however the existence of mobile resource constraint devices, their limited bandwidth and possible temporary unavailability do not make them an ideal candidate for efficient context diffusion. Gossiping has been proposed in Stevenson et al. [2005] as extension of the Construct [Stevenson et al., 2006] framework. Gossip protocols are socially inspired and designed to spread information in a network. They can be categorised into (1) event dissemination protocols carrying out multicasts to report events, (2) background data dissemination protocols continuously propagating. Gossiping selects nodes at random and is only applicable if latency is not a problem, i.e. if the information in question changes slowly.

2.5.6 Overview of Related Frameworks and Middleware Table 2.1 provides an overview of related projects and systems. Their historic evolution is presented. Furthermore, major achievements and limitations with regard to the advances presented in this thesis are discussed. ActiveBadge [Want et al., 1992], one of the earliest localisation and context-aware systems, is based on a centralised location server and communicates through Remote Procedure Calls (RPC). Mainly due to its very limited scope, heterogeneity of networks, context consumption devices and sensors is not supported. Context is represented proprietary and details are not specified in related literature. The support for sensor, context and entity diversity as well as model extendibility and scalability are weak since only localisation of infra-red based sensors embedded in badges is targeted. The ActiveMap [Schilit and Theimer, 1994] system is comparably limited and again, location is the focus. Due to utilisation of the publish/subscribe paradigm, the context management scalability capabilities is supposed to outperform ActiveBadge, albeit no specific performance analysis has been published. Alongside users, the concept foresees support of generic objects. Hence, entity heterogeneity is addressed, however not discussed in detail. Localisation is arranged in hi-

16


erarchies, for example room, building, regions. In addition to basic RPC communication, infra-red based multicast is supported. Cyberguide [Abowd et al., 1997] was developed as a rapid prototyping system for assessing the utility of context-awareness in mobile devices and focussed on location and orientation context of users. Infra-red based beacons and GPS sensors are used for estimating the position of a device. Support of sensors, context and context processing capabilities are very narrow and static. GUIDE [Davies et al., 1999] is another framework supporting location-based travelling. It is an advance on its predecessors by applying a distributed architecture in which separated servers manage individual cells. HTTP is used for communication. The above mentioned systems have been primarily designed to illustrate the benefit of context-awareness based on a selected usage scenario. Being very restricted in functionality, degree of awareness as well as acquisition and processing of contextual knowledge, they can be classified as early systems that increased interest and understanding of ubiquitous computing. However, they cannot be referred to as context provisioning systems. The need for generic and systematic support of context-aware applications and services emerged slowly and has been addressed in later systems. The Context Toolkit [Dey, 2000; Dey and Abowd, 2000; Dey et al., 1999a,b] is one of the first demonstrations of utilising a complex combination of different types of user context information. Its architecture is based on distributed widgets hiding complexity and heterogeneity of sensors. The hybrid design further encompasses a central context interpreter and server. Context is represented by using a custom XML schema. Subscription based context updates are communicated based on the TCP/IP networking suite through SMTP (Simple Mail Transfer Protocol) or HTTP. While the system is by design not intended to be used over a large scale and is focussed on utilising context information bound to a geographical area, physical and functional scalability are partly supported. Gaia [Rom´ an et al., 2002] is the first context provisioning and management framework entitled as middleware by the authors. It models a smart space as a programmable entity, providing support to context based applications via well established operating system concepts. Therefore, Gaia applies I/O operations and file system manipulation for interconnecting active space objects. Event-based communication is established through both RPC and CORBA. Context diversity originates from so called Context Providers and covers for example location, room conditions, weather, stock prices and running applications. Gaia has not been assessed in terms of large-scale use. The authors mention federating multiple active spaces but such an attempt has not been documented. CoBrA [Chen, 2004] is architecturally based on distributed agents being organised by a central broker. Context is represented in ontologies (RDF/OWL). The broker is responsible for providing a shared model of context, removing inconsistencies and masking heterogeneous context sensing sources. Communication is established through the Agent Communication Language (ACL) and HTTP. The concept of compartmentalising context into domains exists in CoBrA but physical scalability has not been evaluated. Functional scalability is problematic due to a tight coupling of applied technologies and the resulting need of following

17


these strict guidelines. SOCAM [Gu et al., 2005b] targets at providing an architecture specified for rapid prototyping of context-aware services. The framework encompasses Context Providers, Context Interpreter, Service Location Service and Context-aware Mobile Services. Context Providers acquire primitive data which is further processed by a central Context Interpreter. Context is modelled based on ontologies (RDF/OWL). SOCAM is built on top of an OSGi service platform, hence facilitating service discovery and management. Further, RMI is applied. The availability of both on-demand queries and subscriptions is only briefly mentioned without any details. Therefore, the scalability capabilities are difficult to estimate. CASS [Fahy and Clarke, 2004] focusses on providing higher level context abstractions through a knowledge base, sensor listener, context storage database and rule engine (for reasoning) deployed on a server. Context-aware applications on mobile devices can listen for relevant changes in context data propagated through the central database. The rule engine monitors such modifications accordingly. Context representation is not discussed, however queries are realised based on SQL. While prototype applications demonstrate feasibility of CASS in keeping resource intensive context processing tasks from mobile devices, it is not designed to be scalable. Firstly, both sensor nodes and mobile devices have to communicate with a central CASS server and no discovery mechanism is built in. Secondly, support for mobility is lacking. CORTEX [Sorensen et al., 2004] proposes a sentient object model to support the construction of ubiquitous applications in wireless mobile ad-hoc networks. Sentient objects are defined as entities consuming, processing and producing events and effect actuators. Therefore, a publish-subscribe component for discovery of neighbouring components and sharing data is provided. Context is represented in XML and serves as input and output of sentient objects. While CORTEX is suitable for a number of mobile entities interacting with sentient objects, this communication is specifically designed to work in ad-hoc environments focussed around a particularly bounded area. Event propagation is limited by the range of multicast protocols, hence scalability is very limited. The JCAF [Bardram, 2005] system is based on a distributed, event-based infrastructure for development and deployment of context-aware applications. Each covered context domain is modelled by a dedicated context service being realised as Java Enterprise Application deployed on an Application Server. Inhabitants of such a domain are programmed as entities. Context is modelled “semantically-free” and utilises an object oriented representation. Context monitor and actuator components serve for acquisition and publication of context. Components apply RMI for communication which limits device heterogeneity severely. Due to the inadequate central RMI registry and unavailability of dynamic lookup facilities JCAF fails to support large-scale deployments. The PACE middleware [Henricksen and Indulska, 2004b] provides a context management component along with a programming toolkit for development and deployment of context-aware applications. In addition, decision support and a flexible messaging framework are investigated. Architecturally a distributed set of context repositories is proposed, each repository managing a specific catalogue which is implemented as relational database. In addition to Java RMI, an HTTP based web interface is provided.

18


The authors explicitly state that scalability is not a targeted design goal and one would conjecture from the two fundamentally different communication protocols. CoWSAMI [Athanasopoulos et al., 2008] addresses the issue of using context from dynamic sources by decoupling context sources from context aggregators and providing dynamic discovery. Context sources expose web service interfaces, including SOAP and WDSL technologies. Users can define relational context views and map them to the context source interfaces and aggregators produce context to satisfy these mappings accordingly. Both context and rules are encoded in XML. The application of CoWSAMI is limited to a particular application domain of mobile users and vehicles. Moreover, the loose coupling and dynamic discovery of context requires explicit involvement of users in defining rules and mappings, hence limiting the usability. MobiLife [Kernchen et al., 2006] applies a role model comprising distributed Context Providers, Context Consumer and a central Context Broker in its Context Management Framework. RESTful HTTP interfaces are used for communication and ensure the support of device heterogeneity. Context is represented in ontologies. Entity diversity is not discussed, however the described application scenarios are clearly user centric. The design as such would allow for a large-scale deployment, however a single Context Broker can be identified as bottleneck. In conclusion, a diverse set of design approaches has been adopted for developing context provisioning frameworks and middlewares. The general trend towards large-scale systems as well as the support of application and device heterogeneity becomes obvious. However, related work fails to adequately address the gradual extendibility of a middleware and the required support of both emerging and evolving context-aware applications and services. This is not only related to the introduction of new context categories but also to the aggregation of detected context in various abstraction levels. The second reason for hindering a middleware from stepping out of bound lab environments into the real world is the lack of scalability performance and its appropriate evaluation.

2.6 Context Processing & Reasoning In general terms, reasoning derives “conclusions from a corpus of explicitly stored information” [Greiner et al., 2001]. In the original philosophical sense deductive, inductive, abductive, analogical and fallacious reasoning can be differentiated, the first two variants being most relevant: Deduction attempts to show that a conclusion necessarily follows from a set of premises or hypotheses. Induction tries to derive propositions about unobserved objects based on previous observations, either specifically or generally [Russell et al., 1995]. Anagnostopoulos et al. [2007a] describe context reasoning as “a process for inferring new context, previously unidentified on the basis of a-priori known context”. In the domain of context-aware and ubiquitous computing and for the scope of this thesis Context Reasoning and Context Inference are synonymously defined as follows.

19


‡

Support for Ctx Diversity

*

Ctx Model Extendibility

Support for Entity Diversity

Support for Historic Ctx

Ctx Processing Scalability

Ctx Management Scalability

RPC RPC & o ? web web RPC, CORBA ag, (web) ? o RMI, web RMI RMI, OSGi web web

? ? ? ? M o Ont ? M OO, M, G OO Ont Ont M

/ / / / X X X (X) X X X X X X

/ / / / X X X (X) (X) X X X X X

/ / / / (X) ? / ? ? (X) (X) ? X (X)

/ (X) / / / X ? / X ? X ? ? (X)

/ / / / / ? ? ? ? ? ? ? ? ?

/ / / / (X) (X) / ? (X) (X) (X) ? (X) (X)

/ (X) / (X) (X) (X) (X) / / / / ? (X) /

C-ProMiSE**

2011

h

web

M

X

X

X

X

X

X

X

*

*

Support for Sensor Diversity

c c c h h h h c d h h h h h

*

Ctx Model & Representation

*

*

*

Communication Technology

1992 1994 1997 1999 2000 2002 2004 2004 2004 2004 2005 2005 2006 2008

Middleware/Project

†

§

Architectural Approach

Active Badge Active Map Cyberguide GUIDE Context Toolkit Gaia CoBrA CASS CORTEX PACE JCAF SOCAM MobiLife CoWSAMI

†

Year of Publication

‡

Table 2.1: Context Management & Provisioning Frameworks

c = centralised; d = distributed; h = hybrid; ? = unknown, i.e. not discussed in available literature. web = web based; ag = agent based; RPC = Remote Procedure Calls; RMI = Remote Method Invocation; CORBA = Common Object Request Broker Architecture; OSGi = OSGi based; o = other; ? = unknown.

§

Ont = Ontology; M = Markup Scheme; G = Graphical; OO = Object Oriented; o = other; ? = unknown.

*

X= support; (X) = limited support; / = no support; ? = unknown.

**

The C-ProMiSE middleware has been added to highlight its advancements compared to related work.

Definition 2.5 (Context Reasoning/Inference) Context Reasoning and Context Inference refer to the automated deduction of high-level context from lower-level or primitive context. In addition to an aggregation of available context information, reasoning/inference may derive new conclusions based on existing context (i.e. measurable and observable facts) and an available knowledge base.

Consequently, a significant number of mechanisms originating from the fields of Artificial Intelligence and Knowledge-based Systems can be adopted for context reasoning. Moreover, there is a strong relation to Activity Recognition (e.g. [Kim et al., 2010]) and Plan Recognition (e.g. [Goultiaeva and Lespérance, 2007]). The entire context detection process can be subdivided into subsequent stages as depicted in Figure 2.2. A specific utilisation of such a layered design is for example discussed in [Korpip¨ a¨ a et al., 2003a]. From bottom to the top of the processing chain, the com20


plexity of mechanisms increases while reducing the amount of data through aggregation. Real world events are initially sensed and sampled. Particularly if physical sensors are utilised, the collected raw data is afterwards preprocessed, either on-the-fly or in bulk. Pre-processing may comprise removal of noise and faulty data by applying filtering techniques, averaging sensor readings or fusion of redundant data. In the next step, features are extracted, for example by Fuzzy logic or crisp filters, to derive low-level context. This primitive context may also be directly fetched from virtual and logical sensors and serves as input for inferring common-sense abstractions, for example a user’s situation, his mental

High-level context, e.g. user‘s intention Time Series Analysis ... Mid-level context, e.g. user‘s activitiy Classification, Labelling

Context Reasoning

and physical activities, his intentions.

Low-level context (primitive context) Feature extraction Preprocessed Sensor Data Preprocessing (e.g. filtering) Raw Sensor Data Sensing, Sampling Real World

Figure 2.2: Context Processing Stages Kim et al. [2010] identify typical challenges when dealing with the nature of human activities: (1) several activities may be performed concurrently; (2) activities may be interleaved; (3) the interpretation of activities may be ambiguous; (4) multiple residents may be present in a smart environment and follow collaborative activities. Identifying users’ activities refers to either a classification problem or to a time-series analysis task [Nurmi et al., 2005]. Various reasoning mechanisms can be applied for recognising highlevel context information. The selection of an adequate technique mostly depends on the targeted context, the available input information and the chosen context model. The following subsections present fundamental background information and discuss related work.

2.6.1 Rule-based Reasoning As in any other rule-based system, rule-based context reasoning requires a fact base (knowledge base) and a rule base in which rules are stored. For inferring high-level context, primitive context is asserted into the fact base. Rule-based reasoning comprises a threefold cycle of (1) matching, (2) conflict-resolution and (3) acting. Whenever the fact base is updated, the internal inference engine checks if the rule base contains any matching premises. After solving potential conflicts, e.g. though consideration of assigned priorities, the rule fires which may optionally change the fact base and/or trigger an asynchronous context 21


update message to external components. This mechanism is also referred to as forward chaining. Current examples of state-of-the art software frameworks are JESS1 and Drools Expert2 . The Rule Markup Initiative3 tries to standardise RuleML as a unifying family of XML-based rule representation languages. The applicability of rule-based context reasoning has been discussed and evaluated for situation inference in [Goix et al., 2007]. Rule-based reasoning comes with certain drawbacks. A large rule base easily becomes confusing and intractable. Particularly, if actions result in fact assertion unforeseen and undesired chain reactions may occur which may not only halt the system but possibly even destroy asserted facts and/or conclusions previously derived. Moreover, the storage of fact knowledge requires a large amount of memory consumption since the input context parameters of all entities need to be watched constantly. Most importantly, rulebased reasoning can only be usefully applied in systems supporting event-based context propagation. Boolean execution, i.e. rules fire or they do not, prevents the support of impreciseness.

2.6.2 Description Logic Description Logic (DL), a compound of logic based formalisms for knowledge representation and reasoning, is applied in conjunction with ontological context representation. The semantic modelling of concepts (classes), roles (properties, relationships) and individuals allows terminological knowledge to be specified in a machine interpretable manner. “An ontology is a formal specification of a shared conceptualisation of a domain of interest” [Gruber, 1993]. The so called TBox (terminological box) contains axioms relating concepts to each other, e.g. describing concept hierarchies. The ABox (assertional box) comprises ground sentences, i.e. it associates individual objects to concepts. Both TBox and ABox constitute the knowledge base whereat the TBox formalises intensional knowledge and the ABox extensional knowledge. DL are variable-free fragments of First Order Logic. Several classes of formal expressiveness are differentiated. The smallest propositionally closed DL is ALC and comprises atomic concepts, atomic rules, conjunction, disjunction, negation, existential restriction and value restriction [Schmidt-Schauß and Smolka, 1991]. S is used if transitive roles are supported moreover. Additional letters indicate further extensions, e.g. H for role hierarchy, O for nominals/singelton classes, I for inverse roles, N for number restrictions, Q for qualified number restrictions and F for functional number restrictions. SHIQ is the basis for OWL, SHOIQ for OWL-DL and SHIF represents the formal range of OWL Lite. Description logic based reasoning has been applied in [Wang et al., 2004b] for inferring users’ activities in the home domain (e.g. watching movies, having dinner, taking shower) 1 JESS, a rule engine and scripting environment based on Java, developed by Ernest Friedman-Hill at Sandia National Laboratories. http://jessrules.com, accessed 17.03.2011. 2 Drools introduces a Business Logic integration Platform as addition to the JBoss application server. http://www.jboss.org/drools/drools-expert.html, accessed 17.03.2011. 3 http://ruleml.org, accessed 17.03.2011.

22


based on an OWL representation. In [Chen et al., 2003a] ontologies describing places, locations and activities have been defined and used for reasoning by an OWL inference engine. Further work discussing the applicability of ontologies and DL with regard to context-awareness can be found in [Serrano et al., 2006], [Ejigu et al., 2007], [Gu et al., 2004], [Christopoulou et al., 2005]. A number of state-of-the art tools and frameworks exist for both ontology design and applying reasoning. Prominent examples of editors include Prot´ eg´ e1 and SWOOP2 . The following list of tools supports inference: CEL3 , Jena24 , KAON25 , Pellet6 , RacerPro7 . Performance measurements of DL based reasoning have been conducted in [Wang et al., 2004a], [Wang et al., 2004b] and [Ejigu et al., 2007]. Researchers share the opinion that reasoning based on ontologies is computationally intensive and that response times largely depend on the size of the data set and rule set. Scalability is a problem addressed in [Ejigu et al., 2007] proposing a hybrid approach combining relational and semantic representation. In addition to the reasoning complexity, designing an ontology is a complex endeavour requiring domain knowledge and expert agreement. In addition to a base layer of (potentially too large) commonly defined ontologies, more specific application dependant ontologies need to be designed on top. Extra effort is needed if uncertainty and unavailability of context are to be supported.

2.6.3 Probabilistic Logic Probabilistic models can be distinguished as generative models or discriminative models as depicted in Figure 2.3. Assuming input values x and the target class variable y, generative models require joint probability distributions p(y, x) to be represented whereas discriminative models are based on conditional probabilities, i.e. p(y|x) [Klinger and Tomanek, 2007; Sutton and McCallum, 2007]. Both categories of probabilistic models can be represented graphically. Each node represents a random variable. The conditional independence of two random variables is graphically represented by the absence of an edge between the associated nodes. Hence, causal dependencies become human comprehensible. Let G = (V, E) be a graph with vertexes V and edges E. The vertexes V = X ∪ Y are depicted as circles, X being the set of input or observation variables and Y the set of output variables. Generative models are represented as Directed Acyclic Graph, i.e. their edges are directed. Discriminative models are undirected and link random variables to so 1 Prot´ eg´ e is a free, open source ontology editor and knowledge-base framework based on Java. http://protege.stanford.edu, accessed 18.03.2011. 2 SWOOP is an open source ontology editor originally developed at the University of Maryland. 3 CEL, a free LISP-based reasoner developed by the Technical University of Dresden, http://lat.inf.tudresden.de/systems/cel, accessed 18.03.2011. 4 Jena2, a Semantic Web Framework for Java, http://jena.sourceforge.net/, accessed 18.03.2011. 5 KAON2 is an infrastructure for managing OWL-DL, SWRL and F-Logic ontologies, http://kaon2.semanticweb.org, accessed 18.03.2011. 6 Pellet is an OWL 2 reasoner for Java distributed under a dual license model, http://clarkparsia.com/pellet, accessed 18.03.2011. 7 RacerPro aids in management of semantic web ontologies based on OWL and serves as reasoning engine, http://www.racer-systems.com/products/racerpro/index.phtml, accessed 18.03.2011

23


called factor nodes graphically represented as small filled rectangle. A factor Ψs comprises all random variables to which the factor node is connected. Generative Probabilistic Models

Naive Bayes

joint

Discriminative Probabilistic Models

conditional

single class

single class

sequence

Hidden Markov

sequence joint

conditional

linear sequence

joint

Linear-chain CRF

linear sequence

general sequence

Generative directed models

Maximum Entropy

general sequence conditional

General CRF

Figure 2.3: Probabilistic Reasoning Models The Na¨ıve Bayes (NB) model [Lewis, 1998] is the simplest generative approach for classifying single class variables in dependence of multiple feature values. The Hidden Markov Model (HMM) [Rabiner and Juang, 1986] extends NB for representing sequentially structured data, allowing modelling of temporal changes. Like the NB model, the Maximum Entropy model [Csisz´ ar, 1996] is used for classifying a single output variable based on a set of observed input parameters. In contrast to NB, it contains conditional probabilities, hence it is discriminative. Linear-chain Conditional Random Fields (CRF) [Klinger and Tomanek, 2007; Lafferty et al., 2001] can be interpreted as a linearly sequential extension to the Maximum Entropy model. Generic sequential analysis of data is also supported when using the unconstrained CRF models. According to Lafferty et al. [2001] CRF tend to be more robust than generative models to violations of their independence assumptions. In particular physical sensors are likely to give imprecise measurements. Moreover, due to potential temporary lack of communication facilities, sensor data may not be available at all. This is why Probabilistic Reasoning is especially applicable in context-aware environments. Furthermore, probabilistic models, i.e. causal dependencies, can be learnt from training data, e.g. by applying the Expectation Maximization or Maximum Likelihood methods. With regard to context-aware systems, such training data may be collected from user based feedback. Sequential probabilistic models can be represented as finite state machine (FSM) with specific transition probabilities between states. This is particularly useful, if the context-aware system tries to detect real-world activities that usually occur in a particular order. In related work, both CRFs and HMMs have been applied for recognition of human activity in the kitchen domain [Kim et al., 2010]. A Na¨ıve Bayesian Classifier was used in [Korpip¨ a¨ a et al., 2003a] to identify various activity context features taken from audio sensors and accelerometers; such as driving a car, running to the door, taking an elevator and listening to music. Oliver et al. [2002] propose theoretic concepts of Layered HMM 24


allowing for inference at multiple levels of temporal granularity. Dynamic Belief Networks (DBN) (a generalisation of Bayesian Networks incorporating temporal dependencies) and Linear Dynamical Systems (LDS) (a more general form of HMMs without constraint on number of state spaces) and their applicability to human activity recognition is discussed by Turaga et al. [2008].

2.6.4 Other Reasoning Mechanisms Wen-Yu et al. [2003] use Situation Calculus to model ubiquitous information services. Situation Calculus [Pirri and Reiter, 1999] is a formal first-order language defining actions, objects, situations, pre-condition axioms and successor state axioms. Sharing its basic philosophy with commonly applied FSM, Situation Calculus eliminates the need for a-priori definition of possible states since situations are dynamically generated and an infinite number of instances is allowed. This makes Situation Calculus eligible to model an open dynamic world but makes it unmanageable and not applicable for context-aware applications that expect a defined output state. Situation Calculus has been applied for incremental plan recognition in [Goultiaeva and Lespérance, 2007]. A combined approach of Fuzzy logic and clustering is presented in [Anagnostopoulos et al., 2007b]. Imprecise reasoning about situational context and unsupervised model learning are supported. Yin et al. [2008] present an activity recognition algorithm segmenting low-level sensor data with a probabilistic model. Each segment of signals is represented as an LDS model where transitions are modelled as Markov processes. The overall goal is to derive high-level activities from WiFi Access Point RSSI values. A notable number of approaches apply workflow-inspired patterns focussing on temporal flows. Bosse et al. [2008] and Both et al. [2008] introduce the Temporal Trace Language (TTL), a formally specified language based on predicate logic which shares similarities with Situation Calculus. Inference rules are translated into temporal rules for describing the reasoning behaviour in temporal partial logic. Both forward reasoning and backward reasoning are supported for deriving human’s progress in task execution while observing their behaviour.

2.6.5 Overview of Reasoning Mechanisms Table 2.2 provides an overview of the approaches presented above. It rates the support of machine based model learning, sequential data analysis and whether the mechanism can cope with imprecise and unavailable input data. Summing up, a diversity of mechanisms has been successfully applied to derive a rich set of high-level context.

25


*

Rule-based Reasoning

Event-based context propagation; scalable fact storage Domain knowledge represented in ontologies

/

(X)

/

/

X

/

Situation Calculus

Formalised language model

/

X

/

Na¨ıve Bayes

Labelled training data

X

/

X

Hidden Markov Models, Linear Dynamical Systems

Labelled training data or knowledge about conditional probabilities, availability of historic context Labelled training data

X

X

X

X

/

X

Labelled training data, availability of historic context Labelled training data or knowledge about conditional probabilities, availability of historic context

X

X

X

X

X

X

Bayesian Networks

Dynamic Belief Networks Conditional Random Fields

Machine Learning

Requirements

Sequential Analysis

*

Reasoning Approach

Description Logic

*

Impreciseness & Unavailability

*

Table 2.2: Context Processing & Reasoning Approaches

Applicability (Examples) Situation Recognition [Goix et al., 2007] Home activities [Wang et al., 2004b], locations [Chen et al., 2003a], unspecific/generic [Serrano et al., 2006], [Ejigu et al., 2007], [Gu et al., 2004], [Christopoulou et al., 2005] Modelling ubiquitous information services [Wen-Yu et al., 2003] Activity Recognition [Korpip¨ aa ¨ et al., 2003a] Activity Recognition [Turaga et al., 2008; Yin et al., 2008] Generic High-level Context Reasoning [Knappmeyer et al., 2011c] Activity Recognition [Turaga et al., 2008] Activity Recognition [Vail et al., 2007]

X= support; (X) = limited support; / = no support.

2.7 Evaluation of Ubiquitous Middleware 2.7.1 Challenges of Middleware Evaluation Context-Awareness and Ubiquitous Computing are both multidisciplinary research areas, incorporating elements of HCI design, artificial intelligence, communication engineering, psychology and social/behavioural sciences. Correspondingly, the evaluation of such a complex and interwoven system is extraordinarily challenging and requires multidisciplinary techniques. Interesting studies and surveys have been conducted with focus on the evaluation of a UbiComp application from the user’s perception, for example see [Consolvo et al., 2002; Rogers et al., 2007; Scholtz and Consolvo, 2004a,b]. Proposed methodologies for context-aware systems are borrowed and extended from the background of HCI research.

26


Though the users’ experience is essential, the work presented in this thesis concentrates on the evaluation of the context management middleware rather than on the applications themselves. Hence, a context middleware is assumed which is able to support the users in their everyday life with their everyday device(s) moving through their everyday environment seamlessly. The middleware has the difficult task of bridging virtual and real world which comes with numerous objectives. One problem with evaluating a middleware supporting rich context-awareness is that a generic one-size-fits-all approach is unrealistic [Neely et al., 2008]. In related work, evaluation often fails to be objective and comparable. A common concensus is required, not only related to UbiComp applications but also to the underlying middleware caring for holistic or partial awareness. Neely et al. [2008] explain the need for a common evaluation framework and for a combination of multidisciplinary approaches. This work agrees with their opinion that evaluation is always goal oriented and needs to be tailored accordingly. The following sections survey existing methods, propose recommendations for usage and discuss limitations.

2.7.2 Prototyping Prototyping the conceptualised middleware is the most commonly applied evaluation technique. Usually, core functionalities are implemented and deployed in a controlled lab environment. In an early stage, lab staff and colleagues are usually taken as test subjects. This community is extended to external persons very rarely. Selected applications or services are realised to demonstrate the benefit of the system under test and prove its correct functionality. Testbeds have for instance been developed in the Active Badge project [Want et al., 1992], for the Active Map Service [Schilit and Theimer, 1994], the Cyberguide [Abowd et al., 1997] and GUIDE [Davies et al., 1999] project. Other examples comprise the Conference Assistant [Dey et al., 1999a], an Office Assistant [Yan and Selker, 2000] and Gaia [Rom´ an et al., 2002]. This kind of evaluation technique has its advantage in illustrating the final user experience while hiding middleware complexity. Obviously, it has been frequently used in early work where the innovative idea of UbiComp and Context-Awareness had to be delivered to a non-technical audience. But still, recent evaluations have focused on and are sometimes even restricted to, building a small demonstrator (e.g. inContext [Truong et al., 2008], MobiLife [Kernchen et al., 2006]). A disadvantageous side effect of achieving middleware transparency in such evaluations is that the internal performance metrics do not become visible. Testbeds seldom succeed in proving scalability. Showing the context and application flexibility and variety requires enormous efforts (time and costs) since a lot of disjunct and complementary services need to be prototyped. However, prototyping is a suitable choice if either the end user view is to be investigated or if the ability of rapid prototyping is to be assessed (e.g. Context Toolkit [Dey and Abowd, 2000]). Nonetheless, the experiences while coding the concepts often help to identify shortcomings and improve or extend the architectural/functional model. The main target is to show the capabilities of the middleware based on experimental applications. As with other HCI evaluation, the user experience can be explicitly 27


(e.g. interviews, questionnaires) or implicitly (observation, application based feedback) evaluated, albeit this view may not necessarily mirror the middleware capabilities but only the look & feel and usability of the applications.

2.7.3 Field Trials 2.7.3.1 Basic Approaches Numerous methodological approaches have been used for evaluating UbiComp applications in the field, particularly their HCI design. Before discussing their relevance for middleware evaluation, the most important techniques for collecting and analysing user behaviour and experience are briefly introduced; see [Consolvo et al., 2002; Froehlich et al., 2007; Intille et al., 2003a; Rogers et al., 2007] for more details. • Interviewing: Qualitative data is gathered by evaluators asking individual users or groups open-ended questions about their work, background, ideas, etc. The answers are captured by a combination of note taking, audio and video. Though this approach is inexpensive, automatic everyday actions might not be reported. When being conducted outside the natural environment, the user might forget to mention important information and impacts. • Direct Observation or Contextual Field Research: Trained observers directly follow the test subjects and note down their behaviour. This costly, time-consuming and disruptive technique may utilise photographic and video analysis and is inappropriate in private settings and for large-scale scenarios. One of the most relevant advantages is that users do not have to recall their actions and the quality of data is independent from variations in their individual reporting. • Self Reporting: Recall Surveys that are based on users orally reporting their behaviour suffer from recall and selective reporting biases. Activities are often either not remembered or incorrectly reported. Alternatively, users note down their daily routines in Time Diaries. This method provides less biased data but due to distraction and annoyance, the records usually do not provide complete information. • Usability Testing: Conventionally, usability data is collected using a combination of methods (observation, interviews, questionnaires) in a controlled setting, usually a lab, where equipment for recording is available. Tailored to software applications running on desktop computers the primary goal is to determine whether an interface is usable by the intended user population. • Lag Sequential Analysis (LSA): Originated from development psychology, the LSA technique allows for acquisition of quantitative data by observing users performing their normal activities. Evaluators can generate statistics such as frequency and conditional probabilities of events. A drawback is that users being recorded by video may alter their behaviour, knowing they are being observed. 28


• Automatic Tracing: Instead of a human evaluator, the behaviour is tracked by an autonomous systems with the help of various sensors and devices. User input or feedback is not supported. • Wizard of Oz : In a Wizard of Oz experiment subjects typically interact with a computer system. This system is believed to work autonomously but its functionalities are in fact being performed by unrecognised human being(s). • Obstacle Course Data Collection: Evaluators prepare a to-do list for the test subjects. Instead of just observing their natural behaviour, specific activities or goals are defined which the user has to follow. • Experience Sampling Method (ESM): This technique, also referred to as Ecological Momentary Assessment, shares similarities with Self Reporting but avoids the retrospective character. An alarm is presented to the user during or shortly after the behavioural activity has been conducted. Upon reception of the alarm, the user has to answer questions or report what he is doing or feeling. This way, data does not suffer from recall bias. Commonly used ESM tools comprise PDAs, smart phones, paper booklets, mobile phones, traditional phones, audio player/recorder, pagers, watches, cameras or custom devices [Consolvo and Walker, 2003]. ESM allows collection of both structured qualitative data (by defining fixed responses) and unstructured qualitative data (by asking open-ended questions). The presented techniques are not only useful for UbiComp application assessment. Recognition of high-level context (i.e. reasoning or inference) can best be evaluated by the users whose context is to be derived. Three different main targets can be identified: 1. Evaluate the reasoning/inference algorithms qualitatively and quantitatively, i.e. assess their accuracy by comparing expected (calculated) context against actual (user reported) context; 2. Collect training and feedback data for reasoning/inference algorithms that support supervised machine learning; 3. Evaluate the overall user experience, particularly as far as adaptive service/application execution is concerned. The evaluation of ubiquitous everyday assistance benefits from in-situ studies, also referred to as in the wild or ethnomethodological. The key idea is to collect data while users are situated in their own natural environment rather than creating an artificial one in the lab which might influence their behaviour [Rogers et al., 2007]. Due to the characteristics of the UbiComp domain (user mobility, invisible sensing systems, distributed and fragmented interaction across different applications and devices [Crabtree et al., 2006]), the ESM technique appears most promising, in particular if combined with automatic tracing and logging. 29


Preferably, the data collection is performed by common everyday device(s) so that users do not have to wear additional hardware. It is important to minimise distraction from their ordinary workflow. Especially if long-term studies are envisaged, minimal obtrusiveness on the user experience is essential. When applying ESM, this can be achieved by supporting (1) event-based context-aware triggering of questions (i.e. when is the alarm activated?), (2) context-aware selection of the alarming mode (i.e. how is the alarm presented?, e.g. audible vs. tactile) and (3) context-aware selection of questions and possible answers. Bearing in mind the variety of context, ESM tools can serve as appropriate human sensor for understanding subjective areas such as emotional state, time use, social interactions, intentions, abstracted activities, habits and goals [Intille et al., 2004]. Another advantage of ESM is that evaluators can collect preliminary data in near real time and the context recognition accuracy can be measured quantitatively by applying stochastic methods. However, the individuality of users and their cognitive perception of events and activities (cp. [Zacks and Tversky, 2001]) results in potential errors and is problematic for learning of generic models. The same applies to long-term activities consisting of short-term successive or even parallel actions. Multitasking, false starts and human error can be serious dilemmas when assigning labels to time sequences [Intille et al., 2004][Li and Landay, 2008]. 2.7.3.2 ESM Tools Various tools for the evaluation of applications have been designed, primarily based on ESM. Four of them are briefly presented below. The Context-Aware Experience Sampling Tool (CAES) [Intille et al., 2003a,b] addresses HCI researchers and allows them to acquire feedback from users in particular situation detected by sensors. It runs on PocketPC devices and supports context-aware alarm triggering for the ESM. The main target is to assess the application interface design while concentrating on defined situations, hence decreasing the degree of interruption and annoyance. The flexibility of questions presented to the test subjects is increased by enabling dynamic upload of new protocols. Sequences of questions, multiple choice and multiple response questions are supported, as well as recurrence patterns and randomisation. Audio and photographic feedback can be collected. MyExperience [Froehlich et al., 2007] combines autonomic caption of objective sensor data (passive tracing) and subjective user feedback (active context-triggered ESM). The open-source implementation is based on .NET and available for Windows Mobile devices. MyExperience utilises a three-tiered, event-driven architecture of sensors, triggers and actions - hence supporting conditionally triggered report surveys and SMS/Email notifications. Moreover, it allows for preliminary data collection by providing direct remote access to collected data without any need for physical access to the device under study. An XML schema has been designed for enabling the scripting based remote configuration or control of the evaluation client. Therefore, study customisation (i.e. definition of surveys, triggers and actions) is simplified and accelerated. 30


Momento [Carter et al., 2007] utilises an architecture that comprises a (1) desktop platform being used by the evaluators in order to configure and monitor an experiment, (2) a server component and (3) mobile devices collecting sensor data and applying ESM. The desktop platform can be connected to the fixed applications via a Context Toolkit. The mobile client is realised based on Java and C#. It can be configured via simple text files in which rules for ESM alarm triggering can be defined. The ActivityDesigner [Li and Landay, 2008] focuses on the test-driven design process of UbiComp applications. It refers to the domain of Activity-Centered Design (ACD) and targets an activity-based UbiComp prototyping. Long-term everyday activities of users are captured over an extended time period. A graphical user front-end is used to analyse automatically generated activity journals and to design prototypes for defined storyboards (i.e. activities, actions, scenes and transitions in between). These prototypes can be deployed in a virtual machine (high-end device) or by a web application based upon the Google Web Toolkit. In summary, the ActivityDesginer tries to support the interlinked process of (1) field observations, (2) activity analysis/modelling, (3) interaction prototyping and (4) in situ testing. 2.7.3.3 Trends & Evolution The increasing penetration of smartphones and the availability of equipped sensors could significantly accelerate the evolution of ESM based clients without the need for any extra hardware. The basic requirements still remain the same: avoidance of massive battery consumption, systems crash and negative impact on the user experience. One constraint of earlier work was the very limited number of participants. In contrast, mobile applications can be developed and disseminated more easily nowadays. Distribution frameworks such as Apple AppStore or Google Market allow large scale studies to be conducted. This would turn the human sensor into a crowd sensor. The more feedback is provided by unknown and unbiased test subjects the more fruitful and meaningful the statistical analyses. However, adaptive filter techniques are required to support a focus on situations and users of special interest. Context-aware alarming could be combined with contextaware selection of test users. Both hoped and unexpected effects have to be monitored [Rogers et al., 2007]. Another important aspect is the motivation of users. Long-term studies may be burdensome if the number of ESM triggered feedback requests is too high. A socially or gaming inspired reward mechanism may help. Finally, it is questionable if a test subject feels being observed by strangers. Privacy, security and anonymisation have to be supported. Moreover, interested users would benefit from improved context recognition accuracy. In conclusion, field trials offer essential insight into otherwise hidden results. They are not only useful for the evaluation of UbiComp applications but also for the assessment and gradual optimisation of reasoning/inference algorithms.

31


2.7.4 Emulation & Simulation In the literature, especially in the scope of UbiComp and Context-Awareness, the terms emulation and simulation are sometimes used synonymously without much differentiation. In general, the goal of emulation is to be able to substitute the object that is emulated. The focus of a simulation is more on the modelling of the essential features of the system under test. In general simulation does not necessarily lead to emulation. In particular, a simulation may run slower (or faster) than real time whereas emulation requires the system under test to be at least partly available in a real deployment and invoked in real time. Transferred to the domain of context-aware middleware, at least four basic categories of approaches appear useful: 1. Emulating Context: The system under test (middleware core) is used as is, i.e. prototyped system components are directly invoked. But context does not originate from real world events and real users, instead it is emulated. 2. Emulating Middleware Components: The real life implementation of the middleware core remains untouched. However, the entire middleware framework is extended by further components, e.g. processors, sources and sinks of context information that are considered outside of the real prototype. 3. Emulating Actuation: In order to illustrate the adaptive behaviour of context-aware applications or actuators, a virtualised environment can be created. 4. Middleware Simulation: The system under test is simulated entirely. The contextual input as well as the functionalities of the system components are modelled in an abstract manner. There is no real life deployment required outside the simulation environment. These four approaches are analysed and discussed in more depth below before related work is summarised. 2.7.4.1 Context Emulation The emulation of context aims at ensuring controlled test conditions. In a UbiComp environment it is impractical to send real users around in the real world and ask them to follow a defined behaviour. That is why the real world (or parts of it) are substituted by a virtual world designed by the evaluators. The reaction of the middleware based on events and context changes in this virtual world is then evaluated. The key challenge is to represent the physical world reasonably and realistically and not just randomly. One approach is to define labelled and parameterised sequences of context changes (e.g. “having breakfast at home”). These templates can then be executed by the emulation environment to create a vivid setting autonomously. Alternatively, a Graphical User Interface (GUI) allows for temporary manipulation of selected parameters. The following targets can be addressed: 32


• Context Emulation allows for generating huge amounts of context information. Not only knowledge about the individual user but also the number of users can be easily increased in the virtual test world. Real context is duplicated and associated to pseudo entities (aka avatars) [O’Neill et al., 2005]. The same applies to device context. Therefore, a real middleware system can be probed in order to analyse its scalability behaviour under almost realistic circumstances. • Context reasoning, aggregation and processing in general, can be evaluated if primitive context (e.g. acceleration, location) is emulated. The high-level context (e.g. activity) output of the middleware is then compared against expectations. This requires context to be recordable and replicable. • The adaptation behaviour of applications and other actuators can be observed while manipulating the context. It is essential to make recorded context profiles exchangeable so that the results of different approaches can be compared with each other. Efforts have been made by researchers at the Massachusetts Institute of Technology who shared their sensor data collected in a smart live-in lab [Intille et al., 2006]. A representation schema is for instance proposed in [Hossein et al., 2009]. The need for dataset exchange has also been emphasised in the BoxLab1 project. In their shared resources not only datasets are available for downloads but also annotation schemas. Current research focus is on smart homes but extensions towards a smart world covering everyday activities are desirable. 2.7.4.2 Emulating Middleware Components The target of emulating middleware components is the substitution of hardware (e.g. physical sensors) by software. This approach is useful if new context types are to be added to the system. Before putting too much effort into the design and implementation, the behaviour of the middleware can be estimated beforehand. The effect of the number of components can be measured. This applies not only for context sources and processors but also for context consumers or sinks. Especially in an event-driven system the number of consumers is expected to influence metrics such as the notification time and network load. 2.7.4.3 Emulating Actuation The evaluation of actuating components can be tricky in a UbiComp environment. Imagine a smart home adjusting the heating or light level according to its inhabitants. The smarter and larger the space is, the more expensive becomes classical prototyping. Therefore, evaluators experimented with virtual three-dimensional graphic engines to produce a realistic demonstration of how the environment would react to context events. Ego shooter game engines (Half Life, Quake III Arena, Unreal Tournament) are reused and adapted. 1

BoxLab Wiki Page. http://boxlab.wikispaces.com, accessed 10.05.2011.

33


Obviously this approach fails if we consider a large scale, e.g. an urban smart space. Even in a geographically small area, it is questionable if a realistic and fancy layout would add value and insight to the middleware evaluation. Only if Actuation Emulation is combined with Context Emulation, these techniques might improve understanding and look & feel of selected UbiComp spaces. Still the focus of emulating actuation remains on the end user perspective and experience rather than on the middleware. 2.7.4.4 Middleware Simulation The methodology of a system-level simulation is borrowed from classical communication engineering. The behaviour of the middleware, including all its distributed components, is modelled. Typically, only limited core functionalities and the exchanged messages are included in the simulation model where Discrete Event Simulation can be applied. When building a simulation model the following questions and challenges need to be addressed: • The appropriate degree of abstractness must be identified for the simulation model. A model with too much details will increase development costs and simulation time without providing more realistic results. The model depends on the specific goals of the simulation [Law and Kelton, 1999]. • The parameters (input values) and metrics (output values) must be chosen. In a UbiComp setting, the definition of reasonable scenarios is extremely complex. Not only the user behaviour but also the application behaviour (or in general the requirements of context consumers) has to be estimated. This comprises the number of context requests/subscriptions per unit time, the amount and frequency of context changes. • In addition, as far as a distributed middleware is to be evaluated, knowledge about the behaviour (e.g. response time, processor and memory consumption) of each component is required. The key is finding simple parameters that are able to represent the real system without simplifying too much. Obviously it is difficult -if not impossible- to build a realistic simulation model without ever having implemented a prototype of the middleware and feeding the simulation parameters with metrics determined in the real testbed. The essential advantage of system-level simulations is that parameters can be varied easily to investigate various scenarios. Parameters like the number of users, number of devices, the amount of context types, the context request frequency can be used to estimate the large-scale performance of a middleware. Network load, context traffic and response times are interesting metrics to observe. If modelled well, the simulation can help to identify bottlenecks of the system and provide guidelines for improving the concepts and algorithms. To facilitate comparison of results obtained by different researchers common simulation scenarios, i.e. sets of parameters, need to be defined in the future.

34


2.7.4.5 Simulation/Emulation Tools Categories of emulation and simulation are not necessarily differentiated in related literature. There is a body of research which concentrates on three-dimensional graphical user interfaces. Testers can navigate around in the first person perspective and see the (emulated) actuation capabilities of the smart room based on emulated context changes, as expanded below. UbiWise [Barton and Vijayaraghavan, 2003] is built on the Quake III Arena graphics engine and allows multiple users to participate in interactive UbiComp scenarios. The physical environment view is simulated by a subcomponent called UbiSim whereas a device view is provided by a separated module, realised in Java, named Wise. As an example the authors emulate a UbiComp camera and an actuating picture frame. Real web service interaction is supported as well. The emulated camera can be controlled in the Wise view and it can be carried around in the UbiSim 3D-simulator environment. Spatial and environmental interaction of devices and users is focused. A Hybrid Test and Simulation Environment [Morla and Davies, 2004] has been developed by researchers at Lancaster University. In contrast to UbiWise, their approach does not provide a three-dimensional GUI interface. According to the System Under Test (SUT) the interfaces of the evaluator components are based on Web Services (HTTP and SOAP). Important features are centralised logging and the support of configuration and automated test scripts. The simulation environment focuses on the evaluation of locationbased applications under consideration of different radio access technologies. Quantitative measurements such as the response and transport delay have been taken. CIVE [Jang et al., 2004] presents a context-based interactive System for distributed virtual environments. It tries to bridge the gap between real and virtual cyber-world with focus on how to deliver real UbiComp interaction (e.g. gestures) into cyber-systems. The submodule ubi-UCAM generates contexts and user profiling out of real world interaction, whereas NAVER cares for a virtual heritage and sensing of users’ activities in the cyber environment. Another component called INTERFACE connects those two. TATUS [O’Neill et al., 2005] also aims at building a virtual ubiquitous computing environment. The complexity is reduced by emulating sensors and actuators. Users’ devices are not emulated but the original ones are connected to the simulator. Further, rapid scenario and virtual world modelling are facilitated by providing a design toolkit. This way, TATUS supports realism, software flexibility, experiment usability and simulator extensibility. Further, a Wireless Network Simulator has been designed in order to evaluate the performance of communication systems used in UbiComp environments. Its main purpose is to model channel conditions based on distance and obstacles (human beings, walls, etc.). UbiREAL [Nishikawa et al., 2006] is another simulator addressing virtual 3D spaces. Its developers extend previous work by generating more realistic context and supporting systematic testing. Both virtual and real devices can cooperate via Ethernet. Besides a network simulator and the 3D GUI interface, UbiREAL comprises a simulator for physical 35


quantities and a test suite. The first one models the change of physical conditions based on triggered actions (e.g. the room becomes warmer if the heating has been switched on). The latter one can be used to define action rules and expected outcomes in a formal representation schema, hence allowing for autonomous validation of results. CAST (Context-Awareness Simulation Toolkit) [Kim et al., 2006] concentrates on a virtual home domain and allows creating virtual context. Security aspects are taken into consideration when sharing such context between simulator components. Conceptually a Virtual Device Manager is responsible for emulating sensors and context consumers. Pseudo user entities can be generated by a Virtual Person Manager and the Virtual HomeMap Editor allows for designing the virtual smart space. The two-dimensional graphical presentation is based on Macromedia Flash and fails to provide a realistic impression of the setting. The comic-like approach is not suited for middleware evaluation either. UbiHolo [Barbosa et al., 2007] is rather a UbiComp software paradigm than a simulator. However, the authors’ work deserves attention because it contains one of the few approaches to apply system-level simulation in the UbiComp domain. To evaluate the large-scale performance of their concept, a peer-to-peer simulator called p2psim has been utilised. Siafu

1

is a representative example of a Java-based context emulator. Based on a two-

dimensional GUI it allows the comfortable manipulation of context temporarily. Since it relinquishes the three-dimensionality, it is suited to cover (spatially) larger areas such as urban smart spaces. Siafu can generate its own context (e.g. by defined user movements) and in parallel incorporate real world context acquired from sensors. Datasets can be produced for machine learning. By plugging an application to it, effects of context changes can be demonstrated and visualised.

2.7.5 Comparison of Methodologies Table 2.3 summarises the main aspects discussed above and compares the approaches against each other.

1

Siafu: 10.05.2011.

An Open Source Context Simulator.

36

http://siafusimulator.sourceforge.net, accessed


Table 2.3: Overview of Evaluation Strategies Evaluation Technique

Targets

Requirements

Prototyping

Most realistic proof-ofconcept for end-to-end scenarios; provides input parameters for simulations

Field Trials

Assess Reasoning/Inference accuracy, collect feedback & training data

Context Emulation

Emulating Middleware Components

Real-world context is extended or replaced by creating a virtual world; prototypes can be fed with input in order to evaluate scalability Substitution of hardware (e.g. physical sensors) by software; reduction of costs in large scale UbiComp environments; Estimation of consequences when extending the middleware

Emulating Actuation

Providing a realistic outlook of context-based actuation in a smart environment

Middleware Simulation

System-level analysis large-scale behaviour

of

Implemented applications and test persons

Context-aware experience sampling, dynamically reconfigurable by evaluators, easily distributable and deployable on everyday devices For evaluating context processing, reasonable models must be defined (e.g. taken from recorded real-life context and associated to avatars)

Examples Active Badge [Want et al., 1992], Active Map Service [Schilit and Theimer, 1994], Cyberguide [Abowd et al., 1997], GUIDE [Davies et al., 1999], Conference Assistant [Dey et al., 1999a], Office Assistant [Yan and Selker, 2000], Gaia [Rom´ an et al., 2002] MyExperience [Froehlich et al., 2007], Momento [Carter et al., 2007], CAES [Intille et al., 2003b] [Intille et al., 2003a], ActivityDesigner [Li and Landay, 2008] Siafu, UbiWise [Barton and Vijayaraghavan, 2003], TATUS [O’Neill et al., 2005], UbiREAL [Nishikawa et al., 2006]

Emulation models must reflect the behaviour of the real hardware

UbiWise [Barton and Vijayaraghavan, 2003], TATUS [O’Neill et al., 2005]

The influence of the actuation must be fed back into the system by producing emulated context (e.g. heating ⇒ warmth) Abstract Simulation model, reasonable parameter assumptions (taken from prototypes)

CIVE [Jang et al., 2004], UbiWise [Barton and Vijayaraghavan, 2003], TATUS [O’Neill et al., 2005], UbiREAL [Nishikawa et al., 2006]

37

UbiHolo [Barbosa et al., 2007]

3 Research Scope The research objectives have been briefly introduced in section 1.2. After having recapitulated related work and having defined required terminology in the previous sections, this chapter provides a more detailed and narrowed presentation of challenges, targets and scientific contributions addressed.

3.1 Research Challenges & Objectives The scientific contribution presented in this thesis aims at experimenting with a novel Context Provisioning Middleware with Support for Evolving Awareness (C-ProMiSE). As explained in chapter 2, concurrent approaches reveal limitations hindering an easy and coherent access to manifold contextual information. Particularly the evolution of context and situation aware applications has not been supported sufficiently in earlier work. It is the subject of research whether and to what extent C-ProMiSE would allow for gradual extension supporting any sensor type (physical, virtual, logical), application domain and any processing/reasoning mechanism. This way, numerous application domains could be covered to assist users in their everyday life proactively. This chapter details the research scope, focus and objectives. Hence, it serves as a driver for the design concepts of context representation & management (chapter 4) as well as context processing & reasoning (chapter 5) and the subsequent evaluation and experimentation (chapter 6). Accordingly, the overall investigation can be subdivided into four objectives as expounded below. 1. Context Management: The work presented in this thesis aims at investigating a particular model of management for its suitability; the applicability of a producerconsumer-broker role model is analysed. Can it serve as a design principle to realise a generic and extendible context provisioning middleware that supports a broad variety of context-aware services and applications in a ubiquitous environment? The research presented in this thesis examines the context management functionality of the middleware design with regard to the following objectives that have not been fully addressed in related work. How can simple and coherent access to rich context information be supported, regardless of device and network heterogeneity? Which interface design allows an efficient and effective sharing (i.e. acquisition and diffusion) of context data between context sources (i.e. sensors) and context sinks (i.e. context-aware applications, services and actuators)? The appropriateness of both synchronous on-demand queries 38

3. Research Scope

and asynchronous event-based context updates have to be investigated. In addition to the coordination of communication, the middleware needs to provide mechanisms for temporary and ultimate storage of context. Most importantly, the middleware has to support emerging UbiComp applications since there is no single killer application proposed by the research community. On the contrary, the strengths of context-awareness can best be leveraged if considering and supporting diverse usage scenarios, application domains and the entire lifecycle of applications. To what extent can the proposed management approach support the required functional scalability and extendibility? Furthermore, new domains are likely to arise in the future. The same applies to the variety of context sources consequently. A generic middleware has to support such application and sensor variety without requiring an entire redeployment. In addition, as the number of context sources and sinks is expected to increase tremendously, the physically scalability of the system is to be investigated. In general, security and privacy are essential functionalities in context-aware systems. Albeit the selected management model would support a straight-forward incorporation of user-defined access policies, the related objectives and detailed concepts are out of scope of this thesis and will not be discussed in the following chapters. 2. Context Modelling & Representation: The research presented in this thesis aims at investigating the support of resource constrained mobile devices with regard to processing, memory and energy consumption. The applicability of a lightweight representation schema is analysed. Is it restricted to certain context types or able to represent multifarious context data? In addition the feasibility of incorporating meta data associated to each context instance is to be examined, e.g. the probability, the validity period, the associated entity, the source of information. Finally, various types of entities have to be supported equally since the inhabitants of the smart place may be objects, persons, devices, smart-its or groups thereof. The context model needs to support a dynamic association of context to these diverse entities correspondingly. 3. Context Processing & Reasoning: In order to cope with characteristics of multidomain context-awareness, the generic middleware ideally supports diverse context processing and reasoning capabilities transparently. Due to resource constrained mobile devices and the envisaged scalability, an approach utilising distributed processing and reasoning is to be applied. How can several processing stages be supported rising from primitive processing up to high-level inference based on artificial intelligence or knowledge-based systems? Specifically, research objectives aim at investigating the applicability of Probabilistic Reasoning to aggregate primitive context and infer users’ everyday activities. The design of a generic reasoning component is to be investigated allowing incremental adaptation of knowledge models based on users’ feedback. 39

3. Research Scope

4. Evaluation & Experimentation: A middleware concept covering management, representation and processing of context has to be evaluated twofold. Based on a prototype implementation of selected concepts and middleware components, the functionality and general applicability are assessed. Furthermore, for determining the system behaviour with regard to scalability, a performance evaluation is to be carried out based on system-level Discrete Event Simulation (DES) in conjunction with an emulation of both user behaviour and architectural components. The context provisioning delay and the influence of caching are of specific interest. Furthermore, the performance of diffusing context is to be evaluated. Therefore, an appropriate evaluation methodology is to be defined and applied. More detailed objectives and deliberations are described at the beginning of each of the consecutive chapters (sections 4.1, 5.1 and 6.1).

3.2 Hypothesis The hypothesis sums up the research objectives and reads as follows: A producer-consumer-broker role model can serve as basis for an effective context provisioning middleware capable of not only scaling physically but scaling with context processing capability to support context-based, context-aware and situation-aware ubiquitous applications and services. In a rapidly changing ubiquitous environment a lightweight context representation schema is able to support broad application domains and context categories. Context can be aggregated in various abstraction levels based on subsequent context processing stages that finally allow for inferring high-level context, e.g. based on clustering and probabilistic reasoning. A methodology covering prototyping, field tests, emulation and system-level simulation can be effective both qualitatively and quantitatively in evaluating pervasive computing systems. Discrete event simulation can utilise empirical simulation models derived from black-box prototype assessments of middleware components to estimate the large-scale performance of such systems.

3.3 Scientific Contributions 3.3.1 Publications The majority of the concepts described in chapters 4 and 5 and their evaluation (cp. chapter 6) has been scientifically published. Therefore, the research work has been presented to and discussed by experts in peer-reviewed conferences, workshops and journals. Table 3.1 provides a list of relevant publications.

40

3. Research Scope

Table 3.1: List of Scientific Contributions Focus Area

References

Context Management

• S.L. Kiani, B. Moltchanov, M. Knappmeyer, and N. Baker. Analysis of the energy conservation aspects of a mobile context broker. In The 4th Conference on Smart Spaces (ruSMART 2011), St.Petersburg, Russia, August 2011b • M. Knappmeyer, N. Baker, S.L. Kiani, and R. T¨ onjes. A context provisioning framework to support pervasive and ubiquitous applications. Smart Sensing and Context, pages 93–106, 2009a • S.L. Kiani, M. Knappmeyer, N. Baker, and B. Moltchanov. A federated broker architecture for large scale context dissemination. Computer and Information Technology, International Conference on, 0:2964–2969, 2010a • M. Zafar, N. Baker, B. Moltchanov, J.M. Gon¸calves, S. Liaquat, and M. Knappmeyer. Context Management Architecture for Future Internet Services. ICT Mobile Summit 2009, 2009 • B. Moltchanov, M. Knappmeyer, C.A. Licciardi, and N. Baker. Context-aware content sharing and casting. In Proceedings of ICIN, 2008 • N. Baker, M. Zafar, B. Moltchanov, and M. Knappmeyer. Context-Aware Systems and Implications for Future Internet. Towards the Future Internet, page 335, 2009

Context Modelling

• M. Knappmeyer, S.L. Kiani, C. Fr´ a, B. Moltchanov, and N. Baker. ContextML: A light-weight context representation and context management schema. In In Proceedings of IEEE International Symposium on Wireless Pervasive Computing, pages 367 – 372, May 2010a • A. Ikram, N. Baker, M. Knappmeyer, and R. T¨ onjes. A chemical model to enable context awareness. In Proceedings of 4th IFIP International Conference on New Technologies, Mobility and Security, 2011

Context Processing and Reasoning

• M. Knappmeyer, R. T¨ onjes, and N. Baker. Modular and extendible context provisioning for evolving mobile applications and services. In 18th ICT Mobile Summit, 2009b • B. Moltchanov, M. Knappmeyer, O. Fuchs, and E. Paschetta. Context management and reasoning for adaptive service provisioning. In Ultra Modern Telecommunications & Workshops, 2009. ICUMT’09. International Conference on, pages 1–6. IEEE, 2009 • M. Knappmeyer, E. Wittkorn, S.L. Kiani, R. T¨ onjes, and N. Baker. Context provisioning middleware with probabilistic reasoning support. In Proceedings of the 20th Future Network and Mobile Summit, Warsaw, Poland, 2011c • S.L. Kiani, A.M. Anjum, N. Bessis, R. Hill, and M. Knappmeyer. Context parsing, processing and distribution in clouds. In Third International Conference on Intelligent Networking and Collaborative Systems (INCoS-2011), Fukuoka, Japan, November 2011a

Continued on Next Page. . .

41

3. Research Scope

Table 3.1 – Continued Focus Area

Evaluation

References

• M. Knappmeyer, S.L. Kiani, R. T¨ onjes, and N. Baker. Modular context processing and provisioning: prototype experiences. In Proceedings of the 4th ACM International Workshop on Context-Awareness for Self-Managing Systems, CASEMANS ’10, pages 8:53–8:58, New York, NY, USA, 2010b. ACM • M. Knappmeyer, S.L. Kiani, N. Baker, A. Ikram, and R. T¨ onjes. Survey on evaluation of context provisioning middleware. In Proceedings of the Second Workshop on Context-Systems Design, Evaluation and Optimisation in conjunction with the 24th International Conference on Architecture of Computing Systems (ARCS). IEEE, 2011b • M. Knappmeyer, D. Brettschneider, and S.L. Kiani. Context source: A smartphone application for serving context to a generic context provisioning system. In Proceedings of the Second Workshop on Context-Systems Design, Evaluation and Optimisation in conjunction with the 24th International Conference on Architecture of Computing Systems (ARCS). IEEE, 2011a • S.L. Kiani, M. Knappmeyer, E.S. Reetz, and N. Baker. Effect of caching in a broker based context provisioning system. In P. Lukowitz, G. Kortuem, and K. Kunze, editors, Proceedings of The 5th European Conference on Smart Sensing and Context (EuroSSC 2010), volume LNCS 6446 of Lecture Notes in Computer Science, pages 108–121. Springer, Heidelberg, November 2010b • E.S. Reetz, M. Knappmeyer, S.L. Kiani, N. Baker, and R. T¨ onjes. Performance evaluation of a context provisioning middleware. In International Conference on Computing, Networking and Communications, Communication Software and Services Symposium (ICNC’12 - CSS), Maui, Hawaii, USA, January 2012

3.3.2 Individual and Collaborative Research The following paragraphs discuss the individual contributions (see also section 7.1) and clarify collaborative work. An early version of the context management concept and the context modelling schema originates from the collaboration in the European research project “Context Casting (CCAST)” 1 . Specifically, the Context Meta Language (ContextML) schema has been introduced by the consortium member Telecom Italia. However, in the scope of the individual research presented in this thesis the original schema has been significantly extended with focus on self-management capabilities and context processing extendibility. Major extensions have been published in [Knappmeyer et al., 2010a]. Similarly, the basic role model, i.e. the definition of consumers and providers of context, originates from C-CAST. However, this architectural basis has been extended by incorporating (1) broker federation, (2) a QoC-supporting proxy query mechanism and (3)

1

The European FP7 research project Context Casting (C-CAST) aims at evolving mobile multimedia multicasting to exploit the increasing integration of mobile devices with our everyday physical world and environment. http://www.ict-ccast.eu; accessed 06.02.2012.

42

3. Research Scope

caching mechanisms to finally derive the C-ProMiSE concepts. These major architectural extensions are described in [Knappmeyer et al., 2009a]. The applicability of probabilistic reasoning in such an architecture was out of scope of C-CAST and constitutes another individual contribution. This work has been discussed in [Knappmeyer et al., 2011c]. Moreover, the specific realisation of the C-ProMiSE middleware, i.e. the design of the Context Provider and Context Source components and their implementation in a prototype testbed has been conducted independently. Related contributions are presented in [Knappmeyer et al., 2010b] and [Knappmeyer et al., 2011a]. The evaluation methodology (cp. [Knappmeyer et al., 2011b]) and its application (cp. [Kiani et al., 2010b] and [Reetz et al., 2012]) resulted from close collaboration with Mr. Eike Steffen Reetz (University of Applied Sciences Osnabr¨ uck) and Dr. Saad Liaquat Kiani (University of the West of England). However, all black-box assessments and the empirical simulation model have been realised independently for the specific C-ProMiSE middleware.

43

4 Context Representation & Management of C-ProMiSE This chapter aims at deriving both a novel context representation concept and the architectural context management basis for the C-ProMiSE middleware. It also covers their subsequent implementation: ContextML, an XML-based context representation schema, is introduced before finally presenting the specific software design of the Context Broker, one of the main architectural components of the middleware.

4.1 Targets and Methodology An adequate context representation and modelling schema is addressed according to the following set of objectives. First the representation of multi-domain context, i.e. various context types and context parameters, is to be supported. This comprises both efficient modelling and exchange between network components. Furthermore, the middleware design aims at facilitating dynamic association of context to various entity types, e.g. users, devices, smart-its and smart spaces. In alignment to the argumentation flow in section 2.4 meta data needs to be represented and associated to context instances. The objectives of context management cover a transparent support of device and network heterogeneity as well as coherent access to context for multi-domain context-aware applications, services and actuators. Moreover, sensor data has to be acquired from diverse physical, virtual and logical sensors. As far as the distribution of context is concerned, C-ProMiSE aims at supporting both synchronous on-demand queries and asynchronous event-based queries. Efficient storage and management of context instances is another target. Overall, the management design tries to allow for distributed and gradual context processing and reasoning in various abstraction layers. This way, the support of evolving and emerging context-aware applications is tackled. Not only physical scalability, i.e. support of large amounts of both context sources and sinks, but also functional scalability are envisaged by the use of self-configuration and self-management capabilities. To address these objectives, the context modelling and representation concepts are introduced before presenting the architectural middleware framework in detail.

4.2 Context Representation Model The benefits and drawbacks of existing context modelling approaches have been discussed in section 2.2. For modelling context in the C-ProMiSE framework, the context representa44

4. Context Representation & Management of C-ProMiSE

tion schema illustrated in Figure 4.1 is applied. Each context instance (cp. Definition 2.4) comprises exactly one object of context meta data (cp. Definition 2.3) and the context data itself. This light-weight design (especially if compared to ontological modelling) has been investigated to cope with the dynamics in a rapidly changing ubiquitous environment. In addition, resource constraint mobile devices lack battery and memory capacities and require an easily processable modelling schema. The details are described in the following subsections. First of all the theoretic concept is introduced before presenting its XML-based implementation. Context Instance Context Instance

1

1

1

Context Data Context Data

1

Context Meta Data Context Meta Data 1

0..n

Context Parameter (Simple)

1..n

0..n

Context Parameter (Array) Context Parameter (Array)

1

0..n

Context Parameter (Struct) Context Parameter (Struct)

1

1

Context Scope Context Scope

1

Associated Entity Associated Entity

1

0..1

0..1

Validity Period Validity Period

Processing Processing

1

1

1

1

Entity Type Entity Type

1

Entity ID Entity ID

1

Detection Time Detection Time

1

Expiration Time Expiration Time

1..n

Sensor Source Sensor Source

0..n

Processing Component Processing Component

Quality of Context Indicator Quality of Context Indicator

Figure 4.1: Context Representation Schema. The dotted lines indicate optional elements.

4.2.1 Fundamental Context Representation Concept Due to the heterogeneity of context information, a flexible and extendible model has been designed. A context instance consists of a set of simple parameters, arrays of similar parameters and parameter structures of different parameters. Parameters may hold alphanumerical strings, integers or double values. Further, context is categorised into context scopes. Context may only be updated and exchanged on an atomic basis per scope. This hierarchical design concept shows similarities to object oriented modelling, the context scope being interpreted as model class. The subordinated parameters refer to class member variables. If new context types are to be added, a unique scope identifier and the corresponding parameters have to be defined. The concept can be compared to key-value based context modelling where the triple of entity identifier, entity type and context scope refers to the key and the context parameters to the value.

4.2.2 Context Meta Representation Each context instance must contain mandatory context meta data and can be further detailed by optional attributes. Most importantly, the context scope is specified. The second mandatory parameter refers to the entity the context is associated to. Since diverse 45


kinds of entities (cp. Definition 2.1) are of interest and have to be supported, the meta model does not only contain a unique identifier for the entity but also its type. New types can be successively added to the model. Classical ubiquitous scenarios may be adequately modelled with the entity types device and user but more complex systems such as smart place scenarios may require the addition of other types (room, furniture, etc). Entity types can be used by C-ProMiSE for autonomous translation and association of context. This association can be dynamic or static. For instance, the association between device and user is almost static. An association between user and the room he is located in is far more dynamic. A third mandatory element of the meta model is the validity period of the context. Each lifetime of a context instance is limited to a specific amount of time after which it becomes invalid. However, expired context instances may still be useful as historic context for inferring the current context. Furthermore, information about where the context originates from (e.g. sensor, device identifier) and which architectural component was involved in the context detection process can be optionally attached.

4.2.3 Formal Model The following formal representation can be derived from the theoretical context model. CE,t denotes the entire set of available context information for entity Ei,j (a compound of unique entity identifier eid = i and entity type etype = j) at a given time t. Sj,t denotes the j-th context scope and contains mj context parameters, n being the number of context scopes. CE,t = {S1,t , S2,t , ..., Sn,t } E = {ei , etype } Sj,t = {c1,j,t , c2,j,t , ..., cmj ,j,t }

(4.1) (4.2) (4.3)

This formalism allows to extract an n-dimensional context feature space. Each scope relates to a dimension and corresponding graphical axis. A temporal snapshot can be used to visualise and calculate the contextual proximity of entities in this feature space, which may be very useful for activity or situation recognition. A 3-dimensional example is depicted in Figure 4.2. The aggregation of context parameters and layered situation recognition will be discussed in chapter 5. Specifically the context feature space will be utilised for group detection (cp. section 5.3.5.1).

4.2.4 Implementation of Context Representation For implementation of the context modelling concept, an XML based meta schema has been designed. It allows for both machine interpretation and human readability. The entire ContextML (Context Meta Language) schema is presented in section A.1.1. Selected context instances are depicted in section A.1.2. ContextML is used to represent not 46


S3

E1,1

E2,1 E3,1 S1 E4,1 S2

Figure 4.2: 3-dimensional Context Feature Space only context but also middleware coordination messages as explained in detail below, cp. sections 4.3.3 and A.1.3. The XML presentation ensures wide interoperability and processing ability on resource constraint mobile devices – especially if compared with formal semantic ontologies.

4.3 Context Management Concept This section presents the architectural context management concept.

4.3.1 Design Considerations First of all, basic design is discussed and the context management model is derived. The argumentation flow covers the general broker pattern and its application to context-aware frameworks as well as appropriate communication paradigms. 4.3.1.1 The Broker Pattern An overview of the general broker architectural design pattern has been presented in [Buschmann et al., 2008]. It is well known for its utilisation in software and system design processes and can aid in structuring distributed software systems with decoupled components that interact by remote service invocations. The broker component is responsible for coordinating communication, such as forwarding requests and transmitting results and exceptions. In general, brokers increase interoperability, flexibility, maintainability and changeability while partitioning functionality into independent components in a location transparent way. Therefore, the system needs to specify interfaces in an Interface Description Language (IDL) and utilise an appropriate compiler. In addition, brokers obligatorily provide a registration and lookup service so that distributed system services can be made available and discovered during run-time. All these characteristics are particularly desirable in a distributed context provisioning middleware which is targeted in this thesis. The most prominent example of a broker implementation is CORBA [Vinoski, 1997], originally developed as an extension of C++ to support remote communication between 47


distributed software components and network services. CORBA has been standardised by the Object Management Group (OMG) and foresees an Object Request Broker (ORB) to manage remote resources and interaction between networked applications. In the scope of context management frameworks, the broker pattern is for instance applied in CoBrA [Chen et al., 2003a,b] for coordinating the communication and information flow between context producing and context consuming system components. The differentiation of these roles, a classic model, enables successive extension of functionalities. With regard to context provisioning, the producer-consumer role model can support the addition of new context detection and processing capabilities, hence broadening the range of application domains and their extent of awareness. The broker pattern is an ideal candidate for facilitating the coordination between those components, i.e. both provisioning of and access to context. However, a single centralised broker constitutes a single point of failure and may negatively influence the reliability of the entire system. Furthermore, it may be the bottleneck of the system as far as scalability and query performance are concerned. In conclusion of these design principles and those discussed previously in section 2.5.3 a hybrid composition of producer-consumer role model with federated brokers seems to be an adequate means for providing the envisaged flexibility and extendibility while supporting heterogeneous sensors, devices, networks and applications. In related work, a framework of distributed components is commonly described as especially useful for increasing scalability while keeping control of privacy and security. Additionally, a hierarchy of brokering elements is believed to aid in realising storage capabilities and the provisioning of historic context. The conducted review of architectural design principles highlights limitations in related work as far as the overall support of various application domains and processing functionalities are concerned. Whereas most of the existing solutions predefine their widgets or context producers in advance, the middleware envisaged in this thesis aims at allowing for self-managed addition of new context sources and context processing capabilities during run-time. Accordingly, based on these deliberations, this thesis concentrates on the investigation of a related architecture concept, its specific implementation and experimentation in a prototype environment. 4.3.1.2 Communication Paradigms A brief overview of communication paradigms and their application in related context provisioning frameworks have already been presented in sections 2.5.5 and 2.5.6. Synchronous invocation enables services and applications to request context information directly on-demand. As long as the required information is processed and possibly even acquired from sensors the communication thread is blocked. In today’s multi-threading environments this circumstance is not critical. However, the active invocation call usually needs resources as long as it is open – which is problematic for energy constrained devices, specifically for mobile handheld devices. Hence, fast responses are particularly important.

48


Battery consumption of recent smartphones has for instance been investigated by Kiani et al. [2011b]. Asynchronous context exchange foresees event-based publication of context updates. Usually the consumer needs to express interest in certain context changes (or other events) by specifically subscribing to offered information channels [Meier and Cahill, 2005]. Channel models may further allow for the detailed definition of events by defining threshold values, exact constraint matches, etc. In asynchronous communication the request and response, i.e. context notification, are timely decoupled from each other. This is exactly one of the challenges when applying asynchronous communication to the domain of mobile devices which are not necessarily constantly reachable. A backward communication channel is required for delivering the notifications. In most of the current push protocol implementations (e.g. MQ Telemetry Transport) this backward channel has to be established and maintained by the mobile device due to potential lack of reachability vice versa because of Network Address Translation (NAT), firewalls and Mobile Network Operator (MNO) specific restrictions. This communication channel requires energy constantly although it might not be required at all. In conclusion the C-ProMiSE middleware design concept aims at supporting both synchronous and asynchronous context queries.

4.3.2 Architectural Management Model As key requirement of the C-ProMiSE middleware, functional, spatial and timely decoupling need to be supported. Therefore, a modular consumer-producer model is applied as architectural basis with one or more intermediating broker(s) facilitating the communication and coordination. Figure 4.3 depicts an overview of the fundamental components. Their high-level functional description is introduced below, before discussing the communication flow and the middleware coordination in more detail. Context Consumer (CxC) Provider Lookup

Context Query (Proxy)

Context Broker (CxB)

Context Query (direct)

Register

Update Context

Context Provider (CxP) Context Query (Proxy)

Context Source (CxS)

Figure 4.3: Architectural Components, High-level Overview

49


4.3.2.1 Context Provider A Context Provider (CxP) is an architectural component producing context instances of a specific context scope (e.g. position, activity). It is invoked synchronously. As illustrated in Figure 4.4 each CxP may access raw data from physical, logical and virtual sensors. The kind of internal data processing strongly depends on the desired output and may consider aggregation, filtering and feature extraction mechanisms. Reasoning and inference based on artificial intelligence and knowledge-based systems may also be applied. In addition, a CxP may internally manage an internal database for persistent storage or caching. Besides accessing sensors, the architectural concept foresees the dependency of a CxP from other (in general more primitive) context instances. Therefore a CxP can advertise its requirements for context parameters, along with its processing capabilities and accessibility. During synchronous invocation, this input context is autonomously provided. Details of the registration process are given in section 4.3.3.2, the query mechanisms are explained in section 4.3.3.5. Regardless of required input and internal processing, each CxP has to produce context information, encode it in the ContextML representation format and respond synchronously upon invocation. Optionally, a CxP may provide mechanisms for remote configuration and monitoring of the internal processing. The configuration API may grant access to specific settings, e.g. sampling rate, sensor access details and restrictions. Monitoring facilities can be utilised to collect and visualise statistics (e.g. processing times, query response times, number of queries, database size, error rates). Although there is conceptually no limitation, both configuration and monitoring are typically made available for administrators through web servlets which can be easily accessed by common web browsers. Since the only mandatory requirement of a CxP is to encode context in ContextML representation and to be synchronously invocable, the concept of a CxP supports device and network heterogeneity to a significant extent. CxP components can be deployed across diverse networks and hardware. They hide the complexity and unify access to context originating from heterogeneous sensors. Most importantly, the development and deployment of a new CxP can increase the awareness successively and incorporate new types of context into the C-ProMiSE middleware. 4.3.2.2 Context Source The concept of a Context Source (CxS) is very similar to that of a CxP. While the CxP has to be invoked synchronously, a CxS asynchronously pushes its context per definition. This may happen either periodically in defined intervals or event based, i.e. if context matches certain constraints. The differentiation between CxP and CxS has been chosen for the following reasons. First of all it enables an event-based context update. Secondly, not all network entities are accessible for synchronous queries constantly. This applies for instance to smartphones whose Internet connectivity may be temporarily interrupted or hindered by firewalls, port

50


Context Provider (CxP)

input context

Advertisement and Coordination

Sensor Data Acquisition and Preprocessing

Configuration

Monitoring

Sensor(s)

Context Processing

Storage

cached sensor data

sensor data

ContextML Parser

C-ProMiSE

output context

Administrator Figure 4.4: Context Provider Functionalities and Interaction. The dotted arrows and boxes indicate optional interactions and functionalities. restrictions, private networks, or Network Address Translation (NAT) performed on WiFi Access Points. Asynchronously pushing context to C-ProMiSE components deployed in the infrastructure overcomes these problems. 4.3.2.3 Context Consumer A Context Consumer (CxC) is a component requesting and requiring context. It may be any context-based, context-aware, or situation-aware application, service or actuator. The CxC utilises context lookup and diffusion mechanisms provided by C-ProMiSE. 4.3.2.4 Context Broker A Context Broker (CxB) has been designed as component facilitating the coordination and context exchange between CxP, CxS and CxC components. Its functionalities are depicted in Figure 4.5. The CxB is responsible for maintaining a registry and lookup service which allows a CxP to register (i.e. advertise) and a CxC to query the appropriate CxP. Furthermore, a CxB provides storage capabilities for context instances. As long as the context is valid (i.e. it has not expired yet), context is stored in a Context Cache database. After expiration it is optionally moved to a Context Storage database holding only historic context entities. An essential functionality is the proxy query service (cp. section 4.3.3.5). It enables a CxC to coherently query context without having to query the specific CxP components itself. Instead, the CxB collects all required context and responds to the CxC directly. Similarly to the CxP, a broker optionally provides mechanisms for remote configuration and monitoring.

51


CxP Registry and Lookup Service

CxP Advertise

CxP lookup

Ctx Query

CxC

Proxy Query Service

Ctx Query

Context Storage Service (Historic Context)

Context Caching Service (Valid Context)

Configuration

Monitoring

Ctx Push

CxS

CxP Lookup

CxP

Context Broker (CxB)

Administrator Figure 4.5: Context Broker Functionalities and Interaction. The dotted arrows and boxes indicate optional interactions and functionalities.

4.3.3 Component Coordination – Middleware Functionalities The architectural distribution of middleware functionalities (as introduced in section 2.5.1) requires coordination of the information flow and the invocation amongst the defined components. Therefore, the ContextML schema was designed for representing not only context instances but also brokering and coordination messages between C-ProMiSE components. The realisation of functional composition is explained in the following paragraphs. Where required, specific interaction flows will be introduced consecutively. 4.3.3.1 Sensor Data Acquisition The sensor data acquisition of the C-ProMiSE middleware is performed by and encapsulated in CxP and CxS components. These are designed to provide access to a wide range of physical, virtual and logical sensors each applying its own specific sensor input preprocessing. The handling of bulk readings may benefit from an optional internal caching. Key requirement is the association of an entity to the sensor data, otherwise the information cannot be handled and processed in C-ProMiSE. It is important to highlight that middleware components do not exchange raw sensor data but only context. Therefore, the CxP / CxS needs to transform the sensor readings into a proper context instance represented in ContextML. 4.3.3.2 Context Lookup and Discovery Since context is provided by CxP components primarily, this section introduces the CxP registration procedure, also referred to as advertisement. In addition, the CxB’s lookup functionality is explained in detail.

52


Basic Context Advertisement Procedure Each C-ProMiSE CxP advertises its communication endpoint, i.e. its accessibility and its context provisioning capabilities to a CxB. Figure 4.6 presents the content of an advertisement; an example is presented in Listing A.16. The identity management of the CxPs foresees a unique ID and a version number to support evolving providers. The CxP informs the CxB (cp. Figure 4.7) about its root URL and in addition a relative URL per scope. The combination of root and relative URL allows for synchronously invoking the CxP for querying context based on HTTP according to the Representation State Transfer (REST) [Fielding, 2000] principle. Each lookup entry is only valid for a limited time and therefore has be to renewed periodically by either sending a full advertisement or a smaller keep-alive advertisement message (see Figure 4.6 for the differentiation) if nothing has changed at the CxP. In case of a mobile CxP, basic mobility is supported this way. In addition, faulty or undeployed CxP components are automatically removed from the system. The advertisement procedure has been designed to enable self-management and support functional evolution: New providers and new context scopes can be added successively. Moreover, each CxP registers with the Lookup Service with information about the context it can provide to the middleware. In addition to the definition of the scope identifier, each context parameter is described – by human readable text and data type: The context parameter maybe a simple parameter, or a compound structure/array of parameters. Required input context and average context provisioning time are key elements for realising sophisticated query mechanisms as explained in section 4.3.3.5. Each input context parameter can be defined to be mandatory or optional. Furthermore, the information gain is a given prerequisite for enabling quality of context based context queries as discussed below. Entity Translation C-ProMiSE supports a variety of entity types (e.g. user, room, device). Putting these different types into relation, i.e. enabling an autonomous entity translation, the middleware is for instance able to derive user-related context based on environmental sensors associated to the room the user is currently in. A mapping between user and device may for instance be performed by a UserProfileCxP as further detailed in section 5.3.3.1. In general, CxP components can advertise their capability to relate different entity types to each other, i.e. to provide entity translation. To accelerate these dynamic relation lookups, the CxB caches the results internally for a configurable amount of time. If the CxB cannot solve the required translation, it queries the corresponding provider.

53


Advertisement * Advertisement *

1

1

C-ProMiSE C-ProMiSE component component (Sender) * (Sender) *

1

Version * Version *

1

rootURL rootURL

1

unique identifier *

1

origin origin destination destination translationURL translationURL

1 0..n

translation translation

1..n 1

scope scope

1..n

1

1 1 1..n 1

name (unique identifyer) name (unique identifyer) relativeURL relativeURL entityType entityType avgProvisioningTime avgProvisioningTime inputContext inputContext

0..n

0..1

scopeDescription scopeDescription

1

inputScope inputScope

1

inputParameter inputParameter

0..1

requirement requirement

0..1

informationGain informationGain

1 1..n

genericDescription genericDescription parameterDescription parameterDescription

* Mandatory in Keep-Alive Advertisement

1

parameterName parameterName

1

cmlType cmlType

1

dataType dataType

Figure 4.6: ContextML Advertisement

CxP

CxB advertiseProvider()

check CxP ID and version; persist advertisement (i.e. store it in lookup database) if valid

(N)ACK

start timer

timer expiration advertiseProvider() (N)ACK

Figure 4.7: CxP Advertisement Procedure (Message Sequence Chart)

54


4.3.3.3 Provider and Scope Lookup A CxB provides its lookup functionalities to CxC components. The access is threefold: • The CxC can query a CxB for a list of registered scopes. • The CxC can query a CxB for information related to a specific scope. The reply contains the context parameter descriptions provided in the advertisements. If the scope has not been registered, the CxC receives an error message in response. • A CxC can query a CxB for the information it requires to synchronously invoke a CxP. Such data includes the accessibility and capabilities of the CxP. In addition, the required input context parameters and the HTTP parameter names which have to be used to transfer the input context are provided. 4.3.3.4 Context Storage The storage of context instances covers both temporary caching and a context history service. The expiration of the context instance is conceptually used as a differentiating characteristic. As long as the context instance is valid, it is cached – mainly for accelerating context queries. Afterwards the information becomes historic context. Context Caching Service Caching is a well-established mechanism used in distributed systems for improving the overall performance. In computer science, caches utilise the principal of locality which dictates that an object is influenced directly only by those in its immediate surroundings. In a temporal sense, it means that some resources will be referenced repeatedly within a small time duration. In a spatial sense, it means that data elements will be referenced within relatively close storage locations. A context instance shares some properties that make it an ideal caching candidate, most importantly the association of a validity duration in its meta data. A CxB provides a caching service enabling storage of context instances which traverse through it during the proxy query procedure (cp. section 4.3.3.5). In case of frequent queries resulting in the same reply, CxP components do not have to be invoked if a valid context instance is present in the cache. This behaviour reduces load of CxPs but introduces the drawback of potentially increased context age, i.e. the time between detection and reception of context. Caching further requires fast databases and parsing of the context instance before the data can be made persistent. But assuming a powerful CxB deployed in the infrastructure and comparably resource constraint CxP components, the overall performance is supposed to increase significantly. Finally, due to the design of the middleware with regard to the CxS components, the cache serves as sink for storage of asynchronously pushed context updates. Therefore, it is an elementary part of the design concept.

55


Context History Service The context history service maintains a database to store expired context instances. Historic context enables context reasoning based on previous events. Particularly sequential activity recognition and the inference of intentions require knowledge of previous context (cp. section 2.6). Hence, the provisioning and storage of historic context adds significant value to the C-ProMiSE middleware. Depending on the deployment size and the number of context updates not all the context may be of interest nor its storage easily feasible due to the large amount of data. Consequently CxB configuration functionalities need to provide means for context lifecycle management. In detail, this covers selection of scopes and frequency of persistence. Obviously, there are two alternatives for adding context to the cache: (1) A CxC directly queries a CxP and finally pushes the received context into the cache, hence taking the role of a CxS. (2) The proxy query mechanism (cp. section 4.3.3.5) of a CxB is utilised for querying context and context is cached accordingly. In both cases – after its expiration and an appropriate configuration – the context instance is automatically moved from the cache into the history database where it becomes historic context. 4.3.3.5 Context Diffusion Context Diffusion deals with the core task of enabling efficient distribution and provisioning of context to CxC components. Depending on the targeted awareness and interaction paradigms, a context-based application or service may prefer synchronous on-demand access to context. Fully context-aware actuators instead will require to be informed asynchronously about relevant context changes as discussed earlier in section 2.3. In the following subsections both the context query models and their corresponding query mechanisms are presented. Query Models Query models generally describe the way and parameters needed for requesting context. C-ProMiSE differentiates between two fundamental query models for the acquisition of context: a simple key-value based model and a more sophisticated one supporting the definition of constraints. The basic key-value query model allows for retrieving a context instance (i.e. value) based on a query triple (i.e. key) consisting of entity identifier, entity type and context scope. The sophisticated query model foresees the definition of query parameters in an XML-based representation schema entitled Context Query Language (CQL). The CQL schema is presented in Listing A.18 and graphically illustrated in Figure 4.8 below. A specific example is given in Listing A.19. The CQL schema allows for the definition of action types SELECT and SUBSCRIBE. Constraints can be defined using comparison operators, e.g. EQ (equals), NEQ (does not equal), GT (greater than), STW (starts with), NCONT (does not contain). In addition, logical operators such as AND and OR are available. Most

56


importantly, the CQL schema allows for querying context of several unspecified entities by using an asterisk as placeholder. C-ProMiSE supports both synchronous on-demand queries resulting in direct replies and asynchronous event-based queries resulting in temporally decoupled context updates as further discussed below. ctxQuery ctxQuery

1

1

action type action type

SUBSCRIBE, SELECT SUBSCRIBE, SELECT

1

entity entity

0..n

constraint constraint

Identifier

1

* for allIdentifier active entities * for all active entities

1

type type 1

0..n

0..n

0..1

Comparison Operator Comparison Operator EQ, NEQ, STW, CONT, ... EQ, NEQ, STW, CONT, ... 0..n

1

Constant Operand Constant Operand Variable Operand Variable Operand

1

Context Scope Context Scope

1

Context Parameter Context Parameter

Logical Operator Logical Operator AND, OR AND, OR

callbackURL callbackURL

Figure 4.8: Context Query Language (CQL) Schema

Synchronous On-Demand Proxy Query The CxB provides a proxy context query mechanism hiding complexity from the CxC by offering a single point of access to manifold context information. The CxC does not have to discover and invoke the required CxP components itself but coordination of subsequent queries and aggregation of context is facilitated through CxB functionalities. The three modes of operation are described below. Basic Proxy Query: The most fundamental proxy query service utilises the basic keyvalue query model introduced previously. It enables a CxC to query a CxB for a specific context scope, given an entity identifier and its type (e.g. position, michael, user ). The CxB fetches all required input context recursively and invokes the respective providers consecutively. Figure 4.9 provides an example of a graph G = (V, E) of scope dependencies. Each vertex vi ∈ V represents a scope. An edge e = (vi , vj , wi,j ) ∈ E, i 6= j denotes an existing dependency between two scopes, i.e. scope Si requires input context from scope Sj if vj is an ancestor of vi . Primitive scopes are those having no ancestor in the acyclic directed graph representation. According to the information provided in the advertisement process, the edges are weighted with (1) processing time, (2) quality of context (QoC) gain and (3) whether the dependency is optional or mandatory. Hence, theoretically three individual weighted graphs are built with the following formal notations. req ∈ {0, 1} • Mandatory and optional dependencies are differentiated: wi,j

57


• Each available and utilised context is assumed to add gain to the final QoC value: qocGain wi,j ∈ (0, 1]

• Further, each edge models how long it takes to process and provide the input scope proc in milliseconds: wi,j ∈ R>0

v10 qocGain=0.8 mandatory=1 processingTime=423

qocGain=0.2 mandatory=1 processingTime=423

v8

v9



v5

v6


v7 qocGain=0.1 mandatory=1 processingTime=97

qocGain=1 mandatory=1 processingTime=28


v1

qocGain=1 mandatory=1 processingTime=49

v2


v3

v4

Figure 4.9: Scope Dependency Graph The coordination and context exchange during the proxy query process are exemplified in Figure 4.10. In this basic mode of proxy querying, each available input context is fetched – the introduced weights of processing time and QoC gain are irrelevant. Each optional input context is attempted to be fetched. A dependant scope is only queried from a CxP if all mandatory context is available. Otherwise, the CxB returns an error message stating that the queried context is not available. Note that all communication is based on HTTP according to the REST principle, i.e. input context is exchanged by utilising the HTTP parameters defined in the advertisement process. Proxy Query with Quality of Context Support: Given the availability of weighted dependency graphs, the proxy query mechanism can be extended to either increase the QoC or minimise the query time as explained below. This QoC-enabled proxy query mechanism allows the CxC to define a minimum QoC and/or a maximum query processing time according to the application/service demands. To provide this functionality, the CxB compiles a tree structure with the queried scope as root element. The required primitive context scopes occur as leaves. The CxB fetches 58


CxC

CxB

CxP (S1)

CxP (S2)

CxP (S5)

getContext

dependency lookup

getContext(entity=E) S1

cache context

getContext(entity=E) S2

cache context

getContext(entity=E, input=S1,S2) S5

cache context S5

Figure 4.10: Message Sequence Chart of basic Proxy Query Mechanism primitive context scopes first and invokes the higher-level CxP if all mandatory input context parameters are available. The availability of context in the cache is considered by proc decreasing the respective context processing time accordingly (cp. wi,j ). If the CxB tree

leads to the conclusion that the CxC requirements cannot be fulfilled (i.e. either the query is supposed to take longer than the maximum threshold or the resulting QoC cannot be reached), the CxB immediately interrupts the entire proxy query process and replies with a negative control message. CQL-based Proxy Query: Synchronous context queries are also supported by the CQL model. If the SELECT key word is used as action type, a CxC can use the CQL model to query not only context of an individual entity but also query all active entities matching given constraints. For instance, all users can be identified who share the same age or gender (context parameters of scope user profile). Asynchronous Event-based Proxy Query The asynchronous query mode utilises the CQL model. Constraints are defined for describing the context changes of interest. The utilisation of the key word SUBSCRIBE as action type requires the definition of a callback URL. Subscriptions are only valid for a limited time after which they are deleted autonomously. Each successful subscription is acknowledged with a message containing the subscription identifier. If a CxC would like to keep its subscription active, it has to refresh the entry periodically by sending a subscription refresh message referring to the unique identifier. A CxB does not only compare its cache with constraints of managed subscriptions but also invokes CxP queries in case of higher-level scopes that depend on lower-level scopes. 59


For instance, if scope S5 is subscribed and a context update of its input scope S2 (cp. Figure 4.9) is received by the caching service, the context of scope S5 is automatically refreshed before checking the subscription constraints. If the constraints match, an asynchronous notification is sent to the CxC which acknowledges its reception. Historic Context Query To provide access to historic context available in the CxB storage, the query models are extended. The following options are supported: 1. The age of context is incorporated in the basic query model key as fourth parameter (scope, entityID, entityType, contextAge). A CxC can either specify relative context age (given in seconds), the absolute time, or the absolute time range comprising start time and end time. If the desired context is not available, an error message is returned. 2. An extended CQL model provides the possibility to define a time range. Similar to the above mentioned model, a corresponding message is returned in case of unavailable context. In order to allow for analysis of previous activities and sequential context reasoning, the need for historic input context can furthermore be advertised to a broker. Therefore, a CxP needs to define the required age of context (relatively to current time). The proxy query mechanism supports the invocation of CxP components with historic context parameter values.

4.3.4 Broker Federation The federation of brokers is a key requirement for supporting physical scalability with regard to an increasing number of both context sources (i.e. sensors) and context sinks (i.e. services, applications and actuators). In a real system the problem of a single point of failure arises when using a single CxB component. However due to focus of the scientific investigation conducted in this thesis reliability is out of scope. To incorporate a system of federated brokers the flat entity model (cp. section 4.2.4) is extended to consider a home domain assigned to each entity. According to the model applied for instance in the Domain Name System (DNS)1 : CxB domains are hierarchically organised as illustrated in Figure 4.11. A CxB Lookup mechanism is introduced to ensure that each CxB knows how to access its superior and subordinated counterparts. Albeit C-ProMiSE foresees a manual configuration of domains due to security reasons by default, the CxP advertising procedure can optionally be adopted. Each CxB forwards context update messages, i.e. asynchronously

1

The Domain Name System (DNS) is specified by the Internet Engineering Task Force (IETF) in its Request for Comments (RFC) 1034.

60


root Master CxB *.de CxB for Country Domain

*.uk CxB for Country Domain

*.hs-osnabrueck.de CxB for University Domain

*.ac.uk CxB for Academic Domain uwe.ac.uk CxB for University Domain

surrey.ac.uk CxB for University Domain

Figure 4.11: Domain Concept of Federated CxB Components (Example) published context and those retrieved while proxy querying providers (if caching is enabled) to the corresponding home domain of the entity which is associated to the context instance. Context subscriptions are similarly forwarded and reside at the home CxB.

4.4 Implementation Design After the context management concept has been explained its specific C-ProMiSE implementation will be presented. This section comprises the interface definition of the CxB, its software design and selected middleware coordination messages.

4.4.1 Context Broker Interfaces The implementation of the argued context representation and management concepts utilises current state-of-the art technologies which allow for the support of heterogeneity. The HTTP is one of the widest deployed protocols of the TCP/IP stack and available on a large set of devices. Therefore, all C-ProMiSE components interact based on HTTP and apply the Representational State Transfer (REST) principle [Fielding, 2000]. The architectural interface definition of a CxB is depicted in Figure 4.12. For the sake of clarity and comprehensibility, the CxB federation mechanism is omitted.

4.4.2 Implementation of Coordination Messages A common message type required for the coordination of all middleware functionalities is the Acknowledgement (ACK) message which has been motivated by HTTP response messages. Its content is described in Figure 4.13. Beside the sender information (unique identifier and version number), a timestamp indicating the message composition time is mandatory. The response codes and messages listed in Table 4.1 have been designed to provide the invoking component with information about successful and erroneous calls. Furthermore, information about the method (i.e. the call) and the related entity are given where applicable. The utilisation of XML allows for human readable debugging, an example of a negative Acknowledgement (NACK) indicating unavailable context is given in Code Listing A.15. 61


Context Broker

Context Source advertiseProvider()

CxP Registry and Lookup Service

getProviders()

Context Provider

updateContext()

Context Caching Service

getActiveEntities()

Advertiser Context Query Handler

getContext()

Context Query Service (on-demand)

getContextQL()

Context Consumer Notification Handler

subscribe(, callbackURL)

Context Query Service (event-based)

subscribe(, callbackURL) getContext(, time)

CxB Administration and Monitoring

getProvider(scope)

Historic Context Query Service (on-demand)

getContext(, time)

Figure 4.12: Selected C-ProMiSE Component Interfaces Acknowledgement Acknowledgement 1

1

C-ProMiSE C-ProMiSE component component (Sender) (Sender)

1

1 1

1

timestamp timestamp

1

resonse resonse

1

method method

0..1

Related Entity Related Entity

1

version version

1

status status code code message message

1

Entity Type Entity Type

1

Entity ID Entity ID

1 1

0..1

unique identifier

Figure 4.13: ContextML Acknowledgment

4.4.3 Context Broker Implementation The following paragraphs discuss specific implementation and technology characteristics of selected components at low detail level. The prototype CxB implementation is based on the Java Enterprise Edition (JavaEE) standard. The result is a Java Enterprise Application packaged as EAR (Enterprise Archive). Each module is deployed on a JBoss 1 application server. Where required, persistence is realised through a Java DataBase Connectivity (JDBC) interface to a MySQL2 database. 1 JBoss is an open source application server providing the full range of JavaEE 5 features as well as extended enterprise services including clustering, caching and persistence; http://www.jboss.org/jbossas, accessed 28.06.2011. 2 MySQL is a relational database management system that runs as a server providing multi-user access to a number of databases.

62


As illustrated in Figure 4.14 the final Context Broker EAR is a compound of a web application (Web Archive, WAR) handling the REST invocation and an Enterprise Java Beans (EJB) package. Internally, the WAR element calls the required methods by EJB invocation and answers external HTTP requests accordingly, hence applying the Model View Controller (MVC) software design pattern.

JavaEE Application Server EAR (ContextBroker.ear) includes

EJB (ContextBroker.ejb)

includes

invokes

WAR (ContextBroker.war)

invokes

External Component

Figure 4.14: Composition of CxB Java Enterprise Application

Table 4.1: ContextML Response Status Codes and Messages Code

Status

200 234 235

OK ERROR ERROR

452

ERROR

455 456 457 458 462 464

ERROR ERROR ERROR ERROR ERROR ERROR

469

ERROR

471 472 488 489 491 492 493 500

ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR

Message Wrong Method Invocation Wrong Method Invocation. Age must be given in seconds according to Long format. Provider version is either wrong (Expected format: [n].[n].[n]) or too old. Context Element not available Scope not defined Entity type not defined Scope and Entity type not defined XML not well formed or not valid Context update message does not include valid context Context provider keep-alive advertisement detected. However, provider is not registered. Missing parameter(s) Malformed Advertisement Message CQL Invalid. ¡Reason¿ Subscription not possible Subscription could not be renewed Subscription could not be deleted Method not correctly invoked Internal Server Error

4.5 Summary of Context Representation & Management This chapter covered both context representation and context management of the C-ProMiSE middleware. Related work has often applied ontologies, i.e. semantic models, for representing context information. However, C-ProMiSE aims at supporting rapidly changing ubiquitous situations and focuses on resource constrained mobile devices both as primary source of

63


context and as context sink. Since the majority of context-aware applications run on these devices (e.g. smartphones), the processing of ontologies would result in an increased battery consumption and negatively affect concurrent processes. Therefore, a semantic-free approach has been chosen for context modelling. Nevertheless, the proposed design allows for representing context instances of diverse context categories, e.g. spatial, temporal, device and activity context. Its implementation is based on a specific XML schema, entitled ContextML. It can be utilised to represent both current and historic context. Various types of entities (e.g. devices, users, rooms) can be associated dynamically. Moreover, the ContextML schema has been conceptualised not only to model context of various abstraction levels but also for representing coordination messages being exchanged between middleware components. This combination ensures extendibility for supporting emerging and evolving applications since new context types can be modelled and the required processing capability can be dynamically added to the system. As basis of the architectural design of C-ProMiSE, a consumer-producer role model has been applied for context management. An intermediating broker facilitates the coordination and is responsible for simple and coherent access to context – regardless of device and network heterogeneity. The following set of components has been defined: Context Provider (CxP), Context Source (CxS), Context Consumer (CxC) and Context Broker (CxB). In collaboration these modules realise the following middleware functionalities in a distributed manner: sensor data acquisition, context storage, context lookup & discovery, context diffusion & distribution, context processing & reasoning. The required interaction and coordination flows have been discussed. Spatial, temporal and functional decoupling is supported. Both asynchronous and synchronous context query mechanisms are foreseen. The simple query model is based on a key-value pair whereas more sophisticated requests can make use of the XML-based ContextQL. ContextQL supports the definition of context constraints and provides various comparison and logic operators. Moreover, historic context can be queried and utilised. The primary unique characteristics compared to related work are the proxy query mechanism and the caching mechanism. The proxy query mechanism hides complexity from the CxC and autonomously acquires the required input context for each of the CxP components that need to be invoked, hence enabling a distributed processing chain. An extended version of the proxy query mechanism considers the individual QoC gain and individual processing times of CxPs in order to optimise this processing chain. CxP components can announce their specific context requirements when registering with a CxB, hence ensuring gradual extendibility of the framework. New context processing capabilities and context scopes can be added during run-time without any need for redeployment. The specific implementation of the context management model is based on RESTful HTTP for ensuring a wide interoperability.

64


As emphasised in Table 2.1 C-ProMiSE advances1 related work by providing: • support for sensor diversity, • support for context diversity, • context model extendibility, • support for entity diversity, • support for historic context, • context processing scalability and • context management scalability. In summary the broker-producer-role model has been applied as a promising candidate to establish an extendible architectural basis for the C-ProMiSE middleware. The incorporation of diverse context processing & reasoning mechanisms will be discussed in the following chapter.

1

The qualitative and quantitative evaluation of the context modelling and context management concepts will be presented in chapter 6.

65

5 Context Processing & Reasoning of C-ProMiSE This chapter discusses how to incorporate diverse context processing and reasoning capabilities into the C-ProMiSE middleware. In particular the support for higher level reasoning is explained and applied to activity recognition of mobile users during their everyday behaviour.

5.1 Objectives and Methodology The key objective addressed in this chapter is how a diversity of distributed Context Providers (CxPs) and reasoning mechanisms can be organised to collaborate in the C-ProMiSE middleware in order to perform relevant high level situation and activity reasoning. The resultant architecture allows inhabitants of smart spaces to be provided with numerous context-based and truly context-aware services and applications in a ubiquitous environment. Most importantly, this chapter will discuss an approach of how to derive required contextual knowledge in a domain independent way, applicable for various application and service scenarios. Real implemented CxPs/CxSs are introduced, covering diverse sensors as well as various processing mechanisms. Through use of these CxPs/CxSs the successive, aggregated and refining behaviour of the context and reasoning processing is shown.

5.2 Context Processing and Reasoning Design Issues This section discusses basic approaches and design deliberations of how to incorporate various processing and reasoning mechanisms into the C-ProMiSE middleware.

5.2.1 Layered and Distributed Processing As discussed previously in section 2.6 related work proposes to build up context in various successive processing stages (cp. Figure 2.2). Furthermore, to prevent complex tasks to be executed on mobile resource and battery constrained devices, C-ProMiSE foresees the distribution of processing and reasoning functionalities amongst network components, i.e. amongst performant servers being deployed in the infrastructure. In this thesis an experimental composition of modular processing logic is proposed. The investigations evaluate the appropriateness of a broker-consumer-producer based context

66

5. Context Processing & Reasoning of C-ProMiSE

management model with regard to heterogeneous and functionally extendible processing and reasoning mechanisms. The architectural concepts of both CxS and CxP, introduced in section 4.3.2, allow several context processing stages to be plugged together successively between physically distributed network entities. A CxS/CxP may either access external sensors or rely on context provided by lower-level CxPs/CxSs. In the following paragraphs a processing chain will be elaborated from bottom to top, i.e. with increasing complexity. The coordination of and interaction between the CxP and CxS components is facilitated through a CxB whose functionalities have been discussed in sections 4.3.2.4 and 4.3.3.

5.2.2 Acquisition and Preprocessing of Sensor Data The acquisition of primitive context data from diverse sensors establishes the basic ground level from which further processing can take place. The data typically originates from physical, virtual or logical sensors. Three categories of sources are considered to be particularly relevant for C-ProMiSE: smartphones, web services and environmental sensors. They enable a large amount of context to be collected. The smartphones constitute today’s everyday companion and the primary device through which a mobile user interacts with the digital world. Furthermore, they are personalised and hence can be associated to unique users easily. The availability of embedded hardware sensors allows for context retrieval of various context categories (cp. section 2.2). The processing power of smartphones is sufficient to perform online preprocessing. As an example, the raw data of accelerometers can be used to infer whether a device is in the pocket of a moving user or lying on the table. A specific CxS concept and implementation for the incorporation of smartphones into C-ProMiSE will be presented later in section 5.3.2.1. A significant amount of information describing the user and his interaction is already present in the Internet. Publicly available web services and their corresponding Application Programming Interfaces (API) can be attached to C-ProMiSE as virtual sensors. Interesting examples for such services cover for instance social networking, weather, information and entertainment services. Infrastructure CxPs handle the required generation of queries and the transcoding of replies into the ContextML representation format. Environmental physical sensors are an important prerequisite for realising smart spaces. Wireless sensor nodes can for instance detect the noise level, light intensity, temperature, pollution, pressure and humidity inside a room. Naturally, the preprocessing capabilities of such nodes depends on the particular hardware. However, the C-ProMiSE architectural concept allows for filtering and aggregation mechanisms to be realised by and hidden in CxPs/CxSs. As long as the respective component provides context instances, heterogeneous physical sensors can be plugged into the middleware. Specific middleware components with focus on acquisition and preprocessing of sensor data will be presented in section 5.3.2. Methodological, their design and implementation contributes to the experimental investigation of how functional extendibility of context 67


processing capabilities can be realised in a broker-consumer-producer model based context management framework.

5.2.3 Context Aggregation The aggregation/combination of context parameters into other abstraction levels follows the methodology and well known approaches of machine-interpreted pattern recognition. Fundamental principles of classification, clustering and machine learning are to be supported by the middleware. Classification is based on supervised learning from labelled training data instances. Input context can be viewed as feature vectors whose classification results in an assignment to – usually discrete – groups. With regard to context processing, classification mechanisms are applied to derive aggregated output context parameters. Both the underlying context representation model and the context management model foresee input and output scopes to be handled by specific CxP components. The lack of available training data prevents the direct application of supervised learning strategies but can be compensated by unsupervised learning. In this case clustering, i.e. the grouping of data into classes based on measures of inherent similarities, can be conducted. The context feature space introduced in section 4.2.3 refers to what is commonly denoted as multi-dimensional vector space of features in the domain of pattern recognition. In section 5.3 selected CxP concepts for both classification and clustering of context will be presented. They serve for investigating general processing capabilities in C-ProMiSE.

5.2.4 Probabilistic Reasoning Due to the required processing and memory consumption in conjunction with the design challenges of ontologies and their interpretation by Description Logic (cp. section 2.6.2), Probabilistic Reasoning has been chosen as the main mechanism for inferring high-level context in C-ProMiSE. Another reason is its implicit handling of uncertain and incomplete input data (i.e. primitive context). Bayesian networks (BN) represent a set of random variables and their conditional dependencies via a directed acyclic graph. Their graphical representation of causal dependencies can be easily comprehended by administrators and even by end users. Additionally, the applicability of machine learning algorithms for incremental model optimisation offers important benefits in the domain of context-awareness. As argued in the preceding sections, an evolving degree of awareness is targeted for the support of existing and emerging application scenarios. Packaged as Generic BayesNetworkCxP (see section 5.3.5.2 for details) a component fitting into the middleware framework is envisaged. The objectives are threefold: (1) primitive context is to be fetched from C-ProMiSE, used as input for reasoning and high-level context to be finally provided back; (2) administrators shall have the opportunity to easily define and upload generic reasoning models, i.e. BN, per high-level context scope; (3) these generic models can optionally 68


be individualised by instantiating a model per user and incrementally learning from user feedback. How this user feedback is represented and utilised will be further elaborated in section 5.3.5.2.

5.3 Design and Implementations of Context Providers and Context Sources This section presents the design and implementation of CxPs and CxSs to illustrate the applicability of the C-ProMiSE design. Each of the following subsections describe the acquisition, processing and provisioning of context. It is important to highlight that only a selected subset of providers and sources is introduced for demonstrating how diverse sensors and processing approaches can be combined in a common framework. The complexity of CxPs differs significantly since the only common requirement is the interface definition, i.e. the registration by advertisement and providing context instances in the ContextML format upon HTTP invocation.

5.3.1 Overview of Implemented Providers and Sources Figure 5.1 gives an example of a processing chain by introducing real context scopes. The directed edges imply dependencies of scopes, i.e. whether a CxP requires input context from another CxP and CxS, respectively. Table 5.1 lists the context scope details in the example processing chain. Sensor data acquisition and processing of these scopes and the corresponding CxP/CxS components are discussed in the following section. An important characteristic is the support of different entity types, i.e. users, rooms, devices and user groups. Selected CxP components ensure the dynamic mapping between entities. The CxPs and CxSs will be introduced according to four categories: the first group covers the components with focus on sensor data acquisition, the second group introduces database-centric components, the third one concentrates on mid-level context processing and the last one comprises high-level context processing.

activity weather time music

social

environment

proximity

civilAddress

place

position deviceStatus calendar

userProfile

tasksInfo

indoorposition

motion wifi

deviceSettings

cell

Figure 5.1: Context Scopes: A Processing Chain Example 69


Table 5.1: Details of Context Scopes shown in Figure 5.1

Scope (CxP/CxS)

Description

Output Context Parameters

Input Context Parameters

firstname, lastname, gender, birthday, messenuserProfile Profile data describing gers{. . . }, address{. . . }, (UserProfileCxP) a mobile user imei, phoneNumbers[. . . ], emailAddresses[. . . ] Relations to users social friendlistNames, friendlistbased on social net(SocialNetworkCxP) IDs, socialProfile{. . . } work profiles batteryLevel, batteryOndeviceStatus Status information of Charge, networkOperator, (SmartphoneCxS) users’ smartphones serviceState, roaming, uptime ringMode, screenHeight, deviceSettings Settings of users’ screenWidth, screenOrien(SmartphoneCxS) smartphones tation Information about wifi wfList, wfRssiList, wfDeWiFi devices in reach(SmartphoneCxS) vices{. . . } ability Information about celcell lular networks in reach- cellList, cellRssiList (SmartphoneCxS) ability Information about bt btList, btRssiList, btDebluetooth devices in (SmartphoneCxS) vices{. . . } reachability motion Characteristics of the accSum. accX, accY, accZ, (SmartphoneCxS) motion of a device accDelta runningTasks, runningAptasksInfo Currently executed applications, runningSer(SmartphoneCxS) plications and services vices, recentTasks Information about music recentTracks{. . . }, users’ music consump(MusicCxP) favouriteTags tion indoorposition The users’ indoor posiroom, corridor, floor, accu- wifi.List, (Indoortion (e.g. on a Univerracy wifi.RssiList PositioningCxP) sity campus) wifi.wfList, position The users’ geographi- latitude, longitude, accu- wifi.RssiList, (PositionCxP) cal position racy cell.cellList, cell.RssiList position.latitude, civilAddress The current address of street, zipCode, city, counposi(CivilAddressCxP) the users’ position try, accuracy tion.longitude The interpretation mostRelevantPlaceLabel, position.latitude, of the users’ posiplace mostRelevantPlaceCateposition based on main (PlaceCxP) gory, relevance values per tion.longitude, businesses of nearby category and label position.accuracy places Physical, i.e. spatial proximity usersInProximity[. . . ], disproximity to users and (ProximityCxP) tance devices Continued on Next Page. . .

70

Entity Type(s)

Internal Processing / Sensor

user

database lookup

user

Facebook API

device

Smartphone OS/SDK

device

Smartphone OS/SDK

device

Smartphone OS/SDK

device

Smartphone OS/SDK

device

Smartphone OS/SDK

device

Smartphone OS/SDK

device

Smartphone OS/SDK

user

Web Service Query

user, device

Na¨ıve Bayes Classifier

user, device

Web Service Query, Lookup Database

user, device

Web Service Query

user, device

Geospatial processing

user, device, room

Spatial database


Table 5.1 – Continued

Scope (CxP/CxS)

time (TimeCxP)

weather (WeatherCxP)

environment (EnvironmentCxP) groups (GroupCxP) groupMembers (GroupCxP) groupInfo (GroupCxP) activity (BayesNetworkCxP)

Description

Output Context Parameters

timezone, localTime, loInformation about the calDate, localDayOfWeek users’ local time taking daytime {morning, noon, their position into acafternoon, . . . }, weekend, count season currentWeather {summary, temperature, Information about the humidity, windSpeed, local weather windDirection}, forecastedWeather[. . . ] Information about the temperature, brightness, physical conditions in a noise room

Input Context Parameters

Entity Type(s)

Internal Processing / Sensor

position.latitude, position.longitude

user, device

Web Service Query

civilAddress.city

user, device, room

Web Service Query

Users’ group relations groupIDs[. . . ] Information about groupMembers[. . . ] group memberships id, name, type, creationDate, numberOfMembers, Group characteristics position{longitude, latitude, radius} The users’ current ac- various (cp. section various (cp. sectivity 5.3.5.2) tion 5.3.5.2)

room

user group

Wireless Sensor Nodes (SunSPOT) Dynamic Clustering Dynamic Clustering

group

Dynamic Clustering

user

Probabilistic Inference

5.3.2 Sensor Data Acquisition Processing In this section only the CxSs and CxPs of the context processing chain example concerned with sensor data acquisition are discussed. These comprise Smartphone Context Source (SmartphoneCxS), Position Context Provider (PositionCxP), Civil Address Context Provider (CivilAddressCxP), Weather Context Provider (WeatherCxP), Music Context Provider (MusicCxP), Time Context Provider (TimeCxP) and Social Context Provider (SocialCxP). 5.3.2.1 Smartphone Context Source As highlighted previously in section 4.3.2.2, CxSs differ from CxPs as far as their provisioning mechanism is concerned. A CxS asynchronously publishes context to a CxB whereas a CxP has to be invoked synchronously upon request. Smartphones are considered to be the primary personalised device of interacting with the digital world. They play the role of fancy everyday companions. Both due to a relatively high probability of temporary connectivity loss and reachability problems due to firewalls and Network Address Translation, context collected on smartphones is pushed asynchronously to an infrastructure CxB. Hence, the CxS model is preferred to a CxP which would require external invocation. 71


The variety of context available on the smartphone mostly originates from embedded physical sensors, e.g. accelerometers and wireless network interfaces, e.g. Bluetooth and WiFi. Furthermore, settings and device capabilities can be detected. Therefore, context parameters are grouped into the primitive context scopes deviceStatus, deviceSettings, cell, bt, wifi, motion and tasksInfo. Internally, the SmartphoneCxS reads sensor data through dedicated SDK/API calls, translates the readings into the ContextML representation and finally transmits context to CxB utilising the HTTP protocol. The scope provisioning lifecycle illustrated below in Figure 5.2(a) is periodically triggered. Recent smartphone SDKs provide capabilities of executing these tasks as transparent background services, preventing the distraction of mobile users from their typical smartphone utilisation. [ALARM]

Collecting Sensor Data

[SUCCESS]

[ERROR]

Sleeping

[ERROR]

Parsing XML

[ERROR]

[SUCCESS]

Sending Context Update

[SUCCESS]

(a) Scope Provisioning Lifecycle of the SmartphoneCxS

AlarmManager triggers alarms periodically

CellScope Service

ScopeService Scheduler ScopeScheduleDB

MotionScope Service

GUI

invokes, wakes up

settingsDB

xyzScope Service ContextCacheDB

ScopeService ScopeStateDB

asynchronous background services

databases

GUI

(b) Software Design of Android-based SmartphoneCxS

Figure 5.2: Design of Smartphone Context Source The scopes deviceStatus and deviceSettings comprise rather static and slowly changing context. They contain information about the battery state, the service state, display size, resolution and orientation. Furthermore, the current ring mode is detected. The wire72


less interface scopes cell, bt and wifi provide information about cellular network towers (UMTS, GSM) in coverage, Bluetooth devices in proximity and currently reachable WiFi access points, respectively. Together with unique identifiers (i.e. WiFi/Bluetooth MAC addresses, Cell Global Identity) the RSSI (Received signal strength indication) values are provided as context parameters. As discussed later in sections 5.3.2.3 and 5.3.4.3, this network context allows position detection of the device. All scopes are directly associated to the device, i.e. the context instances are of entity type device. Only further processing and mapping in C-ProMiSE infrastructure elements allows for establishing a dynamic relation between user and device. The design and internal dataflow of an Android-based implementation of the SmartphoneCxS is depicted in Figure 5.2(b). The AlarmManager is responsible for realising the scope provisioning lifecycle in cooperation with the ScopeServiceScheduler. For each scope a specific class implements the abstract ScopeService class which is responsible for sensor readings, ContextML parsing and the delivery of the context. The Graphical User Interface (GUI) visualises the settings and state information as illustrated in the screenshots in Figure 5.3. Execution logic and GUI exchange data via an internal database due to the asynchronous character of the background services. The user can change the context update settings, cp. Figures 5.3(b) and 5.3(c). In addition he can monitor the current active state of the scope lifecycle (Figure 5.3(d)) and recently transmitted context instances (Figure 5.3(e)). Further functionalities have been incorporated in the prototype application (cp. Figure 5.3(a)) and will be explained later when introducing the respective CxP. 5.3.2.2 Environment Provider The integration of Wireless Sensor Networks is a crucial step on the road to a tighter coupling between the virtual and real world. The Environment Context Provider (EnvironmentCxP) accesses physical sensors and provides the readings as context instances of context scope environment. Each instance is associated to an entity of the type room. Dependently on the the sensor type, noise, temperature and light intensity are provided. A typical context instance is illustrated in Listing A.7. The interface concept is depicted in Figure 5.4(b), the invocation routine is explained in Figure 5.4(a). The design concept foresees that several Wireless Sensor Nodes (WSN) are made accessible through Sensor Gateways. The internal logic and the data flow of a sensor node is illustrated in Figure 5.4(c). The Sensor Discovery functionality sends a discovery message via the Sensor Gateway interface on a periodic basis. The responding sensor nodes are stored in the Sensor Lookup table with information about the currently available link via one of the Sensor Gateways. The EnvironmentCxP applies a Time Synchronisation technique to align all connected WSNs with the CxP in order to aggregate or combine sensor data. The Aggregation and Fusion function is able to fuse data from different sensors in order to reduce traffic overhead and minimise redundancy. It is also possible to request a WSN to aggregate data locally and transmit the result to the CxP. According to di73


(a) Main Menu

(b) Preference Settings

(d) Context Overview

(c) Interval Configuration

(e) Context Instance

Figure 5.3: Screenshots of Android-based Smartphone Context Source rect requests and subscriptions the context detection process on the sensor node can be adapted with the Measurement Adaptation functionality. Adjustments like modifications of the sampling rate or the cache size can be triggered from the CxP and transmitted to the corresponding WSN. The Subscription Monitor handles the detection of events and makes sure that the notification message, i.e. context update, is sent to the subscribed CxC. The prototype implementation is based on the JavaEE standard and attaches SunSPOT1 sensor nodes through a SunSPOT gateway via Java RMI, see [Reetz et al., 2010] for performance indicators and further details. 1

The Oracle Labs (formerly Sun Labs) project Sun SPOT (Sun; Small Programmable Object Technology) provides a hardware and software platform for experimenting with Wireless Sensor Networks. Each node is programmable in Java. http://www.sunspotworld.com; accessed 04.09.2011.

74


EnvironmentCxP Handle on-demand Context Queries

Request Sensor Values

Measurement Adaptation

C-ProMiSE Interface

Subscribe to Event

Sensor Discovery

Advertise CxP

Adjust detection

Time Synchronisation

Accept Subscriptions Context Cache

Request aggregated Sensor Values

Aggregation and Fusion

Discover Sensor Nodes

Sensor Gateway Sensor Lookup

Synchronise Sensor Nodes

Subscription Monitor

(a) Interface Design 2. getContextProvider (scope)

Context Broker

1. Advertise Context Provider

Context Consumer 3. getContext (scope)

Environment Context Provider

4. getPhysicalValuefromSensor (SN address)

Sensor Gateway

Sensor Gateway

5. getPhysicalValue

Wireless Sensor Node



(b) Overall Invocation Flow

Sensor Node Sensor A/D

Sensor A/D

Sensor A/D

Data Cache Data Aggregation Control Logic

Event Detection Subscription Management

Control Interface

Asynchronous Query Interface

Synchronous Query Interface

IEEE 802.15.4 Interface (c) Functionality and Data Flow of Sensor Node

Figure 5.4: Concepts and Implementation of EnvironmentCxP

75


5.3.2.3 Position Provider The Position Context Provider (PositionCxP) is one of the most fundamental components providing primitive context of the category location. It derives geographic latitude and longitude together with the estimated accuracy in meters. A representative context instance of the context scope position is given in Listing A.6. The provider depends on the scopes wifi or cell, i.e. on radio signal strengths indicators (RSSI) of WiFi Access Points or cellular network base stations. The prototype testbed abandons an own implementation of the global positioning logic but instead utilises a web service. This is a good example of how C-ProMiSE accesses virtual sensors and external processing. The REST-based Geolocation API of the Google GEARS1 service is invoked. Therefore, the WiFi and cellular data is translated into the required JSON2 format. The corresponding reply is transferred into the ContextML format. Hence, the PositionCxP is restricted to parsing as far as context processing is concerned. In addition, monitoring and configuration functionalities are added so that an administrator can view statistics, e.g. the number of successful and failed queries as well as the the average query rate and processing time. 5.3.2.4 Civil Address Provider The Civil Address Context Provider (CivilAddressCxP) provides context of the context scope civilAddress. Context parameters comprise the city and country, post code, street name and house number where available. Hence, the location category of context is further extended by providing a more abstract representation. A typical context instance is available in Listing A.8. As input the provider mandatorily requires the geographic coordinates, i.e. context scope position. The processing logic is realised similarly to the PositionCxP (cp. section 5.3.2.3): The CivilAddressCxP invokes a third-party web service provided by the Google Geocoding API3 . Its REST-based invocation needs JSON/ContextML transcoding capabilities. 5.3.2.5 Weather Provider The Weather Context Provider (WeatherCxP) serves the weather context scope and is another example of utilising a web service as virtual sensor. It requires the city name, i.e. a context parameter of the context scope civilAddress. An example of a provided context instance is given in Listing A.9. Output parameters include for instance temperature, humidity, wind direction and strength. The provider makes the current weather conditions 1 The Geolocation API enables a web application to obtain a user’s geographical position. http://code.google.com/p/gears/wiki/GeolocationAPI; accessed 04.09.2011. 2 The JavaScript Object Notation (JSON) is a lightweight text-based open standard designed for humanreadable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is languageindependent, with parsers available for most languages. 3 Google Maps API Web Services. http://code.google.com/intl/en/apis/maps/documentation/geocoding; accessed 05.09.2011

76


as well as a three day forecast available. Similarly to the other providers, an administrator can access statistics, monitoring and configuration capabilities through web servlets. 5.3.2.6 Time Provider The context scope time is provided by the Time Context Provider (TimeCxP) and depends on the scope civilAddress, more precisely on the context parameter country or alternatively on scope position. The TimeCxP contributes the temporal context category and invokes a publicly available web service called GeoNames 1 to determine the local time zone of the entity whose context is queried. In addition to the local time and date, it associates membership values to the daytime (morning, noon, afternoon, evening, night) that sum up to 1 due to successive normalisation. Inspired from fuzzy logic theory, individual membership functions can be declared as illustrated in Figure 5.5. Moreover, the season (spring, summer, autumn, winter) and the differentiation between weekday and weekend are added. 1

Membership

0,75

morning noon afternoon evening night

0,5

0,25

0 0

2

4

6

8

10

12

14

16

18

20

22

24

Hour of Day

Figure 5.5: Membership Functions of Daytime (Example)

5.3.2.7 Music Provider The Music Context Provider (MusicCxP) accesses a web service provided by the music streaming service Last.fm 2 . It allows the retrieval of recent play list entries and flavoured genres. The association between C-ProMiSE user and Last.fm user is made through the UserProfileCxP storing the required ID. Hence, the provider relies on the context scope userProfile. A selected instance of its output scope music is given in Listing A.11. The access to query and response statistics is realised similarly to the previously introduced providers.

1

The GeoNames geographical database. http://www.geonames.org; accessed 05.09.2011. The Last.fm API allows for building own programs using Last.fm data. http://www.lastfm.de/api; accessed 06.09.2011. 2

77


5.3.2.8 Social Network Provider The Social Network Context Provider (SocialNetworkCxP) extends the profile data and contributes to the domain of interaction context, more precisely to the social domain. The output context scope is entitled social. The SocialNetworkCxP connects to a Facebook1 API for querying a friend list and social profile data, e.g. religion, recent status message, relationship status and interests. For their data to be collected, facebook users have to install a Facebook Application and explicitly agree to privacy exceptions. The association between C-ProMiSE user and facebook user is again handled by the UserProfileCxP which is aware of the facebook ID. Accordingly, the SocialNetworkCxP depends on the context scope userProfile.

5.3.3 Database Centric CxPs and CxSs As database centric providers, the User Profile Context Provider (UserProfileCxP) and the Calendar Context Provider (CalendarCxP) are introduced in the following sections. 5.3.3.1 User Profile Provider The UserProfileCxP serves key context related to the Individuality domain (cp. section 2.2). Its high level functional structure is shown in Figure 5.6(a). Users can register to the system using either a web servlet interface or a frontend provided for smartphones, cp. Figure 5.6(b). Privacy is ensured by a user defined password required for modification of existing profiles. Profile data covers name, postal address (street, house number, zip code, country), email addresses and instant messenger details. Furthermore, gender, birthday and phone numbers are maintained. Since the information is supposed to change rarely, the context can be categorised as being only slowly changing. The profile information is directly stored in an internal database for persistence. The user is used as unique primary key. The processing is therefore limited to ContextML parsing and internal database lookups – except from the trivial calculation of the user’s age. Most importantly with regard to the overall C-ProMiSE middleware, the UserProfileCxP supports dynamic translation between the entity types device and user; hence the association between personalised device and user is supported. The required ContextML advertisement message that is sent to the CxB is depicted in Listing A.17. An example of a context instance is available in Listing A.2. 5.3.3.2 Calendar Provider The Calendar Context Provider (CalendarCxP) provides context instances of the context scope calendar. It maintains an internal database in which temporally indexed event entries are stored. Data can be imported through web servlets. A C-ProMiSE user can

1

Facebook is a social networking service and website, operated and privately owned by Facebook, Inc.; http://developers.facebook.com; accessed 06.09.2011.

78


UserProfileCxP Web Servlet Interface

User‘s Browser

Profiles Smartphone Application

REST-based Smartphone API

CxB / CxP

Context Query Interface

Administrator’s Browser

ContextML Parsing

Configuration & Management Interface

(a) Functional Overview of UserProfileCxP

(b) Android-based Profile Settings

Figure 5.6: Concept and Implementation of UserProfileCxP upload his calendar in the iCalendar1 (ics) format. Alternatively, external web services (e.g. Google Calendar) can be attached. Each calendar is uniquely associated directly to the C-ProMiSE user ID. The calendar contributes to the context categories individuality and activity. The CalendarCxP provides a configuration functionality to the administrator so that he can decide if the entire calendar of a user is returned upon invocation or if only a number of entries is returned that are in close temporal proximity to the query time.

5.3.4 Mid-level Context Processing This section introduces the Proximity Context Provider (ProximityCxP) and the Place Context Provider (PlaceCxP). These two components introduce important context processing capabilities into the overall C-ProMiSE middleware. The internal logic exceeds primitive parsing and pre-processing as utilised in the previously described CxPs. However, their intelligence and complexity does not touch reasoning or inference as defined in section 2.6. That is why they are being categorised as applying mid-level context processing. 5.3.4.1 Proximity Provider The Proximity Context Provider (ProximityCxP) relates the geographic location of various entities (e.g. users/devices) to each other. Its primary goal is to identify entities in proximity which may be relevant for the users’ situations. Accordingly, the Euclidean distance to entities is calculated in a configurable maximum range. 1

iCalendar is a well known data format for the exchange of calendar data. It has been specified by IETF in RFC 5545.

79


The ProximityCxP is invoked with the geographic coordinates (scope position) of the target entity, i.e. it depends on the PositionCxP. It acts as CxC for fetching the position of other entities as well. The administrator can choose between two modes of operation: either the ProximityCxP periodically triggers the CQL-based synchronous query mechanism or it subscribes to context changes of scope position at the CxB. Independently from the fetching mode the position of all entities is stored in a spatially indexed database that allows fast calculation of distances. A typical context instance is provided in Listing A.12. The implementation of the ProximityCxP is realised as JavaEE Application. 5.3.4.2 Place Provider In addition to time, location is highly relevant for determining the users’ current activities. The Place Context Provider (PlaceCxP) assigns logical place marks to an entity of interest (e.g. a user), as illustrated in Figure 5.7(a). It depends on context provided by the PositionCxP (cp. section 5.3.2.3), i.e. context scope position. The raw geographic coordinates are taken as input parameter and for each configured place label (e.g. education-school, shopping-supermarket, work-office) a relevance value is calculated and returned. This way, the querying CxC can get to know the logical place the user currently stays at. This information is useful for a wide domain of applications, such as entertainment, shopping guide, or tailored advertisements. A representative context instance is provided in Listing A.13. A place label refers to a selected main business of a geographically bounded area or building. Each place label comprises a tuple of main category and sub category. Some labels are pre-configured but additional ones can be added (and removed) during run-time by an administrator. The relevance value (0..1) indicates which place label is considered relevant to the user and is determined based on Euclidean distance, user rating, reported time and other parameters as further explained below. All relevance values sum up to 1. One key feature is to allow for and consider user feedback, i.e. each user can report a place and populate it to the community. When doing so he can decide how relevant this place mark might be for others and how large the place is. Therefore, the PlaceCxP consists of two conceptual elements: (1) One server component managing the place reports and retrieving the relevant place labels based on geographic coordinates and (2) an Android Place Reporter App, i.e. a mobile application allowing the user to send their place reports. The server component is realised as JavaEE Application and deployed on a JBoss application server. All method calls are based on the common CxP definition. Figure 5.7(b) presents an overview of the interfaces. The internal data storage of the PlaceCxP follow the Entity Relationship Model (ERM) design depicted below in Figure 5.7(c). Technically the data is made persistent by means of the Java Persistency API (JPA) and stored in an attached spatially indexed Postgres database. A label is composed of a main category (e.g. education) and a subcategory (e.g. university). Most importantly, a label is associated to the report. Besides, a place report composes the longitude and latitude of the place centre 80


together with its radius (in meters). Furthermore, the ID of the reporting user (i.e. the user name) and a user defined generic factor (0..5) is stored. The more relevant this place is supposed to be for other people as well, the higher the factor is chosen. A timestamp defines the date and time of storage. For Android-based devices a PlaceReporterApp is provided and integrated into the SmartphoneCxS (see section 5.3.2.1). It enables a user to report place labels (cp. Figure 5.8). When started the application downloads the list of allowed place labels (category & subcategory). The user can browse through the categories and select the most appropriate one in a drop down list. Similarly the subcategory is chosen. Additionally, he can choose how useful his report may be for other users as well and how large he considers the radius of the place to be. Finally, the place report is sent to the PlaceCxP. Whenever a place report arrives, an object is created and made persistent by utilising Java JPA functions. The system time is used to define the timestamp. If longitude and latitude are not given in the method call, the PlaceCxP acts as CxC and tries to retrieve the position of the reporting user by invoking the CxB proxy query. If the position cannot be retrieved, the place reporting fails. A garbage mechanism is foreseen to delete old entries. The maximum age of place reports is definable. Apart from this, there are no means to delete existing place reports. Instead, the importance/relevance of a place report automatically decreases with its age. Therefore, a new user report strategically compensates old and possibly faulty entries. Implicitly, users are encouraged to use their feedback interface actively. Furthermore, administrators can import data from Open Street Map (OSM). As depicted in the pseudo code in Listing 5.1 a relevance value is calculated and added to the overall relevance value per place label. At the end the relevance values are normalised so that they sum up to 1. Listing 5.2 details the weighting functions. 1

foreach ( report ) { placeLabel = report . getPlaceLabel () ; newRelevance = weig htDistan ce ( report . distance , report . radius , query . p o s i t i o n A c c u r a c y ) * w e i g h t G e n e r i c F a c t o r A n d U s e r ( query . entity , report . reportingUser , report . genericFactor , n u m b e r O f R e p o r t s I n P r o x i m i t y ) * weightTime ( report . timestamp ) ;

6

p l a c e R e l e v a n c e M a p . put ( placeLabel , p l a c e R e l e v a n c e M a p . get ( placeLabel ) + newRelevance ) ; } 11

foreach ( placeLabel ) { placeLabel . relevance = placeLabel . relevance / s u m O f A l l R e l e v a n c e V a l u e s ; }

Listing 5.1: Calculation of Place Relevance

81


traffic. busStop traffic. trainStation

sustenance. restaurant

entertainment. cinema traffic. busStop traffic. busStop

traffic. carPark education.university

work. office

shopping. supermarket shopping. shoes

(a) Place Concept Visualisation

Place Context Provider Accept Context Queries

Retrieve Place Labels Add Place Report Add/Remove Place Label Monitor/Configure

C-ProMiSE Query Interface

User Feedback Interface

Process Query

Manage Place Reports

Manage Place Labels

Administrator Interface Place Report DB

(b) Interface Design PlaceReport

PlaceLabel PK

id

PK

id

FK1

geoLongitude geoLatitude reportingUser radius genericFactor timestamp placeLabel

categoryLabel subcategoryLabel

(c) Database Layout (ERM)

Figure 5.7: Design and Implementation of Place Context Provider

82


Figure 5.8: Screenshot of Place Reporter

1

6

11

double weigh tDistanc e ( distance , placeRadius , accuracy ) { if (( placeRadius + accuracy ) > distance ) { return (1 / ( distance * distance ) ) ; } else { return 0.0; } } double w e i g h t G e n e r i c F a c t o r A n d U s e r ( queryingUser , reportingUser , genericFactor , n um be rO f Re po rt s ) { if ( queryingUser . equals ( reportingUser ) ) { return (0.75 * nu mb er O fR ep o rt s ) ; } else { return genericFactor ; } }

16

21

double weightTime ( reportingDate ) { double reportAge = ( currentTime - reportingDate ) / 1 0 0 0 / 6 0 / 6 0 / 2 4 / 3 6 5 ; // in years if ( reportAge 0

(6.2)

θ ∈ R>=0 , N ∈ N>1

(6.3)

N ∈ N>1

(6.4)

1.0

6. Evaluation & Experimentation of C-ProMiSE

0.6 0.4 0.0

0.2

Probability p(x)

0.8

λ=1 λ = 1.5 λ=2 λ = 2.5

0

1

2

3

4

5

x

0.7

(a) Probability Density Function of Exponential Distribution – used for random inter-arrival time selection

θ=0 θ = 0.5 θ=1 θ=2

0.5 0.4 0.3 0.2 0.1

Context Query Probability

0.6

●

0.0

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

1

5

10

15

20

Context Scope ID (b) Probability Density Function of Zipf’s Law – used for random context scope selection

Figure 6.31: Probability Density Functions of CxC Default Distributions

135


6.4.3.4 Context Provider Module The simulation model comprises a configurable number of CxP module instances, all being equipped with a communication gate. Their abstracted functionalities cover (1) registering with a CxB module by sending CxPAdvertisement messages periodically and (2) responding to synchronous context requests that utilise the simple key-value based query model. For the sake of simplicity, each CxP module instance is associated to a single context scope that it serves. To set the content of both CxPAdvertisement and ContextReply message as well as to determine the response delay realistically it requires a set of parameters which are read from a specific CSV configuration file in the initialisation phase. These parameters comprise the numerical ID of the output context scope and a list of input context scopes it depends on. Furthermore, the size of the provided context instances is specified. The expiration time of the context instance is determined through current simulation time and a defined validity period per scope. Additionally, each CxP module incorporates a failure rate which represents the lack of required data or processing errors. A NACK is likewise returned if the number of concurrent requests exceeds the defined threshold. Upon reception of a ContextQuery message, a CxP module basically determines the response time and creates a corresponding event. However due to the observed influence of concurrent requests (cp. section 6.3.4) and non-infinitesimal response delays, the processing time has to be recalculated and adjusted each time a new request arrives (event QUERY ARRIVAL) or a request leaves the processing queue (event QUERY FINALISED). This procedure is sketched in Figure 6.32. The CxP module manages a query queue in which all queries are stored together with their unique ID, their processing progress and the estimated response time, i.e. the simulation time at which 100% of the query will have been processed and its response is due. The module has to keep track of the number of concurrent requests and the last time of a queue update to determine the required processing time. In line with the observations made in the prototype assessment the processing delay is approximated by using a normal (or Gaussian) distribution. The mean value µc and standard deviation σc do not only depend on the specific C-ProMiSE CxP but also on the number of concurrent requests as noted in Equation 6.5. Tables 6.9 and 6.10 provide an overview of the CxP parameters that are stored in the default configuration file. These settings comply to the real prototype system. Hence Table 6.10 presents the empirical processing delay models that have been derived from the prototype measurements by regression. For each real CxP component a linear and a polynomial (2nd order) regression have been conducted for both the mean values and the standard deviations in dependence of the number of concurrent requests c. The choice between linear and polynomial model has been individually made based on the Residual Standard Error (RSE) which is added to the table – albeit not belonging to the model parameters as such. Additionally the minimum response delay is given. The random value generation is repeated until the minimum is exceeded. Figure 6.33 compares the measurement results of three selected 136


[QUERY_ARRIVAL]

[QUERY_FINALISED]

increment number of concurrent requests

decrement number of concurrent requests

add new entry in query queue (parameters: ID, processing progress, estimated response time)

remove entry of finalised query from queue

send response

Update all entries in query queue: - recalculate processing progress - recalculate estimated response time Create QUERY_FINALISED event for query queue entry with smallest estimated response time

set time of last queue update to sim_time

Figure 6.32: UML Activity Diagram visualising the Query Queuing Mechanism of the CxP Simulation Module CxPs with their respective simulation models.

(x − µc )2 1 2σc 2 ; µc ∈ R, σc ∈ R>0 √ e 2 2πσc −

pnor (x; µc , σc ) =

(6.5)

The CxP modules collect the following metrics during simulation: number of received queries, number of successful queries and number of failed queries. Furthermore, the amount of simultaneously processed context queries, i.e. the size of the request queue, is recorded. 6.4.3.5 Context Source Module The design of the CxS module is a combination of CxC and CxP which have been discussed in depth above. It periodically pushes context to the CxB module. Instead of context queries, context instances, i.e. ContextResponse messages, are randomly generated. The parameters of a particular CxS module instance are defined according to the context scope it serves. Table 6.11 lists the default settings which have been inspired by the prototype testbed. Similarly to the CxP design, simulation assumptions foresee that each CxS module only serves one particular scope. As simulation metrics the number of successful and failed context updates are counted.

137

40 20

●

●

●

Measurement Linear Regr. Polyn. Regr.

0

20

40

60

80

60 40

●

● ●

●

20

80 60

●

0

Mean Processing Time µc (ms)

●

●

●

100

0

20

Number of Concurrent Requests c

20

Measurement Linear Regr. Polyn. Regr. 40

60

80

1000 600

●

●

100

●

0

20

Measurement Linear Regr. Polyn. Regr. 60

80

100

100

150 100

●

●

●

50

●

40

80

●

●

0



●

0

Std. Dev. of Processing Time σc (ms)

800 600 400 200

●

0


●

20

60

(d) IndoorPositioningCxP: Standard Deviation Values ●

0

40


(c) IndoorPositioningCxP: Mean Values

●


●


●

100

●

200

●

0

80

●

0


2000 500 1000 0


●

●

60

(b) CivilAddressCxP: Standard Deviation Values ●

●

40


(a) CivilAddressCxP: Mean Values

●


●

0



20

40

60

80

100


(e) PlaceCxP: Mean Values

(f) PlaceCxP: Standard Deviation Values

Figure 6.33: CxP Processing Time of selected CxPs. Comparisons of Prototype Measurements with Simulation Models.

138


*

14,17,19 1 1 3 2,4,6,16 3 ***

14 2 17 1 2

Max Concurr.

Input Scope IDs **

1 2 3 4 6 7 10 11 12 13 14 15 18

Failure Prob.

Output Scope ID *

position userProfile civilAddress place time activity weather group environment social indoorposition proximity music

CML Size [B]

Real Scope

1 2 3 4 5 6 7 8 9 10 11 12 13

CML Validity [s]

CxP ID

Table 6.9: Default Parameters of CxP Simulation Modules

300 1,800 600 600 60 120 1,800 300 300 600 300 300 1,800

748 1,711 867 2,995 1,092 982 1,779 654 1,032 2,174 784 850 3,733

10−2 10−4 10−2 10−2 10−2 10−2 10−2 5 ∗ 10−2 10−3 10−2 10−3 10−3 10−2

100 100 100 100 100 100 100 100 100 100 100 100 100

The Scope ID is highly relevant. Due to the application of Zipf’s law a lower ID increases the number of context queries for this specific scope.

** ***

Some input scopes are provided by CxSs. They will be introduced later in Table 6.11. Instead of synchronous invocation with context parameters, this CxP acquires context as CxC.

Table 6.10: Default Parameters of CxP Processing Delay Distributions CxP ID α 1 2 3 4 5 6 7 8 9 10 11 12 13

µc = αc2 + βc + γ β γ

RSE

1.09 ∗ 10−2 8.44 ∗ 10−2 1.36 ∗ 102 15.2 −1.54 ∗ 10−2 1.82 ∗ 100 −4.25 ∗ 100 14.6 1.54 ∗ 10−3 5.50 ∗ 10−1 1.52 ∗ 101 2.26 −6.72 ∗ 10−3 8.43 ∗ 100 1.12 ∗ 101 14.7 3.28 ∗ 100 −2.01 ∗ 102 1.44 ∗ 103 1,940 3.10 ∗ 10−3 2.17 ∗ 100 9.71 ∗ 100 6.65 1.41 ∗ 100 3.48 ∗ 101 6.72 8.60 ∗ 10−3 5.08 ∗ 100 9.00 ∗ 100 8.57 5.70 ∗ 10−2 1.65 ∗ 100 1.67 ∗ 102 99.6 1.54 ∗ 10−1 1.17 ∗ 101 1.47 ∗ 101 73.3 3.71 ∗ 10−3 1.08 ∗ 100 2.18 ∗ 100 3.59 −9.56 ∗ 102 1.03 ∗ 103 −3.01 ∗ 103 7,496

α

σc = αc2 + βc + γ β γ

Min RSE

1.33 ∗ 100

−9.26 ∗ 101 1.05 ∗ 103 924 1.20 ∗ 100 −5.41 ∗ 10−1 4.07 7.73 ∗ 10−1 1.19 ∗ 100 5.62 1.64 ∗ 100 7.31 ∗ 100 8.55 0 −1.78 ∗ 10 5.41 ∗ 102 253 −3 0 −7.35 ∗ 10 1.65 ∗ 10 5.11 ∗ 100 7.20 1.38 ∗ 10−2 −2.11 ∗ 10−1 2.02 ∗ 101 6.45 3.34 ∗ 100 −4.83 ∗ 10−1 20.47 −2 9.55 ∗ 10 −1.06 ∗ 102 3.52 ∗ 102 134 −9.02 ∗ 10−2 2.14 ∗ 101 −1.67 ∗ 10−2 1.99 ∗ 100 −3.50 ∗ 100 3.88 ∗ 102

−2.52 ∗ 100 2.27 1.18 ∗ 101 26.3 −1.63 ∗ 103 3,975

122 3 16 32 32 7 39 5 26 18 4 94

6.4.3.6 Context Broker Module The CxB simulation module is the most complex one and hence subdivided into submodules representing the most important C-ProMiSE CxB functionalities (cp. Figure 6.34). The CxP Lookup submodule is responsible for storing all information provided in the CxPAdvertisement messages that originate from the CxP modules. Therefore an internal repository is maintained. The data is required by the Query Handler submodule which 139


*

CxS ID

Real Scope

Output Scope ID *

CML Validity [s]

CML Size [B]

Failure Prob.

Update Interval [s]

Table 6.11: Default Parameters of CxS Simulation Modules

1 2 3 4 5 6 7

deviceStatus tasksInfo deviceSettings motion wifi cell bt

5 8 9 16 17 19 20

600 300 600 120 300 600 300

1,056 2,507 1,002 950 1,482 787 789

10−4 10−4 10−4 10−2 5 ∗ 10−2 10−3 2 ∗ 10−2

600 300 600 120 300 600 300

The Scope ID is highly relevant. Due to the application of Zipf’s law a lower ID increases the number of context queries for this specific scope.

Figure 6.34: CxB Simulation Module – OMNeT++ Screenshot models the proxy query functionality and hence invokes CxP modules on behalf of the CxC module by generating and forwarding ContextQuery messages, respectively. The Cache Handler stores all context instances, i.e. data extracted from the ContextResponse messages and provides access to these instances. The behaviour of the CxB module is configured according to the following set of parameters. Firstly, caching can be enabled or disabled with regard to the proxy query mechanism, i.e. context updates from asynchronously publishing CxS modules are still accepted and stored in any case. Moreover, the caching strategy supports three modes of operation that can be chosen for each individual simulation run: Either the (1) context instance with the oldest detection time, the one (2) with the shortest remaining expiration time or the (3) least often queried one is removed first if the maximum cache size is reached. The CxB module further observes both the number of currently processed queries, i.e.

140


tstartQuery Initial CxP Advertisement Phase

Context Query Phase

CxS Push Context Phase

tsim

Figure 6.35: Visualisation of the Simulation Schedule according to a Timeline simultaneous concurrent requests and the number of context instances stored in cache. Unlike the CxP module the CxB module does not apply approximated (e.g. by regression) distribution functions for randomly generating the additional delays. Instead, it applies the inverse transform sampling (ITS) method1 : The empirical cumulative distribution functions (CDF) acquired in the prototype assessment (cp. section 6.3.3) are loaded into the CxB during its initialisation phase. Graphically explained the ITS approach works as follows: In the actual simulation run a uniformly distributed random value 0 < rnd < 1 is generated. This value is then assumed on the y-axis of the CDF. The corresponding value on the x-axis of the graph is taken as output of the random delay. This method is preferred because of two arguments: (1) The analytical approximation (e.g. regression) of the obtained assessment results is not trivial due to the influence of multiple factors (e.g. concurrent requests, context size, number of context instances stored in cache). (2) The CxB is a central component. An inaccurate abstraction model is assumed to significantly affect the overall simulation results. Therefore, the ITS approach is applied for modelling the following delays: (1) query cache based on simple context query model, (2) forward proxy queries and parse results, (3) store context instance in cache, i.e. process context update message. The consideration of concurrent requests is implemented similarly to the queueing mechanism of the CxP module, cp. Figure 6.32. Recorded metrics comprise the number of context instances in cache, the number of failed/successful queries and the number of registered context providers. 6.4.3.7 Simulation Sequence Figure 6.35 illustrates the temporal sequence of several simulation stages with regard to the simulation time. To avoid the influences of a transient response at the beginning of the simulation, the actual context query phase is postponed to a later stage when (1) all CxP have already registered with the CxB modules and (2) there is already a sufficient number of context instances available in the cache, i.e. CxS modules could already push context asynchronously. This time is denoted as tstartQuery . However, the advertisement phase continues during the entire simulation run by triggering keep-alive messages. The context update process is also carried on. The simulation ends when the configured number of context queries has been issued. 1

The inverse transform sampling method is also referred to as inverse transformation method, Smirnov transform or inverse probability integral transform [Devroye, 1986]. It allows for pseudo-random number sampling from any probability distribution given its cumulative distribution function

141


6.4.3.8 Simulation Parameters Table 6.12 summarises the simulation parameters previously discussed and provides their default settings at a glance. They will be used for each simulation run if not explicitly stated differently. As far as CxP and CxB are concerned, the parameters match the empirical measurements conducted previously, i.e. the prototype testbed is modelled by default. 6.4.3.9 Simulation Metrics The simulation metrics of all modules are summarised below in Table 6.13. The presentation of simulation results may also combine several of these values (e.g. number of successful queries and number of failed queries) into a new metric (e.g. ratio of successful queries). A scalar (sc) refers to recording one single value per simulation run whereas a vector (ve) collects several values that can be statistically analysed subsequently to the simulation.

6.4.4 Simulation Results This section presents selected simulation results estimating the performance of the C-ProMiSE system. Strong emphasis is put on evaluating the overall query behaviour, the influence of caching as well as the capability to physically scale with increasing numbers of users and context queries. The first analysis quantifies the overall performance and identifies the influence of caching. The default simulation parameters are utilised where not explicitly stated differently and a single CxB module instance is assumed. Figure 6.36 visualises the influence of the inter-arrival rate λ and the screw θ of the Zipfian scope distribution. The results illustrated in Figure 6.36(a) were obtained with a screw of θ = 1. While generating Figure 6.36(b) an inter-arrival rate of λ = 50s−1 was defined, i.e. queries are stimulated on average every µ∆tQ =

1 λ

= 20ms.

The simulation results indicate that caching generally improves the overall query performance by reducing the response time. The benefit becomes especially visible at a query rate of 10−2 s−1 < λ < 102 s−1 where the response time is nearly halved (cp. Figure 6.36(a)). The positive effect of caching also increases with a higher screw θ of the Zipf distribution which determines the selection of queried scopes. This means, if only a few scopes are more frequently queried, caching is especially useful (cp. Figure 6.36(b)). As a drawback the average context age increases, i.e. the received context instances are older (cp. Figure 6.36(d)). The resulting diagrams also illustrate that a one-broker system operates satisfactorily up to a query rate of λ = 100s−1 . If the inter-arrival time falls below the required processing time, the success rate decreases obviously (cp. Figure 6.36(c)) and the median response time increases with a factor of magnitude of about 10-30. The effect of the caching policy and the maximum cache size is analysed in Figures 6.36(e) and 6.36(f): The diagrams reveal only marginal differences in the performance.

142


Table 6.12: Overview of Simulation Parameters Module

Parameter Name

Description

Nom.

Default Value(s)

CxC

maximumScopeID

The maximum numerical scopeID that is used in a context request The number of context requests that is used in a simulation run The probability distribution function that is used for random selection of the queried scopeID in a context request The probability distribution function that is used for random selection of the entityID in a context request The probability distribution function that is used for random calculation of the query interarrival rate The ID of the scope provided by the provider The size of the ContextML document which represents a produced context instance The amount of time the detected context instances are valid until they expire The interval between two consecutive context update processes The probability of erroneous replies, i.e. a NACK is returned instead of a context instance The ID of the scope provided by the provider The size of the ContextML document which represents a produced context instance The amount of time the detected context instances are valid until they expire The IDs of the scopes the CxP depends on The time delta between two consecutive (keepalive) advertisement procedures The distribution function used to randomly calculate the response delay of the provider The number of requests the provider is capable of processing simultaneously The probability of erroneous replies, i.e. a NACK is returned instead of a context instance Switch to enable or disable caching support for the proxy query mechanism: 0 = off; 1 = on The applied caching strategy: 1 = remove oldest first; 2 = remove least valid first; 3 = remove least required first The maximum number of context instances to be stored in the cache The distribution determining the delay of forwarding proxy queries, dependently on current number of instances stored and concurrent requests processed The distribution determining the cache update delay dependently on current number of instances stored and concurrent requests processed The distribution determining the query cache delay dependently on current number of instances stored and concurrent requests processed The maximum numerical entityID that is used in a context request (sent by the CxC module) and in a context update (sent by a CxS module) The amount of time after which the query is considered to be timed out The point in (simulation) time when the first context query will be sent

Smax

22

N

105

numberOfRequests scopeDist

entityDist

queryRateDist

CxS

outputScopeID outputScopeSize outputScopeValidity updateInterval failureProbability

CxP

outputScopeID outputScopeSize outputScopeValidity inputScopeIDs adverisementInterval provisioningDelayDist maxConcurrRequests failureProbability

CxB

cachingEnabled cachingStrategy

maximumCacheSize forwardQueryDelayDist

updateCacheDelayDist

queryCacheDelayDist

global

maximumEntityID

queryTimeOut queryStart

*

p(S)

pzipf (S; θ = 1, N )

p(E)

puni (E; N )

p(∆tQ )

pexp (λ = 0.2s−1 ∗ Emax ; N ) * * * * *

* * * * 120s * 100 *

1 1

Cmax

103

p(tP Q )

*

p(tCU )

*

p(tCQ )

*

Emax

104

ttimeout

30s

tstartQuery

1,800s

The default values are read from a configuration file and depend on the specific module instance. See Tables 6.9, 6.10 and 6.11 for details. 143

100

●

50

● ●

●

●

●

●

●

●

●

●

●

●

●

●

20

●

10−3

10−2

100

10−1

101

102

2.5

3.0

●

●

●

●

0

Cache=false Cache=true

●

●

●

300

400

200

●

●

200

Median Query Response Time [ms]

●


●

100

500 1000

●

10



●

0.0

103

−1

0.5

1.0

1.5

2.0

Screw of Zipf Distribution (θ) for Requested Scope ID

CxC Context Request Rate λ [s ]

300

1.0

●

●

●

●

●

●

●

●

●

●


●

●

250

●

Average Context Age [s]

0.9

●

●

● ●

●

●

●

●

●

●

●

●

●

●

●

●

50

0.7

0.8

●

200

●

150

●

100

●

10−3

10−2

● ●

●

●

0


●

0.6

Ratio of Successful Context Responses

(a) Median Response Times of successful Queries (b) Median Response Times of successful Queries with Varying Query Rate λ and a Scope Query with Varying Screw θ and a Query Rate of λ = Screw of θ = 1 50s−1

100

10−1

101

102

103

●

●

10−3

10−2

CxC Context Request Rate λ [s−1]

100

10−1

101

102

103


●

●

●

● ●

10−3

10−2

10−1

●

● ●

●

●

● ● ● ●

●

●

● ●

100

●

●

●

●

●

101

●

102

●

0

●

0

●

600

800 ● ●

CacheMaxSize=10000 CacheMaxSize=500 CacheMaxSize=5000

●

400

400

600

●

200


CachePolicy=1 CachePolicy=2 CachePolicy=3

●

200


800

(c) Success Rate of Context Queries with Varying (d) Average Context Age of Successfully Requested Query Rate λ and a Scope Query Screw of θ = 1 Context Instances with Varying Query Rate λ and a Scope Query Screw of θ = 1

103

10−3


10−2

10−1

●

●

● ●

100

●

●

●

●

●

101

●

102

103


(e) Median Response Times of Successful Queries (f) Median Response Times of Successful Queries with different Cache Policies with Different Maximum Cache Sizes

Figure 6.36: Simulated Effect of Caching

144


Table 6.13: Overview of Simulation Metrics Parameter Name

Description

CxC

responseDelay

The time difference between sending out the context query and receiving a reply The status of the response (successful or failed) The error code of failed context queries The time difference between detection of the context and its reception at the CxC Incremental counter of the number of successfully transmitted context update messages Incremental counter of the number of erroneously transmitted context update messages Incremental counter of the number of successfully replied queries Incremental counter of the number of erroneously replied queries The number of concurrent requests being processed by the provider simultaneously The number of context instances stored in cache The ratio of queries that could be answered from querying the cache without having to proxy query any CxP Incremental counter of the number of erroneously replied queries The number of concurrent requests being processed by the provider simultaneously The aggregated overall context traffic in bytes, i.e. the amount of context instances exchanged by all C-ProMiSE components The aggregated overall traffic including not only context instances but also all other ContextML messages

responseStatus errorCode contextAge CxS

numberOfSuccUpdates numberOfFailUpdates

CxP

numberOfSuccQueries numberOfFailQueries concurrentRequests

CxB

cacheEntries cacheHitRatio numberOfFailQueries concurrentRequests

global

overallCtxTraffic overallTraffic

*

Type *

Module

ve ve ve ve sc sc sc sc ve ve sc sc ve sc sc

sc = scalar; ve = vector.

The second cache policy (remove least valid context instance first) slightly outperforms the other strategies. In the case of the parametric default settings a maximum cache size of Cmax = 5, 000 results in the lowest median response time. In conclusion the results can be interpreted and summarised as follows: A system comprising only one single context broker instance is capable of providing satisfactory query response times up to an average query rate of λ = 100s−1 . A central caching facility increases the performance.

6.5 Analysis and Discussion of Evaluation Results This chapter presented an evaluation methodology covering both functional, i.e. qualitative and performance, i.e. quantitative, assessments. Examples of context-aware applications that utilise the C-ProMiSE middleware have been prototyped.

The results lend weight to the argument that a broker-consumer-

producer based context management middleware can well support a variety of existing and emerging application domains. Additionally, the emulation of context instances has been conceptualised. This approach allows for systematic and automated evaluation of actuation functionalities and high-level context processing/reasoning mechanisms. The performance analysis comprised prototype load tests and discrete event simulation.

145


The prototype black-box assessment results have been utilised to derive realistic simulation models as far as both CxB and CxP query response characteristics are concerned. The amount of concurrent requests has been identified as key influence factor. The simulation focused on evaluating the proxy query mechanism. The corresponding results indicate that the middleware design benefits from both caching and broker federation capabilities.

146

7 Conclusions This chapter concludes the results of the conceptual work presented in chapters 4 and 5 as well as the evaluation in chapter 6. Furthermore, it provides guidelines for carrying on related research in the future.

7.1 Summary of Contributions and Findings This thesis argued the relevance of a middleware that aids context-aware actuators, services and applications in acquiring necessary context. Key research objectives for supporting heterogeneous sensors, application domains, devices and gradual extendibility of the middleware are: (1) an architectural framework for context management, (2) an adequate context modelling and representation scheme and (3) support for distributed context processing. These have been investigated and the corresponding contributions and findings are discussed in the following paragraphs. The first research question dealt with the identification of an appropriate context management model and the architectural design of C-ProMiSE – a middleware whose functionalities cover sensor data acquisition, context storage, context lookup & discovery, context diffusion & distribution as well as context processing & reasoning. Based on literature research a consumer-producer role model with coordinating brokers has been chosen as the most promising candidate for providing both gradual extendibility (functional scalability) and physical scalability (increasing number of context sources and sinks). Based on this model an architectural framework has been designed. It consists of a Context Broker (CxB) component that facilitates coherent access to context information – both asynchronous and synchronous diffusion are supported. The proxy query and caching mechanisms are highlighted as two of the most innovative CxB functionalities with regard to related work published by the research community. The registry and lookup service of the CxB allow for a dynamic addition of new Context Provider (CxP) components. The interaction between middleware components may use various protocols, however the specific implementation presented in this thesis utilises RESTful HTTP in order to support a large set of networks and devices. Context modelling approaches have been surveyed, an outcome of which concluded that a ubiquitous rapidly changing environment and mobile resource constrained devices would benefit from a comparably light-weight representation. For this reason an XML-based modelling schema, entitled ContextML, has been utilised and extended. In juxtaposition to ontologies, an XML representation in general lacks semantic expressiveness and machine interpretability. However, its processing is usually easier, i.e. less resource consuming and 147

7. Conclusions

faster. Therefore a follow on research question addressed the ability of ContextML to represent diverse context categories and abstraction levels – as these characteristics are necessary when supporting emerging application domains and the evolution of existing ones. ContextML has been successfully used in the C-ProMiSE middleware to model instances of spatial, temporal, device specific, network and communication related, environmental, individuality, interactivity and activity context. It was used to describe not only current but also historic context. In collaboration with Telecom Italia and in the scope of the European research project Context Casting 1 the advances in ContextML have contributed to the Open Mobile Alliance (OMA) standardisation body and considered in specifications of their Next Generation Service Interface (NGSI) and Mobile Search (MSrch) Framework2 . In addition to modelling context, ContextML has been used to represent middleware coordination messages that support dynamic registration of CxP modules during run-time, most importantly describing their individual requirements and interdependencies. Support of data acquisition from diverse physical, virtual and logical sensors and how layered (with regard to the abstraction level), distributed and successive processing of context can be realised in the C-ProMiSE architecture has been investigated. A number of specific CxP components have been designed. The primitive ones are limited to collecting sensor data and pre-processing it. Specifically, virtual sensors, e.g. web services, turned out to be an important source of useful context. Firstly, they provide access to a variety of context categories that is difficult to be acquired elsewhere, e.g. social interactions. Secondly, web services can be accessed to inherit their processing functionalities, e.g. the identification of the civil address and the associated main business of a certain geographic position. Environmental context can be fetched from physical sensors and wireless sensor networks. Moreover, more intelligent CxPs have been proposed for aggregation of and reasoning based on such primitive context. Indoor positioning utilised a Na¨ıve Bayes classifier, group clustering has been realised based on the Mean Shift algorithm and activity recognition made use of Bayesian inference. For the latter a generic BayesNetworkCxP has been developed allowing new reasoning models, i.e. Bayesian Networks, to be loaded and applied. Overall, the selection of CxPs demonstrated that a diversity of processing mechanisms can successfully be plugged into the C-ProMiSE middleware. However, the efficiency of the middleware design decreases with the number of context parameters required as input for successive processing mechanisms and CxP chained components. In such cases the CxB can be flooded with input context exchange because of its proxy query mechanism. The evaluation of context provisioning frameworks/middlewares and pervasive systems faces numerous challenges mostly due to interdisciplinary influences involved. Related 1

Context Casting (C-CAST) is a European research project funded in Framework Program 7 (Information and Communication Technologies). Its main objective is to evolve mobile multimedia multicasting to exploit the increasing integration of mobile devices with our everyday physical world and environment. http://www.ict-ccast.eu, accessed 21.10.2011. 2 Relevant publicly available OMA standardisation documents comprise “NGSI Requirements” (OMA-RD-NGSI-V1 0), “NGSI Architecture” (OMA-AD-NGSI-V1 0), “MSrchFramework Requirements” (OMA-RD-MSrchFramework-V1 0) and “MSrchFramework Architecture” (OMA-AD-MSrchFramework-V1 0).

148

7. Conclusions

work has often been restricted to or at least focused on functional evaluation by prototyping. In this thesis a novel evaluation and experimentation methodology comprising a prototype testbed implementation, field trials, context emulation, blackbox assessments and discrete event simulation has been proposed and successfully applied. Prototype applications have been developed, e.g. for smartphones, to gather experiences with the C-ProMiSE testbed. Testing and debugging the context-aware applications, i.e. the consumers of the middleware, in an early development phase also led to the conclusion that context emulation capabilities are necessary. Otherwise it would not be possible to assess the adaptive behaviour of these applications since it depends on external triggers, i.e. availability and change of context. The survey of existing work revealed that context emulation tool-kits need to be designed for each middleware specifically to support the utilisation of its interfaces. Correspondingly, a web servlet based context emulator suite has been developed for C-ProMiSE and applied successfully. In addition to these qualitative assessments the distributed C-ProMiSE middleware has been evaluated quantitatively. To the author’s best knowledge this has been one of the first studies that estimates the performance of a context provisioning middleware by simulating its response behaviour by system-level simulation based on empirical simulation models. The combination of prototype measurements (i.e. black-box assessments) and observed context query behaviours (i.e. field trials of context-aware applications) ensure that realistic simulation parameters have been chosen. This methodology has been inspired from mobile communication systems and the obtained experiences lend weight to the argument that it can be applied to middleware evaluation as well. Albeit the estimated response times represent a very specific testbed and the results are not easily transferable to other hardware settings and technologies, the evaluation approach will be useful for future research. With regard to the C-ProMiSE middleware, the simulation results indicate that a brokerconsumer-producer based context management model is appropriate for designing a generic context provisioning middleware. Its responsive behaviour matches well to time duration of human and application activities involved. A specific C-ProMiSE middleware system comprising a single CxB with 13 CxPs connected to it is estimated to provide synchronous context query responses after about 50 − 100ms on average if the frequency of context query rate does not exceed 100s−1 . Both the black-box measurements and the simulation have been prepared and conducted thoroughly. Where appropriate similar middleware components have been compared with each other. Moreover, the simulation of separated simulation modules in the course of the experiment revealed a satisfactory match with the prototype implementation. This is why – even in the absence of comparable metrics in related work due to this relatively young field of research – the results can be considered justified. In conclusion the scientific contributions can be summarised as follows: 1. Development and implementation of a generic and extendible context provisioning 149

7. Conclusions

middleware (C-ProMiSE) based on a broker-consumer-producer role model applied for context management; 2. Development and utilisation of an XML schema (ContextML) for the representation of diverse context and middleware coordination messages; 3. Support for distributed and successive context processing and reasoning mechanisms; 4. Derivation and application of an evaluation methodology for qualitative (functional) and quantitative (performance) assessment of a context provisioning middleware; 5. Seventeen peer-reviewed papers on these concepts and findings published from 2008 onwards (cp. Table 3.1).

7.2 Future Work Directions The research contributions conducted in the scope of this thesis advance previous work since the well-known broker-consumer-producer role model has not been investigated to such an extent before as far as its applicability to context provisioning systems is concerned. Naturally, numerous related side objectives and research questions arose which could not be addressed to an adequate depth due to the chosen focus. This section briefly surveys the most interesting problems that deserve attention in further studies.

7.2.1 Privacy and Security Privacy and security concerns increase with the available variety and amount of context. Personal information allows to virtually trace users and their activities. Therefore, appropriate protection mechanisms are required. Particularly user management, authentication and authorisation need to be systematically incorporated. Third-party context access has to be bound to explicit grants or autonomous anonymisation. How to efficiently and safely support these mechanisms in a broker-consumer-producer based context provisioning middleware is still an open research question that requires further investigation.

7.2.2 Demand-driven Sensor Data Acquisition and Context Processing As far as Context Sources are concerned they often detect and publish irrelevant context that is not required by any application/service at all or at least not in the provided granularity or accuracy. Hence, processing resources and energy are wasted. The efficiency could be increased by autonomous remote (re-)configuration of sensing devices according to the context demands of consumers. These demands may either be explicitly defined through context subscriptions or implicitly derived and predicted from earlier queries. A trade-off between energy efficient in-advance detection of context and added delay due to an increased number of synchronous on-demand queries needs to be further investigated together with mechanisms for adequate context propagation. 150

7. Conclusions

7.2.3 Systematic Evaluation and Comparable Results The quantitative evaluation of context provisioning middlewares or frameworks is not only challenging due of their complexity and distributed nature but also because comparable results are not available in related literature. This applies to reasonable parameters, i.e. context consuming and provisioning patterns, as well as to metrics, i.e. performance indicators. Here, the presented C-ProMiSE evaluation methodology may serve as inspiring guideline. However, an exhaustive evaluation would also have to include the accuracy and speed of context processing and reasoning functionalities. Currently, this is impossible due to the unavailability of appropriate test and/or training data sets in the domain of everyday user assistance or urban/global smart spaces. Since the number of context sources increases tremendously with the market penetration of smartphones, latest distribution platforms could de facto be used to collect data all over the world from unbiased users. This opportunity encourages further field test studies at large scales to record realistic training data in-situ – and finally share it in the research community.

7.2.4 Extension of Performance Assessments and Simulation Model Finally, further performance metrics and influence parameters could be researched in extended prototype assessments. The measurements conducted in the thesis are bound to a specific software and hardware setting. Comparisons to other settings have not been investigated since a contrasting juxtaposition of the various CxP and CxB components has been focussed. The effect of concurrent requests, context/message sizes and database sizes was of major interest although there are certainly more parameters whose relevance has to be determined in further studies and experiments. Moreover, the simulation model allows for reasonable extensions. Such enhancements could for instance cover the availability of clustering and load balancing capabilities of application servers. However, an appropriate balance between accuracy of the model and the required development efforts need to be chosen. The simulation work presented in this thesis has made a novel contribution and may serve as basis for further more specific analyses.

151

8

References

E. Aarts, R. Harwig, and M. Schuurmans. Ambient intelligence, The invisible future: the seamless integration of technology into everyday life, 2001. Gregory D. Abowd, Christopher G. Atkeson, Jason Hong, Sue Long, Rob Kooper, and Mike Pinkerton. Cyberguide: a mobile context-aware tour guide. Wireless Networks, 3 (5):421–433, 1997. ISSN 1022-0038. B. Adams, D. Phung, and S. Venkatesh. Extraction of social context and application to personal multimedia exploration. In Proceedings of the 14th annual ACM international conference on Multimedia, pages 987–996. ACM, 2006. C. Anagnostopoulos and S. Hadjiefthymiades.

Enhancing Situation-Aware Systems

through Imprecise Reasoning. IEEE Transactions on Mobile Computing, pages 1153– 1168, 2008. ISSN 1536-1233. C.B. Anagnostopoulos, A. Tsounis, and S. Hadjiefthymiades. Context awareness in mobile computing environments. Wireless Personal Communications, 42(3):445–464, 2007a. ISSN 0929-6212. Christos B. Anagnostopoulos, Panagiotis Pasias, and Stathes Hadjiefthymiades. A framework for imprecise context reasoning. International Conference on Pervasive Services, pages 181–184, 2007b. D. Athanasopoulos, A.V. Zarras, V. Issarny, E. Pitoura, and P. Vassiliadis. CoWSAMI: Interface-aware context gathering in ambient intelligence environments. Pervasive and Mobile Computing, 4(3):360–389, 2008. ISSN 1574-1192. N. Baker, M. Zafar, B. Moltchanov, and M. Knappmeyer. Context-Aware Systems and Implications for Future Internet. Towards the Future Internet, page 335, 2009. Matthias Baldauf, Schahram Dustdar, and Florian Rosenberg. A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing, 2(4):263–277, 2007. Jorge Barbosa, Rodrigo Hahn, Daniel Bonatto, Fabio Cecin, and Claudio Geyer. Evaluation of a large-scale ubiquitous system model through peer-to-peer protocol simulation. In DS-RT ’07: Proceedings of the 11th IEEE International Symposium on Distributed Simulation and Real-Time Applications, pages 175–181, Washington, DC, USA, 2007. IEEE Computer Society. 152

8

REFERENCES

Jakob E. Bardram. The java context awareness framework (jcaf) - a service infrastructure and programming framework for context-aware applications. In in Pervasive Computing. 2005: Munchen, pages 98–115, 2005. J. Barton and V. Vijayaraghavan. A simulator for ubiquitous computing systems design. Technical Report HPL-2003-93, Hewlett-Packard Labs, 2003. P. Bellavista, A. Corradi, R. Montanari, and C. Stefanelli. Context-aware middleware for resource management in the wireless Internet. IEEE Transactions on Software Engineering, pages 1086–1099, 2003a. ISSN 0098-5589. P. Bellavista, A. Corradi, R. Montanari, and C. Stefanelli. Dynamic binding in mobile applications. Internet Computing, IEEE, 7(2):34–42, 2003b. ISSN 1089-7801. C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Ranganathan, and D. Riboni. A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing, 6(2):161–180, 2010. ISSN 1574-1192. CE Billings. Situation awareness measurement and analysis: A commentary. In Proceedings of the International Conference on Experimental Analysis and Measurement of Situation Awareness, pages 1–6, 1995. S. Bj¨ ork, J. Holopainen, P. Ljungstrand, and R. Mandryk. Special issue on ubiquitous games. Personal and Ubiquitous Computing, 6(5-6):358–361, 2002. ISSN 1617-4909. T. Bosse, F. Both, C. Gerritsen, M. Hoogendoorn, and J. Treur. Model-based reasoning methods within an ambient intelligent agent model. Constructing Ambient Intelligence, pages 352–370, 2008. F. Both, M. Hoogendoorn, and J. Treur. Model-based ambient analysis of human task execution. In Proceedings of the 1st international conference on PErvasive Technologies Related to Assistive Environments, pages 1–8. ACM, 2008. Paul C. Brebner. Real-world performance modelling of enterprise service oriented architectures: delivering business value with complexity and constraints. In Proceeding of the second joint WOSP/SIPEW international conference on Performance engineering, ICPE ’11, pages 85–96, New York, NY, USA, 2011. ACM. C. Burghardt and T. Kirste. Inferring intentions in generic context-aware systems. In Proceedings of the 6th international conference on Mobile and ubiquitous multimedia, pages 50–54. ACM, 2007. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns, volume 1. Wiley-India, 2008. Scott Carter, Jennifer Mankoff, and Jeffrey Heer. Momento: support for situated ubicomp experimentation. In CHI ’07: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 125–134, New York, NY, USA, 2007. ACM. 153

8

REFERENCES

P. Castro and R. Munz. Managing context data for smart spaces. Personal Communications, IEEE, 7(5):44–46, 2002. ISSN 1070-9916. Emmanuel Cecchet, Julie Marguerite, and Willy Zwaenepoel. Performance and scalability of ejb applications. SIGPLAN Not., 37:246–261, November 2002. ISSN 0362-1340. H. Chang, S. Shin, and C. Chung. Context Life Cycle Management Scheme in Ubiquitous Computing Environments. In Mobile Data Management, 2007 International Conference on, pages 315–319. IEEE, 2008. H. Chen, T. Finin, and A. Joshi. An ontology for context-aware pervasive computing environments. The Knowledge Engineering Review, 18(03):197–207, 2003a. ISSN 02698889. H. Chen, F. Perich, D. Chakraborty, T. Finin, and A. Joshi. Intelligent agents meet semantic web in a smart meeting room. In Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems-Volume 2, pages 854–861. IEEE Computer Society, 2004. Harry Chen. An Intelligent Broker Architecture for Pervasive Context-Aware Systems. PhD thesis, University of Maryland, Baltimore County, December 2004. Harry Chen, Tim Finin, and Anupam Joshi. An intelligent broker for context-aware systems. Adjunct Proceedings of Ubicomp 2003, pages 183–184, October 2003b. (poster paper). I.Y.L. Chen, S.J.H. Yang, and J. Zhang. Ubiquitous provision of context aware web services. In Services Computing, 2006. SCC’06. IEEE International Conference on, pages 60–68. IEEE, 2006. Y. Cheng. Mean shift, mode seeking, and clustering. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 17(8):790–799, 1995. W. Choi, H. Kim, J. Kim, and J. Chae. A Context-Aware Framework for Mobile Navigation Service. cit, pages 423–428, 2007. E. Christopoulou, C. Goumopoulos, and A. Kameas. An ontology-based context management and reasoning process for UbiComp applications. In Proceedings of the 2005 joint conference on Smart objects and ambient intelligence: innovative context-aware services: usages and technologies, pages 265–270. ACM, 2005. D. Comaniciu and P. Meer. Mean shift: A robust approach toward feature space analysis. IEEE Transactions on pattern analysis and machine intelligence, pages 603–619, 2002. Sunny Consolvo and Miriam Walker. Using the experience sampling method to evaluate ubicomp applications. IEEE Pervasive Computing, 2(2):24–31, 2003.

154

8

REFERENCES

Sunny Consolvo, Larry Arnstein, and B. Robert Franza. User study techniques in the design and evaluation of a ubicomp environment. In In Proceedings of Ubicomp 2002, pages 73–90. Springer-Verlag, 2002. D.J. Cook and S.K. Das. Smart environments: technologies, protocols, and applications. Wiley-Interscience, 2005. A. Crabtree, S. Benford, C. Greenhalgh, P. Tennent, M. Chalmers, and B. Brown. Supporting ethnographic studies of ubiquitous computing in the wild. In Proceedings of the 6th conference on Designing Interactive systems, page 69. ACM, 2006. I. Csisz´ ar. Maxent, mathematics, and information theory. Maximum entropy and Bayesian methods, 79, 1996. Nigel Davies, Keith Cheverst, Keith Mitchell, and Adrian Friday. ’caches in the air’: Disseminating tourist information in the guide system. Mobile Computing Systems and Applications, IEEE Workshop on, 0:11, 1999. D.R. De Almeida, C. de Souza Baptista, E.R. Da Silva, C.E.C. Campelo, H.F. De Figueiredo, and Y.A. Lacerda. A context-aware system based on service-oriented architecture. In Advanced Information Networking and Applications, 2006. AINA 2006. 20th International Conference on, volume 1, page 6. IEEE, 2006. Luc Devroye. Non-uniform random variate generation. Springer-Verlag, New York, 1986. A.K. Dey. Providing architectural support for building context-aware applications. PhD thesis, Georgia Institute of Technology, 2000. Anind K. Dey. Understanding and using context. Personal and Ubiquitous Computing, 5: 4–7, 2001. Anind K. Dey and Gregory D. Abowd. Cybreminder: A context-aware system for supporting reminders. pages 172–186. Springer-Verlag, 2000. Anind K. Dey, Daniel Salber, Gregory D. Abowd, and Masayasu Futakawa. The conference assistant: Combining context-awareness with wearable computing. pages 21–28. IEEE Computer Society Press, 1999a. Anind K. Dey, Daniel Salber, Masayasu Futakawa, and Gregory D. Abowd. An architecture to support context-aware applications. Technical report, Georgia Institute of Technology, 1999b. S. Dobson, S. Denazis, A. Fernández, D. Ga¨ıti, E. Gelenbe, F. Massacci, P. Nixon, F. Saffre, N. Schmidt, and F. Zambonelli. A survey of autonomic communications. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 1(2):223–259, 2006. ISSN 1556-4665.

155

8

REFERENCES

D. Ejigu, M. Scuturici, and L. Brunie. Semantic approach to context management and reasoning in ubiquitous context-aware systems. In Digital Information Management, 2007. ICDIM’07. 2nd International Conference on, volume 1, pages 500–505. IEEE, 2007. P. Fahy and S. Clarke. Cass-middleware for mobile context-aware applications. In Workshop on Context Awareness, MobiSys, pages 304–308, 2004. Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, 2000. Jon Froehlich, Mike Y. Chen, Sunny Consolvo, Beverly Harrison, and James A. Landay. Myexperience: a system for ¡i¿in situ¡/i¿ tracing and capturing of user feedback on mobile phones. In MobiSys ’07: Proceedings of the 5th international conference on Mobile systems, applications and services, pages 57–70, New York, NY, USA, 2007. ACM. H. Gellersen. Smart-Its: computers for artifacts in the physical world. Communications of the ACM, 48(3):66, 2005. ISSN 0001-0782. F. Giunchiglia. Contextual reasoning. Epistemologia, special issue on I Linguaggi e le Macchine, 16:345–364, 1993. L.W. Goix, M. Valla, L. Cerami, and P. Falcarin. Situation inference for mobile users: a rule based approach. In Mobile Data Management, 2007 International Conference on, pages 299–303. IEEE, 2007. Ian Gorton and Anna Liu. Evaluating the performance of ejb components. IEEE Internet Computing, 7:18–23, May 2003. ISSN 1089-7801. A. Goultiaeva and Y. Lespérance. Incremental plan recognition in an agent programming framework. In Working Notes of the AAAI Workshop on Plan, Activity, and Intention Recognition (PAIR), 2007. Russell Greiner, Christian Darken, and N. Iwan Santoso. Efficient reasoning. ACM Comput. Surv., 33(1):1–30, 2001. T.R. Gruber. A translation approach to portable ontology specifications. Knowledge acquisition, 5:199–199, 1993. ISSN 1042-8143. T. Gu, X.H. Wang, H.K. Pung, and D.Q. Zhang. An ontology-based context model in intelligent environments. In Proceedings of Communication Networks and Distributed Systems Modeling and Simulation Conference, volume 2004, pages 270–275. Citeseer, 2004. T. Gu, H.K. Pung, and DQ Zhang. Toward an OSGi-based infrastructure for contextaware applications. Pervasive Computing, IEEE, 3(4):66–74, 2005a. ISSN 1536-1268. 156

8

REFERENCES

Tao Gu, Hung Keng Pung, and Da Qing Zhang. A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, 28:1–18, January 2005b. ISSN 1084-8045. D. Mc Guinness. Performance modelling of an ejb system: A simulation approach. Master’s thesis, Department of Computer Sciences University Collage Dublin, August 2005. David Mc Guinness and Liam Murphy. A simulation model of a multi-server ejb system. In Proceedings of the 1st international workshop on Advances in model-based testing, A-MOST ’05, pages 1–7, New York, NY, USA, 2005. ACM. A. Gupta, S. Paul, Q. Jones, and C. Borcea. Automatic identification of informal social groups and places for geo-social recommendations. International Journal of Mobile Network Design and Innovation, 2(3):159–171, 2007. ISSN 1744-2869. B. Han, W. Jia, J. Shen, and M.C. Yuen. Context-awareness in mobile web services. Parallel and Distributed Processing and Applications, pages 519–528, 2005. S. Helal, B. Winkler, C. Lee, Y. Kaddoura, L. Ran, C. Giraldo, S. Kuchibhotla, and W. Mann. Enabling location-aware pervasive computing applications for the edlerly. 2003. K. Henricksen and J. Indulska. A software engineering framework for context-aware pervasive computing. 2004a. Karen Henricksen and Jadwiga Indulska. A software engineering framework for contextaware pervasive computing. In PERCOM ’04: Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications (PerCom’04), page 77, Washington, DC, USA, 2004b. IEEE Computer Society. T. Hofer, W. Schwinger, M. Pichler, G. Leonhartsberger, J. Altmann, and W. Retschitzegger. Context-awareness on mobile devices-the hydrogen approach. In System Sciences, 2003. Proceedings of the 36th Annual Hawaii International Conference on, page 10. IEEE, 2003. J. Hong, E. Suh, and S.J. Kim. Context-aware systems: A literature review and classification. Expert Systems with Applications, 36(4):8509–8522, 2009. ISSN 0957-4174. Shantonu Hossein, Sumi Helal, and Andres Mendez-Vasquez. Sensory dataset description language (sddl) specification, April 2009. URL http://www.icta.ufl.edu/persim/ sddl/SDDL_Specification_v1.0.pdf. Y.M. Huang, Y.H. Kuo, Y.T. Lin, and S.C. Cheng. Toward interactive mobile synchronous learning environment with context-awareness service. Computers & Education, 51(3): 1205–1226, 2008. ISSN 0360-1315.

157

8

REFERENCES

A. Ikram, N. Baker, M. Knappmeyer, and R. Tönjes. A chemical model to enable context awareness. In Proceedings of 4th IFIP International Conference on New Technologies, Mobility and Security, 2011. S. Intille, E. Tapia, J. Rondoni, J. Beaudin, C. Kukla, S. Agarwal, L. Bao, and K. Larson. Tools for studying behavior and technology in natural settings. In UbiComp 2003: Ubiquitous Computing, pages 157–174. Springer, 2003a. S. Intille, K. Larson, E. Tapia, J. Beaudin, P. Kaushik, J. Nawyn, and R. Rockinson. Using a live-in laboratory for ubiquitous computing research. Pervasive Computing, pages 349–365, 2006. S.S. Intille, L. Bao, E.M. Tapia, and J. Rondoni. Acquiring in situ training data for contextaware ubiquitous computing applications. In Proceedings of the SIGCHI conference on Human factors in computing systems, pages 1–8. ACM, 2004. Stephen S. Intille, John Rondoni, Charles Kukla, Isabel Ancona, and Ling Bao. A contextaware experience sampling tool. In CHI ’03 extended abstracts on Human factors in computing systems, pages 972–973, Ft. Lauderdale, Florida, USA, 2003b. ACM. Seiie Jang, Youngho Lee, Woontack Woo, Gist U vr Lab, and S. Korea. Cive: Contextbased interactive system for distributed virtual environment. ICAT, pages 495—498, 2004. C. Julien and G.C. Roman. Egospaces: Facilitating rapid development of context-aware mobile applications. IEEE Transactions on Software Engineering, pages 281–298, 2006. ISSN 0098-5589. Y. Kaneko, K. Harumoto, S. Fukumura, S. Shimojo, and S. Nishio. A location-based peerto-peer network for context-aware services in a ubiquitous environment. In Applications and the Internet Workshops, 2005. Saint Workshops 2005. The 2005 Symposium on, pages 208–211. IEEE, 2006. N. Kara and O.A. Dragoi. Reasoning with contextual data in telehealth applications. In Wireless and Mobile Computing, Networking and Communications, 2007. WiMOB 2007. Third IEEE International Conference on, page 69. IEEE, 2007. R. Kernchen, David Bonnefoy, A. Battestini, B. Mrohs, M. Wagner, and M. Klemettinen. Context-awareness in mobilife. In Proc. of the 15th IST Mobile Summit, Mykonos, Greece, 2006. IST Mobile Summit. S.L. Kiani, M. Knappmeyer, N. Baker, and B. Moltchanov. A federated broker architecture for large scale context dissemination. Computer and Information Technology, International Conference on, 0:2964–2969, 2010a.

158

8

REFERENCES

S.L. Kiani, M. Knappmeyer, E.S. Reetz, and N. Baker. Effect of caching in a broker based context provisioning system. In P. Lukowitz, G. Kortuem, and K. Kunze, editors, Proceedings of The 5th European Conference on Smart Sensing and Context (EuroSSC 2010), volume LNCS 6446 of Lecture Notes in Computer Science, pages 108–121. Springer, Heidelberg, November 2010b. S.L. Kiani, A.M. Anjum, N. Bessis, R. Hill, and M. Knappmeyer. Context parsing, processing and distribution in clouds. In Third International Conference on Intelligent Networking and Collaborative Systems (INCoS-2011), Fukuoka, Japan, November 2011a. S.L. Kiani, B. Moltchanov, M. Knappmeyer, and N. Baker. Analysis of the energy conservation aspects of a mobile context broker. In The 4th Conference on Smart Spaces (ruSMART 2011), St.Petersburg, Russia, August 2011b. E. Kim, S. Helal, and D. Cook. Human activity recognition and pattern discovery. Pervasive Computing, IEEE, 9(1):48–53, 2010. ISSN 1536-1268. InSu Kim, HeeMan Park, YoungLok Lee, HyungHyo Lee, and BongNam Noh. Design of context-awareness simulation toolkit for ubiquitous computing. In IEEE International Symposium on Industrial Electronics, volume 4, pages 3220–3225, 2006. R. Klinger and K. Tomanek. Classical probabilistic models and conditional random fields. Technische Universit¨ at Dortmund, Dortmund, Electronic Publication, 2007. M. Knappmeyer, N. Baker, S.L. Kiani, and R. Tönjes. A context provisioning framework to support pervasive and ubiquitous applications. Smart Sensing and Context, pages 93–106, 2009a. M. Knappmeyer, R. T¨ onjes, and N. Baker. Modular and extendible context provisioning for evolving mobile applications and services. In 18th ICT Mobile Summit, 2009b. M. Knappmeyer, S.L. Kiani, C. Frá, B. Moltchanov, and N. Baker. ContextML: A lightweight context representation and context management schema. In In Proceedings of IEEE International Symposium on Wireless Pervasive Computing, pages 367 – 372, May 2010a. M. Knappmeyer, S.L. Kiani, R. Tönjes, and N. Baker. Modular context processing and provisioning: prototype experiences. In Proceedings of the 4th ACM International Workshop on Context-Awareness for Self-Managing Systems, CASEMANS ’10, pages 8:53– 8:58, New York, NY, USA, 2010b. ACM. M. Knappmeyer, D. Brettschneider, and S.L. Kiani. Context source: A smartphone application for serving context to a generic context provisioning system. In Proceedings of the Second Workshop on Context-Systems Design, Evaluation and Optimisation in conjunction with the 24th International Conference on Architecture of Computing Systems (ARCS). IEEE, 2011a. 159

8

REFERENCES

M. Knappmeyer, S.L. Kiani, N. Baker, A. Ikram, and R. Tönjes. Survey on evaluation of context provisioning middleware. In Proceedings of the Second Workshop on ContextSystems Design, Evaluation and Optimisation in conjunction with the 24th International Conference on Architecture of Computing Systems (ARCS). IEEE, 2011b. M. Knappmeyer, E. Wittkorn, S.L. Kiani, R. Tönjes, and N. Baker. Context provisioning middleware with probabilistic reasoning support. In Proceedings of the 20th Future Network and Mobile Summit, Warsaw, Poland, 2011c. P. Korpip¨ a¨ a and J. M¨ antyj¨ arvi. An ontology for mobile device sensor-based context awareness. Modeling and Using Context, pages 451–458, 2003. P. Korpip¨ a¨ a, M. Koskinen, J. Peltola, S.M. Mäkelä, and T. Seppänen. Bayesian approach to sensor-based context awareness. Personal and Ubiquitous Computing, 7(2):113–124, 2003a. ISSN 1617-4909. P. Korpip¨ a¨ a, J. Mantyjarvi, J. Kela, H. Keranen, and E.J. Malm. Managing context information in mobile devices. Pervasive Computing, IEEE, 2(3):42–51, 2003b. ISSN 1536-1268. S. Kounev. Performance modeling and evaluation of distributed component-based systems using queueing petri nets. IEEE Transactions on Software Engineering, 32:486–502, 2006. ISSN 0098-5589. S. Kurkovsky and K. Harihar. Using ubiquitous computing in interactive mobile marketing. Personal and ubiquitous computing, 10(4):227–240, 2006. ISSN 1617-4909. J. Lafferty, A. McCallum, and F. Pereira. Conditional random fields: Probabilistic models for segmenting and labeling sequence data. In Proceedings of 18th International Conference on Machine Learning, pages 282–289. Citeseer, 2001. Averill M. Law and W. David Kelton. Simulation Modelling and Analysis. Mcgraw-Hill Higher Education, 3. a. edition, December 1999. V.R. Lesser. Cooperative multiagent systems: A personal view of the state of the art. Knowledge and Data Engineering, IEEE Transactions on, 11(1):133–142, 2002. ISSN 1041-4347. D. Lewis. Naive (bayes) at forty: The independence assumption in information retrieval. Machine Learning: ECML-98, pages 4–15, 1998. Y. Li and J.A. Landay. Activity-based prototyping of ubicomp applications for long-lived, everyday human activities. In Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, pages 1303–1312. ACM, 2008. Yan (Jenny) Liu, Ian Gorton, Anna Liu, and Shiping Chen. Evaluating the scalability of enterprise javabeans technology. Asia-Pacific Software Engineering Conference, 0:74, 2002. ISSN 1530-1362. 160

8

REFERENCES

R. Meier and V. Cahill. Taxonomy of distributed event-based programming systems. The Computer Journal, 48(5):602, 2005. I. Mikic, K. Huang, and M. Trivedi. Activity monitoring and summarization for an intelligent meeting room. In Human Motion, 2000. Proceedings. Workshop on, pages 107–112. IEEE, 2002. B. Moltchanov, M. Knappmeyer, C.A. Licciardi, and N. Baker. Context-aware content sharing and casting. In Proceedings of ICIN, 2008. B. Moltchanov, M. Knappmeyer, O. Fuchs, and E. Paschetta. Context management and reasoning for adaptive service provisioning. In Ultra Modern Telecommunications & Workshops, 2009. ICUMT’09. International Conference on, pages 1–6. IEEE, 2009. Ricardo Morla and Nigel Davies. Evaluating a location-based application: A hybrid test and simulation environment. IEEE Pervasive Computing, 3:48–56, 2004. ISSN 15361268. Steve Neely, Graeme Stevenson, Christian Kray, Ingrid Mulder, Kay Connelly, and Katie A. Siek. Evaluating pervasive and ubiquitous systems. IEEE Pervasive Computing, 7:85–88, 2008. ISSN 1536-1268. Hiroshi Nishikawa, Shinya Yamamoto, Morihiko Tamai, Kouji Nishigaki, Tomoya Kitani, Naoki Shibata, Keiichi Yasumoto, and Minoru Ito. Ubireal: Realistic smartspace simulator for systematic testing. In 2006: Ubiquitous Computing, pages 459–476. 2006. P. Nurmi, P. Floréen, M. Przybilski, and G. Lindén. A framework for distributed activity recognition in ubiquitous systems. In Proceedings International Conference on Artificial Intelligence (ICAI), pages 650–655. Citeseer, 2005. N. Oliver, E. Horvitz, and A. Garg. Layered representations for human activity recognition. In Proceedings of the Fourth IEEE International Conference on Multimodal Interfaces. IEEE Computer Society, 2002. E. O’Neill, M. Klepal, D. Lewis, T. O’Donnell, D. O’Sullivan, and D. Pesch. A testbed for evaluating human interaction with ubiquitous computing environments. In First International Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities (Tridentcom) 2005., pages 60–69, 2005. Per-Oddvar Osland, Brynjar Viken, Fredrik Solsvik, Gaute Nygreen, Jan Wedvik, and Stein Erik Myklbust. Enabling context-aware applications. Proceedings of ICIN 2006 Convergence in Services, Media and Networks, June 2006. J. Pearl. Probabilistic reasoning in intelligent systems: networks of plausible inference. Morgan Kaufmann, 1988. F. Pirri and R. Reiter. Some contributions to the metatheory of the situation calculus. Journal of the ACM (JACM), 46(3):325–361, 1999. ISSN 0004-5411. 161

8

REFERENCES

L. Rabiner and B. Juang. An introduction to hidden markov models. IEEE ASSP Magazine, 3(1):4–16, 1986. A. Ranganathan, J. Al-Muhtadi, and R.H. Campbell. Reasoning about uncertain contexts in pervasive computing environments. IEEE Pervasive Computing, pages 62–70, 2004. ISSN 1536-1268. E.S. Reetz, R. Tonjes, and N. Baker. Towards global smart spaces: merge wireless sensor networks into context-aware systems. In Wireless Pervasive Computing (ISWPC), 2010 5th IEEE International Symposium on, pages 337–342. IEEE, 2010. E.S. Reetz, M. Knappmeyer, S.L. Kiani, N. Baker, and R. Tönjes. Performance evaluation of a context provisioning middleware. In International Conference on Computing, Networking and Communications, Communication Software and Services Symposium (ICNC’12 - CSS), Maui, Hawaii, USA, January 2012. Yvonne Rogers, Kay Connelly, Lenore Tedesco, William Hazlewood, Andrew Kurtz, Robert E. Hall, Josh Hursey, and Tammy Toscos. Why it’s worth the hassle: The value of in-situ studies when designing ubicomp. In UbiComp’07: Proceedings of the 9th international conference on Ubiquitous computing, pages 336–353, Berlin, Heidelberg, 2007. Springer-Verlag. Manuel Rom´ an, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Campbell, and Klara Nahrstedt. A middleware infrastructure for active spaces. IEEE Pervasive Computing, 1:74–83, October 2002. ISSN 1536-1268. S.M. Ross. Stochastic processes, volume 23. John Wiley and Sons, New York., 1983. S.J. Russell, P. Norvig, J.F. Canny, J.M. Malik, and D.D. Edwards. Artificial intelligence: a modern approach, volume 74. Prentice hall Englewood Cliffs, NJ, 1995. D. Salber, A.K. Dey, and G.D. Abowd. The context toolkit: Aiding the development of context-enabled applications. In Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit, pages 434–441. ACM, 1999. Bill Schilit and Marvin Theimer. Disseminating active map information to mobile hosts. IEEE Network, 8:22–32, 1994. M. Schmidt-Schauß and G. Smolka. Attributive concept descriptions with complements. Artificial intelligence, 48(1):1–26, 1991. ISSN 0004-3702. J. Scholtz and S. Consolvo. Toward a framework for evaluating ubiquitous computing applications. IEEE Pervasive Computing, 3(2):82–88, 2004a. ISSN 1536-1268. Jean Scholtz and Sunny Consolvo. Towards a discipline for evaluating ubiquitous computing applications. Technical report, National Institute of Standards and Technology, 2004b. 162

8

REFERENCES

D.W. Scott. Multivariate density estimation, volume 139. Wiley Online Library, 1992. J.M. Serrano, J. Serrat, and A. Galis. Ontology-based context information modelling for managing pervasive applications. 2006. Nima Sharifimehr and Samira Sadaoul. Markovian workload modeling for enterprise application servers. In Proceedings of the 2nd Canadian Conference on Computer Science and Software Engineering, C3S2E ’09, pages 161–168, New York, NY, USA, 2009. ACM. Q.Z. Sheng and B. Benatallah. ContextUML: a UML-based modeling language for modeldriven development of context-aware web services. In Mobile Business, 2005. ICMB 2005. International Conference on, pages 206–212. IEEE, 2005. J. Simoes and T. Magedanz. Smart advertising in the home of the future. International Journal of Computer Aided Engineering and Technology, 2(2):164–180, 2010. ISSN 1757-2657. J. Soldatos, K. Stamatis, S. Azodolmolky, and I. Pandis. Semantic web technologies for ubiquitous computing resource management in smart spaces. International Journal of Web Engineering and Technology, 3(4):353–373, 2007. ISSN 1476-1289. C.F. Sorensen, M. Wu, T. Sivaharan, G.S. Blair, P. Okanda, A. Friday, and H. DuranLimon. A context-aware middleware for applications in mobile Ad Hoc environments. In ACM International Conference Proceeding Series; Vol. 77: Proceedings of the 2 nd workshop on Middleware for pervasive and ad-hoc computing. Association for Computing Machinery, Inc, One Astor Plaza, 1515 Broadway, New York, NY, 10036-5701, USA,, 2004. Fábio N. Souza, Roberto D. Arteiro, Nelson S. Rosa, and Paulo R. M. Maciel. Using stochastic petri nets for performance modelling of application servers. In Proceedings of the 20th international conference on Parallel and distributed processing, IPDPS’06, pages 332–332, Washington, DC, USA, 2006. IEEE Computer Society. G. Stevenson, L. Coyle, S. Neely, S. Dobson, and P. Nixon. Constructa decentralised context infrastructure for ubiquitous computing environments. In IT&T Annual Conference, Cork Institute of Technology, Ireland, 2005. G. Stevenson, P. Nixon, and S. Dobson. Towards a Reliable, Wide-Area Infrastructure for Context-Based Self-Management of Communications. Autonomic Communication, pages 115–128, 2006. Thomas Strang and Claudia Linnhoff-Popien. A context modeling survey. The Sixth International Conference on Ubiquitous Computing (UbiComp), Workshop on Advanced Context Modelling, Reasoning and Management., 2004.

163

8

REFERENCES

Andreas Stylianou, Giovanna Ferrari, and Paul Ezhilchelvan. A comparative evaluation of ejb implementation methods. Object-Oriented Real-Time Distributed Computing, IEEE International Symposium on, 0:204–213, 2007. C. Sutton and A. McCallum. 1 An Introduction to Conditional Random Fields for Relational Learning. Introduction to statistical relational learning, page 93, 2007. W.R. Tobler. A computer movie simulating urban growth in the detroit region. Economic geography, 46:234–240, 1970. H.L. Truong and S. Dustdar. A survey on context-aware web service systems. International Journal of Web Information Systems, 5(1):5–31, 2009a. ISSN 1744-0084. H.L. Truong, L. Juszczyk, A. Manzoor, and S. Dustdar. ESCAPE–an adaptive framework for managing and providing context information in emergency situations. Smart Sensing and Context, pages 207–222, 2007. H.L. Truong, S. Dustdar, D. Baggio, S. Corlosquet, C. Dorn, G. Giuliani, R. Gombotz, Y. Hong, P. Kendal, C. Melchiorre, et al. incontext: A pervasive and collaborative working environment for emerging team forms. In Applications and the Internet, 2008. SAINT 2008. International Symposium on, pages 118–125. IEEE, 2008. Hong-Linh Truong and Schahram Dustdar. A survey on context-aware web service systems. International Journal of Web Information Systems, 5(1):5–31, 2009b. ISSN 1744-0084. P. Turaga, R. Chellappa, V.S. Subrahmanian, and O. Udrea. Machine recognition of human activities: A survey. Circuits and Systems for Video Technology, IEEE Transactions on, 18(11):1473–1488, 2008. ISSN 1051-8215. D.L. Vail, M.M. Veloso, and J.D. Lafferty. Conditional random fields for activity recognition. In Proceedings of the 6th international joint conference on Autonomous agents and multiagent systems, pages 1–8. ACM, 2007. U. Varshney. Pervasive healthcare and wireless health monitoring. Mobile Networks and Applications, 12(2):113–127, 2007. ISSN 1383-469X. S. Vinoski. Corba: Integrating diverse applications within distributed heterogeneous environments. Communications Magazine, IEEE, 35(2):46–55, 1997. X. Wang, J.S. Dong, C.Y. Chin, S.R. Hettiarachchi, and D. Zhang. Semantic space: An infrastructure for smart spaces. Pervasive Computing, IEEE, 3(3):32–39, 2004a. ISSN 1536-1268. X.H. Wang, T.G. Da Qing Zhang, and H.K. Pung. Ontology based context modeling and reasoning using OWL. 2004b.

164

8

REFERENCES

Roy Want, Andy Hopper, Veronica Falc ao, and Jonathan Gibbons. The active badge location system. ACM Transactions on Information Systems, 10(1):91–102, 1992. ISSN 1046-8188. M. Weiser. The computer for the 21st century. Scientific American, 272(3):78–89, 1995. ISSN 0036-8733. D. Wen-Yu, X. Ke, and L. Meng-Xiang. A Situation Calculus-based Approach To Model Ubiquitous Information Services. Arxiv preprint cs/0311052, 2003. T. Winograd. Architectures for context. Human-Computer Interaction, 16(2):401–419, 2001. ISSN 0737-0024. S. Wu, A. Chang, M. Chang, T.C. Liu, and J.S. Heh. Identifying Personalized Contextaware Knowledge Structure for Individual User in Ubiquitous Learning Environment. In Wireless, Mobile, and Ubiquitous Technology in Education, 2008. WMUTE 2008. Fifth IEEE International Conference on, pages 95–99. IEEE, 2008. Wei Xiong and Tayfur Altiok. An analytical approach for performance analysis of j2ee application servers, April 2008. D.J. Xu, S.S. Liao, and Q. Li. Combining empirical experimentation and modeling techniques: A design research approach for personalized mobile advertising applications. Decision Support Systems, 44(3):710–724, 2008. ISSN 0167-9236. Hao Yan and Ted Selker. Context-aware office assistant. In IUI ’00: Proceedings of the 5th international conference on Intelligent user interfaces, pages 276–279, New York, NY, USA, 2000. ACM. J. Yin, Q. Yang, D. Shen, and Z.N. Li. Activity recognition via user-trace segmentation. ACM Transactions on Sensor Networks (TOSN), 4(4):1–34, 2008. ISSN 1550-4859. Z. Yu, X. Zhou, Z. Yu, D. Zhang, and C.Y. Chin. An OSGi-based infrastructure for context-aware multimedia services. communications Magazine, IEEE, 44(10):136–142, 2006. ISSN 0163-6804. Jeffrey Zacks and Barbara Tversky. Event structure in perception and conception. Psychological Bulletin, 127:21, 3, 2001. M. Zafar, N. Baker, B. Moltchanov, J.M. Gon¸calves, S. Liaquat, and M. Knappmeyer. Context Management Architecture for Future Internet Services. ICT Mobile Summit 2009, 2009. A. Zimmermann. Context Management and Personalisation. PhD thesis, University of Aachen, 2007. G.K. Zipf. Relative frequency as a determinant of phonetic change. Harvard Studies in Classical Philology, 40:1–95, 1929. 165

8

G.K. Zipf. The psycho-biology of language. 1935.

166

REFERENCES

Appendix A.1 ContextML A.1.1 ContextML Schema 1 2

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

A Context Provisioning Middleware with Support for ...

A Context Provisioning Middleware with Support for ...

Suggest Documents

A Context-centric Security Middleware for Service Provisioning in ...

Survey of Context Provisioning Middleware

A Context Provisioning Framework to Support ... - Springer Link

Middleware Support for Quality of Context in ... - UT RIS webpage

Middleware Support for Context-aware Mobile Applications ... - PUC-Rio

CAMPUS: A Context-Aware Middleware

MUM: a Middleware for the Provisioning of Continuous ... - CiteSeerX

POSAML: A Visual Modeling Language for Middleware Provisioning *

A Service Architecture for Sensor Data Provisioning for Context ... - Ufes

Middleware for Ubiquitous Context-Awareness - CiteSeerX

Reflective Middleware Solutions for Context-Aware ... - CiteSeerX

Context-Aware Middleware Architecture for ... - Semantic Scholar

Dependability and Accountability for Context-aware Middleware ...

GRECOM: Group Context Management Middleware for ... - CiteSeerX

Middleware for Ubiquitous Context-Awareness - CiteSeerX

CAMPUS: A Context-Aware Middleware - Semantic Scholar

GRECOM: Group Context Management Middleware for ... - CiteSeerX

Middleware for Distributed Context-Aware Systems - CiteSeerX

Toward Context-Awareness: A Workflow Embedded Middleware

A Middleware Supporting Context-Aware Services Based on Context ...

Odin: A Mobile Service Provisioning Middleware - Department of ...

Odin: A Mobile Service Provisioning Middleware - Department of ...

Software Architecture Patterns for a Context Processing Middleware ...

A Middleware Architecture for Context-Aware and ... - CiteSeerX