CONTEXT-AWARE PARADIGM FOR PERVASIVE COMPUTING ENVIRONMENT (CAPP)
By Umar Mahmud
Submitted to the Faculty of Computer Science, National University of Sciences and Technology, Pakistan in partial fulfillment of the requirements for the degree of MS in Computer Software Engineering
November 2006
ABSTRACT
Pervasive Computing integrates numerous, casually accessible and inexpensive mobile devices with traditional distributed systems. The foremost issue of pervasive computing is Context-Awareness. Context-awareness requires a flexible context sensing and context interpretation mechanisms that are used in smart service discovery and its subsequent delivery to the mobile user.
The proposed research, Context-Aware Paradigm for Pervasive Computing Environments (CAPP), is a Service Oriented Architecture (SOA) that enhances smart service discovery in a pervasive environment. Objective of CAPP is to deliver the best service available, among a pool of similar services, to the mobile user. The system gathers the low-level service and user contexts and interprets both these contexts into ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts. To implement the proposed research, this interpreted high-level context is then simulated to discover the best available service for the user.
Evaluation of CAPP is carried out by simulating test cases from daily interactions, in Computer Science Department, as a Java-based application. The effectiveness of CAPP is measured in terms of success and failures where success is the systems ability to select the appropriate service from a pool of similar service to the user, based on the contexts. The projected success rate of the test cases is 89% which is higher than the minimum of 75% set as a standard for this research.
ii
DEDICATION
To my parents.
iii
ACKNOWLEDGEMENTS
All praise and thanks to Almighty Allah who has showered me with His invaluable blessings throughout my life, given me strength and spirit to complete this research work. I thank my parents whose love, care and prayers have enabled me to be what I am. I also express my deepest appreciation to my colleagues whose unfeigned help and encouragement made the present work a reality.
I gratefully acknowledge the help and guidance provided by my project advisors, Dr. Farrukh Kamran, Brig. Dr. Muhammad Akbar, Dr. Amir Qayyum and Lt. Col. Naveed Sarfraz. Without their personal supervision, advice and valuable guidance, completion of this thesis would not have been possible. I am extremely indebted to them for their support and continual help during this work. My very special thanks are extended to Ms. Naima Iltaf for her positive appraisal during the research. I am also obliged to Col. (R) Amir Khan for his kind review of the documentation of this thesis.
I would like to thank all faculty members, who have always been a source of inspiration, for their cooperation and healthy academic environment thought my career at Military College of Signals, Rawalpindi.
iv
TABLE OF CONTENTS 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1. 2.2. 2.3. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.5. 2.5.1. 2.5.2. 2.5.3. 2.6. 2.6.1. 2.6.2. 2.6.3. 2.6.4. 2.6.5. 2.6.6. 2.7. 2.8. 2.9. 2.10. 3 3.1. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.3. 3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.4. 3.4.1. 3.4.2.
INTRODUCTION Introduction Pervasive Computing Systems Issues In Pervasive Computing Systems Context-Awareness Research Challenges in Context-Aware Computing Problem Statement Research Objectives Organization of Thesis Conclusion CONTEXT AND CONTEXT-AWARENESS Introduction Context Defined Structure of Context Context Acquisition Approaches Direct Sensor Access Middleware Infrastructure Context Server Context Management Models Widgets Networked Services Blackboard Models Context Representation Models Key-Value Models Markup Scheme Models Graphical Models Object-Oriented Models Logic Based Models Ontology Based Models Existing Context Aware Systems Comparison of Existing Systems Limitations of The Existing Context-Aware Systems Conclusion SYSTEM DESIGN Introduction Architectural Foundation Design Principles of Distributed Systems Acquiring Contextual Information Managing Context Representing Context Design of CAPP Dispatcher Module Context Congregator Module Context Interpreter Module Decision Making Module Hypothetical Performance Network Bandwidth Computational Time And Computational Load v
1 1 1 2 3 3 4 4 4 5 6 6 6 6 8 8 8 9 9 9 10 10 10 11 11 11 11 12 12 12 15 16 17 18 18 18 18 20 21 22 23 24 25 25 25 26 26 27
3.4.3. 3.4.4. 3.5. 3.6. 4 4.1. 4.2. 4.3. 4.4. 4.5. 4.5.1. 4.5.2. 4.6. 4.7. 4.8. 4.9. 5 5.1. 5.2. 5.2.1. 5.2.2. 5.3. 5.3.1. 5.4. 5.4.1. 5.4.2. 5.4.3. 5.4.4. 5.4.5. 5.5. 5.5.1. 5.5.2. 5.5.3. 5.5.4. 5.5.5. 5.6. 6 6.1. 6.2. 6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.2.6. 6.2.7. 6.3. 6.4. 7 7.1. 7.2.
Response Time Fault Tolerance Advantages of Design Approaches of CAPP Conclusion CONTEXT CONGREGATOR Introduction Characteristics of Contextual Data Context Types Context Space in CAPP Context Representation Scheme in CAPP Requirements of Ontology Languages For Context-Aware Systems Web Ontology Language (OWL) Controlled Vocabulary Vital Context Data Context Taxonomy Conclusion CONTEXT INTERPRETER Introduction Context Processing The Need of Context Interpreter Output of Context Interpreter Context Interpreter in CAPP High-Level View of Context High-Level User Context Deduced Who (User) Deduced Where (User) Deduced When (User) Deduced Health (User) Interpreted User Context High-Level Service Context Deduced Who (Service) Deduced What (Service) Deduced Where (Service) Deduced When (Service) Interpreted Service Context Conclusion DECISION MAKING MODULE Introduction Decision Making in CAPP Which Service Deduced What (User) vs. Deduced What (Service) Deduced Where (User) vs. Deduced Where (Service) Deduced When (User) vs. Deduced When (Service) Final Selection Uncertainty in Decision Process Flow Model of Decision Making Module Conclusion EVALUATION AND ANALYSIS Introduction Evaluation Criterion
vi
27 27 28 29 31 31 31 32 33 34 34 35 35 36 37 39 40 40 40 41 41 41 42 43 43 44 45 46 46 47 47 48 48 49 50 51 52 52 52 53 53 54 54 55 56 56 57 59 59 59
7.3. Assumptions 7.4. Simulation of CAPP 7.4.1. Sequence Diagram 7.4.2. Class Diagram 7.5. Simulation of Test Scenarios 7.5.1. Ayesha Requests a Print Service 7.5.2. Kashif Requests a Scan Service 7.5.3. Waqas Requests a Projector Service 7.5.4. Maryam Requests a Telephone Service 7.6. Analysis of the Scenarios 7.6.1. Analysis of First Scenario (Ayesha Requests A Print Service) 7.6.2. Analysis of Second Scenario (Kashif Requests a Scan Service) 7.6.3. Analysis of Third Scenario (Waqas Requests a Projector Service) 7.6.4. Analysis of Fourth Scenario (Maryam Requests a Telephone Service) 7.7. Performance of CAPP 7.8. User Bias 7.9. Number of Services 7.10. Conclusion 8 EPITOME 8.1. Introduction 8.2. Overview of CAPP 8.3. Accomplishments 8.4. Limitations of CAPP 8.5. The Road Ahead 8.6. Conclusion BIBLIOGRAPHY
vii
60 60 60 61 62 63 66 69 72 74 75 75 76 77 78 80 80 82 83 83 83 84 85 86 86 88
LIST OF TABLES Table Number
Caption
Page Number
2. 1
Comparisons of the Context-Aware Systems
15
3. 1 3. 2 3. 3 3. 4 3. 5
Comparison of Design Principles of Distributed Systems Comparison of Context Acquisition Approaches Comparison of Context Management Models Comparison of Context Representation Schemes Description of Components of CAPP
19 20 21 22 25
41 42
Characteristics of Contextual Data Description of Context Data Type
31 32
7. 1 7. 2 7. 3 7. 4 7. 5 7. 6 7. 7 7. 8 7. 9 7. 10
Vital Context of First Scenario Results of First Scenario Vital Context of Second Scenario Results of Second Scenario Vital Context of Third Scenario Results of Third Scenario Vital Context of Fourth Scenario Results of Fourth Scenario Weighted Averages of Failures and Successes Effect of Number of Services on the Outcome
63 64 66 67 69 70 72 74 78 81
viii
LIST OF ILLUSTRATIONS Figure Number
Caption
Page Number
1.1
A Pervasive Environment
2
2. 1
Structure of Context
7
3. 1
Architecture of CAPP
24
4. 1 4. 2
Context Space Context Taxonomy
33 38
5. 1 5. 2 5. 3 5. 4 5. 5 5. 6 5. 7 5. 8 5. 9 5. 10
Context Processing High-Level View of Context Deduced Who (User) Deduced Where (User) Deduced When (User) Deduced Health (User) Deduced Who (Service) Deduced What (Service) Deduced Where (Service) Deduced When (Service)
40 42 43 44 45 46 47 48 49 50
6. 1 6. 2 6. 3 6. 4
Single User Context vs. Multiple Service Contexts Which Service Priority Lists of Services Decision Making Module
52 53 56 57
7. 1 7. 2 7. 3 7. 4 7. 5 7. 6 7. 7 7. 8 7. 9 7. 10 7. 11
Sequence Diagram Class Diagram Output of First Scenario Bar Chart Showing Results of First Scenario Output of Second Scenario Bar Chart Showing Results of Second Scenario Output of Third Scenario Bar Chart Showing Results of Third Scenario Output of Fourth Scenario Bar Chart Showing Results of Fourth Scenario Success Rate vs. Number of Services
61 62 65 65 68 68 71 71 73 74 82
ix
Chapter 1 INTRODUCTION
1.1
Introduction
This chapter presents pervasive computing environment and highlights contextawareness as its main issue. The concept of context-awareness and its research challenges are also presented. The problem statement and the research objectives are identified. The chapter concludes with the outline of this thesis.
1.2
Pervasive Computing Systems
The development of numerous, mobile, smart and inexpensive mobile devices like, Personal Digital Assistants (PDA), electronic notebooks, smart phones, etc and their subsequent popularity in the life styles of humans have paved the way for Pervasive (Ubiquitous) Computing Systems [1]. Pervasive computing is the progression of distributed systems to mobile computing and is essentially a highly mobile distributed system. Since Weiser’s dream of flawless amalgamation of devices in daily life [2], pervasive environments have progressed from just location-aware systems to contextaware computing systems. Figure 1.1 shows a pervasive computing environment where a user can interact with legacy application and other services using his mobile devices as well as desktop systems.
A hospital is a pervasive computing environment where doctors, nurses and the staff are connected to the main system through their devices. A nurse when checks temperature of a patient uploads it through her PDA to the concerned physician. The physician can then send the same information to a team of doctors and can change the 1
medicine dosage of the patient. This would save time and the physician can be available for more cases.
An educational institute has a number of services available for use by its mobile users. The students and the faculty members can access these devices from their smart phones and PDA’s. A faculty member after giving a lecture can transfer the notes to the students PDA as well as on the network. A group of students can search and use a photo printer to take prints of the pictures.
Figure 1.1: A Pervasive Environment
1.3
Issues in Pervasive Computing Systems
Pervasive computing, with its focus on users and their tasks rather than on computing devices and technology, provides an attractive vision for the future computing. While hardware and networking infrastructure to realize this vision are increasingly
2
becoming a reality, precious few applications run in this infrastructure. The lack of applications can be attributed to the following that are inadequately addressed by existing systems [3]. These issues include gathering and interpreting the context of the participants, enforcement of security and trust relationships among the participants, seamless communication between the mobile devices and the smart spaces, power constraint of the devices, automatic and self configuration with the systems, lack of support tools, human and social acceptance and absence of business models.
1.4
Context-Awareness
The term context-awareness refers to the devices that have information about the circumstances under which they operate and can react accordingly [4]. Context encompasses all of the information relevant to an interaction between a service or application and its set of users including the participants as well. Traditional computer systems do not have an implicit mechanism of inferring information like humans do in their interactions, require a keyboard-mouse based input mechanism and lack the context gathering as well as its understanding techniques. By improving the ability of computers to gather, represent and infer contextual data the resulting system is a more powerful and more useful computation system that follows the human traits.
1.5
Research Challenges in Context-Aware Computing
The research challenges in design and development of context-aware systems, as identified by Winograd and Schmidt are context sensing and acquisition and context inference [5 and 6]. In addition to this, the development of architectural models and the evaluation of context-aware systems are necessary for global acceptance of context-aware systems.
3
1.6
Problem Statement
Context-aware computing systems promise smart service delivery to the mobile users by interpreting the users’ as well as the services’ context. The vague nature of natural language and its construct makes it difficult to comprehend the meaning of syntax based keywords. The naive user is unable to express his requirements in a machine processable fashion. The system is thus required to deliver the appropriate service to the user or a list of probable services that confer to the user requirements and context. The issue lies in interpretation of the contextual information which maybe incomplete or irrelevant for an interaction between a user and the system. There is also a need for resource arbitration that is the delivery of the best service available, among a pool of similar services, to the user. Due to the highly dynamic nature of context and the presence of replicated services, context-aware systems require a complex search mechanism for the selection of the appropriate service.
1.7
Research Objectives
The immediate goals of this research are adumbrated as organization of contextual information, representation of the contextual information conforming to a universal machine readable representation scheme and interpretation of the contextual information for smart discovery of the appropriate or a list of probable services to the user.
1.8
Organization of Thesis
Chapter 1 introduces context-awareness as an issue of pervasive computing environments. Chapter 2 discusses the existing work done in this area and highlights their limitations as the literature review while Chapter 3 proposes the architecture of
4
CAPP as a solution to the limitations of the current systems. Chapter 4 - Chapter 6 elaborate the methodologies of each of the modules of CAPP separately and Chapter 7 describes the evaluation criteria and analyses the outputs of the test scenarios. The thesis concludes in the summary and recommendations for the future work in Chapter 8.
1.9
Conclusion
Pervasive computing systems are a progression towards mobility in distributed systems. These systems strive at providing services to the end user who communicates through smart and inexpensive devices. Context-awareness; knowing the context of a situation is a prime issue of pervasive computing. Context information is acquired, interpreted and is then used for smart service delivery. A Context-Aware Paradigm of a Pervasive Computing Environment (CAPP) that prudently selects an appropriate service for a mobile user in a smart space based on the context information of both the user and services is anticipated in this thesis.
5
Chapter 2 CONTEXT AND CONTEXT-AWARENESS
2.1.
Introduction
Context-awareness, an issue of pervasive computing, adapts application behaviour on the basis of the context of the participants. Every context-aware system has three distinct phases; context acquisition, context interpretation and adaptation. This chapter presents a review of context-awareness and discusses the existing contextaware systems and highlights their limitations.
2.2.
Context Defined
Context encompasses all the information relevant to an interaction between a service or application and its set of users including the participants as well. A comprehensive definition of context as viewed in the setting of pervasive computing is given by Dey as any information that characterizes the situation of an entity wherein, an entity maybe a person, place or object relevant to the interaction between a user and an application, including the user and the application as well [7].
2.3.
Structure of Context
The contextual information has been structured in a number of ways. Schilit structures context as a set of user environment, physical environment and the computing environment that are all part of an interaction [8]. Dey categorizes context as primary and secondary where primary information includes location, identity time and activity while secondary includes all other information [7]. Gwizdka identifies context as internal context; the state of the user and external context; the state of the 6
environment. Petrelli divides context into material context and social context [9]. Material context includes the location, the devices and the available infrastructure. Social context is the set of social aspects of a user as well as his personal traits. Hofer refers to context as physical context and logical context. Riaz identifies context as a set of user, service and system context [10]. The user context is the context of the user who requests a service, service context is the context of the service that is requested by the user, while system context is the context of the context-aware system. These structures of context are summed up in Figure 2.1.
Context (Dey)
Primary (Location, identification, time and activity)
Context (Schilit)
Secondary (All other information)
User
Computing
Context (Gwizdka)
Internal (State of user)
Context (Petrelli)
External (State of environment)
Material (Location, device and infrastructure)
Context (Riaz)
User
Services
Physical
Social (Social aspects and personal traits)
Context (Hofer)
System
Physical (Measured through hardware)
Figure 2. 1: Structure of Context
7
Logical (Specified by users or by monitoring user interactions)
When dealing with context, three entities can be distinguished places (rooms, buildings etc.), people (individuals, groups) and things (physical objects, computer components etc.). Each of these entities may be described by various attributes which can be classified into four categories. These categories are identity (each entity has a unique identifier), location (an entity’s position, co-location, proximity, etc.), status (or activity, meaning the intrinsic properties of an entity, e.g., temperature and lightning for a room, processes running currently on a device etc.) and time (used for timestamps to accurately define situation, ordering events etc.)[11].
2.4.
Context Acquisition Approaches
An integral part of context-aware systems is the gathering of the context data. The data can be gathered in a variety of ways that start from the basic hardware based approach to the sophisticated server based approach. Baldauf presents three different approaches on context acquisition as described in Section 2.4.1 - Section 2.4.3 [11].
2.4.1. Direct Sensor Access This approach is often used in devices with locally built in sensors. Client software gathers desired information directly from these sensors, i.e., there is no additional layer for gaining and processing sensor data. Drivers for the sensors are hardwired into the application, so this tightly coupled method is usable only in rare cases. Therefore, it is not suited for distributed systems due to its direct access nature which lacks a component capable of managing multiple concurrent sensor accesses.
2.4.2. Middleware Infrastructure Modern software design uses methods of encapsulation to separate e.g., business logic and graphical user interfaces. The middleware based approach introduces a layered
8
architecture to context-aware systems with the intention of hiding low level sensing details. Compared to direct sensor access this technique eases extensibility since the client code has not be modified anymore and it simplifies the reusability of hardware dependent sensing code due to the strict encapsulation.
2.4.3. Context Server The next logical step in context acquisition is to permit multiple clients access to remote data sources. This distributed approach extends the middleware based architecture by introducing an access managing remote component. Process of gathering sensor data is moved to the context server to facilitate concurrent multiple accesses. Besides the reuse of sensors, the usage of a context server has the advantage of relieving clients of resource intensive operations since, probably the majority of end devices used in context-aware systems are mobile gadgets with limitations in computation power, disk space etc. In return one has to consider about appropriate protocols, network performance, quality of service parameters etc. when designing a context-aware system based on client-server architecture.
2.5.
Context Management Models
Winograd describes three different context organization models that are Widgets, Networked Services and Blackboard Models for coordinating processes and components [5]. These models are discussed in Section 2.5.1 – Section 2.5.3.
2.5.1. Widgets Derived from the homonymous Graphical User Interface (GUI) elements, a widget is a software component that provides a public interface for a hardware sensor. Widgets
9
hide low level details of sensing and ease application development due to their reusability. Because of the encapsulation in widgets it is possible to exchange widgets which provide the same kind of context data. The tightly coupled widget approach increases efficiency but is not robust to component failures.
2.5.2. Networked Services This is a more flexible approach than the widgets approach and resembles the context server architecture. Instead of a global widget manager discovery, techniques are used to find networked services. This service based approach is not as efficient as the widget architecture due to complex network based components but offers robustness. The networked services approach is derived from the Internet where a large number of services are organized in a global network.
2.5.3. Blackboard Models In contrast to the process-centric view of the widget and the service-oriented model, the blackboard model represents a data-centric view. In this asymmetric approach processes post messages to a shared media, the blackboard, and subscribe to the blackboard. Processes are notified when some specified event occurs. Advantages of this model are the simplicity of adding new context sources and the easy configuration.
2.6.
Context Representation Models
A context representation model is essential to define and store context data in a machine processable form. To develop flexible and useable context depiction schemes that cover the wide range of possible contexts is a challenging task. Strang
10
summarized the most relevant context modeling approaches which are based on the data structures used for representing and exchanging contextual information in the respective system and are presented in Section 2.6.1 – Section 2.6.6 [12].
2.6.1. Key-Value Models These models represent the simplest data structure for context modeling. They are frequently used in various service frameworks, where the key-value pairs are used to describe the capabilities of a service. Service discovery is then applied by using Matching Algorithms which use these key-value pairs.
2.6.2. Markup Scheme Models All markup based models use a hierarchical data structure consisting of markup tags with attributes and content. Profiles represent typical markup-scheme models. Typical examples for such profiles are the Composite Capabilities/Preference Profile (CC/PP) and User Agent Profile which are encoded in Resource Description Framework (RDF).
2.6.3. Graphical Models The Unified Modeling Language (UML) is suitable for representing context. Various approaches exist where contextual aspects are denoted visually using UML. These models are easy to understand and manage.
2.6.4. Object-Oriented Models Symbolizing context by using object oriented techniques offers to use the full power of object orientation (e.g., encapsulation, reusability, inheritance). Existing
11
approaches use various objects to represent different context types (such as temperature, location, etc.), and encapsulate the details of context processing and representation. Access to the context and the context processing logic is provided by well-defined interfaces.
2.6.5. Logic Based Models Logic Based Models have a high degree of formality. Typically, facts, expressions and rules are used to define a context model. A logic based system is then used to manage the aforementioned terms and allows adding, updating or removing new facts. The inference process can be used to derive new facts based on existing rules in the systems. The contextual information needs to be represented in a formal way as facts.
2.6.6. Ontology Based Models Ontology is used to represent a description of the concepts and relationships and is a highly promising instrument for modeling contextual information due to their formal expressiveness and the support of applying ontology reasoning techniques. Various context-aware frameworks use ontology as the underlying context representation scheme. The conclusion of the evaluation presented by Strang show that the ontology based modeling is the most expressive, standardized and fulfils most of the requirements of context organization.
2.7.
Existing Context Aware Systems
Numerous context-aware systems have been developed as applications and frameworks since the start of the last decade. These systems have developed from the systems that identify only location as the context to the systems that realize context as
12
a complex set of data in the environment. The existing systems are discussed in this section.
In 1992, Want introduced a novel system for identification of the location of staff in an office environment called the Active Badge System [13]. The system locates a person through sensors and forwards an incoming call to the nearest handset available. Xerox PARC also used location information for routing telephone calls [14]. Both Active Badge and the PARC are early examples of context-based applications and both systems consider only location of the user as context information. The Cyber Guide at Georgia Institute of Technology (GA Tech) and GUIDE in University of Lancaster used time in addition to location information to provide tour guide services. The Context Toolkit is a context-aware framework that takes a step towards peer-topeer architecture but still needs a centralized discoverer where distributed sensor units (called widgets), interpreters and aggregators are registered in order to be found by client applications [15]. The major drawback of the Context Toolkit is its context representation scheme; a set of attribute-value tuples.
Gaia [16] is a middleware Operating System (OS) that runs on top of existing systems, such as Windows 2000 and Solaris. Gaia integrates services running on different platforms through Common Object Request Broker Architecture (CORBA). It facilitates agents to acquire various types of contextual information and then reason about the acquired contextual data [17].
The ontology is represented by using
DARPA Agent Markup Language and Ontology Inference Language (DAML+OIL).
13
Service Delivery Architecture in CAMUS [10] is Jini based middleware architecture for context-aware systems being developed in Kyung-Hee University in Korea. It is a Service-Oriented Architecture (SOA) which uses context information to address lookup and access control issues. This architecture searches for the desired service on the basis of the services’ context, the client’s context and the semantic attributes. CAMUS realizes the Context Knowledge Discovery (CKDD) which is a knowledge discovery mechanism that infers the context data [18].
Technology Enabling Awareness (TEA), a project of the University of Lancaster, investigated the realization of multi-sensor context-awareness in a self-contained device that would be available as peripheral or plug-in for mobile host devices [19]. The general application perspective was to supply situational context to a mobile host device to improve the device’s service to its user. The architecture follows a layered approach that is sensor dependent resulting in a tightly coupled architecture.
CAPEUS, a Java based project of University of Munich, proposes a document-based approach called as the Context-Aware Packets (CAP) that contains context constraints and data for describing entire service requests [20]. The work revolves around the premise that just offering services to a user is not enough and services should be aligned to a user’s task with lesser involvement of the user.
The architecture of the Context Managing Framework presented by Korpipaa follows a classical hierarchical infrastructure approach with one or many centralized components [21]. This approach is useful to overcome memory and processor constraints of small mobile devices but provides one single point of failure and
14
thereby lacks robustness. The Service-Oriented Context-Aware Middleware (SOCAM) project is architecture for the building and the rapid prototyping of context-aware mobile services [22]. One further extensible centralized middleware approach designed for context-aware mobile applications is a project called Context-Awareness Sub-Structure (CASS) [20].
Context Broker Architecture (CoBrA) is an agent based architecture that supports context-aware computing in smart spaces [24]. Central to CoBrA is the presence of an intelligent context broker that maintains and manages a shared contextual model on the behalf of a community of agents. These agents can be applications hosted by mobile devices that a user carries or wears, services that are provided by devices in a room and web applications that provide a web presence for people, places and things in the physical world. Another framework based on the layered approach is the Hydrogen project [25]. Its context acquisition approach is specialized for mobile devices. The main limitation of this approach is the use of markup representation scheme that lacks the flexibility of representing the concepts of the contextual data.
2.8.
Comparison of Existing Systems
Table 2.1 gives a comparison of the context-aware systems that are presented in Section 2.7 as the existing context-aware systems. Table 2. 1: Comparisons of the Context-Aware Systems
Context Active Badge (1992) Xerox PARC (1992) Classroom 2000 Guide
Location only Location only Location and time
Design Approach Centralized
Ontology n/a
Resource Discovery n/a
n/a
Centralized
n/a
n/a
n/a
Centralized
n/a
n/a
n/a
15
Reasoning
GAIA OS (2002)
Rich set of context information
Service Delivery in CAMUS (2005)
Context is categorized as services’ , user’s and system’s context Context is gathered from multiple sensors Context is represented as a ContextAware Packet Rich set of context data
Table 2.1 (Contd.) DAML+OIL CORBA based compliant ontology middleware OS that runs on different platforms Uses common JINI based ontology Serviceoriented architecture
Discovery Service
Allows a variety of reasoning and learning mechanisms.
Service registration module
Semantic matching and rule based context knowledge discovery n/a
Multi-sensor approach.
n/a
n/a
Documentbased decentralized approach
n/a
n/a
Rule based at service access nodes
Blackboard approach
RDF based ontology
Context recognition
Rich set of context data
Centralized server
OWL based ontology
Rich set of context data Rich set of context data
Centralized middleware Agent based
Relational data model OWL based ontology
Resource servers and subscription mechanism Uses a Service locating service n/a
Context Toolkit (1999)
Rich set of context data
Widget based
Attributedvalue tuples
Discoverer component
Hydrogen (2002)
Rich set of context data
Layered architecture
Object oriented
n/a
TEA ContextAwareness Module
CAPEUS
Context Managing Framework (2003) SOCAM (2004) CASS (2004) CoBrA (2003)
2.9.
n/a
Reasoning engine inference engine Knowledge based inference engine Context interpretation and aggregation Interpretation and aggregation of raw data
Limitations of The Existing Context-Aware Systems
The early context aware systems were only location based. With the development of further systems context took a more comprehensive meaning that describes a situation. The existing context-aware systems are either applications that adapt application behaviour or adjust other applications based on the contextual information. Not all the systems have a rich context representation scheme that allows 16
flexibility of representing and incorporating new concepts that define a state. In addition, the context interpretation mechanism is not standardized and custom reasoning engines have been employed. These systems are not generic and have been developed to address specific problems.
2.10. Conclusion This chapter introduces the concept of context and context-awareness, identifies the approaches of context acquisition and context management and lists the representation schemes used for contextual data. An overview of the existing context-aware system is presented with their comparison and the chapter concludes with the limitations of the present systems.
17
Chapter 3 SYSTEM DESIGN
3.1.
Introduction
A service oriented architecture following the networked services approach of contextaware computing for the development of CAPP is projected. Such a system is able to fit in any environment, gather context, interpret it and deliver services to the user. This chapter discusses the architectural foundation of CAPP and presents the design of CAPP. The hypothetical performance of CAPP is discussed and the advantages of the selected approaches are listed.
3.2.
Architectural Foundation
This section gives a comparison of the design principles of distributed systems, context acquisition techniques, the context management models and context representation schemes as presented in Section 2.4, Section 2.5 and Section 2.6 respectively, and selects the approaches followed in CAPP.
3.2.1. Design Principles of Distributed Systems The context-aware system being a specialization of ubiquitous computing has its foundation in the design principles of distributed computing. These principles include Service Oriented Architecture (SOA), Message Oriented Middleware (MOM) and Mobile Agents. These principles provide a guideline on which a distributed system is designed and developed. Table 3.1 highlights the differences among these three principles [26 - 28].
18
Table 3. 1: Comparison of Design Principles of Distributed Systems
Service Oriented Architecture (SOA) Uses services to support the requirements of software users through request-response paradigm. Services are stateless in SOA
Message Oriented Middleware (MOM) Relies on asynchronous message passing paradigm based on a message queue system
Advantages
Loosely coupled, highly interoperable, independent of development technology. Provides a discovery mechanism.
Provides a persistent storage to back up message transfer, is able to route messages within the middleware layer and allows message transformation to meet the requirements of the sender
Disadvantages
Requires more programming effort as well as more computation
Requires an extra component in the shape of message transformation in the architecture which can reduce performance. Does not support synchronous services
Description
Mobile Agents Mobile agents are composition of data and code that is able to migrate from one computer to another autonomously and continue its execution on the destination computer Highly mobile, autonomous, has learning ability, are tolerant to network failures, flexible maintenance, asynchronous and dynamic
Security and trust, requires smaller size and does not mask heterogeneity completely
From the comparison in Table 3.1, SOA provides a better architecture by ensuring loose coupling. MOM requires a message transformation mechanism and does not support synchronous services. Since, in a pervasive environment, services can be synchronous as well as asynchronous MOM does not fit effectively in a pervasive environment. The mobile agent approach is newer than the other two. Though it is highly mobile but is not completely secure and still has platform dependence due to the code it carries. Thus service oriented approach for development of the environment as well as CAPP is followed in this thesis.
19
3.2.2. Acquiring Contextual Information The basic task of a context-aware system is to acquire contextual information from the environment. The three different approaches as Direct Sensor Approach, Middleware Infrastructure and Context Server of Context Acquisition are given in Section 2.4. The comparison of these approaches is in Table 3.2. Table 3. 2: Comparison of Context Acquisition Approaches
Description
Advantages
Disadvantages
Direct Sensor Approach Suitable for devices with locally built sensors
The client gathers information directly from the sensors making the design simple Tightly coupled and not suited for distributed systems
Middleware Infrastructure Introduces a layered architecture to context-aware systems by providing an abstraction layer that hides the low level sensor data Ease of extensibility and simplifies reusability
More complex than direct sensor approach and no access management is present
Context Server Extends the middleware infrastructure by introducing an access managing component Highly reusable and extensible, loosely coupled
Complex
Analyzing the comparison in Table 3.2, the middleware infrastructure and the context server approaches are more suited for distributed applications. Since the context is gathered from a number of sensors providing different type of information, a need for a synthesizer is intuitive. Also the sensor providing low level contextual information must be protected from the malicious user. The presence of a person who can exploit someone’s privacy by gaining location information by directly accessing the sensor demands an access management component that disallows access to the sensors or the sensor services directly. In such a case, the context server approach is the obvious choice.
20
3.2.3. Managing Context Winograd describes Widgets, Networked Services and Blackboard Model as three different context management models for coordinating multiple processes and components as discussed in Section 2.5. These models are evaluated under the tradeoff criteria including efficiency, configurability, robustness and simplicity. The comparison is given in Table 3.3 as follows. Table 3. 3: Comparison of Context Management Models
Widgets
Networked Services
Blackboard Model Follows a datacentric approach as opposed to process centric view of networked services. The processes send messages to a shared board and can subscribe to receive messages Highly loosely coupled
Description
An extension of the device drivers to the software interface. They separate functionality of a component from its implementation
Designed on the client-server architecture and require a discovery process
Advantages
Provides an abstraction layer
Independence of components and do not require a central manager. They follow a decentralized approach and are loosely coupled Requires registration and lookup processes
Disadvantages
Efficiency
Configurability
Robustness Simplicity
Active widgets require a centralized widget manager and tightly coupled Most efficient
Less efficient
Complex configurability due to presence of different platforms Lack robustness Simple
21
Easily configurable
Highly Robust Complex
Require an optimized message structure Less communication efficiency Easily Configurable
Highly Robust Simplicity of providing a uniform path while management is complex
Widgets were used by Dey in the Context Toolkit and are an older approach which lacks robustness and are complex to configure. The Internet saw the development of networked services that interact with each other using a client-server paradigm. The blackboard approach follows the blackboard technique of artificial intelligence. The networked services are a time tested technique which has been implemented as the Internet. The main difference between the networked services and the blackboard technique is the decentralized and centralized approaches respectively. In a distributed system the centralized approach becomes more complex due to the failures in the network and the processes. Also, the lack of an optimized message structure requires more programming effort in the blackboard model.
3.2.4. Representing Context The context representation schemes as discussed in Section 2.6 are used to structure the contextual information. The comparison of these representation techniques is given in Table 3.4. Table 3. 4: Comparison of Context Representation Schemes
Description
Advantages
Disadvantages
Uses Key-valued pairs to describe contextual data
Simplest data structures and are easy to manage, fastest data retrieval
Lack capabilities to structure complex and sophisticated contextual data
Markup Scheme Models
Uses markup schemes to represent the contextual data.
Provides a hierarchical data structure consisting of markup tags with attributes and contents that have a rich representation mechanism and efficient retrieval.
Does not support incomplete or vague information. Lack reasoning support
Graphical Models
Follows a graphical approach to represent contextual data
Generic structure due to the use of visual components
Limited to the structuring for a relational database
Key-Valued Models
22
Table 3.4 (Contd.)
Object Oriented Models
Logic Based Models
Ontology Based Models
Uses object and object relations approach to model the context Uses facts, expressions and rules to represent the contextual information Uses ontology (concepts and relationships) to represent the context
Provides encapsulation, inheritance. Access through specified interfaces Provides a high degree of formality and powerful reasoning mechanisms Provides a rich and standardized approach that incorporates reasoning to interpret the context
Lacks support of the reasoning techniques
Does not provide a rich representation of the context
Is complex and requires more programming effort
In a pervasive environment the contextual data is highly dynamic and distributed throughout the network. The context representation scheme should provide a rich structure to represent the data as well as adapt to its dynamic nature. From the comparison in Table 3.4, the noticeable candidates for selection are the markup scheme model, object oriented model, logic based models and the ontology based model. Among these three selected models the markup scheme model lacks the support of incomplete or ambiguous data which is frequently occurred in a pervasive system. The object oriented model does not provide reasoning to interpret the data. Reasoning can be provided through external components that requires a high interaction between the two components. The logic based model is also not selected due to their lack of flexibility. However, ontology based models promise an efficient model that supports reasoning and hence, ontology based model is selected as the context representation scheme in CAPP.
3.3.
Design of CAPP
The architecture of CAPP is designed to be generic so that it can fit in with any pervasive environment. The preferred implementation is envisaged to be platform as 23
well as programming language independent following an industry standard. The objective is to select the best service, among a pool of similar services, for a client based on the client’s context as well as the services’ context. The entire gathered context is represented as a hierarchy while providing flexibility of change. The context is interpreted by inferring the ‘What’, ‘Who’, ‘When’ and ‘Where’ contexts while weighted averages are used to facilitate the selection of the best service. Keeping in view the various design approaches presented in Section 3.1 CAPP is proposed as a SOA based on a modular structure, as shown in Figure 3.1. Table 3.5 gives a description of the components.
Figure 3. 1: Architecture of CAPP
3.3.1. Dispatcher Module It is the interface to CAPP responsible for forwarding request to the congregator. It communicates directly with the session manager present in the smart space. This module hides the functionality of the system from external users and systems and provides threading mechanism for a higher efficiency.
24
3.3.2. Context Congregator Module This module gathers context data by invoking sensor services and represents the contextual data as services’ context and users’ context by using ontology. The methodology employed in this module is further elaborated in Chapter 4.
3.3.3. Context Interpreter Module This module interprets the gathered context by inferring the context data into ‘What’, ‘Where’, ‘When’ and, ‘Who’ contexts of both the service and the user. The module implements rule-based techniques for interpretation process and is discussed in Chapter 5.
3.3.4. Decision Making Module This module makes a decision on which is the best service for the user by employing weighted averages. The system returns the best service or a short list of the probable services to the users. This module implements the smart service discovery process which is presented in Chapter 6. Table 3. 5: Description of Components of CAPP
Dispatcher Module
Function
Receives request and dispatches it to the context congregator module. Returns the result to the requester This module listens to incoming requests and forwards them to the congregator for context gathering. Client information and request Client information and request with a request ID Gather context data on the basis of client’s info and request and represent the gathered information in the form enforced by the rule repository This module gathers context data. Client information and with a request ID Gathered (vital) context
Description
Inputs Outputs Context Congregator Module and Representation Rules Repository
Function
Description Inputs Outputs
25
Table 3.5 (Contd.)
Context Interpreter Module
Function
To interpret the gathered context as Who, What, When and Where contexts of both the user and the services This module interprets the gathered context by and identifying Who, What, Where and When contexts Gathered (vital) context Interpreted context The main task of this module is to interpret the gathered context Makes decision on which service is to be delivered to the client on the basis of interpreted context and weighted averages of the interpreted contexts Receives interpreted context and decides as which is the best available service that should be delivered to the client or returns a list of probable services to the client Interpreted context Best service/list of probable services Uses weighted averages to make decision
Description
Inputs Outputs Other Decision Making Module
Function
Description
Inputs Outputs Other
3.4.
Hypothetical Performance
This section discusses the hypothetical performance of the design suited for CAPP. The performance parameters are network bandwidth, computational time and load, response time and fault tolerance. The performance attributes in Sections 3.4.1 - 3.4.4 highlight the limitation of the system design and propose optimization techniques to overcome these limitations.
3.4.1. Network Bandwidth The architecture of CAPP being service oriented requires the implementation of a discovery service. This service is used to lookup services present in the system. This requires at least a pair of request response messages for a single lookup. With the implementation of the sensors as sensor services, the context service also requires to discover the sensor services before each request is received. This reduces the network bandwidth due to the presence of redundant messages. This network overhead could
26
be defeated by limiting the discovery of sensor services by the context service to the optimum. Other performance tuning practices could also be applied to increase the network bandwidth by decreasing the network load.
3.4.2. Computational Time And Computational Load The gathering of context information from the sensor services and then its interpretation leading to a decision becomes computation heavy. The computation time can be reduced by using faster rule-based techniques while avoiding time consuming machine learning practices. The context service will typically encounter heavy loads due to the presence of multiple requests for each user in an environment filled with a large number of eager users. This puts heavier load on the system and requires an efficient threading process that also monitors each request made to the service.
3.4.3. Response Time In the fast world of computations, naïve users judge the performance of a service on the basis of the response time. The responsiveness of the system is dependent on the moment it receives a request for a client to the moment it generates some result. The shorter the response time the better is the service. It also encompasses reaching a conclusion by providing a single best service or a short list of probable services to the user.
3.4.4. Fault Tolerance All distributed systems are subject to faults arising in the network as well as the nodes. These systems require a higher degree of fault tolerance due to the nature of
27
unreliable connections. In CAPP, the sensor services may fail at any time or might not be able to response due to high load. The data gathered would be incomplete and will have vague values. This requires a powerful interpretation mechanism that can overcome the missing data and is still able to produce some result.
3.5.
Advantages of Design Approaches of CAPP
The advantages of the design approaches of CAPP in terms of modularity, scalability, service orientation, standardization, atomicity, heterogeneity and transparency are discussed in this section.
The model is modular in structure which increases the flexibility of the system. The modular approach also segregates tasks in to different modules making the programming efforts as well as the validation process simple. This avoids serial execution by providing a parallel foundation. The dispatcher module present in the model is responsible for generating threads when a request is received. These threads can support a large number of users thus ensuring scalability of the system
The architecture being service oriented conforms to the time tested standard of networked services, example of which is the Internet. This follows a more loosely coupled and robust approach than the middleware based tightly coupled design. The presence of multiple sensor services demands a centralized management that is responsible for gathering context from these sources. This is managed through the use of a context server based approach that provides an access managing component. The use of industry standard data representation scheme provides a loosely coupled, platform independent implementation that is able to communicate with all standard
28
components. The standardization provides an abstraction layer that separates the underlying platform from the application. The result is a highly accessible architecture that is able to speak with other standard services.
The architecture is based on a request response messaging passing paradigm that supports both the synchronous as well as the asynchronous calls. This increases the horizon of the system that incorporates synchronous as well as asynchronous request reply messages. The system hides the sensor services from being directly accessed by the user thus ensuring access transparency. Location transparency is achieved as the sensor sources are accessed without knowledge of their location. The support of multiple instances of resources enables replication transparency. Configurability of the system to achieve high performance provides performance transparency whereas; the system provides mobility transparency by allowing clients to be highly mobile. The system is able to mask faults and expand in scale without change to the structure of the model thus enabling fault transparency and scalability transparency respectively. The model ensures that either a result is generated or an error reported hence ensuring atomicity. There are no arbitrary responses in the model. The result may be a single service or a short list of probable services. The model supports heterogeneous systems by using standard message structures as well as protocols. This provides an abstraction to the underlying platform that includes the hardware and the operating system.
3.6.
Conclusion
This chapter presents the design of CAPP that follows the service oriented and module based approach. The model uses the context server approach for acquiring
29
contextual data, the networked service approach for managing the context and the ontology for representing the context. The module provides heterogeneity, transparency, atomicity, scalability and supports asynchronous and synchronous calls.
30
Chapter 4 CONTEXT CONGREGATOR
4.1.
Introduction
The context-aware system delivers the best service to the user on the basis of the users’ context as well as the services’ context. This chapter discusses the Context Congregator that gathers the contextual data and represents the data using ontology. This module receives the user identification (ID) and the request, searches for the requested service type in the service list and gathers the vital contextual data required for the requested service type. The output of this module is the gathered context. The ontology has been developed in Web Ontology Language (OWL) [29 and 30], which is an industry standard, using the Protégé tool [31 and 32].
4.2.
Characteristics of Contextual Data
Context is everything that describes a particular situation of an entity in its surroundings. In a pervasive environment the user and the services are the entities of context. Contextual information has some characteristics that are presented in table 4.1. Table 4 1: Characteristics of Contextual Data
Characteristics of Contextual Data Heterogeneity
Vibrant Context
Description
The contextual data comes from a variety of systems and platforms and can have different representation. There is a need for a data representation standard that masks the heterogeneity of the platforms. The contextual data is highly dynamic and vibrant. This generates a high quantity of data which raises storage and bandwidth constraints.
31
Table 4.1 (Contd.)
Due to the inherent packet losses in wireless networks, the contextual information may not be gathered from an unreachable sensor service or out-dated information may be returned that will hamper the interpretation of the higher-level context. Some parameters of the contextual information are sensitive the health record or location of a person. These parameters should not be accessed unnecessarily or provided to unauthorized parties. The context data has different levels of interpretation as it is structured as low-level context and high-level context. The highlevel context is inferred from the raw, meaning-less low-level context. The context information is spread across the network which requires that the context be consistent throughout the system. All the sensor services and the context-aware systems must have the latest information and any change must be propagated through the network.
Missing and Imperfect Data
Privacy
Levels of Interpretation
Consistency
4.3.
Context Types
The context is a large data set and can be classified into numerous context types that organize the raw contextual data into spatial, temporal, environmental, activity, community and identification categories. The context types that have been identified in CAPP are described in Table 4.2. Table 4 2: Description of Context Data Type
Context Data Type Identification Information
Spatial Information
Temporal Information
Activity Information
Description This category includes the identification parameters e.g., name, ID, social security number (SSN), work and home address of the user while it specifies the name, description, type and ID of a service. These parameters are used to uniquely identify the participants of an interaction. This is the context that is related to the location parameters. For the nonmobile user it is simply the current location of the user. If the user is mobile then the speed, direction and heading information yield the expected location of the user. Similarly, the location parameters of a service are part of its spatial information. Time, date, month, season and year are part of the temporal information of both the user and the service. For the user it is more specifically the time of initiation of request and for the service it is the time of receipt of the request. Attributes that describe the activity of the user as busy or idle as well as those that describe the status and activity of the service as idle, offline or active are elements of the activity information for both the user and the service respectively.
32
Table 4.2 (Contd.)
Environmental The environmental conditions of the surrounding area in terms of temperature, humidity, noise, air composition and quality, pollen and Information dust levels and illumination are the environmental parameters. Context that describes the peers and their devices and available services Community and their status form the community information. Information Information that provides the health of the user including blood Health pressure, pulse, and heart beat rate, temperature and the sugar level. This Information also specifies if the user has any health constraints e.g. allergies, frequent headaches etc. Advanced information includes mood, emotions, and role of the user Advanced while it specifies the availability time, queue length, load, battery power Information and the network bandwidth parameters of the service and the user device. Advanced information can also incorporate any unseen context information that may not fall into the previous categories.
4.4.
Context Space in CAPP
The contextual information is classified into hierarchical category that provides efficient organization and retrieval. The main entities are the user and the services. The user interacts with the services including the system through a number of devices. These devices are part of the user’s context since they are client to the services. Figure 4.1 shows the categorized context that is used in CAPP.
Figure 4. 1: Context Space
33
The broad subcategories of both types of context are same as well as some of its attribute names like location, time etc but the values stored in these attributes are in perspective of either the user or the service. The resulting hyperspace formed by instantiating the attributes is referred as context space. The context space comprises of set of contextual information where a point in the context space identifies a situation or interaction between the user and the service.
4.5.
Context Representation Scheme in CAPP
There are a number of languages that are used to implement ontology. Ontology is the specification of concepts or real world entities [33]. It is a description of the entities and there relationships that can exist for a community. The ontology is expressed in a concrete formal notation called the ontology language. There are a number of ontology languages both proprietary and standards based. These include DAML+OIL, RDF and OWL.
4.5.1. Requirements of Ontology Languages For Context-Aware Systems A representation scheme is required to symbolize the contextual information [34]. The requirements of an ontology based representation scheme in context-aware systems are discussed in this section. The ontology should be well-defined and well-structured thus ensuring high degree of formality by providing a complex data structure. The structure of the context maybe complex but retrieval of context should be simple and efficient. The data structures should be standardized so as to mask the representation issues of heterogeneous platforms. The ontology language should be reusable, flexible and adaptable to the fast changing context. The representation format should support interpretation to meaningful or high-level context through semantic reasoning.
34
4.5.2. Web Ontology Language (OWL) OWL is a standards-based ontology language for publishing and sharing concepts on the Internet. It is an extension to the RDF and is derived from DAML+OIL. OWL is a part of the Semantic Web Vision where information on the web is machine readable, has exact meaning and is described [29]. OWL is a strong language with greater machine interpretability and comes in three flavors or sub-languages [30 and 31], OWL Lite, OWL DL and OWL Full. OWL Lite is the simplest form of OWL and supports those users who primarily need a classification hierarchy and simple constraints. It also has a lower formal complexity and provides easier reasoning. OWL DL (Description Logics) supports those users who want the maximum expressiveness while retaining computational completeness and decidability. This means that all computations will finish in finite time and are guaranteed to be completed. OWL Full is meant for those users who want maximum expressiveness and the syntactic freedom of RDF at the cost of lack of computational guarantees.
All these sub-languages are a simple extension of its predecessor but not vice versa. OWL Full includes capabilities of OWL Lite and OWL DL, while OWL DL includes capability of OWL Lite. OWL Full has been employed because of its support of automated reasoning in addition to highly expressive structure.
4.6.
Controlled Vocabulary
Controlled Vocabulary is a set of keywords or phrases that are used to tag units of information for smart and efficient retrieval by a search. These terms improve the accuracy of free text searching by reducing irrelevant terms and reducing the search space and eliminate the ambiguities present in natural languages.
35
The context congregator requires that it searches for the services present that are requested by the users. These services may have names or aliases different than the request made by the client. These uncertainties can be avoided by providing a controlled vocabulary. Such a controlled vocabulary has keywords that provide us to search for a type of service. For example, a user asking for a temperature service could be replied by locating a weather service that is registered with the system. The controlled vocabulary is used to find the service type on the basis of the user request. This service type provides us the services that have the target functionality and must be considered as a candidate for selection of the best service.
4.7.
Vital Context Data
The amount of contextual data specified in section 4.3 as the context space is large and not easily manageable. It is inefficient to gather all the data at all times or when a user has requested an interaction. Some of the data is necessary for a particular interaction while the rest has no effect on the interaction. If all the data is to be maintained at all time, the system will become inefficient and will have large response time. This can be avoided by gathering only the data that is critical to the interaction. For example, a user requesting a file service may not require the health and environmental information to be maintained whereas, the suitable service may not be delivered to the user if the spatial information of both the user and the print service(s) is not maintained.
A list of necessary data for each type of interaction has been identified and is maintained in the context congregator. In CAPP hard-coded lists of vital contexts are developed as files. This lacks adaptability and is unable to incorporate future
36
contextual data types. The list of necessary data can be further improved by providing knowledge based sub module that identifies the vital context for the requested services on the basis of the use of the contextual data and modifies the list as required.
4.8.
Context Taxonomy
Based on the concept space in Figure 4.1, the concept taxonomy of CAPP is generated using the Protégé OWL plug-in [32]. The parent concept Context has sub contexts User Context and Service Context. The user context is concerned with the user of the system including the human user as well as the devices held by the human user. The service context is responsible for the context of the services including the system which is developed as a service. The user and the service contexts are further sub classified into the temporal, activity, environmental, identification, spatial, community, health and advanced sub-concepts that are discussed in Section 4.3. Each of these sub-concepts is further classified into the low-level concepts. The subconcepts are designed to categorize similar contextual data into the same parent concepts. The actual contextual data is held in the data type properties at the low-level concept layer.
The Service Context identifies only that contextual data which corresponds to the services in the system. These include the service identification, service surroundings information, peer services information, service temporal and service spatial information. The context of the user and the user devices are identified in the User Context. These have been classified into identification, environment, community, temporal, spatial and health information. The context taxonomy is shown in Figure 4.2.
37
Context ServiceContext ServiceActivityInformation ServiceQueueAvaialableSpace ServiceQueueLength ServiceStatus ServiceAdvancedInformation ServiceAvailabilitySituation ServiceNetworkSituation ServiceCommunityInformation AvailableServices RedundantServices ServiceEnvironmentInformation ServiceSurroundingNoise ServiceSurroundingTemperature ServiceIdentificationInformation ServiceDescription ServiceIdentification ServiceOwner ServiceType ServiceSpatialInformation ServiceLocation ServiceMobility ServiceTemporalInformation ServiceTimeAndDate UserContext UserAdvancedInformation UserDevicesAndState UserEmotionalState UserRole UserAvtivityInformation UserActivity UserCommunityInformation UserPeerDeviceSituation UserPeerInformationInVicinity UserEnvironmentInformation UserSurroundingNoise UserSurroundingTemperature UserHealthInformation UserBloodPressure UserPulseAndHeartBeatRates UserSugarLevel UserTemperature UserIdentificationInformation UserAddress UserIdentification UserName UserSSN UserSpatialInformation UserLocation UserMobility UserOrientation UserTemporalInformation UserTimeAndDate
Figure 4. 2: Context Taxonomy
38
4.9.
Conclusion
This chapter discusses the Context Congregator Module of CAPP. The main task of this module is to gather the context data and represent the gathered context using OWL based ontology. The ontology has been broadly classified as the users’ context and the services’ context and Protégé OWL Tool has been used to specify the context taxonomy. A controlled vocabulary that maintains the keywords, aliases and names of each service has been developed to search for the requested service type in the system. The services falling under the requested service type are then selected for vital context acquisition from the sensor services. The output of this module is the gathered vital context which is then forwarded to the Context Interpreter Module.
39
Chapter 5 CONTEXT INTERPRETER 5.1.
Introduction
The gathered low-level context is interpreted to high-level context that provides meaning to the raw data. This task is carried out in the Context Interpreter Module that takes the vital context as its input and generates the interpreted context of both the users’ and the services’. This chapter discusses the context interpreter and elaborates the transformation process from low-level context to high-level context.
5.2.
Context Processing
Context processing is used to gather the raw context data and produce a meaningful interpretation [11]. Context processing has two parts Congregation and Interpretation as shown in Figure 5.1.
Context Processing Context Congregation Raw, Low-Level Context Context Interpretation Interpreted, High-Level Context
(To The Decision Making Module)
Figure 5. 1: Context Processing
40
(Data from Sensor Services)
5.2.1. The Need of Context Interpreter The low-level contextual data is raw and meaning less. To provide meaning to the low-level context, a transformation process in the form of a context interpreter is envisaged. The context interpreter produces a high-level context that facilitates the smart service delivery to the user. For example, Tariq a faculty member and located in lecture hall does not mean anything when seen separately. But, as soon as the role as well as the location is combined the interpretation specifies the activity of Tariq as he is giving a lecture in the lecture hall.
5.2.2. Output of Context Interpreter The output of the context interpreter is an interpreted, high-level context. This context is constructed in a way that highlights the meaning of the situation both in machine understandable as well as human comprehensible form. The output of CAPP is based on the ‘What’, ‘Who’, ‘Where’ and ‘When’ contexts of both the users’ and the services’.
5.3.
Context Interpreter in CAPP
Conforming to the context processing as shown in Figure 5.1, CAPP provides a context interpreter that takes in the low-level context from the Context Congregator and then transforms the low-level context using a rule-based technique to the highlevel context. This section discusses the algorithms designed to interpret the gathered context. This high-level or interpreted context is then passed to the decision module that selects the appropriate service for the user. Section 5.3.1 presents the high-level view of the contextual data while Section 5.3.2 discusses the composition of the highlevel context.
41
5.3.1. High-Level View of Context The context congregator structures the contextual data in a hierarchy that separates the users’ context from services’ context as described in section 4.3. This top layer of the hierarchy is actually the high-level context view of the low-level context as highlighted in Figure 5.2.
Figure 5. 2: High-Level View of Context
5.3.2. Composition of High-Level Context The high-level context identifies the ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts of both the users’ as well as the services’. The low-level context is firstly categorized into the above mentioned categories and then interpreted to give meaning to the context. The ‘Who’ context is concerned with the identification and description parameters and the ‘What’ context interprets the user’s request as well as the services’ capabilities or functionalities. The ‘Where’ context specifies the location and environmental parameters while ‘When’ gives the time when the request was made and the time when the service will be delivered.
42
5.4.
High-Level User Context
The High-Level User Context attempts to identify the user, locate the user and specify when the user requested the service. The ‘Deduced What’ context for the user is the requested service type and is handled in the context congregator to provide smooth functionality. The user also has a special category of his health that specifies his health constraints.
5.4.1. Deduced Who (User) The user is deduced on the basis of the ID, role, name or alias and SSN. This module returns the ID and the role of the user who generated the request. In an everyday interaction, role is generally misinterpreted or is not present at all. So, in the absence of the role, try to deduce the role of the user by comparing the activities of the user with the activities of its peers. This is shown in Figure 5.3 as a flow model.
Figure 5. 3: Deduced Who (User)
43
5.4.2. Deduced Where (User) This reasoning is concerned with as, where the service should/will be delivered to the user. More specifically, this identifies on the basis of user location, user mobility and user orientation that where the user is located. In an event the user location information is missing, user surroundings information is then used to deduce the location of the user. This process is shown in Figure 5.4.
Figure 5. 4: Deduced Where (User)
44
5.4.3. Deduced When (User) Deduced when is divided into two parts; Deduced Time and Deduced Activity. The objective of the first part is to infer the time when the service is requested by the user. This is inferred from the user date, user time and the user time of day. In the absence of all or some of the user time parameters, the time is identified as the time when the request was received in the dispatcher module. The second part infers the time when the service should be delivered to the user. This time is based on the activity of the user and the state of users’ devices. This procedure is shown in Figure 5.5.
Figure 5. 5: Deduced When (User)
45
5.4.4. Deduced Health (User) The health category involves all those parameters that are part of the health parameters of the user. If the health of the user is not normal, this would constraint the selection of best service for the user. The deduced health will simply identifies whether the user has an abnormal health situation or not as shown in Figure 5.6.
Figure 5. 6: Deduced Health (User)
5.4.5. Interpreted User Context With the deductions of the high-level context in terms of ‘Who’, ‘Where’, ‘When’ and ‘Health’ of the user, the interpreted user context is hypothesized as, “User Deduced User (User) has requested a Deduced What (User) service at Deduced When (User) time. The user wants the service to be delivered at Deduced Location (User) while he/she is involved in activity Deduced Activity (User) and has health condition Deduced Health (User)”.
46
5.5.
High-Level Service Context
The High-Level Service Context attempts to identify the service and its type, locate the service and when the service will be available for use. There are no health constraints for a service but future unseen constraints may be incorporated in the system as per requirement.
5.5.1. Deduced Who (Service) The service is deduced on the basis of the service name, service ID, service alias or the service owner. Every service has a unique service ID in a smart space and hence is referenced through its ID. If the ID is unavailable then it must be inferred through name, alias or the owner as shown in Figure 5.7.
Figure 5. 7: Deduced Who (Service)
47
5.5.2. Deduced What (Service) This category infers the primary and secondary types of the service by evaluating the type information in service list as well as the description of the service. A service may have different name than its type and thus, requires a ‘What’ associated with each service. If the type of the service is available then the deduced what is simply the available type information. In the absence of the type information, the service description is used to infer the type of the service. The process is shown in Figure 5.8.
Figure 5. 8: Deduced What (Service)
5.5.3. Deduced Where (Service) The high-level where information of the service specifies where the service is located and in case the service is mobile specifies its expected location. In an event the location information is unavailable the location of the service is inferred through the service surrounding information as shown in Figure 5.9.
48
Figure 5. 9: Deduced Where (Service)
5.5.4. Deduced When (Service) This information identifies the time when the service will be available for use. This high-level view considers the load on the service, the network situation of the service and the time information of the service to deduce the availability time of the service. This process is depicted in Figure 5.10.
49
Figure 5. 10: Deduced When (Service)
5.5.5. Interpreted Service Context With the inferences of the high-level context in terms of what, where, when and who of the service the interpreted service context is hypothesized as “Service Deduced Service (Service) is of type Deduced What (Service). The service is located at location Deduced Where (Service) and will be available at time Deduced When (Service)”.
50
5.6.
Conclusion
This chapter deals with the design of the Context Interpreter which is the core module of CAPP. The context interpreter receives the gathered vital context of the user and the services and hypothesizes the interpreted user and service contexts. The interpreted contexts are structured as ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts for both the entities. These categories help establish a comparison, with respect to each other, between the user and the services. The output of this module is made available to the Decision Making Module which is tasked with selecting the best service for the user.
51
Chapter 6 DECISION MAKING MODULE
6.1.
Introduction
Decision Making is the cognitive process leading to the selection of a course of action among alternatives. Decision making process is involved in everyday human interactions and various methods have modeled the human decision making behaviour into computer systems. The decision making in CAPP selects the best service among a pool of similar service for a user based on both the users’ and the services’ contexts. This chapter discusses the decision making process in CAPP and uses the weighted averages to select the most appropriate service.
6.2.
Decision Making in CAPP
The output generated by the Context Interpreter is the Interpreted User Context and the Interpreted Service Context. In a typical scenario the decision making module is met with a single user context and multiple service contexts. This is illustrated in Figure 6.1.
Service Context
User Context
Service Context
Service Context
Figure 6. 1Single User Context vs. Multiple Service Contexts
52
6.2.1. Which Service The presence of multiple service contexts against a single user context for a single interaction highlights the selection of the most appropriate or ‘Which’ service for the user. The selection is made on the basis of deduced high-level contexts of ‘What’, ‘When’ and ‘Where’. The outcome is a ‘Who’ service that is suitable for the ‘Who’ user. The process of Which Service is shown in Figure 6.2.
Service Context 1 Service Context 2
User Context Inputs
Service Context N
Decision Making Module
Output
User Context
Best Association
Service Context J
WHICH
Figure 6. 2: Which Service
6.2.2. Deduced What (User) vs. Deduced What (Service) The ‘Deduced what’ in terms of the user infers the requested service type of the user. The user requested keyword is deduced to find the type of the requested service. All
53
the services listed under the same type are evaluated as a candidate for decision making module. On the other hand, the ‘Deduced what’ in terms of the service infers the primary and secondary type of each service listed in the smart space.
The deduced what of the user is compared with the deduced what of the service and if the values of both variables are same the service is selected. The service also selects services that have the similar type. The output of this process is a priority list of the service context on the basis of the requested type matched with the primary type of the service or the secondary type of the service.
6.2.3. Deduced Where (User) vs. Deduced Where (Service) The Deduced When in terms of the user specifies the location of the user while, the Deduced When of the service identifies the location of the service. This comparison process lists the services starting from the nearest to the farthest service from the user in the smart space.
6.2.4. Deduced When (User) vs. Deduced When (Service) The Deduced When of the user is the time when the user initiated the request while, the Deduced When of the service is the time when the service will be available for use. This comparison process makes a list of the services starting from the service that will be available the earliest to the service that will be delivered at the latest.
6.2.5. Deduced Health (User) The user health imposes restrictions on the selection of the service. For example, a user having dust allergy would not like a service in the dusty area or a user with fever
54
will not require a service located in cold server rooms. These restrictions are evaluated and a priority list is made.
6.2.6. Final Selection The final selection process selects the best service for the user that is labeled as the most appropriate following a weighted average scheme of What, Where, When and Health for any scenario. The outcome of each comparison described in Section 6.2.2 – Section 6.2.5 is a priority list of the service contexts on the basis of type, location, time and health of the user. The priority list gives weights to the services. The weights are used to provide a bias for one type of context over the other. The normalized weighted averages are calculated for each service and the selected service is the one with the highest normalized weighted average.
Equation 6.1 shows the weighted average for a service. Weighted averages have been used in decision making to provide a simple mathematical basis for the decision making process. The weights when set to 1, reduce the mechanism to a simple arithmetic mean that can be efficiently measured.
The graph in Figure 6.3 shows the interpreted service context and the interpreted user context. The services under each category are listed from the best to the worst in topbottom order. The weighted average of each service is then taken and the service having the highest value is selected and returned to the user. ServiceNWA = [( p × WhatValue) + (q × WhereValue) + (r × WhenValue) + (s × HealthValue)] ÷ 4 (6.1) (Where p, q, r and s are the weights in Equation 6.1.)
55
Service A Service C Service B
When
Interpreted User Context
Service C Service A Service B
Where
Service A Service B Service C
What
What
Where
When
Interpreted Service Context
Figure 6. 3: Priority Lists of Services
6.2.7. Uncertainty in Decision Process In the event that the services selected by the comparison between interpreted contexts of both the user and the services do not lead to the selection of a single best service, the short list of the most probable service (services having the same highest value) is then returned to the user. The user then selects the service from the short list. It may happen that all of the services may be returned as a result of the decision making process, the system is then considered to be unable to reach a conclusion and the outcome is termed a failure.
6.3.
Flow Model of Decision Making Module
Figure 6.4 illustrates the flow model of the decision making process in CAPP. This model is developed to assist the programming of the decision making module. The system starts with the interpretation of the gathered contexts and then calculates the weighted averages of each interpreted context. The system then discovers if the
56
selected appropriate service is a single service or a short list of the probable services. Both types of the result are returned to the user.
Figure 6. 4: Decision Making Module
6.4.
Conclusion
This chapter elaborates the Decision Making Module in CAPP that is tasked with selecting the best service among a pool of similar services for the user. The
57
interpreted context received from the Context Interpreter Module in terms of ‘Who’, ‘What’ and ‘Where’ of both the user and the services are compared. Each comparison generates a priority list of the services which is then used to calculate the normalized weighted averages of each service. The service with highest weighted average is the best service for the user. If more than one services share the same highest value, they are returned to the user as the most probable services. In an event of all the services having the same weighted average, the system is unable to reach a conclusion and the outcome is considered a failure.
58
Chapter 7 EVALUATION AND ANALYSIS
7.1.
Introduction
CAPP is a context-aware system that gathers the users’ as well as the services’ context, interprets the gathered contexts and then decides which service is for the user. If CAPP is unable to reach a decision it returns a short list of all probable services and then asks the user to select a service from the short list. This inability to reach a single best service may be termed as a disappointment but ensures availability by providing a list of similar or most-probable services to the user. CAPP has been simulated as a Java based service the algorithms described in Chapters 4 – Chapter 6 of this thesis has been implemented. This chapter sets an evaluation criterion, develops test scenarios and analyses the results of test run on the simulation.
7.2.
Evaluation Criterion
To evaluate CAPP the Simulation approach has been selected to validate the results of test case scenarios. The effectiveness of the system is termed successful if it is able to return a single service or a short list of probable services to the user. In an event the system is unable to reach a conclusion either by returning a single service or a short list of probable services, the test run is considered as a failure. For the case when the user requests a service that is not listed in the smart space, informing the user that the service is not listed is also termed as a success. The evaluation criterion has been set as; the successes should be at least 75% of the total number of cases. This means that the system should be able to reach a successful conclusion atleast three forth of a time. 59
7.3.
Assumptions
This section lists the assumptions made for the evaluation of the system that serve the purpose of controlling the scenarios as well as the outcome of the system. It is assumed that the system is deployed in a smart space and the user is able to communicate with the system using his mobile devices as well as traditional keyboardmonitor based systems. The service requested by the user is available and present in the smart space. Each service type has at most and at least three services and each user has at most and at least three devices (mobile or traditional). The contextual data is always available to the system and no ambiguous data is provided by the sensor services. Finally, the system reaches a conclusion in finite time.
7.4.
Simulation of CAPP
The simulation of CAPP has been developed as a Java based service. Java provides platform independence and has been widely used in distributed applications. Java based services can easily be discovered and invoked through Jini or CORBA services. The network environment has not been imitated in the implementation and focus is only on context-awareness in CAPP. The simulation conforms to the object oriented approach of application development.
7.4.1. Sequence Diagram Figure 7.1 illustrates the Sequence diagram of the system. A client sends his request and ID to the Session Manager which forwards it to the Dispatcher class. The Context Congregator looks up the service type and if the service type is listed gathers the vital context for that service. The user is informed if the service is not listed. The gathered vital context is then interpreted by the Context Interpreter and the Decision Maker,
60
selects the best service or the short list of the probable services and returns to the user. If the decision maker class is unable to reach a successful conclusion, it returns the list of all services.
SessionManager
Dispatcher
ContextCongregator
ContextInterpreter
DecisionMakingModule
Client userID, Request invokeDispatcher Write Log
invokeCongregator
Service not listed
Check if service is listed gatherContext
Gathering contextual data
invokeInterpreter
Interpret users’ and services’ contexts invokeDecisionModule decisionMaker
Appropriate service / list of probable services
Decision
Figure 7. 1: Sequence Diagram
7.4.2. Class Diagram The main classes in the system include a Session Manager Class that communicates with the system as well as the user, a Dispatcher Class that serves as the interface to the system, a Context Congregator Class that gathers the data, Context Interpreter Class that interprets the data and a Decision Maker Class that is responsible for the decision making process. The context interpreter class identifies the ‘Who’, ‘What’, ‘Where’, ‘When’ and ‘Health’ contexts. The decision maker class creates a suitability level of the services as ‘High’, ‘Medium’ and ‘Low’ based on the interpreted context
61
types mentioned under the ContextInterpreter Class. These suitability levels are assigned the floating point values as ‘0.9’ for ‘High’, ‘0.5’ for ‘Medium’ and ‘0.1’ for ‘Low’. The weighted averages of the values assigned to each service under the ‘What’, ‘Where’ and ‘When’ categories are calculated. The service with the highest weighted average is returned to the user. Figure 7.2 shows the Class Diagram of the CAPP.
Figure 7. 2: Class Diagram
7.5.
Simulation of Test Scenarios
Three scenarios have been identified, outputs of which after the test runs in the simulation are presented in Sections 7.5.1 – 7.5.2. These scenarios are taken from the Computer Science (CS) Department of Military College of Signals (MCS). The simulation platform is Intel 2.4 GHz Processor with 512 MB RAM, Microsoft
62
Windows XP Professional (Service Pack 2). The compilation tools used are Java Standard Development Kit (SDK) version 1.5 and JCreator LE version 3.5.
7.5.1. Ayesha Requests a Print Service In the first scenario, Ayesha a student of BE is sitting in BELAB and requests a Print service. There are three print services in the department, one in MSLAB and two in BELAB. One of the services in BELAB is a Fax service that provides prints as a secondary capability. Ayesha’s health condition is Normal and has No health constraints. The output is shown in Figure 7.3 and Table 7.1 shows the gathered vital context of Ayesha and the three print services. The rule to calculate the weighted averages is shown in Equations 7.1 – 7.3. For this scenario assume that the weights of the three types of contexts is same i.e., 1. W A = [(( p × WhatValue A ) + (q × WhereValue A ) + (r × WhenValue A )) ÷ 3] (7.1) WB = [(( p × WhatValue B ) + (q × WhereValue B ) + (r × WhenValue B )) ÷ 3] (7.2) WC = [(( p × WhatValueC ) + (q × WhereValue C ) + (r × WhenValueC )) ÷ 3] (7.3) Where p = 1, q = 1, r = 1 and A, B and C are the services. The notation WA is the weighted average of first service, WB is the weighted average of the second service and WC is the weighted average of the third service. Table 7. 1: Vital Context of First Scenario
User Context Attribute Ayesha Role Devices Type Status Activity of user Illumination
Student 3 PDA, smart phone, PC Active, Idle, Idle Busy Bright
Service Contexts Service A Service B
Service C
Queue length Space avail Status
65 64 Busy
60 67 Busy
50 44 Busy
Bandwidth
100 Mbps
100 Mbps
100 Mbps
Availability time Illumination
25 minutes
10 minutes
18 minutes
Bright
Bright
Bright
Attribute
63
Table 7.1 (Contd.)
Dust level Temperature Humidity Noise Sistolic Di Sistolic Pulse User temp
Normal 16 C Normal Normal 80 110 71 38.2 C
Sugar level ID
Normal AYESHA_ BE_08_37 374050521200-6 Ayesha Ahmad NULL
SSN Name Alias Orientation Mobility Direction Speed Location Date Time
Sitting False NULL 0 BELAB 18 June, 2006 1130 hrs
Dust level Temperature Humidity Noise Air quality Owner Primary type Secondary type ID Name Alias IP Namespace Port Location Mobility Direction Speed Date Time
Normal 16 C Normal High Fit Admin Fax Print
Normal 16 C Normal High Fit Admin Print NULL
Normal 16 C Normal High Fit Admin Print NULL
PRFAXBE PRINTFA X BEPRINT ANDFAX 192.168.13 .33 //belab023/ /prfaxbe 8080 BELAB False NULL 0 18 June, 2006 1130 hrs
PRINTBE02 PRINTBE
PRINTMS PRINTCS
NULL
NULL
192.168.13.1 81 //belab075//p rintbe02 8080 BELAB False NULL 0 18 June, 2006 1130 hrs
192.168.13 .201 //mslab017/ /printms 8080 MSLAB False NULL 0 18 June, 2006 1130 hrs
Figure 7.3 shows the output after the test run. The selected service is PRINTBE, which is Service B in Table 7.1. This test run returns a single service and is successful as per the criterion. Table 7.2 shows the values of ‘When’, ‘Where’ and ‘What’ contexts and the weighted averages of the three print services in the first scenario. Figure 7.4 shows the result in the form of a bar graph. It is clear in Table 7.2 as well as Figure 7.4 that Service B has the highest weighted average and is selected for Ayesha. Table 7. 2 Results of First Scenario
Service A Service B Service C
What Value 0.1 0.9 0.9
Where Value 0.9 0.9 0.1
64
When Value 0.1 0.9 0.5
Weighted Average 0.63 0.9 0.5
Figure 7. 3: Output of First Scenario
Values
First Scenario: Ayesha Requests a Print Service 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
What Value Where Value When Value Weighted Average
Service A
Service B
Service C
Services
Figure 7. 4: Bar Chart Showing Results of First Scenario
65
7.5.2. Kashif Requests a Scan Service In the second scenario, Kashif a student of BE is sitting in MSLAB and requests a Scan service. There are three print services in the department, two are in MSLAB and one is in BELAB. Kashif’s health condition is Not Normal and has Fever as his health constraint. Table 7.3 shows the gathered vital context of Kashif and the three scan services. The rule to calculate the weighted averages is shown in Equations 7.4 – 7.6. For this scenario assume that the weight of the health context is higher than the rest of the contexts. WA = [(( p ×WhatValueA ) + (q ×WhereValueA ) + (r ×WhenValueA ) + (s × HealthValueA )) ÷ 4] (7.4)
WB = [(( p ×WhatValueB ) + (q ×Where ValueB ) + (r ×WhenValue eB )) ÷ 4] (7.5) B ) + (s × HealthValu WC = [(( p ×WhatValueC ) + (q ×WhereValueC ) + (r ×WhenValue eB )) ÷ 4] (7.6) C ) + (s × HealthValu Where p = 0.5, q = 0.5, r = 0.5, s = 1.5 and A, B and C are the services. The notation WA is the weighted average of first service, WB is the weighted average of the second service and WC is the weighted average of the third service. Table 7. 3: Vital Context of Second Scenario
User Context Attribute Kashif
Attribute
Service Contexts Service A Service B
Service C
Student 3 PC, PDA, Laptop Active, Active, Active
Queue length Space avail Status
0 0 Idle
0 0 Idle
0 0 Idle
Power supply
A.C.
A.C.
A.C.
Activity of user
Busy
Availability time
0 minutes
0 minutes
0 minutes
Illumination Dust level Temperature Humidity
Bright Normal 25 C Normal
Illumination Dust level Temperature Humidity
Bright Normal 25 C Normal
Bright Normal 16 C Normal
Normal Normal 16 C Normal
Role Devices Type Status
66
Table 7.3 (Contd.)
Noise Sistolic Di Sistolic Pulse User temp
Normal 82 120 71 102 F
Noise Air quality Owner Primary type Secondary type
Normal Fit Admin Scan NULL
Normal Fit Admin Scan NULL
Normal Fit Admin Scan NULL
Sugar level ID
Normal KASH_BE _05_199
ID Name
SCANBE BESCAN
SCANMS MSSCAN
SCANMS2 MSSCAN2
SSN
37405126524-9
Alias
NULL
NULL
NULL
Name
Kashif Farooq Standing
IP
MSLAB 28 July, 2006 1215 hrs
Location Date
192.168.13. 26 //belab024/ /scanbe BELAB 28 July, 2006 1215hrs
192.168.13.1 25 //mslab096//s canms MSLAB 28 July, 2006
192.168.13. 129 //mslab065/ /scanms2 MSLAB 28 July, 2006 1215 hrs
Orientation Location Date Time
Namespace
Time
1215hrs
Figure 7.5 shows the output after the test run. The selected service is BESCAN, which is Service A in Table 7.3. This test run returns a single service and is successful as per the criterion. Table 7.4 shows the values of ‘When’, ‘Where’, ‘What’ and ‘Health’ contexts and the weighted averages of the three scan services in the second scenario. Figure 7.6 shows the result in the form of a bar graph. It is clear in Table 7.4 as well as Figure 7.6 that Service A has the highest weighted average and is selected for Kashif. Table 7. 4: Results of Second Scenario
What Value
Where Value
When Value
Health Value
Weighted Average
Service A
0.9
0.1
0.9
0.9
0.575
Service B
0.9
0.9
0.9
0.1
0.375
Service C
0.9
0.9
0.9
0.1
0.375
67
Figure 7. 5: Output of Second Scenario
Values
Second Scenario: Kashif Requests a Scan Service 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
What Values Where Values When Values Health values Weighted Average
Service A
Service B
Service C
Service s
Figure 7. 6: Bar Chart Showing Results of Second Scenario
68
7.5.3. Waqas Requests a Projector Service In the third scenario, Waqas a faculty member of CS Department is sitting in faculty offices and requests for a Multimedia Projector service. There are three projector services in the department, one in LECTUREHALL01, one in LECTUREHALL02 and one in MSLAB. Waqas’s health condition is Normal and has No health constraints. Table 7.5 shows the gathered vital context of Waqas and the three multimedia projector services. The rule to calculate the weighted averages is shown in the Equations 7.7 -7.9. For this scenario assume that the weights of the three types of contexts is same i.e., 1. W A = [(( p × WhatValue A ) + (q × WhereValue A ) + (r × WhenValue A )) ÷ 3] (7.7) WB = [(( p × WhatValue B ) + (q × WhereValue B ) + (r × WhenValue B )) ÷ 3] (7.8) WC = [(( p × WhatValueC ) + (q × WhereValue C ) + (r × WhenValueC )) ÷ 3] (7.9) Where p = 1, q = 1, r = 1 and A, B and C are the services. The notation WA is the weighted average of first service, WB is the weighted average of the second service and WC is the weighted average of the third service. Table 7. 5: Vital Context of Third Scenario
User Context Attribute
Waqas
Service Contexts Attribute
Service A
Service B
Service C
Role Devices
Faculty 3
Queue length Space avail
1 1
0 1
0 1
Type
PC, phone, laptop
Status
Busy
Idle
Idle
Status
Idle, Active, Active
Availability time
50 minutes
0 minutes
0 minutes
Activity of user
Busy
Primary type
Multimedia Projector
Multimedia Projector
Multimedia Projector
ID
WAQ_FA C_CS_23
Secondary type
NULL
NULL
NULL
69
Table 7.5 (Contd.)
SSN
37405053320-8
ID
ML1
ML2
MMSLAB
Name
Waqas Arshad
Name
MULTIME DIALECH ALL1
MULTIMED IALECHAL L2
MULTIMEDI AMSLAB
Alias
Viky
Alias
NULL
NULL
NULL
Orientation
Sitting
IP
NULL
NULL
NULL
Location
Faculty office
Location
LECHALL 01
LECHALL02
MSLAB
Date
July 28, 2006 1030 hrs
Date
July 28, 2006 1030 hrs
July 28, 2006
July 28, 2006
1030 hrs
1030 hrs
Time
Time
Figure 7.7 shows the output after the test run. The selected services are MULTIMEDIALECHALL2 and MULTIMEDIAMSLAB, which are Service B and
Service C in Table 7.5. This test run returns a short list of two probable services and is successful as per the criterion. Table 7.6 shows the values of ‘When’, ‘Where’ and ‘What’ contexts and the weighted averages of the three projector services in the third scenario. Figure 7.8 shows the result in the form of a bar graph. It is clear in Table 7.6 as well as Figure 7.8 that Service B and Service C have the same highest weighted average. Both the services are returned to Kashif as a short list for manual selection.
Table 7. 6: Results of Third Scenario
What Value
Where Value
When Value
Weighted Average
Service A
0.9
0.1
0.1
0.367
Service B
0.9
0.1
0.9
0.633
Service C
0.9
0.1
0.9
0.633
70
Figure 7. 7: Output of Third Scenario
Values
Third Scenario: Waqas Requests a Projector Service What Values
0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
Where Values When Values Weighted Average
Service A
Service B
Service C
Services
Figure 7. 8: Bar Chart Showing Results of Third Scenario
71
7.5.4. Maryam Requests a Telephone Service In the second scenario, Maryam a faculty member is standing in the Hallway of CS department and requests a Telephone service as she wants to make a phone call. Maryam being new to the CS department requires the system to select a telephone service for her. There are three telephone services in the department, one is in MSLAB, one is in BELAB and one is in the faculty offices. Maryam’s health condition is Normal and has No health constraint. Table 7.7 shows the gathered vital context of Maryam and the three telephone services. The rule to calculate the weighted averages is shown in the Equations 7.10 – 7.12. For this scenario assume that the weight of all the contexts is same i.e., 1. W A = [(( p × WhatValue A ) + (q × WhereValue A ) + (r × WhenValue A )) ÷ 3] (7.10) WB = [(( p × WhatValue B ) + (q × WhereValue B ) + (r × WhenValue B )) ÷ 3] (7.11) WC = [(( p × WhatValueC ) + (q × WhereValue C ) + (r × WhenValueC )) ÷ 3] (7.12) Where p = 1, q = 1, r = 1 and A, B and C are the services. The notation WA is the weighted average of first service, WB is the weighted average of the second service and WC is the weighted average of the third service. Table 7. 7: Vital Context of Fourth Scenario
User Context Attribute
Maryam
Service Contexts Attribute
Service A
Service B
Service C
Role
Faculty
Status
Idle
Idle
Idle
Devices
3
Power supply
A.C.
A.C.
A.C.
Type
PDA, PDA, Availability Laptop time
0 minutes
0 minutes
0 minutes
Status
Idle, Idle, Idle
Owner
Admin
Admin
Admin
Activity of user
Idle
Primary type
Telephone
Telephone
Telephone
72
Table 7.7 (Contd.)
MARY_F AC_EE_05 7 37405056204-7 Maryam Ayaz
Secondary type
NULL
NULL
NULL
ID
TELMS
TELBE
TELFAC
Name
MSLABTE LEPHONE
BELABTEL EPHONE
Orientation
Standing
Location
MSLAB
BELAB
Date
29 July, 2006 1227 hrs
Date
29 July, 2006 1227 hrs
29 July, 2006
FACULTY TELEPHO NE FACULTY OFFICE 29 July, 2006 1227 hrs
ID
SSN Name
Time
Time
1227 hrs
Figure 7.9 shows the output after the test run. All the three telephone services are selected. This test run is a failure.
Figure 7. 9: Output of Fourth Scenario
73
Table 7.8 shows the values of ‘When’, ‘Where’ and ‘What’ contexts and the weighted averages of the three telephone services in the fourth scenario. Figure 7.10 shows the result in the form of a bar graph. It is clear in Table 7.8 as well as Figure 7.10 that all the three services have the same weighted average and are returned to Maryam for Manual selection. The system is unable to either select a single service or short list the services and hence the test run is marked as failure. Table 7. 8: Results of Fourth Scenario
Service A Service B Service C
What Value 0.9 0.9 0.9
Where Value 0.1 0.1 0.1
When Value 0.9 0.9 0.9
Weighted Average 0.633 0.633 0.633
Fourth Scenario: Maryam Requests a Telephone Service 1
What Values Where Values
Values
0.8
When Values
0.6
Weighted Averge
0.4 0.2 0 Service A
Service B
Service C
Services
Figure 7. 10: Bar Chart Showing Results of Fourth Scenario
7.6.
Analysis of the Scenarios
Section 7.6.1 – Section 7.6.4 analyze the results obtained after the test runs discuss the success and failures of the example scenarios. The analysis is carried out with respect to the successful and unsuccessful conclusions generated by the system.
74
7.6.1. Analysis of First Scenario (Ayesha Requests A Print Service) In this scenario, Ayesha a student of BE has requested a Print service. She is located in BELAB and has three devices that include a PDA, a Smart phone and a Desktop PC. Ayesha is busy and her health is normal. She has no health constraints. On the other hand there are three print services that are PRFAXBE, PRINTBE02 and PRINTMS. PRFAXBE is a fax service and has print as its secondary capability. Since, this service can provide prints so it must be considered for selection. The PRFAXBE and PRINTBE02 are both located in BELAB while PRINTMS is in MSLAB. The availability times are 25 minutes for PRFAXBE, 10 minutes for PRINTBE02 and 18 minutes for PRINTMS. In terms of location PRFAXBE and PRINTBE02 are in the same room as Ayesha’s location while PRINTMS is not in the same room. The primary capabilities select PRINTBE02 and PRINTMS as the first choice while PRFAXBE is selected as a second choice. The availability times select PRINTBE02 as the first choice.
The weights as given in the section 7.5.1 are set to 1. This means that all the contexts (‘what’, ‘where’ and ‘when’) have equal effect. The weighted average identifies PRINTBE02 as the most appropriate service. In this case the system was able to reach a conclusion and provided the service that has its primary functionality as the service requested by the user, is in the same room as of the user, and will be available the earliest among the rest of the services to the user. The outcome is thus a success.
7.6.2. Analysis of Second Scenario (Kashif Requests a Scan Service) In this scenario, Kashif a student of BE has requested a Scan service. He is located in MSLAB and has three devices that include a PDA, Laptop and a Desktop PC. Kashif
75
is busy and his health is not normal. His health constraint identifies that he has fever. On the other hand there are three scan services that are SCANBE, SCANMS and SCANMS2. SCANMS and SCANMS2 are both located in MSLAB while SCANBE is in BELAB. All the three services are idle and are readily available. In terms of location SCANMS and SCANMS2 are in the same room as K Kashif’s location while SCANBE is not in the same room. All these services have the same primary capability of Scan and are available for use. The surroundings of SCANMS and SCANMS2 have lower temperature than the surroundings of SCANBE service. Since the user’s health condition is not normal, the health context must be considered. The user has fever hence strive to provide the service that is maintained in a warmer environment.
The weights as given in the section 7.5.2 are set to 0.5 for the ‘what’, ‘where’ and ‘when’ contexts while 1.5 for the ‘health’ context. This increases the effect of the health context and decreases the effect of the rest. The output thus considers the users health requirements. The weighted average select SCANBE as the most appropriate service. In this case the system was able to reach a conclusion and provided the service that has its primary functionality as the service requested by the user but, is not in the same room as of the user. The health constraint selects the service that is appropriate as per users’ health constraint and gives it a higher weight. Since the system is able to reach a conclusion, the outcome is thus a success.
7.6.3. Analysis of Third Scenario (Waqas Requests a Projector Service) In this scenario, Waqas a faculty member of CS Department has requested a Multimedia Projector service. He is located in his faculty office and has three devices
76
that include a Laptop, a Smart phone and a Desktop PC. Waqas is busy and his health is normal. He has no health constraints. On the other hand there are three multimedia projector services that are ML1, ML2 and MMSLAB. ML1 is located in lecture hall 01 and is busy, ML2 is in lecture hall 02 and is idle while MMSLAB is in MSLAB and is idle as well. In terms of location none of the services are in the same room as Waqas’s while all the services have the same primary capability. The availability times select MMSLAB and ML2 as the first choice while ML1 is the second choice.
The weights as given in the section 7.4.3 are set to 1. This means that all the contexts (‘what’, ‘where’ and ‘when’) have equal effect. The weighted average identifies ML2 and MMSLAB as the most appropriate services. In this case the system was able to reach a conclusion and provided two services out of three services as a short-list to the user. The outcome is thus a success.
7.6.4. Analysis of Fourth Scenario (Maryam Requests a Telephone Service) In this scenario, Maryam a faculty member has requested a Telephone service. She is located in the Hallway of CS department and has three devices that include two PDA’s and a Laptop. Maryam is not busy and her health is normal. She has no health constraints. On the other hand there are three telephone services that are TELMS, TELBE and TELFAC. The TELMS is located in MSLAB, TELBE in BELAB and TELFAC is in FAACULTY OFFICES. All the three services are readily available. In terms of location none of the services are located in vicinity of Maryam. The primary functionality selects all the three services as the first choice while the availability times also select the three services as the first choice. This is a special scenario where the decision making process does not reach a solid conclusion as a single appropriate service or a short list of probable services.
77
The weights as given in the Section 7.5.4 are set to 1. This means that all the contexts (‘what’, ‘where’ and ‘when’) have equal effect. It can be seen in Section 7.5.4 the system is unable to select a single service or short list the available pool of services and returns the complete list as the probable services. The outcome is thus a failure.
7.7.
Performance of CAPP
Every system in the world has successes and failures. The need is to identify the failures and reason about them. This results in the improvement of the system and provides more successes than failures. The performance of CAPP is measured in terms of the success rate i.e., number of successes among all cases. In the scenarios there were three successes and one failure. This highlights the need to find the failures among all possible combinations of the values. Only cases where there are no health constraints and the weights are set to 1 are considered. The total number of values where there are three services and each service can have the same three values is given in Equation 7.13 where ‘A’ is the all possible combination when ‘V’ is the value levels for ‘N’ number of services. Table 7.9 highlight all the failures among all possible combinations when three value levels are used for three services.
A =V N A = 33
(7.13)
A = 27
Table 7. 9: Weighted Averages of Failures and Successes
Service A
Service B
Service C
Outcome
1
0.9
0.9
0.9
ABC
2
0.9
0.9
0.5
AB
3
0.9
0.9
0.1
AB
4
0.9
0.5
0.9
AC
78
Table 7.9 (Contd.)
5
0.9
0.5
0.5
A
6
0.9
0.5
0.1
A
7
0.9
0.1
0.9
AC
8
0.9
0.1
0.5
A
9
0.9
0.1
0.1
A
10
0.5
0.9
0.9
BC
11
0.5
0.9
0.5
B
12
0.5
0.9
0.1
B
13
0.5
0.5
0.9
C
14
0.5
0.5
0.5
ABC
15
0.5
0.5
0.1
AB
16
0.5
0.1
0.9
C
17
0.5
0.1
0.5
AC
18
0.5
0.1
0.1
A
19
0.1
0.9
0.9
BC
20
0.1
0.9
0.5
B
21
0.1
0.9
0.1
B
22
0.1
0.5
0.9
C
23
0.1
0.5
0.5
BC
24
0.1
0.5
0.1
B
25
0.1
0.1
0.9
C
26
0.1
0.1
0.5
C
27
0.1
0.1
0.1
ABC
As highlighted in Table 7.9, there are 3 failures out of a total 27 possible combinations. 15 cases resulted in selection of single service while 9 cases provided a short list of the probable services. The success rate is given in Equation 7.14, where ‘F’ is the failure rate when ‘f’ is the number of failures among ‘A’ possible combinations and ‘S’ is the success rate.
F = f
A
F = 3 27 F ≅ 0 . 111 S ≅ 0 . 889 ≈ 89 %
79
(7.14)
Equation 7.14 shows that 89% of the time the system will be able to reach a conclusion. This value is a high success rate for a context-aware system and is also higher than the criterion set by us i.e., a success rate of minimum 75%.
7.8.
User Bias
The failure rate calculated in Section 7.6 is the maximum failure rate. This rate was calculated when the weights of the ‘what’, ‘where’ and ‘when’ contexts were set to 1. To further decrease this rate the weights must be altered. Altering the weights will have more effect of one type of context on the weighted average than the rest of the contexts. This increases the probability of successes by ensuring that the system reaches a conclusion.
These weights cannot be set randomly but must be set according to some external bias or the user bias. Some users have preference for services that are closely located while others have preference for services that are available at the earliest. These preferences are the user bias. User bias is a dynamic term and changes with context. For example, a person who has a bias for rice as lunch may not like top have rice for dinner since he is having the same dish for the past three days. Hence, the user bias changes with context. But, this prediction of the users’ bias requires close monitoring of users’ history. Presently, history is not being maintained in CAPP but is recommended for future enhancements.
7.9.
Number of Services
It has been assumed that there will be at most and at least three services in the system. Here, the effect of the number of similar services in the system is emphasized. Table 7.10 shows the effect when number of services increase. It is assumed that there will
80
be three possible levels ‘High’, ‘Medium’ and ‘Low’ that correspond to the values ‘0.9’, ‘0.5’ and ‘0.1’, respectively. The all possible value levels are denoted by ‘V’ and are equal to three levels for all cases. The failure occurs when all services have the same level of all high, all medium or all low. Surprisingly, the number of cases when this situation occurs is three for all number of services. Table 7. 10: Effect of Number of Services on the Outcome
Number of services (m)
All possible combinations
3
27
3
0.111
88.889%
4
81
3
0.037
96.296%
5
243
3
0.012
98.765%
6
729
3
0.004
99.588%
7
2187
3
0.001
99.862%
3
3
N
c =V
m
Number of failures (f)
N
3
Failure rate
F= fc
Success rate
S = (c − f ) × 100 c
3N
It can be seen in Table 7.10 that the success rate increases with an increase in the number of the services, while the value levels and the failures remain constant. For ‘N’ services the success rate ‘S’ is calculated as shown in Equation 7.15. Figure 7.12 shows the increase in success rate as a line graph.
(
)
N S = 3 − 3 N × 100 3 S = 100 − 300 N 3 S = A− B N 3 S ∝ 1 N 3
(
( )
81
)
(7.15)
Success Rate vs. Number of Services 102 Success Rate
Success Rate
100 98 96 94 92 90 88 0
2
4
6
8
Number of Services
Figure 7. 11: Success Rate vs. Number of Services
7.10. Conclusion Evaluation of context-aware systems is a difficult task. We have selected a prudent technique that evaluates the systems performance by identifying successes and failures in the system. A setting is considered successful if it reaches a conclusion and returns one service to the user or a short list of probable services among a pool of all services to the user, as compared between the users’ context and the services’ contexts while, a setting is marked as a failure if it is unable to reach a conclusion and returns all services.
The success rate, when the weights are set to 1, is 89% which is higher than the target of 75% success rate. This rate can be increased more by providing mechanisms that store and monitor history of each user and infer the user preference or user bias as well as by increasing the number of similar services in the system.
82
Chapter 8 EPITOME
8.1.
Introduction
This chapter gives an overview of CAPP and its capabilities and discusses the achievements of this research work. The limitations of CAPP have been highlighted with recommendations for improvement. The chapter concludes with an insight into the future of CAPP.
8.2.
Overview of CAPP
The fourth generation of computing recognizes the emerging era of pervasive computing as a result of fast development in mobile technologies and mobile devices. There is an ever increasing need for smart service delivery to the mobile and naïve user. CAPP is a service oriented approach that realizes context awareness in ubiquitous systems. The process starts with acquiring contextual data of the services and the user, interpreting contextual data to a high-level meaningful form and then choosing the service that is most appropriate for the user.
The user sends his request to the session manager that forwards the request to the context server or CAPP. This module searches for the requested service type in the service list and informs the user of unavailability of the service if it is not found in the list. The necessary contextual data for the intended interaction is then gathered through the sensor services. The data is in large quantity and requires considerable delay in acquisition. The gathered data is represented in OWL based ontology. This
83
representation provides a prudent organization that separates the services from the users.
The congregated data is then interpreted into a set of ‘What’, ‘Who’, ‘Where’ and ‘When’ contexts of both the user and the service. This interpretation allows us to answer the query; who wants what service to be delivered where and when. The interpretation process is designed as a rule-based module that ensures efficient processing at the cost for adaptability.
The interpreted context of the services are then given numerical values corresponding to the selection priorities of ‘High’, ‘Medium’ and ‘Low’. These numerical values are then used to calculate the weighted average which is the aggregate selection level of each service. The service with the highest weighted average is then selected as the best service for the user. In an event, when two or more services share the same highest weighted average, the services are returned as a short list of the probable services. Selection of a single service or a short list of probable services is both termed as successes in the system. Failure occurs when the system is unable to select a single service or a short list of probable services and returns all possible services to the user.
8.3.
Accomplishments
The system design has been simulated as a Java based service and developed test scenarios for the evaluation of CAPP. These test scenarios have been taken by observing the users in the CS department of MCS. The raw, low-level contextual data of each scenario has been identified and interpreted to a meaningful, high-level
84
context. The simulation also serves as a framework for development of CAPP as a commercial product.
The effectiveness of CAPP is judged successful if the success rate is at least 75% of all interactions. Analysing the results of test scenarios conclude that the system has high performance that guarantees a success rate of 89%. This is a high achievement for a context-aware system. The failures in the system have been controlled in a way that provides maximum availability to the user. Users manually select the services from the list of all possible services provided by the system in case of failure to select a single service or a short list of probable services.
8.4.
Limitations of CAPP
The prime constraint in the system is the availability of the context sensing devices or the sensor services. All of the sensor devices cannot be available everywhere and at all times. This requires that some of the necessary context be predicted on the basis of some history. In CAPP, a history is not included as it is considered storage overhead. We assume that the sensor devices are available and provide true and real time data to the system.
The data generated by the devices is very large (expected to be in Giga Bytes), resulting in a large network traffic thus reducing the overall bandwidth of the system. Users face large delays due to the acquisition process and are dissatisfied with the performance of the system. There is a need to optimize the number of context data packets by increasing the size of each packet. Alternatively, the context sensing services may only be accessed when required while a maintained history provides
85
predicted contextual data to the system. This would increase the performance of the system but the results may not be accurate due to the presence of wrongly predicted or out-dated information.
8.5.
The Road Ahead
CAPP has been structured as a service oriented framework that ensures contextawareness in pervasive environments. The systems promises 89% success rate but there are still limitations and issues that need to be addressed. The first issue is the maintenance of a history of the contextual data that allows us to predict the future context of the entities. The history is also used to correct vague sensor information provided by faulty sensors. The history is storage overhead and requires efficient purging operations that discard old data and maintains only the latest data.
The contextual data of the users as well as the services is sensitive information. This data can be easily exploited if it is not secure. There is a need for the presence of access control module that disallows unauthorized access and a privacy control module that ensures confidentiality of the data. The confidentiality can be provided by encrypting and then storing the data. The security measures also include gathering data only from the trusted sensor services present in the environment.
8.6.
Conclusion
In the computing era of pervasive computing, context-awareness being a prime issue demands a generic context-aware system that gathers and interprets contextual data and facilitates the process of smart service delivery to a mobile user. The process starts with context acquisition, followed by the representation using a rich and
86
standardized ontology language and its subsequent interpretation, decision making on the basis of users’ and the services’ context and ends in the delivery of the appropriate service to the user.
CAPP is a service oriented framework that realizes context-awareness in pervasive computing environments. CAPP is designed as a robust, scalable and modular architecture that masks heterogeneity of the underlying platform and conforms to the object-oriented features of encapsulation and information hiding. The model facilitates delivery of the finest service to the users by interpreting the contextual data. The context interpretation is carried out on the axes of ‘Who’, ‘What’, ‘Where’ and ‘When’ contexts of the user and the services involved.
Undoubtedly, context-awareness is the future of computing and will change the way services are accessed. The preceding chapters provide an insight into the development of CAPP as a context-aware system for intelligent service delivery. By the Grace of Almighty Allah, the objectives that were set forth in the start of this thesis have been successfully accomplished.
87
BIBLIOGRAPHY [1].
T.P. Moran and P. Dourish, “Context-Aware Computing,” Special Issue of Human-Computer Interaction Journal, vol. 16, 2001.
[2].
M. Weiser, “The Computer for the 21st Century,” Scientific American Journal, 1991.
[3].
J. Crowfort, “Scalable Ubiquitous Computing Systems or just Ubiquitous Systems,” http://www.nesc.ac.uk/esi/events/Grand_Challenges/proposals/US, 2003.
[4].
B. Schilit and Theiner. Disseminating Active Map Infrastructure to Mobile Host”, Journal of IEEE Network, 1994.
[5].
T. Winograd, “Architectures for Context,” Human-Computer Interaction Journal, pp 401-419, 2001.
[6].
A. Schmidt, M. Beigl, and H. Gellersen, “There is more to Context than Location,” http://www.comp.lancs.ac.uk/~albrecht/pubs/pdf/schmidt_cug_ else vier_12 -99-context-is-more-than-location.pdf.
[7].
A.K. Dey, “Understanding and Using Context”, Personal and Ubiquitous Computing Journal, Vol. 5, Issue 1, pp. 4 – 7, 2001.
[8].
W.N. Schilit, “System Architecture for Context-Aware Mobile Computing,” PhD Dissertation, Columbia University, 1999.
[9].
D, Petrelli, E. Not, M. Zancanaro, C. Shapparava and O. Stock, “Modeling and Adapting to Context,” Personal and Ubiquitous Computing Journal, Vol. 5, Issue 1, pp. 20 – 24, 2001.
[10].
M. Riaz, S.L. Kiani, S. Lee, S. Han and Y. Lee, “Service Delivery in Context Aware Environments: Lookup and Access Control Issues,” in proceedings of RTSCA’05, 2005.
[11].
M. Baldauf, S. Dustdar, and F. Rosenberg, “A Survey on Context-Aware Systems,” International Journal of Ad Hoc and Ubiquitous Computing, 2004.
[12].
T. Strang, and C. Linnhoff-Popien, “A Context Modeling Survey,” First International Workshop on Advanced Context Modeling, Reasoning and Management, 2004.
[13].
R. Want, A. Hopper, V. Falcao and J. Gibbons, “The Active Badge Location System,” ACM Transactions on Information Systems, 10(1), pp. 91-102, 1992.
[14].
B.N. Schilit, D.M. Hilbert and J. Trevor, “Context-Aware Communication,” IEEE Wireless Communications, pp. 2-10, October 2002.
88
[15].
A.K. Dey, “The Context Toolkit – A Toolkit for Context-Aware Applications,” http://www.cs.berkley.edu/~dey/context.html, 2001.
[16].
M. Roman, C. Hess, R. Cerqueira, A. Ranganathan, R.H. Campbell and K. Nahrstedt, “Gaia: A Middleware to Enable Active Spaces,” IEEE Pervasive Computing Journal, pp. 74-83, 2002.
[17].
A. Ranganathan and R.H. Campbell, “A Middleware for Context-Aware Agents in Ubiquitous Computing Environments,” in proceedings of International Middleware Conference, 2003.
[18].
K.A.P. Ngoc, Y. Lee and S. Lee, “Context Knowledge Discovery in Ubiquitous Computing,” OTM Workshops, pp. 33-34, 2005.
[19].
H. Gellersen, A. Schmidt and M. Beigl, “Multi-Sensor Context-Awareness in Mobile Devices and Smart Artefacts,” ACM Journal of Mobile Networks, 2002.
[20].
M. Samulowitz, F. Michahelles and C. Linnhoff-Popien, “CAPEUS: An Architecture for Context-Aware Selection and Execution of Services,” in New developments in distributed applications and interoperable systems, pp. 23 39, 2001.
[21].
P. Korpipaa, J. Mantyjarvi, J. Kela, H. Keranen and E. Malm, “Managing Context Information in Mobile Devices,” IEEE Pervasive Computing Journal, pp.42 - 51, 2003.
[22].
T. Gu, H.K. Pung and D.Q. Zhang, “A Middleware for Building ContextAware Mobile Services,” IEEE Vehicular Technology Conference, 2004.
[23].
P. Fahy and S. Clarke, “CASS – A Middleware for Mobile Context-Aware Applications,” Workshop on Context Awareness MobiSys, 2004.
[24].
H. Chen, T. Finin and A. Joshi, “An Intelligent Broker for Context-Aware Systems,” in proceedings of UbiComp 2003, pp. 183-184, October 2003.
[25].
T. Hofer, W. Schwinger, M. Pichler, G. Leonhartsberger and J. Altmann, “Context-Awareness on Mobile Devices – The Hydrogen Approach,” in proceedings of the 36th Annual Hawaii International Conference on System Sciences, pp. 292-302, 2002.
[26].
Y.V. Natis, “Service-Oriented Architecture Scenario,” http://www.gartner. com/ resources/114300/114358/114358.pdf, 2003.
[27].
“Message-Oriented Middleware”, http://www.sei.cmu.edu/str/descriptionsmo mt.html.
[28].
W. Jansen, T. Karygiannis, “Mobile Agent Security”, NIST Special Publication, http://csrc.nist.gov/publications/nistpubs/800-19/sp800-19.pdf.
89
[29].
“Introduction to OWL”, http://www.w3schools.com/rdf/rdf_owl.asp.
[30].
“OWL Web Ontology Language Overview”, W3C Candidate Recommendation, http://www.w3.org/TR/2003/CR-owl-features-20030818/, 2003.
[31].
M. Horridge, H. Knublach, A. Rector, R. Stevens and C. Wroe, “A Practical Guide To Building OWL Ontologies Using The Protégé-OWL Plug-in and CO-ODE Tools Edition 1.0”.
[32].
Protégé 3.1.1, Computer http://protege.stanford.edu
[33].
T. Gruber, “What is an Ontology?” http://www.ksl.stanford.edu/kst/what-isan-ontology.html.
[34].
K. Goslar and A. Schill, “Modeling Contextual Information using Active Data Structures,” http://www.rn.inf.tu-dresden.de/scripts_lsrn/veroeffent_print/gosl ar2004active_data.pdf, 2004.
Software,
90
Stanford
University,
