Mobile Hanging Services: Modelling, Implementation and Methodology for Context-Aware Regulated Services
by
Evi Syukur Bachelor of Computing (Hons)
DISSERTATION Submitted in Fulfillment of the Requirements for the Degree of
Doctor of Philosophy
Caulfield School of Information Technology
Monash University
 Copyright by Evi Syukur 2007
ii
iii
Declaration
In accordance with Monash University Doctorate Regulation 17/Doctor of Philosophy and Master of Philosophy (Mphil) regulations the following declarations are made: I hereby declare that this thesis contains no material which has been accepted for the award of any other degree of diploma at any university or equivalent institution and that, to the best of my knowledge and belief, this thesis contains no material previously published or written by another person, except where due reference is made in the text of the thesis.
________________ Evi Syukur Date:
/ / 2007
iv
Acknowledgements
At this opportunity, I would like to thank and acknowledge all of you who have helped and supported me through the last three years. First of all, I am very thankful to have had Dr. Seng Wai Loke as my supervisor. Seng, thanks for guiding me through the years and providing very valuable feedback on my research proposal, literature review, presentation and thesis. If it is not because of you, I do not think I would have adequately understood my research area as this topic is relatively new and at the same time challenging. I would like to thank Dr. Peter Stanski and A/Prof Arkady Zaslavsky for being my supervisors. Thank you for inspiring and motivating me throughout the PhD years. This thesis would have never been possible without the tremendous support of my supervisors. I would like to thank the administrative and technical staff of the Caulfield School of Information Technology for their support, particularly Michelle Ketchen, Allison
v
Mitchell, Aleisha Matthews, Akamon Kunkongkapun, See Ngieng, Duke Fonias, and Rob Gray. I thank Monash Research Graduate School (MRGS) for providing me with scholarship to undertake this PhD research. These three years of hardship would have never been possible without constant support from my parents, sisters (Sonya Ciayadi, Shelvi Ciayadi and Shelli Ciayadi), brothers (Rudy Ciayadi and Frans Ciayadi) who have very helpful to me and for their great support. I would especially like to mention Aunt Kim, Aunt Poh and Aunt Anna for her kindness, guidance and support. I am also very glad to have spent my PhD years with all my friends: Mei Qun, Miao Lee, Yo Kuan, Dempsey Chang, Flora Salim, Wanita Sherchan, Mohamed Gaber, John Page, Ruwini Kodikara, Phillip Chen, Trent Mifsud, Dominic Cooney, Paul Hii, and many others. I thank all the staff that I worked with as a lecturer at Monash College and a tutor at Monash University. I thank Julie Simon, Dr. Maria Indrawan, Renee Gedge, Prof. Bala Srinivasan, Dr. Nandita Bhattacharjee, Dr. Peter Stanski, Andy Cheng, Peter Granville, Pravin Shetty, and Simon Cuce. Finally, I thank my colleagues (Marselina Wiharto and Ronny Koswara) at Yarra Trams Company for their best wishes and positive encouragement to finishing my PhD.
vi
List of Publications and Thesis Work Outcomes
This thesis has resulted in eleven peer-reviewed publications. The accepted publications are two journal papers and nine international conference/workshop papers. Journals 1. Syukur, E. and Loke, S.W., Implementing Context-Aware Regulation of ContextAware Mobile Services in Pervasive Computing Environments. Accepted for publication in the International Journal of Web and Grid Services (IJWGS), 2006, Inderscience Publisher, Vol. 2, Issue no. 3, pp. 260-305. 2. Syukur, E. and Loke, S.W., Policy based Control of Context-Aware Pervasive Services. Accepted for publication in the Journal of Ubiquitous Computing and
vii
Intelligence (JUCI), 2007, American Scientific Publishers, Vol. 1, Issue no.1, pp.110-131. International Conferences/Workshops 3. Syukur, E. and Loke, S.W., MHS Learning Services for Pervasive Campus Environments, Accepted for publication at 5th IEEE International Workshop on PervasivE Learning (PerEL 2007) in conjunction with Percom2007 Conference, New York, USA, March 2007, IEEE Computer Society, pp. 204-210. 4. Syukur, E. and Loke, S.W., Context-Aware Regulation of Context-Aware Mobile Services in Pervasive Computing Environments, Accepted for publication at 2nd International Workshop on Ubiquitous Web Systems and Intelligence (UWSI 2006) in conjunction with ICCSA Conference 2006, Glasgow, 8-11 May 2006, SpringerVerlag Lecture Notes in Computer Science (LNCS), pp. 138-147. 5. Syukur, E. and Loke, S.W., The MHS Methodology: Analysis and Design for Pervasive Context-Aware Systems, Accepted for publication at 3rd IEEE International Workshop for Software Technologies for Future Embedded and Ubiquitous Systems (SEUS 2006) in conjunction with IEEE International Symposium on Object-oriented Real-time Distributed Computing (ISORC 2006), Gyeongju, Korea, April 2006, IEEE Computer Society, pp. 6-14. 6. Syukur, E., Loke, S.W. and Stanski, P., Methods for Policy Conflict Detection and Resolution in Pervasive Computing Environments, Accepted for publication at Policy Management for Web workshop in conjunction with WWW2005 Conference, Chiba, Japan, 10-14 May 2005, pp. 13-20. 7. Syukur, E., Loke, S.W. and Stanski, P., A Policy based framework for Context Aware Ubiquitous Services, Proceedings of the Embedded Ubiquitous Computing Conference, Aizu-Wakamatsu, Japan, 26-28 August 2004, Lecture Notes in Computer Science, Springer-Verlag, Vol. 3207, pp. 346-355. viii
8. Loke, S.W., Syukur, E. and Stanski, P., Adding Context-Aware Behaviour to Almost anything: the Case of Context-Aware Device Ecologies. Accepted for publication at the MobiSys 2004 workshop on context-awareness. 9. Syukur, E., Loke, S.W. and Stanski, P., The Mobile Hanging Services Framework for Context-Aware Applications: the Case of Context Aware VNC. Accepted for publication at WIS (Wireless Information Systems) Workshop, Porto, Portugal, April 2004, pp. 81-88. 10. Syukur, E., Cooney, D., Loke, S.W. and Stanski, P., Hanging Services: An Investigation of Context-Sensitivity and Mobile Code for Localised Services, Proceedings of the IEEE International Conference on Mobile Data Management (MDM) , Berkeley, USA, 19-22 Jan 2004, IEEE Computer Society, pp. 62-73,. 11. Syukur, E., Loke, S.W. and Stanski, P., Performance Issues in an Infrastructure for Mobile Hanging Services, Proceedings of the First International Conference on Mobile Computing and Ubiquitous Networking (ICMU), NTT DoCoMo R&D Center, Yokosuka, Japan, 8-9 Jan 2004, pp. 32-37. Presentations •
Gave a presentation on “Augmenting Everyday Objects with Context-Aware Services” as part of CoolCampus summer projects, Dec 2005 – March 2006. Available Online from: http://www.infotech.monash.edu.au/promotion/coolcampus/summer/summerproj0506/index.html
•
Presented a paper “Methods for Policy Conflict Detection and Resolution in Pervasive Computing Environments“ at Policy Web International Workshop in conjunction with WWW Conference, May 2005.
•
Gave a demonstration on “Context-aware VNC service” at CoolCampus Workshop, April 2004. Available Online from: http://www.infotech.monash.edu.au/promotion/coolcampus/workshop/2ndworkshop/
ix
•
Presented a paper “Performance Issues in an Infrastructure for Mobile Hanging Services“, at ICMU International Workshop, Jan 2004.
•
Presented a paper “Hanging Services: An Investigation of Context-Sensitivity and Mobile Code for Localised Services”, at MDM International Conference, Jan 2004.
•
Gave a presentation on “Context-Aware Mobile Services in Pervasive Computing Environments” as part of the PhD confirmation seminar, Feb 2004.
x
Abstract
With computing technology maturing, a multitude of computer based services (ranging from controlling the lighting in the environment to booking a flight) can be made available for users anytime anywhere but not all such services are needed anytime anywhere. There is a sense in which myriad services are “hanging� over users, but different services are appropriate in different contexts. The idea is to give mobile users the right services depending on their current context and in an automatic, responsive and attentive to the user manner. There have been a number of context-aware pervasive systems to date. However, most of the existing systems only focus on context (e.g., how to discover and interpret context information) and service aspects (e.g., how to discover, select, deliver and execute relevant services in the right contexts). To develop context-aware pervasive systems that could proactively adapt to users’ contexts requires other system elements (e.g., an environment element, a contextual policy element, etc.) than just a contextual
xi
service element. Moreover, the existing systems only address the modelling of physical spaces (e.g., building) in the environment. They have not explored the grouping of physical spaces into a logical boundary (domain). The complexity of context-aware pervasive systems means software developers have to model such systems by taking into account several system elements such as environments, contexts, services, entities, rules of service usage, and devices. Moreover, as the system often consists of a number of entities (i.e., many users), balancing control given to one user (entity) in performing actions on the service, by considering other entities’ activities or situations is important, especially, as users tend to be on the move from one geographical location to another and are allowed access to services or to perform actions on the service at any time and any place. This dissertation investigates, analyses and addresses the complexity in developing context-aware pervasive services. It proposes concepts, an architectural design and techniques to realize such services that are tailored to users’ needs, and also provides an implementation and evaluation of a framework for such services, which we call the MHS (short for Mobile Hanging Services) framework. Our view of context-aware pervasive systems consists of a collection of a pervasive computing environment (domains - logical boundaries and spaces - physical boundaries), entities, software components (context, service and policy) and computing devices. The MHS system is designed for building, delivering and regulating context-aware services with a policy mechanism that hides details of interactions with remote services. Applicable policies are selected depending on context of users and policies determine what services one can see and access in different contexts. The MHS system governs service visibility and execution in pervasive computing environments. Our framework uses Web services and highly compact mobile code as illustrated through sample Mobile Pocket Pad, Mobile VNC and Mobile Media Player applications. In addition, to effectively guide developers to build and achieve such a vision of context-aware regulated services, the dissertation also discusses a methodology for analysing and designing a system for context-aware regulated services, to help developers think about relevant notions such as pervasive computing environments,
xii
entities, computing devices, and contextual software components. Our methodology is general and not only specific to one particular domain. It is applicable to a wide range of pervasive computing environments, and comprehensive in a way that covers aspects required for context-aware regulated services. The concept, design and practical contribution of this dissertation have been published in 11 refereed journal and conference/workshop papers.
xiii
To my family and friends, for their unconditional support throughout all these years
xiv
Table of Contents
Declaration.......................................................................................................................iv Acknowledgements...........................................................................................................v List of Publications and Thesis Work Outcomes ........................................................vii Abstract............................................................................................................................xi List of Figures................................................................................................................xix List of Tables ................................................................................................................xxii 1.
Introduction ............................................................................................................1 1.1.
The Characteristics of Pervasive Computing Environments.............................3
1.2. The Role of Context-Awareness in Pervasive Computing................................8 1.2.1. System Requirements of Context-Aware Pervasive Systems ......................10 1.2.2. Context-Aware Services in Pervasive Computing.......................................12
xv
1.2.3.
Context-Aware Policy (Regulation) in Pervasive Computing .....................14
1.3.
Research Objectives ........................................................................................18
1.4.
Scope and Contributions .................................................................................20
1.5.
Structure of the Dissertation............................................................................22
2.
Related Work.......................................................................................................24 2.1.
Pervasive Computing Environment Modelling ...............................................25
2.2. Location-Aware Systems.................................................................................27 2.2.1. Location Sensing Techniques.......................................................................28 2.2.2. Location-Aware Projects..............................................................................32 2.2.3. Discussion ....................................................................................................33 2.3. Context-Aware Systems ..................................................................................35 2.3.1. Discussion ....................................................................................................42 2.4. Policy based Context-Aware Systems .............................................................42 2.4.1. Discussion ....................................................................................................50 2.5. 3.
Summary..........................................................................................................52 Issues and Conceptual Design for MHS.............................................................54
3.1.
The MHS View of Pervasive Computing Environments ................................57
3.2.
Overview of the MHS Framework ..................................................................63
3.3. The Design of MHS Context-Aware Services ................................................65 3.3.1. Design Criteria for Context-Aware Services ...............................................72 3.3.2. Context-Aware Service Issues .....................................................................74 3.3.3. The Lifecycle of MHS Context-Aware Services..........................................76 3.4. The Design of MHS Context-Aware Policies .................................................77 3.4.1. MHS Policy Language Requirements ..........................................................80 3.4.2. Roles of Policies in Pervasive Computing Environments............................81 3.4.3. Context-Aware Policy Issues .......................................................................82 3.4.4. MHS Context-Aware Policy Concepts ........................................................83 3.4.4.1. MHS Policy Associations......................................................................87 3.4.5. The MHS Policy language Notation ............................................................93 3.4.6. Context-Aware Policy Conflict Sources and Types.....................................97 3.4.7. Policy Conflict Detection .............................................................................99 3.4.7.1. Goals of Policy Conflict Detection........................................................99 3.4.7.2. Conflict Detection Techniques ............................................................100 3.4.8. Policy Conflict Resolution .........................................................................104 3.4.8.1. Goals of Policy Conflict Resolution....................................................104 3.4.8.2. When to Resolve Policy Conflicts.......................................................105 3.4.8.3. Techniques to Resolve Policy Conflicts..............................................106 3.4.8.4. When to Update the Policy Conflict Resolution Result ......................108
xvi
3.5. 4.
Summary........................................................................................................108 Implementation of MHS: Detailed Design and Prototype..............................110
4.1. Architecture of the MHS Framework............................................................112 4.1.1. Server Side Software Components.............................................................114 4.1.1.1. System Manager ..................................................................................114 4.1.1.2. Code Server .........................................................................................115 4.1.1.3. Remoting Service ................................................................................117 4.1.1.4. Context Component.............................................................................117 4.1.1.5. Context-Aware Policy Component......................................................118 4.1.1.6. Context-Aware Service Component....................................................120 4.1.1.7. Register and Deregister Component....................................................124 4.1.2. Client Side Software Components .............................................................124 4.1.2.1. Mobile Client Manager........................................................................124 4.1.2.2. Code Cache..........................................................................................125 4.1.3. Mobile Code...............................................................................................126 4.1.4. Repository ..................................................................................................127 4.2. Execution Behaviours of the MHS Prototype ...............................................128 4.2.1. Accessing Shared Resource Services .........................................................132 4.2.2. Policy Conflict Detection and Resolution in MHS ....................................138 4.2.3. Controlling Users’ Behaviours...................................................................141 4.2.4. Partial Control between Users and the System ..........................................150 4.3.
Adding New Context-Aware Services ..........................................................151
4.4. MHS Sample Context-Aware Services .........................................................153 4.4.1. Mobile Pocket Pad Service ........................................................................153 4.4.2. Mobile Remote Media Player Service .......................................................155 4.4.3. Mobile VNC Service..................................................................................157 4.5. 5.
Summary........................................................................................................159 Evaluation of the MHS Prototype ....................................................................160
5.1. Efficiency of the Prototype System ...............................................................161 5.1.1. System Performance...................................................................................163 5.1.2. Prefetching Techniques ..............................................................................174 5.2.
Scalability of the System ...............................................................................181
5.3.
Usability of the System..................................................................................183
5.4.
Discussion .....................................................................................................184
5.5.
Summary........................................................................................................187
6.
Using the MHS Framework: The MHS Methodology....................................188 6.1.
Overview of the MHS Methodology .............................................................190
xvii
6.1.1. 6.1.2.
MHS Methodology Requirements .............................................................191 Scope of the MHS Methodology................................................................193
6.2. Details of the MHS Methodology .................................................................193 6.2.1. Analysis Phase............................................................................................195 6.2.2. Design Phase ..............................................................................................197 6.2.2.1. Architectural Design............................................................................197 6.2.2.2. Detailed Design: From Design to Implementation..............................207 6.3. Case Study.....................................................................................................213 6.3.1. A Pervasive Campus Domain ....................................................................213 6.3.1.1. Analysis Phase.....................................................................................216 6.3.1.2. Design Phase .......................................................................................219 6.4.
Related Work.................................................................................................238
6.5.
Summary........................................................................................................240
7.
Conclusions and Future Work..........................................................................243 7.1.
Summary of Contributions ............................................................................245
7.2.
Future Work...................................................................................................248
References .....................................................................................................................254 Glossary.........................................................................................................................274 Appendix .......................................................................................................................276
xviii
List of Figures Figure 1.1: An Overview of Pervasive Computing Environments ....................................4 Figure 1.2: The MHS View of Pervasive Computing......................................................21 Figure 2.1: Indoor Location Sensing Techniques.............................................................28 Figure 2.2: Physical Spaces in the Information Technology Building.............................30 Figure 3.1: MHS Pervasive Computing Environments....................................................57 Figure 3.2: A Pervasive Computing Domain and Its Spaces ...........................................58 Figure 3.3: Logical Boundaries in Pervasive Computing Environments.........................59 Figure 3.4: Different Types of Spaces in Pervasive Computing Environments...............62 Figure 3.5: High Level Abstraction of the MHS Framework ..........................................64 Figure 3.6: The Visibility of Services Depends on the Boundary....................................68 Figure 3.7: The Lifecycle of MHS Context-Aware Services ...........................................77 Figure 3.8: MHS Context-Aware Policy Concepts..........................................................84 Figure 3.9: Synonyms of Actions in the MHS System ....................................................85 Figure 3.10: Role Collections Document in a Campus Domain......................................87 Figure 3.11: An Example of Context_Activity Mapping Document ...............................88 Figure 3.12: An Example of Public Space Policy Document ..........................................91 Figure 3.13: An Example of Private Space Policy Document .........................................92 Figure 3.14: An Example of Policy Document by Users Who Do Not Own a Space .....93 Figure 4.1: A High Level Architecture of the MHS System ..........................................113 Figure 4.2: Get Service Web Method.............................................................................115 Figure 4.3: Get Mobile Code Web Method ...................................................................117 Figure 4.4: A User's Profile Document ..........................................................................121 Figure 4.5: The MHS System Architecture....................................................................128 Figure 4.6: Get Current Contexts Web Method .............................................................130 Figure 4.7: Starting a Shared Resource Service .............................................................132 Figure 4.8: A Remote VNC Web Method .....................................................................134 Figure 4.9: A Remoting Client Web Method.................................................................135
xix
Figure 4.10: Terminate VNC Service on the Target Machine .......................................137 Figure 4.11: MHS Policy Conflict Resolution Techniques............................................141 Figure 4.12: The MHS Context-Aware Policy Implementation ....................................143 Figure 4.13: (a) Accessing the System from a Laptop Device (b) Accessing the System from a Pocket PC Device and (c) Mobile Pocket Pad Service.......................................155 Figure 4.14: (a) Accessing the System from a Pocket PC Device, and (b) Remote Media Player Service.................................................................................................................157 Figure 4.15: The MHS System with More than One Service Available ........................157 Figure 4.16: (a) Accessing the System from a Pocket PC Device, (b) Mobile VNC Service, and (c) Displaying a User’s Information on a Desktop Machine – VNC Started ........................................................................................................................................158 Figure 5.1: Evaluation Stages of the MHS System ........................................................162 Figure 5.2: Location Context Change Delay, Service Activation and Policy Decision Checking on a Time Line (distances between vertical bars are not indications of time scales).............................................................................................................................163 Figure 5.3: Experimental Results...................................................................................166 Figure 5.4: Policy Evaluation Results ............................................................................169 Figure 5.5: Logical Area Representation .......................................................................176 Figure 5.6: Average Client Delay for a Location Web Service......................................182 Figure 6.1: The MHS Methodology Analysis and Design .............................................194 Figure 6.2: Domain and Space Boundaries in Pervasive Computing Environments.....198 Figure 6.3: Hierarchical Relationships between a Domain and Spaces .........................199 Figure 6.4: A Template of an Environment Element .....................................................208 Figure 6.5: A Template of an Entity Element ................................................................209 Figure 6.6: A Template of a Context Element ...............................................................209 Figure 6.7: A Template of a Service Element ................................................................210 Figure 6.8: A Template of a Policy Element..................................................................210 Figure 6.9: A Template of Mapping between Activity and Context Information..........210 Figure 6.10: A Template of a Computing Device Element............................................211 Figure 6.11: Relationships between System Elements...................................................211
xx
Figure 6.12: A Campus Pervasive Domain....................................................................214 Figure 6.13: Use Case of Users’ Activities in a Pervasive Campus Environment.........218 Figure 6.14: A Campus Domain and Sub Domains .......................................................220 Figure 6.15: Monash Berwick Campus Map .................................................................221 Figure 6.16: End-Users’ Activities in the Class Room ..................................................225 Figure 6.17: Relationships between System Elements in a Campus Domain................233 Figure 6.18: A Detailed Template of an Environment in a Campus Domain ................235 Figure 6.19: A Detailed Template of an Entity in a Campus Domain ...........................236 Figure 6.20: A Detailed Template of a Context in a Campus Domain ..........................236 Figure 6.21: A Detailed Template of a Service in a Campus Domain...........................237 Figure 6.22: A Detailed Template of a Computing Device in a Campus Domain.........238
xxi
List of Tables Table 2.1: Comparison of Location-Aware Projects........................................................35 Table 4.1: Policy Decision Checking.............................................................................146 Table 4.2: Policy Consistency Checking of “Imposed On� Value.................................148 Table 6.1: Detail of an Environment Element ...............................................................200 Table 6.2: Detail of a Domain Boundary .......................................................................200 Table 6.3: Detail of a Space Boundary...........................................................................201 Table 6.4: Detail of an Entity Element...........................................................................202 Table 6.5: Detail of a User Element...............................................................................202 Table 6.6: Detail of a Software Client Element .............................................................202 Table 6.7: Detail of a Context Element..........................................................................203 Table 6.8: Detail of a Service Element ..........................................................................205 Table 6.9: Detail of a Policy Element ............................................................................206 Table 6.10: Detail of a Computing Device Element ......................................................207 Table 6.11: Detail of a Campus Domain........................................................................221 Table 6.12: Details of a Campus Domain and Sub Domains.........................................223 Table 6.13: Details of Spaces and Sub Spaces in a Campus Domain............................224 Table 6.14: Detail of Entities in a Campus Domain ......................................................225 Table 6.15: Details of Users in a Campus Domain........................................................226 Table 6.16: Details of Software Clients in a Campus Domain ......................................227 Table 6.17: Detail of Contexts in a Campus Domain ....................................................227 Table 6.18: Details of Services in a Campus Domain ...................................................230 Table 6.19: Details of Policies in a Campus Domain ....................................................232 Table 6.20: Details of Computing Devices in a Campus Domain .................................232
xxii
CHAPTER
1
1. Introduction
Today, computing is increasingly being carried out using mobile and small devices such as Personal Digital Assistants (PDAs) and mobile phones which allow users to access data or information (e.g., Web browsing, emailing, text messaging) while on the move. Recent advances in mobile devices, wireless networking and sensing systems are offering new possibilities for empowering users to be more effective in completing their daily tasks. Sensor devices and software systems can be invisibly installed in the environment of our everyday lives. This convergence of advanced computing devices and connected software systems via wireless technology and the Internet is known as “pervasive computing� [Wei91]. Pervasive computing is the next generation of software systems, computing devices and environments with information, services and communication technology available everywhere in the environment for users at any time. Pervasive computing aims to create software systems that are connected, proactive, intuitive, appropriately available for users and unobtrusively embedded in the
1
environment. Pervasive computing focuses on mobility in accessing information from a mobile device and so, making appropriate information available everywhere for users. The idea is that a mobile or non-mobile user can communicate with any embedded or non-embedded software system as soon as s/he steps into a particular space or an environment. Communication here can be in the form of explicit or implicit requests from users to the system. The implicit mode would use several sensor systems such as a location sensing system to detect a user’s location, a physical sensing system to monitor a user’s current activities and so on. For example, the moment a user steps into his/her office, the light switches on and when the user steps out of the office, the light turns off. This contrasts with an explicit request, where a user needs to manually turn on/off the light. In addition, context-awareness in conjunction with pervasive software applications is emerging as intuitively suitable for being delivered as context-aware pervasive services [SAW94; Sch95; LKA96; DAW98; Leo98; CDM00; Nob00; BGS01; CHK02; GSB02; LSD02; Hen03; CEM03; Ran05; Mit05; DSS06; BCM06]. This dissertation investigates the delivery of context-aware pervasive services onto a mobile device and proposes a novel context-aware regulated services model to address the specific infrastructure for pervasive computing requirements imposed on context-aware pervasive systems, by using a policy (rule) based access to govern users’ behaviours in accessing and executing services. This chapter is organised as follows. After providing an overview of pervasive computing, in Section 1.1, we discuss the characteristics of pervasive computing environments. This is followed in Section 1.2 by introducing the role of contextawareness in pervasive computing. In Section 1.2.1, we highlight seven main requirements for building a context-aware pervasive system. We further illustrate sample scenarios that drive the usefulness of having context-aware services in Section 1.2.2 and context-aware policy (regulation) in Section 1.2.3. In Section 1.3, we highlight the objectives of the research presented in this dissertation. The scope and contributions of our research are outlined in Section 1.4. Finally, section 1.5 describes the structure of this dissertation.
2
1.1.
The Characteristics of Pervasive Computing
Environments As the number of computing devices and software systems continue to grow, the demand for exploring pervasive computing continues to expand. Pervasive computing goes beyond traditional computing systems, on the one hand employing small and mobile devices and on the other hand, integrating information, communication technology and software systems as part of an environment (e.g., embedded into walls, cupboards, rooms, buildings, etc.). Pervasive computing represents the next evolutionary step in a distributed computing system, namely the transformation of software systems from relatively static, not adaptive and only locally available to highly adaptive and proactive software systems that adapt to users’ needs [Wei91; Sat01; SaM03]. A pervasive computing environment can be characterized by the existence of wireless networks, different types of computing devices, sensing systems, software systems (e.g., Web services, server and client side software components) as illustrated in Figure 1.1.
Location sensor systems
Wireless network
PC client Server components
Repository (Service, Context, Policy, etc.)
Service invocation via Web service
Laptop client
Small device client
3
Figure 1.1: An Overview of Pervasive Computing Environments
In this section, we highlight nine characteristics of pervasive computing with a focus on pervasive computing environments that motivate the establishment of the pervasive computing vision. The discussion aims to provide a broad understanding of pervasive system characteristics/aspects that need to be taken into account when analysing and designing the system. The first key characteristic of pervasive computing is that of an intelligent system that is viewed as an embedded or non-embedded software system in the environment. The system proactively senses users’ needs and delivers relevant information to users. Eight other characteristics of pervasive computing are: (1) Disappear Computing devices are becoming progressively compact, smaller and more powerful. Computing devices (e.g., sensor devices) are embedded everywhere in the environment. They can be embedded in a room, on a user’s mobile devices, personal belongings (e.g., a cup), etc. The devices and software systems are weaved into our daily life. (2) Proactive A proactive system refers to an active system that proactively suggests a list of relevant services to users, instead of users have to explicitly request services. The word “service”
4
in the notion of electronic services (e.g., Web services) suggests the use of software systems for providing assistance to users at a level that is more personal and in ways that, even if non-technical, they can understand. The system automatically senses users’ needs and deliver relevant services. For example, as soon as the system senses a user’s current location (e.g., approaching a lecture room), the system proactively retrieves and downloads relevant lecture materials onto a user’s mobile device and hence, by the time the user enters the lecture room, the material is ready to read. (3) Autonomous A pervasive system targets many different entities from novice to expert users. The pervasive system needs to be self directed and self configured. The execution of a service is done with minimal user intervention. Ideally, end-users do not need to know low level details (e.g., architecture and implementation) of the system.
(4) Aware and adaptive Traditional software systems are not adaptive to users’ contexts and not proactive in delivering services to users. The traditional systems do not take into account the notion of contexts. In contrast to pervasive systems, they potentially tailor services according to users’ contexts. Having the ability to sense users’ contexts and delivering relevant information (according to users’ needs – personalised services) would empower and help users in completing their daily tasks. Taking into account information regarding users’ preferences on when and where s/he would like to receive such services would be useful. Thus, the software systems which are running in the environment need to be highly adaptive to adjust to the changing contexts and resource availabilities. The challenge for such a system lies in the complexity of capturing, representing, interpreting and processing context information and services. It requires some additional context sensors (e.g., a location sensor to keep track of a user’s current location, an activity sensor to capture a user’s current activities, etc.) and some intelligent software components to interpret and deduce the meaning of contexts. (5) Intuitive
5
A pervasive system needs to target all levels of users such as expert users who are familiar with the system and non-computer literate users who have no or little knowledge about computing. An intuitive system can be achieved by having a simple system interface that is able to tune itself with minimal or without user distractions. As a user’s context changes, the system proactively computes a new set of services which are relevant and useful in that context and this list of services is automatically updated on the user’s mobile device. (6) Mobile The current traditional system relies on permanent Internet connectivity in order to obtain information or resources over the network. In a pervasive system, service and information are available and widely accessible to users at any time and any location. The pervasive system targets mobile devices and caches services/information for future re-use. This then enables users to access information while on the move with or without Internet connection. Pervasive computing deals with mobile users who are always on the move, from one location to another. A mobile user brings a mobile device along (when moving) to access software applications and resources (e.g., information) from time to time. Likewise, mobile users, applications and resources (e.g., data) are stored on the server side and can be downloaded or transferred onto a mobile user’s device. (7) Dynamic The pervasive computing environment is highly dynamic. Unlike pervasive computing, traditional computing applications (e.g., desktop applications), resources, devices (e.g., desktop computers) are relatively static. The information and applications are stored in a local device and only accessible from that device. In pervasive computing, each user in the environment would have his/her own profiles (requirements) that specify how s/he wants a system to execute services at a particular time. The user profiles may be different from one location (place) to another, one occasion to another, etc. Moreover, the user profiles are largely dynamic which can be modified from time to time depending on the user’s needs. Therefore, pervasive systems need to adapt to highly flexible and active requirements from end-users.
6
(8) Heterogeneous A pervasive computing environment typically consists of many computing devices such as mobile devices (e.g., a pocket PC, a laptop, etc.) and stationary devices (e.g., a desktop PC, an embedded device, a printer, a server, etc.). A desktop computer in general has higher processing speed and memory capacity compared to small devices. As a result, the success of development of pervasive systems depends on the ability of software systems to adapt to resource constrained devices. The development of software applications that targets resource constrained devices does incur greater development effort. One notable system that embeds the service application and interface onto a mobile device is discussed in [Rin02]. As the mobile device is very limited in resources (memory and speed), this approach is less resource smart. To overcome this limitation, developers need to exploit another technique (e.g., mobile code [Jas97; PRM97; FPV98; CML00; CMZ01; Cap03]) by downloading the service application (mobile code) which is stored on the server side, onto a mobile user’s device only when needed. Contextawareness can be combined with mobile code techniques to allow applications to select when (e.g., at a certain time), where to download the code from (e.g., from trusted servers), and where to download the code to (e.g., onto a specific mobile device). In the environment, there is also a variety of wireless network infrastructures (e.g., Wi-Fi, Bluetooth, Infrared, etc.). In addition, a pervasive computing environment features a variety of system elements (e.g., a location positioning system, service invocation, service delivery, etc.) which are inter-dependent. Each of these system elements has its own role and need to be able to communicate with each other. For example, a location sensing system passes the location information to a context interpreter in order to analyse and interpret a user’s current location. Pervasive system components are normally deployed (installed) in many server/client sides (e.g., a contextual manager component is installed on the server side and a service execution component is installed on the mobile client device). System components are also deployed in many pervasive computing environments (e.g., a pervasive shopping environment, pervasive home environment, pervasive campus
7
environment, etc.). Though the system components are already deployed into several server/client sides and environments, there is a need to integrate them into one single platform that consists of various information, contexts, services, system configurations, and business rules (policies). Ideally, these information and system components are accessible across different pervasive computing environments, different devices and different applications. As pervasive computing environments face a proliferation of users, devices and applications, integration of the information and system components become more complex. We have presented a brief overview of the main characteristics of pervasive computing. The above characteristics need to be considered carefully in order to achieve the vision of pervasive computing. The evaluation of the developments in the field of pervasive computing provides a basis for investigating, analysing, designing, and implementing the delivery of context-aware pervasive services with policies to govern service behaviours, which is the focus of this dissertation. In the next section, we discuss the role of context-awareness especially, the necessity of having context-aware regulated services in pervasive computing environments.
1.2.
The Role of Context-Awareness in Pervasive Computing
Recent innovations in wireless networks, mobile devices and software systems, are fueling new possibilities for tighter coupling of technology with people, in more ways than ever. One sample contextual service is an e-note service that allows users to leave a message for other users in particular contexts (e.g., to user A at room A and time t1) and stores this message on the server. The message is only pushed onto the designated recipient’s mobile device, when the user is in the relevant context (e.g., about entering room A). Another sample contextual service is an automated office task service, which helps users perform tasks automatically (on behalf of users). This service is useful if there is regularity in the user’s activities. For example, a user checks email; a contextual service that is running on the background can automatically start Outlook Express, upon
8
detecting the user’s location (when the user is approaching the office), and so, all incoming emails are already downloaded and ready for the user to read. As Web service technology evolves, the idea of context-aware services gains more interest. Context-awareness has been proposed as a criterion that satisfies the adaptivity, flexibility and proactivity in discovering, delivering and executing services in pervasive computing environments [SAW94; PRM99; Kar03; Bec04]. A context-aware system extracts, interprets context information and adapts its system functionalities to the current contexts. An idea is that different sets of services will dynamically drop into mobile users’ devices depending on their contexts. The user on selecting a service to use will have the required software for utilizing the service automatically set up, effectively “pulling” down the required service (interface and data). As the user’s context changes, the list of services is automatically updated on the user’s mobile device and the downloaded code managed with respect to limited device resources. Contextual information such as location and user information have been employed to tailor applications. There are various definitions of context. For example, Dey defines context as any useful information that helps to describe the situation of an entity [DeA99; Dey01]. An entity can be a user, target software client or any object that exists in the environment. There is a range of sensing devices used in a pervasive computing environment such as a location sensor, an activity sensor, a temperature sensor, RFID objects, etc. The sensing devices capture users’ current contexts and help a system to potentially tailor services according to users’ needs. Schmidt et al. define context as any knowledge regarding users and their surrounding devices and location [SAT99]. Chen [ChK00], and Schilit [SAW94] identified four categories of context: (a) Computing context: This can be any information related to computing environments such as computer resources (e.g., printers, scanners and workstations), available bandwidth and network connection. (b) User context: It refers to any knowledge about users such as a user’s profile, intention, location, user identity, preference, history, mood, surrounding user and context of other users or objects. A location context is represented by an indoor logical model
9
such as a room location. An activity context is related to the user’s current tasks (e.g., studying, resting, etc.). (c) Physical context: Physical context involves physical objects and properties in the user’s environment such as lighting, temperature, traffic conditions and noise levels. (d) Time context: Time refers to the current time and the user’s schedule (in terms of days, weeks, months and years) that can be used to determine a mobile application’s behaviours. Another dimension of context is context history, which includes the information over a time span related to the user’s context [ChK00]. Work has been done in [PTH03] on a dynamic conceptual model of context that supports cognitive activities other than just location, time and parts of physical contexts. The context consists of a set of parameters to suggest on behalf of a user what services are useful and relevant with respect to the user’s situation. With the use of context, a pervasive system would have the ability to usefully adapt services or applications to the user’s current situation, intention or environment, as well as, presenting services in forms that the user can readily use, perhaps personalised to his/her needs. The contextual system enables users to receive a relevant set of services that fit his/her current contexts, instead of a barrage of irrelevant services. The system requirements of context-aware systems in pervasive computing environments are discussed in Section 1.2.1.
1.2.1. System Requirements of Context-Aware Pervasive Systems The key requirements of a context-aware system in pervasive computing environments include: (1) Have a location positioning system As target entities (e.g., users) are always on the move and users are the center of a system. A system needs to employ a location sensing system to detect users’ locations accurately and in a minimum amount of time. That way, users can see the updated services (applications) at the right time and location contexts.
10
(2) Proactively capture contexts, discover and deliver relevant services There is a need for capturing and retrieving a user’s context information (e.g., a user’s current location, activities, etc.) at the right time. The system also needs to proactively sense and update the context information when changes. (3) Support sharing of services As a context-aware system deals with many services and often, one service is used by many users, the system needs to store services in an accessible place (e.g., on the server side). In contrast to storing services on the server side, storing services on the mobile client side does not offer or support reusability (sharing) of services. It also does not support the extensibility of the system, as the number of services that can be stored locally on the device is limited by its memory size. The only benefit is that the service is on the device and ready to be executed. It does not require a contextual component to retrieve and download the service onto the client’s device. (4) Support genericity A context-aware system needs to support many types of services. As a result, a system needs to be generic in order to support new services. The applications can be traditional applications that do not have context information, and context-aware applications that take into account context information. (5) Support interoperability Similarly, a context-aware pervasive system must support interoperability of contextual software components. Ideally, the contextual system functionalities can be invoked and accessed within the system as well as from external systems, regardless of platforms and languages used. This is possible by developing contextual software functionalities as Web services, where Web methods can be accessed by other systems which are connected to the Internet from various platforms and languages. (6) Support policy to control access to services With its vision of pervasive information access, the user-centric approach that takes into account information regarding users’ contexts often gives users full control over the system. In specific contexts, a system needs to be in control by specifying a set of rules
11
(policies). A policy controls a set of services that users would be able to see in particular contexts, as well as execution of services (e.g., can start music service, but not stopping the music). In short, a policy consists of a set of rules that could govern the visibility and execution of context-aware services. In addition, having task services that could help users perform routine tasks automatically would be a benefit. To have an automatic task, a user needs to impose a set of obligations on a system along with the information (e.g., what service to perform, when and where to perform the service). The system then executes the service when the specified contexts are met. Each of the policy components is published via the system as a Web service, in order to support interoperability. (7) Support scalability A pervasive computing consists of a number of computing devices and software applications. As devices and software applications continue to multiply, scalability of the system becomes a major issue. A pervasive system must accommodate simultaneous users’ requests to access software applications from multiple devices (which are embedded in the environment or carried by users) in a minimum amount of time. The above discussion highlights the usefulness of a framework for the dynamic, adaptive, proactive, and autonomous operation and delivery of diverse context-aware services.
1.2.2. Context-Aware Services in Pervasive Computing
To clearly understand the usefulness of context sensing behaviours in pervasive computing environments, we first consider the following system scenario that uses a traditional Windows Media Player [Mic06] as an example. Here, a “traditional application” refers to a primitive stand-alone application that does not have or utilise any context sensing ability. “Every day after lunch (around 1:30PM), user A likes listening to instrumental music in his office (room A). After having his lunch at
12
Merlins Café, he wants his favourite instrumental music to be played on his desktop machine, as soon as he opens the door and steps into his office. However, since a traditional Windows Media Player application does not use and utilize the knowledge of the user’s context information, this smart activity cannot be performed implicitly by the system. Hence, user A needs to manually start the Windows Media Player application, select the music name and start the music on his desktop machine”. To manually start the music each time the user wants to listen to it can be quite tedious and annoying and perhaps unnecessary, especially if there is regularity in the user’s behaviours. For example, the user always listens to the same music everyday at the same time and location. Now, we look at another scenario of a context-aware Windows Media Player application that uses context-sensing behaviours. By sensing the user’s contexts, the system then automatically starts or stops playing the music on the user’s desktop machine: “By identifying a user and sensing a user’s current location (e.g., user A is now at the corridor and walking towards his office), the contextaware Windows Media Player application will then start playing the user’s favourite instrumental music on the desktop machine, as soon as the system senses that user A is now stepping into the office (room A). The music playing depends on who the user is. This instrumental music will be played until the system detects that the user has walked out of the room (e.g., gone out for a meeting)”. Adding context sensitivity to a traditional Windows Media Player application certainly maximises a user’s experience in using the application. This is due to the intelligent behaviours of the system that frees users from some manual computation tasks. Hence, this empowers the novice or even the non computer literate users to be more effective in
13
performing their daily tasks. This sensing ability that can be found on any context-aware applications distinguishes them from existing traditional applications. As pervasive computing often consists of a number of entities (i.e., many users) and each user may perform different activities (e.g., user A is in the meeting, user B is giving a lecture, etc.), balancing control given to one user (entity) by considering other entities’ activities or situations is important. For example, while user A is currently studying in her office, all visitors who enter the office, are not permitted to start any service (e.g., a music service) that could disturb user A. This becomes paramount in pervasive computing environments, as users tend to be on the move from one geographical location (e.g., a room) to another and are allowed to access services or perform actions on the service at any time and any place that the user visits. This then opens up a new research avenue known as context-aware regulated services in pervasive computing, where the flexibility and convenience given to a user to access and perform actions on the service need to comply with a policy specified by a space. The idea is to balance a user’s convenience with compliance aspects, where a user could access services, but the system also has control over users’ behaviours. For example, during exam time in the examination room, all students are not permitted to access any services (e.g., an online browsing service, a lecture note service, etc.). These services are not visible to students during the exam time (e.g., Monday, 25 Jan 2007). However, when the exam is over, the students could access services as per normal (e.g., can access any services related to the room, related to the user’s current activities, etc.). In the next section, we discuss background and usefulness of having context-aware regulated services in pervasive computing, which is the focus of this dissertation.
1.2.3. Context-Aware Policy (Regulation) in Pervasive Computing Another use of context is to suggest an applicable policy or rule in the environment. Now, consider another scenario of context-aware services that makes use of policy to control the visibility and execution of context-aware services in pervasive computing environments. This sample scenario extends the idea of intelligent context based Windows Media Player application as discussed above. This is done by allowing an end 14
user to define a rule or a policy that specifies when, where and what type of information (e.g., music) that s/he wants to be played or stopped at each particular situation. The applicable policy is enforced depending on current contexts (also known as a contextaware policy). Each space in the environment can have its own policy that specifies how things should be executed in specific contexts. The entities (e.g., users) need to adapt to specified rules when moving from one physical place to another. The scenario below illustrates the usefulness of having a policy document with which the user can specify control behaviours for services in particular situations. The policy is applied when a context is satisfied.
(1)
Intention: Every day during lunch time from 12 to 12:30PM, I want the Media Player service to automatically start my favourite music at my room (room B538). Rule:
On any day of the week between 12 and 12:30PM, when the system detects the user is currently approaching room B538, the system automatically starts the specified music.
(2)
Intention: I do not mind other users starting a Media Player service in my room (e.g., room B538) on Wednesday from 12 to 2 PM, as I am somewhere else at that time.
Rule:
All visitors can start a Media Player service on a shared desktop machine, and play any song that they wish on Wednesday from 12 to 2PM at room B538.
(3)
Intention: Do not let anyone bother me in my office (room B538) from 2 to 3PM every Wednesday, as I am preparing for my meeting.
Rule
No services are allowed to be executed by other users on Wednesday
15
from 2 to 3PM at room B538.
(4)
Intention: None of the services are allowed to be executed by students during exam time on Wednesday, 03/03/2007, from 12 to 2PM at the exam room.
Rule
All students are prohibited from executing any services on Wednesday, 03/03/2007 from 12 to 2PM at the exam room.
(5)
Intention: I only allow my colleagues (i.e., all other lecturers) to start a Media Player service at my room on Wednesday from 2:30 to 3:30PM.
16
Rule
Only visitors who have the same role (i.e., a power user role), can start the media player service. Other roles can only listen to the running music (e.g., on the shared desktop machine) without being able to start his/her own music, stop, pause or resume the currently running music on Wednesday from 2:30 to 3:30PM.
(6)
Intention: I do not allow anyone to access any service in my office on weekends, as there is no security staff on premises and security systems may be shut down during weekends.
Rule
All services are not visible to any visitors who enter my office on weekends. However, the lists of services are still visible to the owner of the space during weekends.
Note that another way to allow the above intentions is by having a sensor system (i.e., a location sensing system to detect a user’s current proximity). By sensing the user’s current location, the system then controls the visibility of a service and allows or prohibits others from performing actions on the service. For example, if an owner of a room (e.g., user A) is not in his/her room, the system automatically allows all visitors starting a Media Player service at room A and when, the system detects user A is approaching the room, the system then prohibits all visitors from starting any services or warns visitors that the running services need to be stopped. This approach is simple to implement and maintain, as there is no policy (rule) required. However, it does not support more fine grained complex situations or conditions such as: (a) What happens if I only allow visitors with the same level of role with me to start the service. (b) Although, I am not in the room, I do not allow them to start any service unless they are my supervisors. (c) I only give them a certain period of time to start any service in my room, when I am
17
not in. The above complex situations can be realized with the use of policy that specifies what activities or actions that a space allows, obligates, or prohibits visitors from doing so. Integrating the concept of policy into the development of context-aware services has motivated our research and it impacts on the way users access services. All users within a system are bound to the rules and each action that they perform need to comply with the rules. An objective of our research and the specific contribution that this dissertation makes is to enable proactive context-aware services with context-aware policies to regulate the visibility and execution of services in pervasive computing environments. We present the detailed objectives of our research in the next section (Section 1.3).
1.3.
Research Objectives
The objectives of this dissertation are
To investigate the concept of context-aware regulated services in pervasive computing environments, and to design, implement, and evaluate a system that realizes this concept.
The system supports a proactive and intuitive contextual system along with the ability to specify policies for regulating access to services in particular contexts. The research presented in this dissertation addresses system requirements and an infrastructure that facilitates the development of context-aware regulated services. The dissertation proposes context-aware regulated services, and architectural and interaction models between contextual software components. While the focus is on context-aware regulated services, the research presented in this dissertation also benefits context-aware systems modelling especially pervasive computing environment modelling. The proposed system models a system at a high
18
level of abstraction and is not tied to particular devices, spaces, users and platforms in the environment. Our system supports three basic system elements to enhance services for mobile users in pervasive computing environments: (a) Context It can be user contexts (e.g., a user’s identity and location) and environment contexts (e.g., day and time). A user would see different services depending on context. (b) Service It is software that helps users perform daily tasks by taking into account context information. Some examples of services are an online browsing service, an online booking service, etc. We discuss in details visibility, scope and accessibility of contextaware services in Section 3.3, Chapter 3. We discuss two types of context-aware services in our system in Section 4.1.1.6, Chapter 4. (c) Policy A policy controls service visibility and governs users’ behaviours in accessing services in pervasive computing environments. The policy is aware of user, and environment contexts. This work addresses five research questions in developing a system for contextaware regulated services: (1) What are key elements/concepts of a system for context-aware regulated services? (2) What techniques are used to implement context-aware regulated services? (3) How will the regulated services interact with users (in terms of convenience and compliance) in pervasive computing? (4) How to achieve effective system performance in context-aware regulated services? (5) Suppose we want to introduce context-aware regulated services in pervasive computing environments (e.g., in a campus environment), what are procedures
19
(guidelines) to develop such a system (in terms of system requirements, scope, architectural and detailed design of the system)?
1.4.
Scope and Contributions
The dissertation focuses on the development of an indoor context-aware regulated system that controls users’ behaviours in accessing context-aware services in pervasive computing environments. The issues of design, infrastructure and interaction between software components that supports the discovery, delivery and execution of contextaware regulated services are considered in great detail. This dissertation introduces the Mobile Hanging Services (MHS) framework. The MHS framework includes basic building blocks of contextual software components, techniques to deliver contextual service applications to end-users and mechanisms to enable context-aware regulated services in pervasive computing environments (e.g., an MHS enabled campus environment). The MHS framework supports awareness of both services and policies, in which the applicable services and policies would completely depend on surrounding contexts in the environment. A service in our system provides access to resources (e.g., devices in the environment) and data/information. The system controls access to services running on shared devices (e.g., an embedded device, a workstation, etc.) and personal devices (e.g., a user’s mobile device, a laptop machine, etc.). The research contributions of this thesis are threefold: (1) The MHS view of pervasive computing The dissertation proposes a novel model of context-aware regulated services in pervasive computing including environments, software system components (i.e., context-aware service and policy components), entities and computing devices as shown in Figure 1.2. We model a system in a high-level manner, in terms of abstract system elements and parameters which are not tied to any specific environment. We view a pervasive computing environment as a collection of domains (logical boundaries) and each of these
20
domains consist of several physical spaces. The model provides comprehensive design for context-aware regulated services.
Entities • Mobile user • Software client
Software components • Context-aware service • Context-aware policy
Environments • Domain (logical boundary) • Space (physical boundary) Computing devices • Sensing device • Mobile device • Stationary device
Figure 1.2: The MHS View of Pervasive Computing
(2) MHS Framework architecture, design and implementation The second contribution is the development of a software framework with contextual software components that supports design and deployment of context-aware regulated services. This framework enables a novel contextual services infrastructure that allows services to be described at a high level of abstraction and to be regulated by contextual policies. This contextual policy governs the visibility and execution of contextual services in the environment. In addition, a range of contextual services are developed to illustrate different types of services used in the MHS framework. Our conception of the MHS system employs a location sensing system (e.g., using the Ekahau Positioning system [Eka00]), and a Web service conceptual design that allows method invocation in disparate platforms and languages. This is a way of thinking about context-aware applications, driven by end-to-end high interoperability design
21
principles, which can move between hosts during their execution lifetime and support sharing of applications between laptop computers and handheld devices. (3) MHS Methodology Many of the existing context-aware projects concern low-level descriptions and concepts, rather than high level design. This makes the system design too focused on a particular environment/platform/implementation and so makes it difficult to apply or reuse the pervasive system concepts in other environments that may have different system elements and software architectures. As a result, a new methodology is required to effectively and repeatedly guide developers to achieve consistent results during analysis and design of the system. The third contribution is the MHS methodology that provides step by step high level guidance for building context-aware regulated services in pervasive computing environments.
1.5.
Structure of the Dissertation
The dissertation is organised into seven chapters. Chapter 2 provides the background necessary for context-aware services. It reviews related research from the context of the work related to this dissertation. Chapter 3 presents a high level abstraction of MHS system modelling including issues in developing localised contextual services in pervasive computing environments. The novel context-aware regulated services model proposed and developed in our research is then presented. We then provide our conceptual model and introduce our approach to building such a system for context-aware regulated services. Chapter 4 discusses techniques used to implement such a system as discussed in Chapter 3. It presents the implementation of a prototype MHS framework with a logical view of its system components. The framework addresses the message passing between contextual software components in order to discover, deliver and execute context-aware regulated services in specific contexts.
22
Chapter 5 presents the experimental results of our MHS framework. We first evaluate the efficiency of the prototype system by measuring the time that it takes to execute the service, detect/update the location context change and check for policy decision results. We then experimentally evaluate the scalability of the prototype system against the number of users. The usability of the proposed model is then evaluated against the aim of pervasive computing and complexity in using the system. Chapter 6 presents the MHS methodology that gives step by step guidelines for building a system for context-aware regulated services from system analysis to architectural and detailed design. The dissertation is summarised in Chapter 7, where lessons learnt are presented, key research contributions are highlighted and future directions of this research are discussed.
23
CHAPTER
2
2. Related Work
As discussed in the previous chapter, context-aware pervasive systems are at a stage of rapid evolution and emerging as the next phase of pervasive intelligence computing. Current research and development in context-aware services are leading towards a usercentric computing that focuses on users’ contexts in discovering, delivering and executing services. Designing a system based on a user-centric approach has now become one of the key factors that plays a significant role to empower users to be more effective in completing their daily tasks. These user-centric environments provide the underlying framework for diverse contextual services to be registered in a service repository and for these services to be discovered, interacted and downloaded with seamless effort. End-users gain the benefit of receiving only relevant services, while server components look for available services for users in the particular context and guarantee opportunities for end-users to experience and interact with only relevant services. In this chapter, we present a discussion on a range of techniques and tools which
24
have been used to construct systems that deliver contextual services in pervasive computing environments. The chapter provides a discussion of key areas in contextaware pervasive services, inspiring the research presented in the next chapters. This chapter also discusses the different context-aware system implementations and the degree to which the solutions accommodate high level decision of systems. This chapter is organised as follows. Section 2.1 presents approaches to model a pervasive computing environment. Section 2.2 discusses a variety of location sensing techniques and briefly discusses location aware projects. Section 2.3 briefly discusses a number of techniques used to model context-aware systems. Section 2.4 discusses policy work in pervasive computing environments. This is followed in Section 2.4.1 by introducing a notion of context-aware regulated services and how it is different from existing projects. Finally, section 2.5 summarises the current state of the art of work done in location-aware systems, context-aware systems and policy based context-aware systems. It highlights a variety of shortcomings in the current development of contextaware systems, and provides solutions in relation to these shortcomings as part of the contributions of the dissertation.
2.1.
Pervasive Computing Environment Modelling
A pervasive computing environment, broadly speaking, consists of different types of boundaries: logical and physical boundaries. We define an environment as a collection of logical boundaries that contains one or more physical boundaries (e.g., library building that consists of several floors and rooms). In this dissertation, we refer to a logical boundary as a domain (e.g., a shopping domain, an entertainment domain, an education domain, a city domain, etc.). One notable project that describes environment modelling is the Spatial Agent Framework [Sat00; Sat04]. The Spatial Agent framework has a unified view of smart spaces that consists of mobile entities, devices and spaces [Sat05a]. It has decentralised database servers (e.g., portable terminals in the space) to support dynamic connection or disconnection of computing devices in an ad-hoc and peer to peer manner [Sat05b]. The
25
framework introduced a world model (called M-Space) that presents containment relationships between physical and logical entities such as computing devices and software components in the environment. In addition, it has a containment relationship between physical spaces (e.g., one building consists of many floors and one floor consists of many rooms). The floor is contained within at most one building and each room is contained within at most one floor. However, it has not addressed the logically grouping of the environment. Moreover, the representation of physical spaces is based on symbolic location modelling where a space is noted as a labeling of position to identify overlapping geometric location information (e.g., a mobile computing room). The symbolic location modelling is considered useful as it directly represents and maps the software based services with the physical space (e.g., display a service when a user is in the mobile computing room). Apart from environment modelling, there has been work on location semantics [JRG98; Hig03; Mat04; YIS06]. Location semantics indicate an activity that is most likely to occur at that location. For example, a restaurant is a place for dining. By knowing the location semantics, a system can identify users’ locations and their activities, suggest useful services which are related to the activities. The idea of grouping physical spaces into a logical boundary (domain) has not been addressed adequately. The lacking of a logical grouping of physical spaces has resulted in an independent view of physical spaces, which may not be related to other spaces. For example, a room may not be recognized as part of a floor or a building in a model, and instead, it is viewed as a room on its own. We recognize the need and convenience for logically grouping physical spaces, as it affects the scope of visibility of context-aware services (e.g., only in a particular space within a building). The grouping also minimizes redundancy in specifying same services throughout the domain level that may consist of several sub domains. For example, imposing services on the building that consists of floors and rooms makes the service visible for the entire building (including all floors and rooms within a building). In contrast, imposing a service on a certain floor, or a certain room, would make the service
26
visible only to the room within the floor or only the particular room, and we might need to define service visibility for each room in the building, one by one. We discuss in detail in Chapter 3, the need for modelling pervasive computing environments and an approach to model the environment (e.g., by having a logical and physical view of an environment). The proposed environment model captures characteristics of an environment element and illustrates a mapping between logical and physical spaces that is well suited for use in the implementation of context-aware systems.
2.2.
Location-Aware Systems
In pervasive computing environments, there is a variety of sensor devices embedded in the space (e.g., location, temperature, motion sensors, etc.). The environment itself can be indoor and outdoor environments. The scope of an indoor environment is inside buildings such as within floors and rooms. The indoor context-aware pervasive system is expected to monitor users’ current movements (locations) by employing indoor location sensing systems. The indoor sensing system keeps track of users’ movements from one room to another and one floor to another. Outdoor environments, on the other hand, consist of events that happen outside, rather than inside a building. For example, a user is in an open space, and walks in from one building to another. To keep track of users’ movements in outdoor environments, the outdoor system needs to employ outdoor location sensing systems (e.g., a global positioning system – GPS sensor system). This dissertation focuses on developments of context-aware services that target indoor environments (e.g., within a campus building, a shopping mall building, an airport building, etc.), though the general concepts and methodology are applicable to outdoor spaces. The dissertation discusses in detail on how to enable context-aware services in an indoor scope of an environment. As a result, this section presents some techniques that assist with indoor location sensing tasks and highlights several indoor location-aware projects that use location context. Outdoor location positioning systems are not discussed and it is out of the scope of this dissertation. Finally, we give a
27
comparison of the related location-aware projects by taking into account prominent features of location-aware systems such as how to sense a user’s current location, how to display service information to users, and target devices of the system.
2.2.1. Location Sensing Techniques Detecting a user’s location accurately plays an important role in context-aware pervasive systems. Ideally, a location sensing system could detect a user’s current location accurately and in a minimum amount of time (with minimum delay). A few wireless networks in an indoor environment are infrared, ultrasound, radio frequency, Wi-Fi, etc. They vary in terms of range, sensing speed, accuracy, cost and amount of bandwidth that can be transferred at one time [MLH05]. Four sensing techniques commonly used in an indoor environment are (a) signal measurements, (b) triangulation, (c) scene analysis and (d) cell proximity (as shown in Figure 2.1). The signal measurement sensing technique uses a dataset of signal strength measurements by observing radio transmissions (e.g., IEEE 802.11b networks) at many positions in a building.
RFID and Ultrasound
Signal Measurements
Scene analysis
Triangulation
Cell Proximity
Wi-Fi
= An indoor wireless network
Figure 2.1: Indoor Location Sensing Techniques
Some location sensing technologies that use signal measurements are •
Microsoft Research RADAR
A RADAR uses radio frequency (RF) for tracking users’ positions inside buildings (e.g., 28
floors and rooms) [BaP00]. RADAR locates a user’s position by recording and processing signal strength information at multiple base stations. It then estimates user location by propagating signals at the overlapping coverage of base stations. •
Ekahau Positioning Engine (EPE)
The EPE is based on signal strength and triangulation that maintains the dynamic information related to a user’s position [Eka00]. Ekahau consists of three main parts: the Ekahau server, Ekahau client and Listener-application. The EPE server includes a standalone manager application and a Java Software Development Kit (SDK) that can be used for tracking client’s position. The EPE returns location information includes X, Y coordinates, building, floor, room, or any user defined logical area. For example, when the user is in the mobile computing room (as shown in Figure 2.2), the EPE returns the following location information. Building = {Information Technology building} Floor = {Level 1} Room = {Mobile computing room} X, Y coordinates of the user in the room = (22, 23} Logical area = {Research area}
Reading Room
Meeting Room
Office
Level 2
Mobile Computing Room
Discussion Room
Office
Level 1
Information Technology building Note: = Research area
= Office area
= Discussion area
29
Figure 2.2: Physical Spaces in the Information Technology Building
In order for the Ekahau server to keep track of a client device, the Ekahau client software needs to be installed on a mobile client device. The listener-application refers to the application code that implements the listener interfaces (to obtain the location estimate, logical area and status) to accurately track wireless devices. The Ekahau server version 2.0 can detect up to 30 devices at one time and targets several devices such as: wireless PDAs, laptops and any 802.11b-enabled devices [Eka00]. •
PhD
PhD is an indoor location modelling project from Carnegie Mellon University that employs signal strength from wireless access points to obtain a user’s position [SSS00]. In order to acquire results with a higher degree of accuracy, PhD requires relatively more extra hardware on top of the ordinary Wireless LAN infrastructure. This contrasts with Ekahau, which is a pure software solution that does not need any extra hardware, apart from the ordinary WLAN infrastructure with at least three access points. The triangulation sensing technique uses geometric properties such as lateration (using distance measurements) and angulation (using angle measurements) in computing object locations [HiB01b; MLH05]. The disadvantage of this technique is that it often requires the emission of signals which can compromise privacy and require more power. Some location sensing technologies that use the triangulation technique are Active Bat [HHS99], VHF Omini directional ranging [LYH84; Vhf05], Cricket [PCB00], Easy Living [Kru00], E911 [Fed06], PinPoint 3D-iD [Els99; Pin02], Bluesoft [Blu01], PulsOn time modulated ultra wideband technology [Pul01] and Spot On [HWB00]. The scene analysis sensing technique observes a scene from a particular point in order to draw conclusions about location of objects in the scene (particular location) [HiB01b]. This technique senses the location of objects using a passive observation of objects in an environment that does not correspond to geometric properties (distances and angles). The disadvantage of this technique is that an observer needs to have access to a set of predefined features in the environment for comparing the observed object against it and requires a reconstruction of a set of predefined features data set when there
30
is a change in the environment. One notable location sensing technology that uses this technique is MotionStar [RBS79]. The cell proximity sensing technique determines an object when it is “near” or “close” to a known location. The object’s proximity is sensed using several physical proximity approaches such as detecting physical contact (e.g., using touch sensors), monitoring wireless cellular access points and observing the contact with automatic ID systems (e.g., location of credit card point of sale terminals) [HiB01b]. When the location is known, then the location of an object device can be inferred. Some location sensing technologies that use this technique are Active Badge [WHF92] for tracking users in the current vicinity in an indoor space, Cricket [PCB00], Avalanche Transceivers [Atk99], Smart Floor [OrA00], Automatic ID systems [KoD04] and Wireless Andrew [Hil99]. In general, different location sensing techniques would give different accuracies and delays in detecting a user’s current location. There are four location system properties that need to be taken into account in deciding on what sensing technologies to use [HiB01a; HiB01b; BeD05]: (1) Physical versus Symbolic. Physical positions use physical coordinates (e.g., 38 degrees 39’17’’N by 122 degrees 18’23’’W). In contrast, a symbolic location defines an abstract location where something is based on its positions. The symbolic location uses a meaningful location name (e.g., in the library, in the lecture room). This makes it easier for human to understand and remember the location. (2) Accuracy. The location sensing system must be able to detect a user’s current proximity accurately. (3) Cost. Low costs of installation and maintenance of location sensing systems are desirable. (4) Limitations. It is related to the difficulties or issues in installing and maintaining the location sensing systems. For example, Microsoft RADAR requires the wireless NIC card, Avalanche transceivers suffers from short range and unwanted signal attenuations.
31
2.2.2. Location-Aware Projects Location has been one of the most exploited forms of contexts, since the first emergence of context-aware pervasive systems. Such location projects are •
Tourist guide [CDM00] presenting location aware information to visitors based on their current proximity,
•
CybreMinder [DeA00] triggering an event based on a user’s location,
•
Cool town [KBM00] and Virtual tour guide [DCM99]. The Cool town project from Hewlett Packard also developed a location-aware system that makes use of the knowledge of a user’s location. An interesting aspect of this project is the creation of a mobile WWW infrastructure with respect to the user’s current location. As the mobile user walks towards the space, the relevant WWW pages are displayed on the user’s mobile browser.
•
The Virtual tour guide project uses a GPS sensor system to detect a user’s location in an outdoor environment [DCM99]. As soon as the user walks past or enters an area which is delimited by the GPS coordinates, a relevant stick e-note to a physical location is delivered onto the user’s mobile device.
•
The Stick e-notes framework was developed at University of Kent, Canterbury in 1997 [BBC97]. The concept of electronic stick-e notes is similar to paper based PostIt notes. The idea is to allow users to attach notes with specific context (e.g., location) and the note is triggered when the context is satisfied. For example, a user could type in a message and virtually assign the message to a specific location (e.g., room B538). The system then displays the message to users when they are approaching room B538.
Some other location projects are surveyed in [HiB01a]. A few notable location-aware projects that make use of the mobile agent concept in delivering location-aware services are the Mobile shadow project [FMP02], Hive [RMW99], and the Hodes system [HoK99]. An agent delivers services by downloading code from a server onto a client side or from one workstation (can be a server/client) onto another workstation. The agent performs information gathering and processing tasks autonomously in the background
32
with minimal user intervention. We discuss each of these projects in turn. The Mobile Shadow project focuses on prototyping applications for proactive cellbased location aware services [FMP02; FMS03]. Mobile Shadow employs mobile agent technology to keep track of a user’s location. The location aware service is implemented as mobile code that can be transferred from one device to another. To keep track of a user’s location, the system uses a cell based location approach. Hive is a distributed software agent platform that uses a combination of wearable and ubiquitous computing devices to implement location-aware services [RMW99]. In this project, the computation and information are shared between the environment and the wearable. Rhodes claims that implementing location-aware systems in both pure ubiquitous and wearable have presented fundamental difficulties. This is due to pervasive computing tending to have trouble with personalisation and privacy, whereas the wearable system has some drawbacks with localised information, resource control and management. Hive is a Java-based agent architecture that relies on the Remote Method Invocation (RMI) distributed objects and mobile code. The Hodes system [HoK99] also recognised the need to use mobile code in downloading a service interface and application into a mobile device. This system aims at providing variable network services in different network environments, which involves changing connectivity. Hodes introduced an open service architecture with minimal assumption about standard interfaces and protocols to support heterogeneous client devices.
2.2.3. Discussion In general, there are two different approaches that can be used to implement services for end-users: (a) The first approach is to implement a service as an executable application. The service application contains a service interface and information (data). The service needs to be downloaded and executed on a target device when needed. In terms of the mobility, there are two types of an executable application:
33
•
A standalone application is also known as a stationary application that is embedded (installed) on the target computing devices (e.g., a small client device, a desktop PC, a laptop, etc.). As a mobile device is very limited in resources (memory and processing speed), this approach is less resource smart. This design is not extensible, as we can not add more services in the future. This is mainly due to limited memory resources on mobile devices. In addition, it does not support reusability of services, as it is stored locally on the device (not centralized). The only advantage is that the service or code is there on the user’s device and hence, does not need to be transferred or downloaded. A sample location-aware project that implements this approach is CybreMinder [DeA00].
•
A mobile application (e.g., mobile code) that is usually stored on a server side and only downloaded onto a user’s device such as a desktop, laptop or mobile device when required. This application can move from one server to another, from one device to another and from a client to a server or vice versa. Example location-aware projects that implement this type of service are Mobile Shadow [FMP02] and Hive [RMW99].
(b) The second approach is to implement a service as an HTML Web page. It is mainly used for displaying information to users (presentation). Access to the service requires a Web browser and Internet connection. This design is simple and easy to develop. It also supports reusability of a service as access to the same service from Web browsers can be done by referencing to the URL site. This design is also extensible as Web pages are normally stored on the server side and so, developers can create or add new services in the future. The drawback of this approach is that an HTML Web page that is based on a simple markup language can not be used for complex programming operations (i.e., storing data locally, filtering, searching for local data, etc.). This is mainly because an HTML is not an object oriented language. It does not support an attribute, method or even simple programming logic and operations (e.g., if else statement, looping, etc.), and thus, limiting its ability for reusing some properties (i.e., attributes and methods from other classes) and performing complex Web features such as Web service and remoting. Some
34
location-aware projects that implement this approach are Tourist guide [CDM00], Cool town [KBM00] and Virtual tour guide [DCM99]. A comparison of the above location-aware projects is summarised in Table 2.1. Location
Context used Service
tracking Tourist guide
CybreMinder
Target device
application
Cell based
Location
An HTML web
Desktop and
location
information
page
laptop devices
RF location
Location,
Standalone
Desktop,
tag
user identity,
application
laptop, and
Mobile Shadow Cell based location
and time
mobile phone
information
devices
Location
Mobile code
information
Pocket PC and mobile phone devices
Hive
Locust
Location
location
information
Mobile code
mobile phone
beacon Cool town
Pocket PC and
devices
Location
Location
An HTML web
Laptop, Pocket
beacon
information
page
PC and mobile phone devices
Virtual tour
GPS sensor
Location
An HTML web
Pocket PC
guide
system
information
page
devices
Table 2.1: Comparison of Location-Aware Projects
2.3.
Context-Aware Systems
A context-aware system is more complex compared to a location-aware system, as it uses a range of context information (e.g., a user’s current location, day, time,
35
preferences, activity, mood, etc.). To address challenges in context-aware computing, concerning uncertainty, diversity and complexity of context information, research has started to investigate different aspects of contexts such as discovering, modelling, reasoning, and managing context [HKL99; Dey00; Cap03; Hen03; Che04; KhK05; Pad06]. The context-aware projects vary in terms of system design and implementation. They also range from small projects that may only target single users to large scale projects which can be deployed in pervasive computing environments that support many users. This section discusses existing context-aware projects which are closely related to the aim of this dissertation which is to enable contextual services in pervasive computing environments. The aspects that we are looking at are context information (e.g., a user’ location, a user’s identity, activity, etc.), techniques used to collect and interpret context information, as well as, operations to discover, deliver and execute contextual services on a user’s mobile device. Finally, we conclude this section with a brief discussion of existing context-aware systems. Several recent projects in a context-aware field are surveyed in [ChK00; Kor00; MeR03; EnB05; RJF06; Lok07]. Seven closely related context-aware research projects are discussed as follows. ParcTab was the first mobile computing application in the context-aware ubiquitous field [WSA95]. The ParcTab system was developed at the Xerox Palo Alto Research centre in 1992. This context-aware project was prototyped on the ParcTab, a wireless palm sized computer. The system provides automatic detection of the user’s current location. Based on this location information, the system may share the user’s information with other users which are located in the same building (i.e., the concept of the virtual whiteboard). The virtual whiteboard persists from meeting to meeting and follows users from room to room. An interesting aspect of this project is that the information adapts to the user’s current context. A user gets different types of information depending on the context that s/he is in. For example, when a user is in the kitchen, the printer button on the mobile device is invisible, but as soon as the user enters the printer room, the printer button is visible. In addition, context triggered actions are based on simple IF then rules or statements that specify what actions need to be performed.
36
The system has predicates or information about the user’s activity, for example, “Between 10 and 12 noon, when the user arrives at Tea room and using the Coffee machine, plays a rooster sound.” This action is detected using the badge system that is attached to the physical device (i.e., a coffee maker device in the kitchen). As soon as the system detects that there is a user using the coffee machine, a rooster sound is played. This project only discusses context and service aspects. An example of context-aware system that uses ParcTab as a terminal is Forget-Me-Not [LaF94]. It is a PDA based system that keeps track of where the user is, who s/he is with and what s/he is doing. The Intelligent Room project [Bro97] was developed by MIT research groups. The project aims to deliver services that could adapt to users’ current contexts. In order to do this, the project employed robotics technology with speech and vision recognition systems, and agent based systems. The idea is to capture users’ current activities by understanding their gestures and to track users’ current movements. Based on the information, the system then guesses relevant services for users. The proposed system only developed standalone applications that targets desktop PC users. In this case, the service is pre-installed on each client machine. GAIA was developed in the year 2000 by some researchers at University of Illinois, Urban-Champaign [RoC00; RHC02; Rom03; CMC04; CMC05]. GAIA is a middleware that aims to implement active spaces, where the focus is on the user. It aims to develop applications which are not bound to a specific device. These applications are associated with a user and have the ability to move with the user and adapt to changes in the environment. It has a system kernel that consists of six component management services (i.e., a context service, file system, component and space repositories, event manager, presence and security). GAIA uses CORBA with IIOP technology as the network protocol. GAIA is especially designed for use with mobile applications that need to be dynamically partitioned and migrated to various devices. However, to extend the GAIA system is a challenge. It requires the application programmer to know and understand GAIA’s scripting language LuaOrb. Several applications were developed using GAIA as a middleware such as ConChat
37
[RCR02] and Active Space [Sam05]. ConChat is a context-aware chat program that enriches communication between users by utilizing context information and resolving misinterpretation between users that could lead to a conflict due to different contexts using semantic rules. Active Space focuses on a context-aware security project that only allows authorized users to use and access resources in certain contexts. We discuss in detail the Active Space project in Section 2.4. Cyberguide is a project that is initially designed to assist visitors in a tour of the GVU (Graphics Visualisation and Usability) centre [LKA96]. It focuses on an indoor or outdoor (not both) mobile context-aware tour guide system. Cyberguide takes into account knowledge of a user’s location and a history of a user’s past location. The initial implementation of a communication module consisted of a wired Internet Appletalk connection from an Apple MessagePad through a Unix Appletalk Gate. The architecture consists of four components: (a) Mapping: it provides a map that illustrates places of attractions within a tourist information building, (b) Information: this component addresses the structured repository of information relating to objects. For example, information related to visitors and the interesting sights within a building that they may encounter during their visits, (c) Navigator: this component helps visitors navigate around places of attraction (e.g., by knowing the visitor’s current locations, the system is able to show (display) other nearby interesting sights, and (d) Communication or Messenger: it helps visitors send queries or comments regarding a place. CyberDesk is a framework that takes into account a user’s contexts in delivering right services [DeA97; DAW98]. It recognizes two properties in integrating software services: (a) From a developer’s perspective. A developer needs to predict all possible tasks that a user might want to perform in specific situations. (b) From a user’s perspective. The contextual services need to be relevant to the user’s current activities. For example, when the user is searching for a house (from Google
38
site), the suggested lists of services need to be relevant to the activity that the user is currently carrying out. The aim of CyberDesk is to support self integrating software components that help programmers by removing low-level details of contextual services. It also removes the necessity of users needing to understand how to make the different software components work. CyberDesk consists of five main components: (a) Registry. The registry is like a database that stores and maintains a directory of all components in the system such as an interface that an application can support, the functionality that it has and data that is provided. The registry notes down each new component that is added to the system and updates the database when the component is removed from the system. (b) Services. A service is an application that provides information or could perform actions as requested by users. There are two types of services in the system: (a) standalone such as finding a phone number or address. (b) part of a large application such as a concierge that consists of a hotel booking service, a restaurant booking service, a user’s daily plan service, an activity reminder service, and so on. (c) Type converter. The converter analyses a user’s context, converts the user’s current context to a predefined data type and suggests a list of useful services for this context. For example, a user that is currently in a room will be given a list of services that is just for that room. (d) Integrator. The integrator obtains from the converter a list of useful services that match with users’ current context. (e) User interface. After finding the relevant services, the services are then delivered onto users’ mobile devices. The interface is created by using an HTML and can be accessed from Web browsers from the CyberDesk Web page. On the Web page, there is a button associated with some data (information); clicking on the button will request the system to deliver relevant data. Currently, CyberDesk is unable to automatically determine services that an application provides. It needs to have a wrapper around each application to perform two tasks: register the service and execute the service when called. In addition, CyberDesk was
39
developed using Java programming language, the target application is mainly a desktop or laptop device. It does not target a small device (e.g., a pocket PC device). It explores the concept of chaining that suggests additional actions, services which are directly related or indirectly related to a user’s current context. For example, when searching for a user’s email address, more details are suggested such as the user’s name, location, occupation, interests, etc. By knowing a user’s name and mailing address, a new service can be created such as a phone number service that contains a list of users with their phone numbers. There are a few limitations with CyberDesk. The wrapper needs to be created for each new service. Only a limited set of contexts can be used. The system does not check dependencies between one service and another. For example, if the system could not find the user’s name, there should not be an option to further look for the user’s details such as phone or email address. Instead, the system needs to be context-aware. For example, by knowing that a user has been to this place, a general service such as introduction about the place should not be included. Instead, more advanced services which are related to the user’s past activities could be displayed. Another example is when the system has access to a user’s history file and could determine the most likely actions that a user would take. The system then could limit services only to those actions, suggesting services related to those actions. They have not measured the performance and delays of their system. The Context Toolkit project focuses on acquiring and sharing context among users. It was developed by some researchers at Georgia Institute of Technology [DSA99b; DSA01]. The project aims to provide a formalism of context at various levels of abstraction and a framework for building context-aware mobile applications. Context here is defined as any information that can be used to characterize entities. The meticulous approach of this system leads to its systematic design and structure. The Context Toolkit consists of three main abstractions: (a) Widgets: to collect context information (e.g., a user’s location or activity) from the sensor, (b) Aggregators: to aggregate the context. It can also be considered as meta-widgets, and
40
(c) Interpreters: this component tries to guess or sense the user’s current activities based on the information collected from the widgets. The Context Toolkit hides the details about how the context information is retrieved. Hence, applications do not need to know whether these context components are executed locally or remotely. All of the components share the common communication mechanisms, which is XML via the HTTP protocol. There are also a number of projects which were built on top of this generic framework: a. An in/out board that displays which member of a research group is in the building. b. An information display that shows relevant information to users standing in front of it. c. A context-aware mailing list that delivers email only to listed subscribers who are currently in the building. d. An augmented electronic whiteboard that records handwriting and audio when it detects the presence of users in front of it. The Context Toolkit project is implemented using Java programming language with some interfaces for clients in Flash and .NET. It also supports various types of devices (handhelds and wearable devices). However, its scalability is limited by its centralized architecture. To some extent, the Context Toolkit is useful for developing a process to acquire contextual information separate from the actual context-aware applications that use the context acquired. This is important as contextual systems normally deal with many types of context (static or dynamic contexts) and service applications which require some mechanisms to collect and interpret contexts which are independent from contextual system functionalities. There is one project done using the Context Toolkit as context inference engine: CybreMinder that reminds users based on the location, time or complex reminder structures [DeA00] Context Gateway is an ongoing project done by [Xia03] that aims to deliver contextaware mechanisms by exploring semantic context modelling in a pervasive system middleware. The design of Context Gateway consists of context modelling, context querying and resource discovery using the Web Ontology language that supports knowledge sharing, hybrid logic inference reasoning and context interpretation.
41
2.3.1. Discussion Most of the existing context-aware systems only employ a few context parameters. The most commonly used ones are a user’s location, a user’s identity and time. This is mainly due to the difficulty in obtaining, representing, interpreting and processing the context values. Most of the context-aware applications developed are still in research labs and academic world [Kor00]. They are not many context-aware applications commercially available yet. Again, this is due to the issues in acquiring context, complexity in implementing context-aware applications that take into account various contextual components (e.g., a context collector, context interpreter, service manager, service discovery, service delivery, etc.), dynamic, and heterogeneous nature of context-aware pervasive computing (e.g., many users, services and target various computing devices).
2.4.
Policy based Context-Aware Systems
Many existing policy projects focus on implementing access control in the field of distributed Internet systems [GoM02; UBH03; San98; YLS96; DDL01; MBH00; MoS93; Edw96; Hen05; KeC03; MoS93]. A policy defines a set of activities that authorised users can perform (permission), can not perform (prohibition) and must perform (obligation) within an organization depending on the position or level that the user has. For example, a boss can read and write a meeting document; however, staff can only read the document without being able to modify it. In Role Based Access Control (RBAC), users are assigned roles and roles determine permission that users can do. Traditional RBAC does not take into account context information. Zhang and Parashar [ZhP05] presented a dynamic context-aware access control mechanism by extending the traditional RBAC model [GKF01]. They presented a model that dynamically adjusts role and permission assignments based on current context information. This is done by assigning each authorized user in the system a role subset from the entire role set. In the same way, services and resources in the system are assigned permission subset for each role (and its role subset). To select relevant access
42
control based on the context, the system navigates the role subset (the subject) and then, iterates the permission subset (the object) for that particular role. The maintenance task for this model can be quite tedious, especially if there are a number of services in the system. This is because, developers need to assign certain permission (based on the role) on each of the service. In some occasions, in pervasive systems, users with different roles may have the same permission. For example, a student (with a general user role) and a lecturer (with a super user role) have the same permission to access sample examination questions during lecture time at lecture room B.123. In this case, assigning permission on each service (resource) can be redundant and may not be necessary. In addition, the same service may have different policy specifications depending on the space and activities running in the space. The dynamic access control model as proposed in [ZhP05] does not support this mechanism. The same permission is imposed on the service regardless of spaces (or activities running in the space). We want some flexibility in accessing services (e.g., due to some events occurring in room R1, user A is not allowed to execute service S. However, the user is still allowed to execute service S in room R2). The permitted action depends on the activity that is currently running in the space. The existing policy projects do not take into account proactivity and adaptation of policy in the environment. It requires more user interaction prior to deciding relevant policy information such as a user needs to manually log on to the system and explicitly request permission to perform certain actions. This explicit interaction does not support the aim of pervasive computing that is unobtrusive and proactive in delivering useful contextual services to mobile users. There are some notable existing policy work in pervasive computing environments, however, they focus on different types of context such as context of an agent [SBM03; MCL05; MoT02; CML00], networking [LLS04; ZGL03; Wie94; CCC03], authorization [CLS01; ZhP05; GKF01; GiI97; MCA00; FSC96] and security [KFJ01; CFZ02; MRC03; NoC02; TAK04; MIT04; CMR02; BeS04]. There is a little policy work done in
43
pervasive systems, especially in the field of context-aware pervasive services. Nine closely related policy projects that deal with users’ contexts are discussed as follows. The Automatic device project [CoK04] discusses a preliminary architecture for automated device configurations in smart computing environments. It takes into account context of users (e.g., location, identity and preferences). Users need to register their set of preferences in the system (e.g., what actions or activities that they wish to perform in particular context). Based on this information, a system then proactively performs actions or tasks as specified in the preference list. For example, by sensing a user’s current location (e.g., walking towards a cinema), the system automatically switches the user’s mobile phone to a silent mode. When the user walks out of the cinema, the system switches back the phone to a normal mode (ring tone mode). In addition, the system recognizes two sources of policy documents: from a user’s preferences and from a space (e.g., a cinema). As a result, there is a high chance of conflict occurring. This is mainly due to the space trying to limit the user’s activity (action) that is often contradicted with the user’s preferences. For example, a cinema entity sets a rule that prohibits users from switching on the mobile phone, while in the cinema. Users may have different specifications (e.g., turn on the mobile phone while I am in the cinema, as there may be an urgent incoming call). The project has not identified and addressed techniques used for resolving the conflicts. It only discussed several guidelines for resolving conflicts such as conflicts need to be resolved in a minimum amount of time with less user involvement. It also identified possible issues for resolving conflicts (i.e., when conflicts need to be resolved, how they should be resolved and where policy resolution logic resides). The Satchel system [FPJ00] provides mobile access to documents via services. The service is aware of a user’s current location. For example, when a user is in front of a printer device, Satchel presents a printer service. The service is accessible to users via Web browsers (i.e., using HTML) for desktop PC users and mobile Web browsers (i.e., using Handheld Device Markup Language – HDML [Han97]) for mobile phone users. Satchel employs policy mechanisms to securely access to documents (information). This is done via tokens issued by a Satchel browser and these tokens are signed using public
44
key cryptography. In this case, Satchel uses two keys, one public (i.e., available to any user who wishes to access the service) and one private (that resides in the user’s browser). The current prototype system only focuses on the location context. It has not taken into account other contexts (e.g., day, time, and activity running in the space). The access control is based on a simple database. The database stores a list of users with certain permission (e.g., read, write and execute) to work with documents. The permission given is relatively static and only depends on the user’s identity and location. In this case, the permission remains the same regardless of days, times and activities which are running in the space. The policy document only contains permission information, it does not contain obligation of what users or the system needs to do in certain contexts. The policy based agent model [HAK03] proposed a system that supports personalized multimedia services to mobile users and provides them with a home like environment at any visiting place. Each registered user in the system has an agent that stores, manages, maintains and enforces the user’s specifications of what, how and when to execute the service. A policy contains a set of actions that needs to be performed by a subject agent on the specified target services, providing the conditions have been satisfied. The user only needs to specify one policy document which is a home policy. This policy will be applied globally to any place that a user visits based on interagent negotiation. The system used MicMac for interagent communication which provides an environment capable of handling and dealing with multiagent interaction and negotiation protocols. The negotiation protocol starts when a user moves to a different place (e.g., from room A to room B). Once the system detects a user’s current proximity, an agent creates a proposal according to the user’s home policy (specification), and then submits it to the agent at room B. The proposal here consists of a set of elements (services or resources) which are associated with specific parameters (e.g., cost of CPU speed and bandwidth, quality of service and time). The agent at room B then evaluates the proposal until the agreement (final decision has been reached) such as whether or not to agree with the proposal from agent A or even a negotiation deadline (if the submitted proposal
45
is not agreed on). If agent B does not agree with agent A’s initial proposal, agent A then re-generates a new proposal based on its policy-based strategy in order to satisfy requirements set by agent B and re-submits this new proposal. The policy agent project is too specific to multimedia services. It has not taken into account other types of services (e.g., shared resource services) that involve concurrent access from more than one user. It has different specifications of cost and quality of services from multimedia services (e.g., a printing service, teleporting service, etc.). The project also has not discussed how run time modification of a user’s home policy is supported. Moreover, performance evaluation (user wait time) such as how long it takes to negotiate or re-submit a new proposal was not discussed in detail and the use of a caching mechanism to keep the service agent for future requests has not been explored. The current prototype system also has not supported any contextual information and so, the agent is not able to adapt the system behaviours to any users’ current context. The purpose of security control in the Active Space project [SNC02; Sam05] is to ensure that entities (e.g., users) only use and access resources (e.g., devices) in authorized ways. The space is shared by different groups of users for different purposes (activities). Each virtual space is configured for a particular activity. These virtual spaces may have different policy requirements. Active Space aims to allow seamless transitions between virtual spaces and applying the relevant policies. Active Space supports different policies for different virtual spaces depending on users and the activity that is currently running in the space. It implements the policy model in a form of role-based access control, which can support both mandatory access control (MAC) and discretionary access control (DAC). RBAC simplifies policy administration by dividing the task into two parts: a user-role assignment and a rolepermission assignment. A MAC policy applies to space default devices (e.g., embedded devices) and is specified by the system. The MAC policies for the space (room) are required for sharing equipments securely between authorized users. This is imposed on all users in the room (e.g., ordinary users are not allowed to disable system logs). A DAC policy is specified by the end-user who owns a personal device. It specifies how a device should behave in a particular context. Users may have privacy requirements that
46
may conflict with the room policies and this needs to be detected and flagged. The system also supports three types of roles: system, space and application roles. All roles must be mapped to space roles in order to ensure consistency. In Active Space, a service is used to control access to devices in the space. The service makes sure that only authorized users are allowed to use and access the devices and resources. For example, only a presenter can access and control the power point presentation slides and a student is only allowed to read the slides (not to control). Active Space recognizes four different modes (i.e., an individual, shared, supervised and collaboration mode) to handle users’ requests for accessing shared resources. This mode is maintained by the space. There are also several things that have not been explored in the Active Space project such as types of possible conflicts that may occur between system, space and a service; techniques used to detect and resolve conflicts; and the performance for policy authorization decisions. Ether [ArM04] aims to secure communications in the Smart Home by having a policy embedded in each device. This project focuses on access control to devices and levels of authorization for each user. The access control is based on public and private keys, in which all legitimate users own a public key of a device. It is not based on RBAC (Role Based Access Control) and therefore, there is no notion of hierarchical roles in deciding what permission to give to certain users. There is a mapping between a public key (e.g., an owner of a public key and a list of users who know the public key), security context (e.g., only valid within certain time – duration) and permission to devices which are allowed (e.g., access to printer machine). The idea is that only authorized users could access devices by providing their public keys. These authorized users can also delegate access to unauthorized users (e.g., visitors). For example, an owner walks into his/her office and wishes to control a lighting appliance by using his/her wristwatch. There is a security association between computing devices and users in the environment. When a visitor walks into a house, an owner of the house can choose to delegate the access right to the visitor (e.g., full or half access (lesser extent) than the permission given to the owner). In addition, the owner that acts as a parent can also limit access to the kids (e.g., only allows to watch TV after 8PM
47
or between 8-9PM). This project only associates permission between users and devices. It has not imposed any obligation and prohibition on users or systems. It also only addresses a fixed number of users in the environment. In general, there is a limitation of using a public or private key, where we have to assume that all devices come from their manufacturers with built in public key pairs. Cerberus [MRC03] is a ubiquitous security policy mechanism that integrates context-awareness with automated reasoning for preventing unauthorized access to resources in ubiquitous computing environments. It aims to develop context-aware security policies unobtrusively in ubiquitous environments. Cerberus consists of three major components: (1) Service access (authentication and authorisation), (2) Security policy documents, and (3) A reasoning engine that performs automated reasoning and enforces security policies. The inference engine authenticates users by assigning a confidence level based on the authentication policies. It also evaluates requests or queries from resources (applications) to decide whether a certain entity has access to resources. Each resource in the system has specific policies. The inference engine evaluates policies to determine whether a user has permission to access resources based on the current context, the confidence level of authentication and the role of a user. It discusses several authentication mechanisms such as wearable devices, voice and face recognitions, badges that contain identification information, finger print identifications, retina eye scans, and etc. Different levels of authentications are represented with a range of confidence values (from 0 to 1). The confidence values show how confident the system is about the entity. It proposed a federated authentication service that uses distributed, pluggable authentication modules (PAM). The PAM is an independent authentication module that separates an application from an authentication system and devices. The security mechanisms in Cerberus make use of first-order predicate calculus and boolean algebra. There are two kinds of policies in Cerberus: one is used to authenticate users (when logging on to the system) and another to decide access control to a particular
48
service in ubiquitous environments (e.g., whether a user has access to resources in the system). As it uses confidence values to determine security mechanisms, policy decisions can use the confidence information for specifying access to resources. In Cerberus, different policy decisions are applied depending on the context. This is done by having a callback method, so that when context changes and the existing policy is no longer valid (has changed), the system gets notified in order to update the service. Cerberus does not take into account the notion of rights, prohibitions, and obligations (by a system or user) for specifying policies. Moreover, it only controls services and tasks that users can perform on central devices (e.g., a desktop PC). It does not address access control to services which are running on a user’s mobile device. It also only exploits one type of service (i.e., a presentation service). The Spatial policy framework [SBM03] aims to control execution of a mobile agent in pervasive computing environments. Depending on the location that a user enters, a mobile agent has different states of executions. The state of an agent is specified by a user’s policy. In this case, each user specifies agents that need to be started or terminated at certain time and location contexts, as well as actions that need to be performed if there is an external agent that comes across the place (e.g., an action can be to continue the execution or kill the external agent). The framework also defines a concept of role. The role refers to a position of a user in the system (e.g., a boss, manager or staff). In the case of conflict between users that have the same role, a system seeks policy resolution from a user with a higher level of role. In this case, a boss which is the top level of hierarchy can write a policy to override other users’ policies. However, this project has not incorporated support for mobile devices. The portable device that is used in this project is a laptop. This project only focuses on the development of a security policy language that restricts behaviours of mobile agents. The Rei Policy Language was developed by some researchers at HP Lab [Kag02; Kag04]. The aim of the Rei policy language is to provide flexible constructs based on deontic concepts [Mal26] that are reusable across domains (such as networking and access control security). Task Computing [MCL05] uses Rei [Kag02] as a policy engine for enforcing the authorization decision (e.g., whether to permit or prohibit a user from
49
the requested action to use a printer at Fujitsu Lab). Trust Context Spaces [RoB03] focuses on security in pervasive computing environments. It aims to provide and maintain trust based context spaces in an interactive environment. The proposed solution is monitoring user and environment contexts, and acting implicitly based on the context changes (explicit parameters of physical human-human interaction). The resources (information or data) are only available to authorized users in the right context. For example, consider a meeting that consists of a group of people and various tasks: three audiences, one presenter and one narrator. The meeting discusses private and confidential business plans, which are limited only to those people. When an unknown user enters the meeting room, ideally, the managers need to be notified (e.g., by sending an alert reminder that the meeting needs to adjourn and all important documents needs to be closed). At the same time, it also needs to automatically notify devices such as a desktop that is running Power Point presentation slides and printing devices. All devices need to be automatically closed. To solve this issue, they came up with an idea to use context information to generate symmetric keys between peers. The trust context space architecture consists of communication, context-management, entity mapping, policy management and trust service management. The policies are specified and enforced per entity as well as per environment. It also includes an introspective policy that describes an obligation of a user in specific contexts. The trust service management component controls the invocation of services and handling authentication, authorization and confidentiality in accessing resources. However, the integration of policy documents has not been addressed in this project.
2.4.1. Discussion Many existing projects focus only on one or a few elements of a pervasive computing system as discussed in Sections 2.2, 2.3 and 2.4. Some existing projects only focus on the location context, contextual service and policy information. Only a few projects focus on a combination of the following context-aware system elements: a user context, 50
contextual service and contextual policy. Two notable projects are GAIA [RHC02] with Active Space [SNC02] and Cerberus [MRC03] with Rei [Kag02]. We discussed earlier GAIA as a middleware by itself. Now, we discuss the Active Space project that uses the GAIA framework. The policy here is used to control access to resources by manually installing policies on each physical device in the environment. It is limited to controlling access to devices per active physical space. The Cerberus system that employs the Rei policy language emphasizes on controlling access to physical devices in the environment. Both the Active Space and Rei projects do not address how context and mobile services are used together with the policy to control access to devices and resources via services in pervasive computing environments. The system for context-aware regulated services proposed in this dissertation is unique as it is not only able to deliver contextual services, but also contextual policies. The policy itself is context-aware, in which, different policies are applied (enforced) in different situations (contexts). For example, our system only prohibits students from accessing a lecture note service during exam time at the exam room. Some other times (before and after exam) at the exam room, the user can see and access all services as per normal. Our model to some extent has a similar philosophy to the Active Space and Rei projects, since we aim to develop a policy language to control users’ access in pervasive computing environments. However, we focus more on controlling access to contextual services by permitting or prohibiting users’ behaviours in accessing services in specific context. The policy in our work determines what services one can see and access in particular context, and the applicable policy, not just services, depends on the user’s context. Our contextual policy is also different from Active Space and Rei projects, in which, a space owner can specify a set of rules that controls entities (e.g., visitors’ behaviours) in accessing services in the particular context in his/her space (e.g., his/her own room). This is possible by creating a space policy for the particular room that specifies when, where and what type of services the owner of the room permits, obligates, or prohibits other entities from doing so. In addition, a user can also impose a certain task on the system to automatically perform. The execution of this task needs to comply with the
51
permission given by the space. Having introduced the concept, design and operation of a system for context-aware regulated services, we present a model that illustrates the operations of such a system in the next chapter. This facilitates a discussion on the high level modelling of contextaware pervasive systems, interactions between contextual software components and an infrastructure that supports the aim of pervasive services.
2.5.
Summary
In this chapter we have discussed requirements, frameworks, and operations of contextaware services in pervasive computing environments. The system of context-aware services requires support for adaptive, proactive and spontaneous delivery of contextual services onto clients’ devices. The current systems of context-aware pervasive services do not represent, in abstraction, pervasive computing environments. They do not provide the notion of logical space boundary and does not cater for extensible spaces in the environment. The developments of context-aware systems present an opportunity for realization and extension of current context-aware pervasive services. This is done by providing a context-aware regulated architectural model for governing users’ behaviours, which are considered necessary for such context-aware pervasive systems. We have presented a general model for context-aware regulated services that is consistent with the operation of context-aware system environments. This model will be the focus in this dissertation and will be further explored. In this context, we have examined the techniques/mechanisms for discovering and delivering contextual services that exist in various context-aware service frameworks. The framework provides an underlying basis for specifying context and delivering services between clients and service managers and the message passing for this exchange. However, it is the service managers’ responsibility to provide and deliver only relevant services to users (depending on their current contexts). In this context, we examined related research in policy languages to determine their applicability in a
52
context-aware pervasive computing. The focus of context-aware policy language has been on the specification of a context-aware service task rather than specification of capabilities, preferences and role associated activities that a user can have in pervasive computing environments. In terms of the infrastructural requirements in pervasive computing environments, we examined the issues of integrating policy language into context-aware services, especially the issues that affect visibility and execution of contextual services in the context of convenience versus compliance aspects of end-users. We also examined the reusability of policy language across spaces and entities in pervasive computing environments. We evaluated the proposed context-aware regulated system in terms of the purpose and architecture with respect to its ability to constrain and control access to resources in the specific context. While the existing policy models support access control to devices in pervasive computing environments, they do not support access control to contextual services in the environment. In the following chapters of this dissertation, we present a novel context-aware regulated services model for supporting context-aware services requirements, along with a context-aware policy specification language for controlling users’ behaviours in accessing contextual services in pervasive computing environments. As shown by the discussion in this chapter, the two major issues of environment modelling and infrastructure must be addressed to successfully enable a context-aware regulated services system. Building context-aware regulated services motivates the research presented in this dissertation. The next chapter presents our high level view of environment modelling, contextual service and policy modelling to support delivery of context-aware regulated services in pervasive computing environments.
53
CHAPTER
3
3. Issues and Conceptual Design for MHS
As discussed in Chapter 1, our pervasive computing system consists of entities (e.g., mobile users and software clients), logical boundaries (domains), physical boundaries (spaces), contextual services, policies and computing devices. A pervasive computing environment is dynamic; a new domain, space or sub space can be added to or removed from the system. A mobile user is an end-user who is always on the move. In addition, sensing devices and software systems can be embedded everywhere in the environment. The software systems can be a server component that resides on a server side and a client component that is installed on a user’s mobile device or embedded in objects (e.g., wall, fridge and so on) in the environment. The client component responds to users’ requests by interacting or communicating with server components. The idea is to provide autonomous and proactive systems that could suggest and deliver useful services as soon as users step into a particular space in the environment. The discussion in Chapter 2 concluded with the motivation to include policy (rule)
54
for controlling users’ behaviours in accessing services in pervasive computing environments. This is mainly due to, a pervasive computing environment consisting of many users who are always on the move and can access services at any time and any location. In some situations, the system wants to limit users’ behaviours by specifying policies. This avenue imposes new requirements and constraints that challenge the development of context-aware regulated services. We have discussed the requirements for developing context-aware pervasive systems in Section 1.2.1, Chapter 1. From our investigation of context-aware architectures and systems in Chapter 2, it was found that context-aware regulated systems that control visibility of services, as well as users’ behaviours in accessing services are useful for operation in dynamic and heterogeneous environments, where services are aware of users’ contexts. This is especially important as more than one mobile user can access and control services running on public devices. The public device is a shared device that is accessible to all authorised users in the system. This then results in conflicts, if there is no proper management in terms of who, what and when services can be accessed. In this chapter, we present the Mobile Hanging Services (MHS) model that addresses the requirements of systems for context-aware regulated services in pervasive computing environments. We have published the concepts, architecture and modelling of the MHS system in [SLS04a; SLS04b; SLS04d; SLS04e; SLS05; SyL06a]. Our MHS explores user-centricity, context-sensitive information, service-awareness, policyawareness and a pervasive computing environment model, in order to provide contextaware regulated services for users with minimal or no effort for service set-up prior to use. It is a context-aware regulated services framework that assists developers with development of context-aware services along with policies for controlling visibility of services, as well as access to services in certain contexts. This chapter is organised into the following sections. Section 3.1 discusses the MHS view of pervasive computing environments. Section 3.2 introduces a high level abstraction of the MHS framework and discusses its software components. Section 3.3 discusses criteria that need to be considered when modelling context-aware services, contextual service issues related to the design of context-aware services, and the
55
lifecycle of context-aware services (especially, in the MHS system). Section 3.4 discusses the MHS context-aware policy model. It discusses aspects that need to be taken into account when designing policies, roles of policies in pervasive computing environments, and challenges in integrating policies with context-aware systems. This section also presents the MHS policy language notation in extended Backus–Naur form (EBNF) format [Sco93]. This section further discusses different types and sources of policy conflicts, as well as techniques used to detect and resolve policy conflicts in pervasive computing environments. This chapter is summarised in Section 3.5.
56
3.1.
The MHS View of Pervasive Computing Environments
In MHS, our view of an environment consists of logical boundaries (domains) and physical boundaries (spaces). A domain represents a logical boundary of an environment that is not perceptible. A domain is considered as a top level hierarchy of an environment followed by spaces and sub spaces. Our view of a pervasive computing environment is not only limited to one domain (see Figure 3.1). Instead, users can move freely between spaces, which have been grouped into a domain. For example, an office building belongs to a campus domain and an entertainment room belongs to a home domain. MHS Pervasive Computing Environments has domain Campus Domain
Home Domain
Shopping Domain
New Domain
has space Office building
Lecture building
has sub space
Alice’s office at home
Entertainment room
= Has domain
Alice’s office at Campus
Bob’s office = Has space/sub space
Figure 3.1: MHS Pervasive Computing Environments
Samples of domains are a campus domain, shopping domain, home domain, etc. (as shown in Figure 3.1). These domains offer unique services that differentiate them from each other. For example, services within a campus domain are related to education purposes that target students and staff; a shopping domain is related to shopping (buying/selling) items that targets buyers and sellers. A domain can contain zero or more (sub) domains. For example, different types of parks such as Rose Garden, Natural Park are considered as sub domains of a park domain. A domain also consists of one or many physical spaces (see Figure 3.2).
57
has sub domain
0..* Pervasive domain 1 1 has
1..* Space
has sub space
0..* 1
Figure 3.2: A Pervasive Computing Domain and Its Spaces
A space is a physical location (boundary) that is conceivable (e.g., a building, a lecture room, a railway station, etc.). A space contains zero or many sub spaces (e.g., a building space consists of several sub spaces: floors, rooms, corridors, etc.). A user can move between spaces in the same domain or move to different domains. For example, at time t1, a user can be at a lecture room (within a campus domain) and at time t2, the user moves to a grocery shop within a shopping domain. A space needs to be associated with at most one domain. Each space has its own policy (also known as a space policy). The scope of this policy is valid within the space. The types of system elements contained within a domain are the same as those in its sub domains; however, it is different from other domains. For example, in a shopping domain, the types of user elements are buyers and sellers. In a campus domain, the users are students, lecturers and staff. Our system also recognizes different roles of users depending on a domain and space that s/he is currently in. For example, a user has a student role in a campus domain, but when s/he moves to a shopping domain, the user takes on a different role (e.g., a buyer). With our conception of an environment, we can draw logical interconnections between similar physical spaces in the system. For example, for a house domain, there is a logical interconnection between different types of houses (e.g., a villa house sub domain, residential house sub domain, etc.). The idea is that mobile users do not need to manually specify their locations to the system when accessing services, instead, the
58
system needs to proactively detect the users’ current locations and find the mapping of relevant services for users in that particular context. We recognize two types of logical boundaries in pervasive computing environments (see Figure 3.3): (a) Based on a geographical boundary Physical spaces within the same scope (area) can be grouped into one logical boundary. For example, buildings such as a council building, shopping building, library building, etc. which are located in the city, can be grouped into a “city� domain. In addition, we can also have a suburb domain that consists of spaces which are located in the suburb area. (b) Based on an organisational boundary This refers to tasks/activities that occur within an organization. For example, in a campus domain, services are related to education. In a cinema domain, services are related to entertainment. In a shopping domain, services are related to buying and selling goods. 0..*
has sub domain
Domain
1
Geographical Domain
Organisational Domain
Figure 3.3: Logical Boundaries in Pervasive Computing Environments In addition, there are five techniques used to represent physical spaces in pervasive computing environments [Bec04; BeD05]: (a) Geometric location model This is based on X and Y coordinates. This model is required for accurate positioning, where an exact direction or position is used. The modelling is simpler, precise and accurate in specifying locations and distance. However, it is not very intuitive in
59
describing spatial relationships and difficult for humans to understand the corresponding location by knowing its coordinates. (b) Symbolic location model The location modelling uses a meaningful location name, instead of X and Y coordinates. For example, a lecture room, laboratory room, library building, etc. This makes it easier for humans to understand and remember the location. It uses a domain name as a prefix in case there are two different buildings referring to the same physical space (e.g., CampusDomain//Library Building//Lecture room A1.23). The ‘//’ denotes a separator of logical/physical boundaries. However, this modelling technique is not as precise and accurate as geometric modelling. (c) Hierarchical location model This technique models physical spaces as hierarchical spaces. For example, a room within a floor, a floor within a building and a building within a campus domain. This model is very intuitive in expressing spatial relationships. However, it is not precise (compared to coordinates) and accurate in specifying locations and computing distance. (d) Hybrid location model This model uses a combination of hierarchical and geometric locations to model physical spaces. One notable project that uses this technique is the AURA Location Identifier (ALI) model [JiS02] that consists of hierarchical names followed by a set of coordinates to identify an exact location within a hierarchical space. The ALI model can be used to represent a physical space in the hierarchy (e.g., a seminar room on the first floor in building H – ALI://BuildingH/FirstFloor/Seminar room); to represent exact coordinates (e.g., a location of a front door of a seminar room at the first floor in building H – ALI://BuildingH/FirstFloor/Seminar room#(12,38,68); and to represent a specific area within a hierarchical space (e.g., a room booking office of a seminar room at the first floor in building H – ALI://BuildingH/FirstFloor/Seminar room#{(12,18,68), (1,5,8), (3,6,8),(5,3,8)}). (e) Semantic location model
60
With this technique, a location is expressed in a human understandable form and yet, can be efficiently processed by software systems. It processes a semantic query with keywords like “near” and “contains”. Our MHS system uses a symbolic representation of an environment. We have a symbolic name for each domain and space. For example, we have a campus domain that has several buildings such as a library building, a lecture building and a bookshop building. In our system, services, resources (e.g., computing devices) and policies are mapped against the symbolic name of domains or spaces, rather than geometric coordinates of the spaces. The mapping against symbolic names of domains/spaces, supports re-mapping of services, resources and policies in a new environment. For example, an old IT faculty is in building B and it is now moved to building H with a slightly different floor plan. The mapping can be done by re-mapping the new spaces in a new building against existing services, resources and policies. Hence, a mapping of services to the IT faculty remains the same, but the mapping from the IT faculty (i.e., a domain) to its physical spaces is revised. In addition, depending on how much difference there is between the old and the new buildings, the existing mapping of spaces, services, and policies could be used immediately, or re-structuring of spaces is required to reflect the existing mapping (e.g., grouping several spaces into one, or partitioning one space into several sub spaces). Ideally, to users, they do not need to know about this re-mapping. When they enter the faculty of IT in the new building (i.e., building H), they would still be able to see services as in the old building. Moreover, there exists a set of computing devices which are embedded or installed in the space and a group of users who move in or out of a space. Each physical space in the environment may offer different sets of services depending on the space purposes. For example, a lecture room offers a set of services that is related to education (e.g., teaching and learning). In general, we recognize three types of spaces in pervasive computing environments (see Figure 3.4). (a) Permanent physical space: the space structure is fixed and does not change over time.
61
(b) Temporary physical space: the space structure changes from time to time to suit users’ needs. (c) Mobile physical space: a physical space can move from one domain or sub domain to another domain or sub domain. For example, an ambulance car is considered as a mobile space of a health care domain. When it moves from a health care domain to a hospital domain, it then becomes part of the hospital domain.
Library building Room 1
Room 2
Room 3
(a) Permanent physical space Library building Room 1
Room 2
Library building
changes to Room 3
Room 1
Room 2
(b) Temporary physical space Domain
Space
Domain
Mobile space
Moves to another sub domain
Sub domain
Mobile space
(c) Mobile physical space
Figure 3.4: Different Types of Spaces in Pervasive Computing Environments In our MHS system, we only deal with a fixed space (a permanent physical space). This is to simplify our environment modelling, as fixed spaces require less maintenance compared to temporary and mobile spaces. The fixed physical space only needs to be registered once with the system. In contrast, temporary and mobile spaces require registration and deregistration when changes occur (e.g., when the existing space is removed or a new space is added to the system). 62
The mapping between a domain and a space is represented in XML. We presented a template that shows a domain, sub domains, spaces and sub spaces mapping, as well as details of the domain and the space (e.g., environment ID, environment name, environment description, category, policy, services and devices in the environment) in Figure 6.4.
3.2.
Overview of the MHS Framework
The MHS system provides end-users with relevant services (information) as permitted by a space. A service is a contextual software component, where the visibility is regulated by a policy. The relevant policy is selected based on the current context information such as a user’s current contexts (e.g., a user identity and location), and environment contexts (e.g., day and time). In addition, there are four major building blocks of the MHS system: .NET component management core (i.e., a Web service library, .NET Common Language Run Time, VB and C# managed code libraries), MHS software components, computing devices (i.e., sensor devices and desktop/mobile devices) and MHS services (as shown in Figure 3.5). The MHS application framework contains six basic system elements: context-aware service component, context-aware policy component, system repository, message passing (interaction) component, system manager and remoting service. In our model, these basic system elements will be the same in any pervasive computing environments (e.g., a campus domain, a shopping domain, etc.), but the information about contextual components (e.g., space rules and resources information), services and computing devices used can vary across systems in different pervasive computing environments.
63
MHS Services Computing Devices ContextAware Service Component
ContextAware Policy Component
System Repository
Message Passing (Interaction) Component
System Manager
Remoting Service
MHS Software Components
.NET Component Management Core
Figure 3.5: High Level Abstraction of the MHS Framework The MHS framework itself is generic that it supports different types of services from traditional applications (e.g., a stand alone media player application that is run on a desktop machine and does not have built-in context sensing ability) to context-aware services (e.g., a navigation service that adapts to a user’s contexts). The context-aware services are built on top of an existing MHS framework while others (e.g., traditional applications) are extensions to the MHS system. The system, via a remoting service and a context-service mapping, turns a non-contextual (traditional) application into a context-aware application [SLS04b; SLS04d]. The system also adds rules for governing users’ behaviours in accessing these services (context-aware regulated applications) [SLS04e; SyL06a; SyL06c; SyL07b]. The system relieves developers from the low-level task of finding matching services with locations as it handles the computing of a set of relevant services given contextual information about users. The system provides important abstractions for delivering, downloading and executing services. It also hides details of interactions with remote services from mobile users. The downloaded service provides a service interface for controlling the running service from a user’s computing device (e.g., a laptop or a pocket PC device). Users do not need to know or have any knowledge of where services reside, how to call services, what service APIs to use and how to execute services once they are downloaded. All these low level tasks are handled by our system via a software client (i.e., a mobile client manager) that resides on the client side (e.g., on a user’s laptop or a
64
pocket PC device). The software client monitors users’ actions, displays services and implicitly communicates with context-aware server components (i.e., contextual service and policy components) on behalf of users. In designing a context-aware system, we take into account information about environments, entities, software systems and computing devices. Sensing a user’s current contexts, the system computes a list of useful services and this list “drops” onto the user’s computing device. When selecting a service to use, the required software for utilizing the service automatically sets up, effectively “pulling” down the required service. As the user’s context changes, the list of services is automatically updated on the user’s mobile device and the downloaded code managed with respect to limited device resources. Context-sensing is particularly important if the system is to give the user the impression of adaptive and proactive behaviours and the use of mobile code [SLS04a] is important in enabling services that can be used (almost) immediately without the burden of effortful set up. The next sections discussed in details designs of two core software components in the MHS system: context-aware services and context-aware policies.
3.3.
The Design of MHS Context-Aware Services
The notion of service suggests software systems for providing assistance to users to complete their daily tasks, such as automatically configure a printer according to a user’s profiles (e.g., print document in single sided using a colour printer). Such manual tasks can be handled implicitly by the system via services. In this case, a user who is a subject of a system, can say “I want to print my thesis in colour (single sided) by 10AM on Friday”. Upon receiving this command, the service then places the thesis document in a queue, configures the printer according to the user’s preferences and prints it out before Friday, 10AM. It then notifies the user when the printing is done. Delivering only the right service to users is considered necessary, as they are always on the move and often limited in time to explore service functionalities. Ideally, a user should see the service interface as soon as it is downloaded on the mobile device and
65
does not need to know the detail on how to compile and execute the service. This all needs to be handled implicitly and proactively by a system. In our work, a service to developers refers to a mobile code application that contains a service interface and data associated with it. The code application is mobile and compact in size. Each code bundle handles one particular task/service; more services mean more code existing in the system. Our system stores code on a server and manages the downloading and uploading of code from the server to a client and vice versa. To a user, a service is a tool that is enlisted as the user needs it, which takes care of how tasks get done. A service can just display information to users or perform tasks. For example, by scanning a cup tag ID, not only information about the cup will be displayed, but also, a service interface appears allowing the user to perform an action (e.g., buying a cup, emailing the owner of the cup, etc.). The service in our system is context-sensitive, mobile and regulated by policies (rules). Having context-aware regulated services is considered important, as in some situations a system may want to be in control by asking all users to obey policies which have been pre-specified. The policy controls the visibility of services, and actions permitted on the service, depending on the user’s role and current contexts. For example, during exam time, all users who sit for closed book exams are unable to access services. The users could access services as per normal before and after exam time. This example shows how services and policies can be aware of (or vary depending on) contexts. Our system supports the creation of services that targets mobile devices (e.g., pocket PC, and laptop devices) and desktop devices. Ideally, users do not need to know where s/he is (or under what domain s/he currently is), relevant services should be seen across domains and spaces. In addition, a user should be able to see relevant information related to a space, regardless of a domain that s/he is currently in. For example, a user who owns offices in a few domains (e.g., an office at home domain, office at work domain and office at campus domain) could see the same information related to the office in different domains. This is possible as we store service information per user. This information can then be retrieved by the user in any domain and within a related space. In general, there are two approaches for implementing context-aware services:
66
(a) Without the need to download the service onto users’ devices For example, as soon as a user enters a room, the light is automatically turned on and when the user steps out of the room, the light is turned off. (b) By downloading the service onto users’ devices This then allows users to control service behaviours (e.g., start, stop the service) from their devices. For example, when a user steps into a room, the light is automatically turned on, but also, the user can control this service, by manually turning the light off from the device. The MHS system focuses on the development of context-aware services as in approach “no. b”. The service provides a way of controlling the running services from mobile devices (e.g., a user would be able to control the execution of a music service that is running on a desktop machine). It has a user interface which a user could interact with. We recognize five aspects that would affect the visibility of services. These can be based on the scope of services, a user’s role, a history log file, a user’s preferences and space policies. Each of the aspects that affect visibility of services is described as follows: (a) The scope of services A service is visible only within a certain scope (boundary). As illustrated in Figure 3.6, depending on the boundaries, different services would be visible. For example, in a car exhibition, a service can be delivered depending on the types of cars (i.e., specific to the car) or a generic service for the exhibition (e.g., an exhibition map service). A specific service is termed a local service and a generic service is termed a global service. (b) A user’s role Users with different roles would see different services in the same contexts (e.g., location, day and time). A user with a higher role would generally see more services compared to users with a lower role. For example, a lecturer in the campus could see more services (e.g., an exam service, a lecture note service, a student mark service, and a
67
student attendance service) compared to students.
Corridor
Mercedes Car Display
Volvo Car Display
Reception
BMW Car Display
Corridor
Legend: = This boundary receives specific information (i.e., a local service)
= This boundary receives generic information (i.e., a global service)
Figure 3.6: The Visibility of Services Depends on the Boundary (c) Information that is stored in the history log file For example, at time t, a system takes information about a user’s current context and history such as a user’s previous whereabouts and services associated with those places. This history information is useful for computing a set of services that would be useful to the user at time t. This computation can be modeled as a function f, where f (current_context, history) = a new set of services With this technique, there are two major challenges that need to be addressed in order to allow the system to behave more intelligently in computing a set of useful services. The first issue is how often or when should f be computed? To address this problem, there are three approaches that can be incorporated. The first approach is to compute the function f when a change in the current_context (e.g., location) is detected. With this approach, potentially less bandwidth, memory and battery power will be consumed. However, if a new service is just added for that location, the system will not be able to detect that particular service, as the user’s location remains the same. The new service will only be detected if there is a change in the current context.
68
The second approach is to re-compute function f periodically even though there might not be a change in the current context. The set of services available for a location is not considered part of the context, but used in the computation of f. With this approach, the user is able to see new services which have been added to that location context. However, relatively more resources are needed for this approach. Our MHS system employs this approach to update a list of services on the user’s device. We discuss in detail in Chapter 4, how our context-aware service component updates list of services when context changes. The third approach is to compute function f, only when there is a new service added to the system. With this approach, the user may not be able to see the updated services when s/he moves to another location, as there may not be any service added. This approach is less useful compared to the first and second techniques. The second issue is how do we decide what should go into the current context and history? Current context is basically related to any knowledge about the user, physical location and time contexts. The context history is like a history log that contains any information over a time span that is related to the user’s behaviours. This can be a log file of the user’s activities in particular contexts. By analysing the user’s history log file, the system can then predict the user’s future needs and actions. For example, every Wednesday, the user comes to the office (room B3.50) at 3PM. The system then records this information in the history log file. As the system works out what situation the user will be in, the system could then predict a set of required services proactively before the user gets into that situation (e.g., switch on the room light at 2:58PM). This will avoid lag time between the user getting into a situation and the user being able to use the service. The third issue is how often do we need to update the history log file (update the user’s information that has been stored in the history file)? Updating the information is important as the past information may be no longer relevant to the user’s current activities. This may due to the user having different interests from the past and different aims or goals that need to be accomplished from the past. The question here, we need to know when to update the history file? This can be done proactively or reactively. As for
69
proactive behavior, the system updates the information proactively at the regular time (periodically) (e.g., every Monday or at the beginning of a month). Reactive behavior tends to update reactively and is only performed as there is an explicit request from users to update the history files. The fourth issue is how accurate the prediction using history log file? This predictive model works if the system prediction is correct (e.g., a user always goes to the same place and performs the same activities as specified in the history log file). The system would not know of what services need to be delivered if the user’s current activities are different from a history file and so, there may be a delay in responding to the user (delay in delivering services). Nevertheless, the system can help the user for his/her activities that are predictable. (d) The user’s preferences A user specifies a list of services that s/he might need in a specific situation or context. As a result, two users may see different sets of services, though they are in the same context. This is due to different sets of preferences that they have specified. System management for this technique is quite complex, as the system needs to maintain all users’ preferences and display services differently for each user depending on his/her preferences. In addition, the system may also allow users to modify their preferences dynamically at run time. The issue with dynamic modification here is that the user may not be able to see the updated preferences instantly. There is a delay in displaying the updated preferences just modified and so, the system may still display the old preferences. The delay is mainly because the system takes some time to process the updated preferences and re-map the services to the updated context.
Allowing users to modify their
preferences at run time would require complex system management (i.e., the cached code which have been stored on the device earlier may be no longer useful depending on the updated users’ preferences). The system may need to remove and re-cache the updated service preferences, as well as service application. The question here is how often the system needs to update the cached results (for both preferences and service applications)?
70
(e) Space policies (rules) Developers and owners of physical spaces could set policies (rules) that specify list of services which are available (visible) in the space in certain contexts. As a result, two users in different contexts (e.g., location, day and time) would see different services. Our MHS system uses a combination of a user’s role and space policies in determining visibility of services in the space. We discuss in detail in Section 4.2, Chapter 4 how context-aware policies control the visibility of services in pervasive computing environments. In addition, our system employs two approaches for accessing services: (a) Proactive approach With this approach, a service is available (visible) to users as soon as they are approaching a space and when contexts are met (without an explicit request). For example, a library information service is delivered when a user enters a library building. The user does not have to request it. (b) Reactive approach Some services which are specific to a particular object or task are only delivered when there is an explicit request (e.g., by touching an object using RFID tag reader). We call this the reactive service [SyL06d]. For example, there are several objects in the kitchen such as a painting, refrigerator, table, chair, etc. When entering a kitchen area, a painting service that describes information about the painting (e.g., the painter, year and place of the painting was made) is only delivered when a user touches the RFID tag on the painting. An object could communicate with the system as it has a RFID tag on it. The RFID tag contains information (data) that could be passed onto the system as soon as the user touches it (using RFID reader). The reason we make such a service reactive (i.e., available only on further action or request) is because, not all users are interested or want to know the information about the specific object in the kitchen. In contrast, a room lighting service and a room temperature service are considered as proactively delivered services. These services can be assumed to be mostly needed by users.
71
In the next section, we discuss design criteria that need to be taken into account when modelling context-aware services, issues in developing context-aware services, and the lifecycle of context-aware services in our MHS system.
3.3.1. Design Criteria for Context-Aware Services There are seven design criteria that need to be considered in modelling context-aware services: (a) Simplicity of a service A service needs to be easy to use and allow easy setup. The service needs to encapsulate all interactions (message passing) between a user and a system. Ideally, a service can be used by all levels of users (i.e., novice and experienced users). (b) Functionality of a service A service is normally designed to handle a particular task. For example, a reminder service is to alert a user of his/her future events. (c) Modularity of a service When designing a service, it is important to have a loose coupling design between services. This simply means all required information, logic and computation of a service is independent from another service as much as possible. Modification of a service only needs to be done in one place, with less or no impact on the rest of the services. (d) Relevance of a service A service needs to be closely related to an environment where it is deployed. There is not much use of a service if it does not help users in completing their tasks. For example, for a shopping domain, the primary services would be all services which are related to shopping purposes. (e) Reusability of a service
72
Reusability of a service refers to the ability to share a service across computing devices, as well as re-using the service in other context-aware systems (e.g., a context-aware system based home environment, shopping environment, etc.). (f) Size of a service application In order to support resource constraints of a mobile device, a service needs to be compact in size. A service needs to target most computing devices and can move easily from a server machine to a client machine (e.g., a user’s computing device) and vice versa. (g) Responsive delivery of a service A service needs to be proactive and have sensing ability associated with it. Ideally, when a system senses that a user is approaching a space or when context conditions are met, the system needs to automatically respond by selecting and delivering relevant services and information to the user. In addition, our system recognizes three main properties in modelling context: (a) Accuracy of context information The context information needs to be accurate. For example, the accuracy of a location context can be increased by employing a number of access points in the location. This then helps a location positioning system to sense a user’s current location accurately. (b) Context-change delay The updated context information needs to be retrieved in a minimum amount of time. The system needs to proactively sense and retrieve the updated context information. (c) Usefulness of context information The context information needs to be useful in deciding a list of relevant services for users. For example, to decide on services which are useful for a particular space, developers need to take into account a location context of a user.
73
3.3.2. Context-Aware Service Issues Context-aware services set a relevance and utility boundary on services using context. In this case, a particular service is only available in certain contexts. For example, mobile users get different set of services as they move to a different physical location. Several issues must be addressed in order to deliver a consistent user experience and to build a framework supportive of frequent users and applications context switching. Three major issues related to context-aware services are as follows: (a) Web Service API issue Fundamentally, one key issue to address is how a user (client) may interact with a service. A user needs to know the XML Web service API to interact with a certain service and to manually call or interact with the service. One simple solution is by manually generating SOAP messages of the Web service proxy clients and interpreting responses, but intimate knowledge of the service is required by the client. This is an unrealistic model as an infinite number of service providers may exist. Hence, knowledge of Web service APIs must be somehow delivered to a user and the client device up-front. Common solutions to this have been performed by a Web application offering a standard user interface to the related service. However, such browser based systems lack a real time nature and the richness of on device applications. Therefore, this creates an opportunity for mobile code, or mobile agents, to be downloaded to devices on demand. These computational units of code may be obtained on demand or proactively within a user’s context, activated to service the user’s needs and later discarded or cached for future re-use. By supporting mobile code in mobile devices, we have a model whereby arriving code encapsulates knowledge of XML Web service APIs and their respective communication protocols. Hence, these code payloads provide a rich user interface and application logic. For each service only one mobile code is required and many mobile code may be in existence on one or numerous client devices. (b) Localised service validity issue
74
The localised service challenge is related to a situation where in the middle of service execution, a user moves to another place, in which case, such a service is no longer relevant or useful to the user. One possible solution to address this issue is by applying some expiry time or maximum suspension time for service invocation, if the system detects that the user has moved out of a place. Our MHS system employs an approach where the service will not be valid after exceeding the amount of specified time, akin to a leasing mechanism. Therefore, the executed service will be automatically terminated after some time. However, in a situation where the user is still within a place and such service is still considered useful, there is no expiry time applied. In this case, a service is only terminated when the user wishes to do so. (c) Contextual service performance issue The system needs to deliver the updated set of services to users in the right context. Sometimes, there is a delay in updating users’ current contexts (e.g., a delay in detecting and updating users’ current locations, and current activities). This then results in delays in delivering and displaying updated useful services for users. Due to this delay, a user may not be able to see the right service in the right context. Hence, services which have been delivered earlier may no longer be relevant and useful for the user. For example, due to a delay in detecting a user’s current location, the system may still display old services, even though, the user is already in a new space. Hence, the user may need to wait for some time to see the updated list of services for that space and often, when the system has displayed the updated services, again the user has moved to another space (thereby, services displayed may no longer be useful). Reducing the amount of delay in updating the users’ context information, as well as displaying the updated services are important issues that need to be addressed. One solution to address this issue is to consider a heuristic model that proactively prefetches the relevant services depending on the user’s movement, location or system prediction. We propose seven heuristic based models to help minimizing the user wait time in seeing the updated list of services on the mobile device, as s/he moves to a new place. We discuss in detail each of the proposed heuristic based models in Section 5.1.2
75
3.3.3. The Lifecycle of MHS Context-Aware Services At the first time, before a user logs on to the system, the service is invisible. The service becomes visible (a list of services is displayed on the user’s mobile device) when the user enters a particular context where such a service is useful. When the user selects the service name from a mobile device, a mobile code for interacting with this specific service is then downloaded onto the user’s mobile device. More than one service can exist in the user’s device, but, only one service can be active at a time. The code delivers a rich user interface and functionality, even if the device is temporarily disconnected from the network. This is possible as the handheld device software caches downloaded applications (stores it locally on the mobile device). The cache contains code and metadata describing applications. Hence, if a downloaded application is running, its cache code also exists in the memory. Once the service is downloaded, the client application (which resides on the client side) compiles and executes the downloaded code application. After that, this running service may be paused, set to sleep for a while, resumed, frozen for a little while (as the mobile device may run low of memory or CPU time slices) or even terminated. Then, once it reaches certain time, the paused service may be resumed, the dormant service may wake up, the service that gets frozen may continue to run and the user may choose to re-start the terminated service. This is the lifecycle of the service in the MHS system, from services being invisible, visible, downloaded, executed, terminated, removed from a user’s device and going back to being invisible (as illustrated in Figure 3.7).
76
Figure 3.7: The Lifecycle of MHS Context-Aware Services
3.4.
The Design of MHS Context-Aware Policies
Our policy design takes into account an interoperability aspect, in which policy software components need to be easily accessed within a system itself and by external systems that have disparate platforms and languages. In our policy model, the policy enforcement depends on a user’s current contexts. For example, when a user enters a campus domain such as the entrance of the campus, the campus policy is applied. When the user enters Blackwood building which is under a campus domain, the building policy is applied and when the user enters a lecture hall in the Blackwood building, then the lecture hall policy is applied. Note that a lecture hall might also have different policies at different times and occasions. However, if the space does not have a policy, the system then applies the policy which belongs to the closest logical or physical boundary to this space. For example, as shown in Figure 3.1 above, if a space named “Bob’s office” does not have a policy, the office building policy is then applied in the space. In short, the system first looks for a 77
relevant policy in the space of where the user is currently in. However, if the space does not have a policy, the system then takes the policy that belongs to another space/sub domain/domain, which has a higher level of the environment structure compared to the current space. Our policy design takes into account the reusability aspect. This is possible by storing policy documents and having policy software components on the server side. The relevant policy for the space is applied to all users in the space. Our system also separates rules from contexts. We do not explicitly specify context information in the policy document (e.g., a space or location as well as the exact date and time of when and where activity occurs). Instead, we store the context and activity mapping separately in an external XML file (see Figure 3.11). The mapping here works like a scheduling system, where it stores a list of spaces’ activities in particular contexts. The advantage of separating the policy and context_activity details is that the policy document does not have to be modified when the activity and contexts are updated. Only the mapping needs to be updated when there is a new event or modification of an existing event. The rule can also be reused by other spaces which have the same activity. This is possible as we have a consistent naming of activity throughout all spaces. The system refers to this mapping document (context and activity mapping) to retrieve a relevant space’s activity under specific context information (e.g., location, day, and time). The system then enforces the relevant policy (rule) to users who visit the space when contexts elapse. The activity information can also be retrieved via sensor devices which are installed in the environment. In addition, our policy system controls behaviours of services which are running in the space. Our policy design separates the mobile code application (service application) functionalities and interfaces from the policy. Another approach is to embed the rule itself, as well as policy mechanisms into the application in a tightly coupled way. This complicates both the application’s design and run time adaptation to change context or execution
environment.
We
have
separately
encoded
service
application’s
functionalities, and context-aware service components from context-aware policy components.
78
MHS differs from all other approaches in its ability to specify the policy strategies (mapping between policy, context information and services) at a high level of abstraction. It also supports policy conflict resolution during application execution at run time. When designing a policy language, it is important to balance the convenience and compliance aspects, where a system has control over users’ actions or activities, but does not overly restrict or control users’ behaviours. This is possible by specifying a rule per activity, in which only in certain occasions, the space will be in control. Different policies are applied depending on the activities running in the space. Ideally, it should allow seamless transition between different activities which are happening in the space. The right policies should be easy to configure and enforce with or without a delay. Ideally, the end-user would still be able to access services as per normal in the spaces and only in some situations (e.g., during exam or meeting time), the space takes full or partial control over the service from users (e.g., allowing users to perform certain actions on the service or prohibiting users from performing any action on the service). For example, during exam time, the space (the exam room) makes an “online browsing service” visible only to hall supervisors and this service is invisible to all students who are sitting for a closed book exam. In short, the idea of having policy in pervasive computing environments is like a user who has a car, where she can drive anywhere that she likes. However, she needs to follow the road and traffic rules. Having the rules here do not stop the user from driving. In general, implementing a policy for controlling access to services would benefit a certain entity (i.e., the one who is in control). However, by taking into account convenience versus controlling behaviours in designing policies, the system would allow an entity to give as much permission as possible to other entities in most of the contexts and only in some situations when it is necessary, developers or owners of spaces give partial control to users to access services in specific contexts. In designing a policy, there are several questions that need to be addressed, such as: (a) Who are we trying to control (e.g., the system, end-user)? (b) What are we protecting (e.g., resources, network information, services)?
79
(c) What is the different policy objects (e.g., permission, obligation, prohibition) used in the policy system? (d) What is the target computing environment (e.g., networking, distributed, pervasive computing environment, etc.)? This section is organised as follows. In Section 3.4.1, we discuss policy language requirements specifically for the MHS system. In Section 3.4.2, we highlight the role of policies in pervasive computing environments. In Section 3.4.3, we describe issues in designing policy in pervasive computing environments. In Section 3.4.4, we discuss the MHS context-aware policy concepts. In Section 3.4.5, we illustrate the MHS policy language notation. In Section 3.4.6, we discuss policy conflict sources and types in pervasive computing environments. Finally, we discuss in detail in Section 3.4.7 and Section 3.4.8 policy conflict detection and resolution techniques, respectively.
3.4.1. MHS Policy Language Requirements Nine criteria that need to be taken into account when designing a policy language are as follows: (a) Simple. A policy language needs to be simple and at the same time, comprehensive enough to capture all possible and necessary activities. (b) Has loose coupling policy design architecture (separate an abstraction layer between policy and service implementations). (c) Extensible and allows a new rule to be added without any modification to the existing rules. (d) Can be used to describe situations in an expressive and concise way. (e) Have a standard policy language (i.e., conforms to the XML policy schema). (f) Support basic deontic logic concepts (i.e., permission, obligations and prohibitions). (g) Easy to configure, enforce and administer with minimum (or without) delay.
80
(h) A policy needs to be aware of a user’s current contexts. The right policy is enforced depending on the permission given by the space. For example, during a meeting, the meeting policy is applied. All users who are in the meeting are bound to this policy. When the meeting is over, the system then proactively enforces other relevant policies according to the activity that is scheduled in the space. (i) Convenience. Ideally, an entity would still be able to perform or execute actions on services as s/he wishes. We need to balance a controlling property with a convenience property.
3.4.2. Roles of Policies in Pervasive Computing Environments In addition, there are several main roles of a policy in pervasive computing environments. (a) The policy defines visibility of services in particular contexts (e.g., two users with different roles may see different services available in the context). (b) To constrain behaviours of foreign agents or visitors accessing services in the user’s room [SBM03] (e.g., to protect a user’s privacy [GHJ00; Sne01] and give an owner of a room the ability to control activities of visitors in his/her room). (c) To help users perform a task automatically within a certain situation (e.g., a policy rule can say “automatically start the music (service) at 12:30PM at room R1, playing The First Noel”). (d) To control behaviours of entities in accessing services, especially on public (shared) resource devices and controlling the services from their mobile devices. For example, there are multiple users trying to control the execution of a service on a shared resource device with different interests (e.g., one user wants to start music A, but, another user wants to start music B on the same embedded music device). These differences lead to a conflict and require a resolution. (e) To emphasize different rules to users depending on surrounding contexts (e.g., context of a user and an environment).
81
(f) To control access to resources (e.g., devices, services or data/information). This is to ensure that users only use the resources (both hardware and software) in authorised ways.
3.4.3. Context-Aware Policy Issues Several issues specifically in integrating policy in pervasive computing environments are: 1. Users are always on the move and more contexts (e.g., a user’s current location, activity, current day and time) need to be collected before applying the right policy. 2. Many conflicts may occur in pervasive computing environments. This is due to more contexts, more services used and mobility of users. The conflicts need to be detected and resolved in an appropriate manner seamlessly with minimal or without user intervention. 3. Developers need to have strong understanding of how users want to express their policies in order to design robust systems. This is the key to adoption and survival of policy language. 4. Performance is paramount in pervasive systems. The policy decision checking, policy conflict detection and policy conflict resolution need to be done in a minimum amount of time. 5. Users should not be controlled at all times by the system. Developers need to balance a user’s convenience (ability) in accessing services with the space regulation that limits the user’s behaviours in accessing services in particular contexts. For example, in a particular situation, the system lets users remain in control. This then allows users to access any service or to see the automatic execution of the service as specified in their profiles. However, in some other contexts, a system needs to be in control; the user does not have full access to services (may be partial or no control to services).
82
3.4.4. MHS Context-Aware Policy Concepts Figure 3.8 below illustrates an overall picture of policy concepts in our system and how these concepts are related. Four main policy concepts are described below: (a) Policy objects Policy objects are based on the logic of norms for representing the concepts of rights, obligations and prohibitions in our system. Right (R) refers to permission (positive authorisation) that is given to an entity to execute a specified action on the service in a particular context. Obligation (O) is a duty that an entity must perform in a given context. Prohibition (P) is a negative authorisation that does not allow an entity to perform the action as requested in the given context. (b) Policy actions Currently, there are five different actions that our system employs. These actions are Start, Stop, Pause, Resume and Submit. The types of actions applicable to one service might vary from another and would depend on what the service does. The five actions we identified, we found, occur frequently among a number of MHS services. For example, a Mobile Pocket Pad service that allows users to retrieve and submit their information online, would require two types of actions (Start or Retrieve, and Submit). A Media Player service that allows users to listen to any music at any nearby desktop machines supports four different actions (Start or Play, Pause, Stop and Resume) the music. A Mobile VNC service that allows users to teleport their desktop information to any nearby desktop machine in a location would require Start and Stop actions.
83
= a concept = “is-a” relationship (a generalization) = “consist of ”relationship (an aggregation)
Figure 3.8: MHS Context-Aware Policy Concepts Our system stores a semantic definition of an action, as one action could have different names, but, the purpose is the same (see Figure 3.9). Hence, we group the action based on its purpose. For example, in a Media Player service, a start button is called “play”, but in the Mobile Pocket Pad service, a start button is called “retrieve”. In this case, they both have the same purpose (i.e., to start a service), though the action name is different. In addition, our system could support many types of actions. An addition of a new action or a modification of an existing action only needs to be updated in one place, which is in the synonym action document (as shown in Figure 3.9). Therefore, it is not an issue if the number of actions employed increases in the future. Figure 3.9 describes the synonym of actions in our MHS system. For example, an action with the name “start” has the same meaning with “play”, “turn on”, “retrieve”, “calculate”, “print”, and “search”. As for actions that do not have synonyms (e.g., pause, resume and submit
84
actions), they do not have a synonym tag as part of their child elements. The action name “any” means all actions are allowed (i.e., start, stop, pause, resume and submit). The action name “None” means none of the actions is allowed, and hence, it does not have a synonym tag. <ActionSynonymDescription> <Action Name="Start"> <Synonym>Play</Synonym> <Synonym>TurnOn</Synonym> <Synonym>Retrieve</Synonym> <Synonym>Calculate</Synonym> <Synonym>Print</Synonym> <Synonym>Search</Synonym> </Action> <Action Name="Stop"> <Synonym>TurnOff</Synonym> <Synonym>Close</Synonym> <Synonym>Upload</Synonym> </Action> <Action Name="Pause"> </Action> <Action Name="Resume"> </Action> <Action Name="Submit"> </Action> <Action Name="Any"> <Synonym>Start</Synonym> <Synonym>Stop</Synonym> <Synonym>Pause</Synonym> <Synonym>Resume</Synonym> <Synonym>Submit</Synonym> </Action> <Action Name="None"> </Action> </ActionSynonymDescription>
Figure 3.9: Synonyms of Actions in the MHS System (c) Target services Target service refers to a particular service that a user is allowed to access or obligated to access or prohibited from accessing. As illustrated in Figure 3.12, in the activity name=”Meeting”, policy object=”Right”, and service allowed=”MobilePocketPad service”, this means during meeting in the classroom C.12, the only service that is visible to any group of users is Mobile Pocket Pad service. Our MHS system deals with two types of services: shared resource services and non-shared resource services (see Section 4.1.1.6, Chapter 4). 85
(d) Target entities A user is an active entity who is always on the move (able to move from one geographical place to another). Our system recognises two types of entities: (a) an embedded or non-embedded object (a client software system) that is installed in the environment and (b) a mobile user who is always on the move. A mobile user interacts with the system (e.g., requests to deliver music service) via a software client that is installed on the user’s mobile device or embedded in the wall in the environment. A software client monitors a user’s current contexts by requesting contextual information from context sensing devices and passing on the result to a context interpreter. The software client implicitly performs tasks on behalf of users, such as contacting software system elements to retrieve users’ information and automatically executing tasks based on the users’ preferences. Each user in the system is assigned a specific role. The role is associated with privileges that determine actions that users can perform and visibility of services in particular contexts. There are three different types of roles in our system: super entity, power entity and general entity. Depending on the role that an entity has, s/he may have different privileges in accessing the service. For example, a user with higher role can do more things and may have more services available in the context compared to the user with lower role. Figure 3.10 illustrates the role and entity mapping in our system. As shown in Figure 3.10, an “instance” element (that is a child of “role” element) refers to a sample role in a particular domain. For example, in a campus domain, instances of a general entity role are undergraduate student and postgraduate student.
<RoleCollections> <Domain name="CampusDomain"> <Role name="GeneralEntity"> <Instance>UndergraduateStudent</Instance> <Instance>PostgraduateStudent</Instance> </Role> <Role name="PowerEntity"> <Instance>Lecturer</Instance> <Instance>AdministrativeStaff</Instance>
86
<Instance>TechnicalStaff</Instance> <Instance>Supervisor</Instance> </Role> <Role name="SuperEntity"> <Instance>HeadOfSchool</Instance> <Instance>Dean</Instance> </Role> </Domain> </RoleCollections>
Figure 3.10: Role Collections Document in a Campus Domain
3.4.4.1. MHS Policy Associations We can associate a policy with a space, service or user. Each of these policies has similar purposes; it sets a rule so that users’ behaviours comply with the standard policy. Any of these policies control users’ behaviours in accessing services in particular contexts. The only difference is the scope of the policy. The space policy specifies rules for all users in a particular space. One space policy (e.g., room A’s policy) in a system may be different from another space policy (e.g., room B’s policy). This all depends on the purpose and activity that is currently running in the space. Each of the spaces in a system has its own rules (permission, prohibition and obligation) for users or visitors in that space. In our system, we store a mapping between locations, activities, days and time in a context_activity document (see Figure 3.11). The following context and activity mapping is created by developers (e.g., for public spaces) and owners of spaces (e.g., for private spaces). We assume that the activities in the space always happen as they have been pre-scheduled. The context-activity mapping document shows a list of activities that happen in the space in different days and time. For example, Alice who is the owner of the RoomB530 (i.e., a private space) specifies a list of activities which happen in her office. There is a meeting every Monday between 9-12PM in this room. After that, Alice goes out for lunch between 1-2PM. Alice self studies between 3-5PM. She then goes home at 6PM. Note activity details with attribute day =“Any”, means the specified activity happens on any day of the week. In addition, activity details with attribute startTime or endTime =“Any”, means the specified activity happens at any time of the day.
87
Another example is at a public space (e.g., an exam room), a developer specifies daily activities (e.g., day=”Friday”) which run in the space. For example, every Friday between 9-12PM at the exam room, there is an exam going on. A user can also specify one time off activity that only occurs at certain date and time. This is done by specifying the exact date time (e.g., Wednesday, 22/08/2007 between 9-12PM). As illustrated in Figure 3.11, there is a seminar running in room B530 on Wednesday, 22/08/2007 between 9-12PM. This context_activity mapping document can be modified by authorized users (i.e., developers for public spaces and owners of spaces for private spaces) in order to suit the needs of the space. <ContextActivityCollections> <ContextActivity forLocation="RoomB530" createdBy="Alice"> <ActivityDetails day="Monday" startTime="9AM" endTime="12PM"> <Activity name="Meeting"/> </ActivityDetails> <ActivityDetails day="Wednesday,22/08/2007" startTime="9AM" endTime="12PM"> <Activity name="Seminar"/> </ActivityDetails> <ActivityDetails day="Any" startTime="1PM" endTime="2PM"> <Activity name="Lunch time"/> </ActivityDetails> <ActivityDetails day="Any" startTime="3PM" endTime="5PM"> <Activity name="Studying"/> </ActivityDetails> <ActivityDetails day="Any" startTime="6PM" endTime=“Any”> <Activity name="Going home"/> </ActivityDetails> </ContextActivity> <ContextActivity forLocation="ExamRoom" createdBy="Developer"> <ActivityDetails day="Friday" startTime="9AM" endTime="12PM"> <Activity name="Exam"/> </ActivityDetails> </ContextActivity> </ContextActivityCollections>
Figure 3.11: An Example of Context_Activity Mapping Document There are two types of spaces in our system: (i) Public space (e.g., a tea room, a seminar room, a lecture room, etc.). The policy for a public space is written by a developer (in the public space document is noted by a “system”). This policy is bound to all users who enter a public space. The system entity controls users’ behaviours in accessing or executing services depending on activities running in the space. The policy document contains a mapping between services, contexts and actions. The policy specifies services and actions that users can perform 88
depending on the space activity and roles that users have. The space activity is retrieved by looking up a context_activity mapping document (as illustrated in Figure 3.11) by passing current location, day and time contexts. As there are many spaces in pervasive computing environments and each of them is used for different purposes (has different activities), there is a need to specify rules that target each of these spaces and the activities running in the space. Hence, one space policy may be different from another. Figure 3.12 illustrates a sample of a public space (e.g., a classroom C.12 policy) in our system. The space (exam room) restricts the permission of students who have the general entity role during the exam time (i.e., activity name=”Exam”). In this case, students are not allowed to access any service (none of the service is available for students during these contexts). In contrast, hall supervisors (power users), lecturers (power users) and a head of school (a super user) are allowed to access any service with any action execution as per normal. The values of the attributes “allowed”, “obligated”, and “prohibited” on both service and action elements, can be “any”, “none” or “a particular service”. “Any” on service allowed or service obligated or service prohibited means any services which are registered in the system. “Any” on action allowed or action obligated or action prohibited, means the system looks for action name =“Any” (as described in Figure 3.9), which is “start”, “stop”, “pause”, “resume”, and “submit”. Depending on the attribute name “allowed”, “obligated” or “prohibited”, the services or actions are allowed or obligated or prohibited. In this case, if action allowed =“Any” that means users are allowed to perform either of these actions (start, stop, pause, resume, and submit) on the service. By specifying a particular service name (e.g., a mobile pocket pad service) as a value of the attribute name (e.g., “allowed”, “obligated” or “prohibited”), is a way of the system or the owner of the space, to limit the visibility of services, or to obligate the services or to prohibit the services in the space at particular contexts. Likewise, specifying a particular action (e.g., action allowed =”Start”), means users are only allowed to access the service with the limited action (i.e., only the specified action). In the case, where there is no activity specified for particular space, day, and time
89
slots (e.g., at RoomB530 on Monday, between 12-1PM as shown in Figure 3.11), the system then looks for the activity name=“Any” in the policy rule. During this time (activity name=“Any”), all visitors are given flexibility to access any service and perform any action on the service. This then balances the convenience and compliance aspects in our system, where the space is only in control in some situations (activities) and in others, users could still access services as per normal. Note that “Any” as a value of the attribute name =”on” (e.g., <Right by=”System” on=”Any”>), means this permission rule is imposed on any user in the system (i.e., for general entity, power entity and super entity). In addition, “OtherEntities” as a value of the attribute name “on”, means other than the specified entity. For example, as shown in Figure 3.12, on the activity name=”Exam” and policy object =”Prohibition”, other entities here means other than users with general entity roles (i.e., power entity users and super entity users) in the system. <Rule> <Activity name="Meeting"> <Right by="System" on="Any"> <Service allowed="MobilePocketPadService"> <Action allowed="Any"/> </Service> </Right> <Obligation by="System" on="Any"> <Service obligated="Any"> <Action obligated="Stop"/> </Service> </Obligation> <Prohibition by="System" on="Any"> <Service prohibited="MediaPlayerService"> <Action prohibited="Any"/> </Service> </Prohibition> </Activity> <Activity name="Exam"> <Right by="System" on="GeneralEntity"> <Service allowed="None"> <Action allowed="None"/> </Service> </Right> <Right by="System" on="OtherEntities"> <Service allowed="Any"> <Action allowed="Any"/> </Service> </Right> <Obligation by="System" on="Any"> <Service obligated="None"> <Action obligated="None"/> </Service> </Obligation>
90
<Prohibition by="System" on="GeneralEntity"> <Service prohibited="Any"> <Action prohibited="Any"/> </Service> </Prohibition> <Prohibition by="System" on="OtherEntities"> <Service prohibited="None"> <Action prohibited="None"/> </Service> </Prohibition> </Activity> <Activity name="Any"> <Right by="System" on="Any"> <Service allowed="Any"> <Action allowed="Any"/> </Service> </Right> <Obligation by="System" on="Any"> <Service obligated="None"> <Action obligated="None"/> </Service> </Obligation> <Prohibition by="System" on="Any"> <Service prohibited="None"> <Action prohibited="None"/> </Service> </Prohibition> </Activity> </Rule>
Figure 3.12: An Example of Public Space Policy Document (ii) Private space (e.g., a personal office room â&#x20AC;&#x201C; room B538). The private space policy is written by the owner of the room. We assume here a room is owned by only one user. Hence, only one space policy document exists for one private space. All visitors (including colleagues) who are visiting the room are bound to rules specified by the owner of the room. The policy here is to restrict visitorsâ&#x20AC;&#x2122; behaviours in accessing services in the room for certain situations or contexts. All visitors who visit the room are not allowed to execute any service or perform any action if not permitted by the owner. As the owner owns the room, s/he would have more privileges compared to visitors. Basically, the rules as illustrated in Figure 3.13 are not applied to the owner of the room, but only to his/her visitors. We discuss in Section 4.2, Chapter 4 how the policy decision checking is performed. The permission given to visitors depends on their roles. As illustrated in Figure 3.13, the owner of the room allows certain permission for certain group of users. For example, when the owner is studying, the owner only allows the super entity to start the 91
service â&#x20AC;&#x153;Mobile Pocket Pad Serviceâ&#x20AC;? and permits any action related to the service. The owner does not allow general and power users to start any service under this activity. <Rule> <Activity name="Studying"> <Right by="Owner" on="SuperEntity"> <Service allowed="MobilePocketPadService"> <Action allowed="Any"/> </Service> </Right> <Right by="Owner" on="OtherEntities"> <Service allowed="None"> <Action allowed="None"/> </Service> </Right> <Obligation by="Owner" on="System"> <Service obligated="OnlineBrowsingService"> <Action obligated="Start"/> </Service> </Obligation> <Obligation by="Owner" on="GeneralEntity"> <Service obligated="MediaPlayerService"> <Action obligated="Stop"/> </Service> </Obligation> <Obligation by="Owner" on="OtherEntities"> <Service obligated="None"> <Action obligated="None"/> </Service> </Obligation> <Prohibition by="Owner" on="Any"> <Service prohibited="MediaPlayerService"> <Action prohibited="Any"/> </Service> </Prohibition> </Activity> <Activity name="Any"> <Right by="Owner" on="Any"> <Service allowed="Any"> <Action allowed="Any"/> </Service> </Right> <Obligation by="Owner" on="Any"> <Service obligated="None"> <Action obligated="None"/> </Service> </Obligation> <Prohibition by="Owner" on="Any"> <Service prohibited="None"> <Action prohibited="None"/> </Service> </Prohibition> </Activity> </Rule>
Figure 3.13: An Example of Private Space Policy Document
92
In addition, the owner imposes an obligation on the system in his/her space. It is noted by Obligation by=”owner” on “system”, for example, to automatically execute an online browsing service on a user’s machine as the user is currently studying. Moreover, the owner prohibits any users (e.g., general, power and super entities) to perform any actions on the media player service. Figure 3.14 illustrates a sample policy document that is created by users who do not own a space in the system, but want to impose a set of obligations on the system. As they do not own a space, the right and prohibition elements are left as empty elements. For example, as shown in Figure 3.14, the user imposes an obligation on the system to automatically start Mobile VNC Service when the user is having a meeting. <Rule> <Activity name="Meeting"> <Right/> <Obligation by="User" on="System"> <Service obligated="MobileVNCService"> <Action obligated="Start"/> </Service> </Obligation> <Prohibition/> </Activity> </Rule>
Figure 3.14: An Example of Policy Document by Users Who Do Not Own a Space
3.4.5. The MHS Policy language Notation By default, the space (i.e., a public space or private space) imposes on users: (a) Rights (denoted by spRu). spsRui is a set of permission (Rights) that space (say s) gives to a user (say i). For example, <Right by=”System” on=”GeneralEntity”> as shown in Figure 3.12 - a public space policy document. <Right by=”Owner” on=”SuperEntity”> as shown in Figure 3.13 - a private space policy document. (b) Obligations (spOu). spsOui is a set of actions that the space (say s) obligates the user (say i) to (manually) do in particular contexts. For example, <Obligation by=”System” on=”Any”> as shown in Figure 3.12. <Obligation by=”Owner” on=”GeneralEntity”> as shown in Figure 3.13. The obligation from a space to a user
93
is useful to allow the space or the environment to be in control of the surrounding situation. This is to ensure that all services are off before the user leaves the tea room, the space obligates the user to stop all running services every day at any time at 6PM. (c) Prohibitions (spPu). spsPui is a set of actions which the space (say s) prohibits the user
(say
i)
from
doing.
For
example,
<Prohibition
by=”System”
on=”GeneralEntity”> as shown in Figure 3.12. <Prohibition by=”Owner” on=”Any”> as shown in Figure 3.13. (d) On top of this default space policy, users can also impose a set of obligations on the space (system). This is denoted by uOsp. uiOsps is a set of actions that a user i obligates the space (say space s) via a system to perform in particular contexts, representing what the user wants the system to do automatically. For example, <Obligation by=”Owner” on=”System”> as shown in Figure 3.13. Imposing a set of obligations on the system is a means for the user to have the system perform tasks automatically on behalf of the user at pre-specified activity, location, day and time. For example, user A is always checking his/her email when s/he first arrives at his/her room B538 at 9:30AM. Instead of s/he needing to manually open his/her email account by clicking on the email button every day, the user can ask the system to perform this task automatically. So, when s/he enters his/her office, Outlook Express has already started and the user is ready to check her incoming e-mails; this is possible by the user imposing an obligation on the space (a uOsps) to do so. The permission or prohibition given to the user will depend on the role that s/he has, location that s/he is visiting and the ownership of the location. This would mean that two users who have different roles will have different permission in executing a service depending on the place that s/he is visiting and whether or not the user is the owner of the place. For example, the user with the higher role and visiting a public place will have more rights on services compared to the user with a lower role who is visiting the same place. Another example is two users with the same level of role will have different permission when they are visiting a place that belongs to one of those users. The owner of the room is not bound to the policy that s/he sets up in his/her space. Other legitimate 94
users (who do not own a space) can impose a set of obligations on a system by having a uOsp (see Figure 3.14). The relevant rules of uOsp are executed when contexts are met and if there is no conflict with a space policy or other uOsp. We now describe policy objects for a location that consists of one or more users. Let m be the number of users currently in a location. “sp” denotes a specific space, a public space such as a tea room or a private space, room B538, say. “u” denotes a user. Examples of policy objects are: •
spsRu = {spsRu1, spsRu2, spsRu3, …,spsRum} be the set of rights given by room S to m users in a location.
•
spsOu = {spsOu1, spsOu2, spsOu3, …, spsOum} be the set of obligations imposed by the room S on m users in a location.
•
spsPu = {spsPu1, spsPu2, spsPu3, …, spsPum} be the set of prohibitions by room S on m users in a location.
•
uOsps = {u1Osps, u2Osps, u3Osps, …, umOsps} be the set of obligations imposed by m users on the system at room A (involving services for context where location is room S). After describing requirements and issues in integrating policy in the pervasive
computing environments, we now present our policy language notation in EBNF. Subject ::= “SUBJECT(”entityIdentity“)” “WITH” Role “HAS” Rules entityIdentity ::= DATA Role ::= DATA Rules ::= Rule | Rule “,” Rules Rule ::= policyObject “(”activityName policyImposedBy policyImposedOn Action“)” policyObject ::= “RIGHT” | “OBLIGATION”| “PROHIBITION” activityName ::= Context policyImposedBy ::= DATA policyImposedOn ::= DATA Action ::= targetService actionName targetService ::= DATA actionName ::= DATA
95
Context ::= Location createdBy Day startTime endTime Location ::= DATA createdBy ::= DATA Day ::= DATA startTime ::= DATA endTime ::= DATA *(DATA is a string in some format).
For example: (1) SUBJECT (GU01) WITH ‘General Entity’ HAS rule1, rule2, rule3. GU01 who has a general entity role has three rules at her private room (B530).
Rule1= RIGHT(‘Lunch time’ ‘GU01 user’ ‘Any’ ‘Any’ ‘Any’) This rule is specified by GU01 user that allows all visitors to access any service with any action during her lunch time at her office (e.g., room B530). In this case, all relevant services are visible to visitors during the activity name=”lunch time” at room B530. The owner of the room specifies certain day, time and location with a certain activity. For example, as illustrated in Figure 3.11, the owner of the room always has lunch (activity name = “Lunch time”) between 1-2PM every day.
Rule2= PROHIBITION(‘Studying’‘GU01 User’ ‘Any’ ‘Any’ ‘Any’) The rule prohibits all visitors with any levels of roles to access any service (with any action) when GU01 is studying at her office.
Rule3= OBLIGATION(‘Going home’ ‘GU01 User’ ‘System’ ‘Any’ Any’) The rule obligates the space (room 530) via the system to automatically stop any running service after 6PM on any day, as the user normally leaves the office between 5:30 and 6PM.
(2) SUBJECT (PU01) WITH ‘Power Entity’ HAS rule1
96
PU01 is a user (i.e., a developer) who has a power entity role and has one rule at the exam room. As the exam room is a public space, the rule is specified by a developer. Rule1= PROHIBITION(‘Exam’ ‘System’ ‘General entity’ ‘Any’ ‘Any’) The rule prohibits all users who have a general user role (e.g., students) and are sitting for exam to start any service at the exam room. Other students who are not in the exam room (e.g., at school lounge) may be allowed to access relevant services. This depends on the rule in the space (i.e., a school lounge space). At the exam room, the space only restricts students access to services, other users (e.g., staff or hall supervisors) are allowed to access services as per normal.
3.4.6. Context-Aware Policy Conflict Sources and Types This section discusses several possible sources and types of conflicts for a system that employs policy for regulating access to services in pervasive computing environments. We have published our work in describing sources and types of conflicts, techniques used to detect and resolve conflicts in [SLS05]. The conflict happens as more than two users are trying to access the same resources (e.g., services or devices) with different interests (specifications) such as users are trying to do opposing actions. The shared resource service can be controlled and accessed by all legitimate users from their mobile devices in that specific location. Hence, there is a high chance of conflict occurrence here as there may be more than one user in the location trying to access or control the same shared resource service with different interests or specifications on what action to perform (e.g., start, stop, pause or resume) and when to perform this particular action. One example is one user (with higher privilege) can execute more types of services at any time and any place compared to other users (with lower privilege) that can only execute certain services in the certain place and time. In our system, the level of privilege is determined based on the level of positions or roles that the user has. As each entity has different levels of privileges, a user with higher level role may override the execution of the shared resource service that has been started earlier by a user with a
97
lower role. For example, one user has started the service (e.g., start the music) and another user wants to stop the execution of the running music or perhaps start a different music). This then leads to a conflict that needs to be resolved as soon as the conflict is detected or just when the conditions for the conflict to happen are satisfied. A non-shared resource service, on the other hand, is a service that is downloaded and compiled onto a user’s mobile device only. This service is running on the user’s personal device and only accessible to that user (i.e., a Mobile Pocket Pad service). Hence, there is a less chance of conflict occurrence. In addition, a conflict may occur due to different interpretation and expectation of policies. Some assume the system would take policies that take priority over others as would one person’s over another’s. Other participants thought the system would stop at a certain point whilst others assumed the system would seek clarification from the user. We recognize two types of policy conflicts: a potential conflict and an actual conflict. As pervasive computing systems deal with mobile users, in which, the user can move freely from one geographical location to another (e.g., from one place to another place) and the user carries its own role and rule (e.g., uOsp) on how the service should be executed, more conflicts could occur. In our word, a potential conflict refers to a conflict that has not happened yet at the time the system detects that such a conflict can happen, as the context or condition for the conflict to occur has not been met. Potential conflicts can be further classified into two different types: a definite potential conflict and a possible potential conflict. A definite potential conflict refers to a conflict that will definitely occur if the user is in the right context. For example, one user obligates the system to start music A, but another user obligates the system to start music B (at room B538 on Friday, at 5.30PM). Once the user is in the right context, this definite conflict will become an actual conflict, as both users have different interests on what music to be played on the same shared resource device. A possible potential conflict, on the other hand, refers to a conflict where the possibility of the occurrence is less than the definite potential conflict. This conflict may still not happen even in the right user contexts of location and time. For example, a
98
system allows user A and user B (who have the same role) to “start any service”. “Any” here means all services which are available for the user in that context. The conflict only occurs if the users are starting the same service with the opposing action (e.g., one wants to start music A and another wants to start music B, or one wants to start music A and another wants to stop music A on the same target device). Hence, we categorize this conflict as a potential conflict with the type possible. Although, with the use of policy, conflict would still occur due to users who have the same role and permission access services with different specifications. Introducing policy with role helps to minimise the possible conflict, but a conflict would still occur. Controlling access of each user by further restricting access depending on the activity that a user is in and the role that s/he has, will help to further minimise the conflict.
3.4.7. Policy Conflict Detection In this section, we briefly describe goals of policy conflict detection, followed by several strategies used to detect conflicts in pervasive computing environments.
3.4.7.1. Goals of Policy Conflict Detection The primary goal of detecting policy conflicts is to investigate several possible sources of conflicts, as well as types of conflicts that may occur in the system. Knowing that there is a potential conflict, it would allow the system to accommodate the conflict resolution earlier. Hence, when the conflict occurs, the system is ready with the conflict resolution result. There are also several sub-goals of policy conflict detection: (a) To group a conflict based on its type (i.e., a possible potential conflict or a definite potential conflict). It is to know the type of conflicts in order to decide when to resolve the conflict. (b) To predict the probability of potential conflicts which will become actual conflicts. This is useful to decide when to resolve the conflict. For example, if we can predict
99
that the potential conflict never happens, the conflict resolution for this type of conflict may not be necessary. The occurrence of policy conflicts can be reduced by: â&#x20AC;˘
Having one party to be in control at certain contexts. For example, all visitors who enter public rooms have to obey the space rule (in this case, the rule is written by a developer).
â&#x20AC;˘
Having a consistent checking within one policy document. For example, users who impose obligations on the space (system) should be within their permission given by the space. Users are not allowed to set an obligation on the space (system) if not permitted by the space. In addition, it is also important to check the consistency between permission and prohibitions (i.e., to ensure tasks which are permitted should not be prohibited).
3.4.7.2. Conflict Detection Techniques By analysing several possible sources of conflicts that may happen in pervasive computing environments, we propose static and dynamic techniques to detect conflicts. 1. Static conflict detection Static conflict detection aims to detect all types of potential conflicts (possible or definite) which clearly could cause conflicts from the policy specification. This static conflict detection is performed offline on the client side or on the server side. Performing the static conflict detection on the client side is less desirable as it slows down the conflict detection process. This is due to some constraints (e.g., limited resources, power and processing speed on the mobile device). The only advantage is the conflict detection result is there on the mobile client side when the user needs it (hence, it does not have to be transferred onto the client device). On the other hand, performing static conflict detection on the server side has more advantages compared to the client side (i.e., the server â&#x20AC;&#x201C; normally a desktop PC has larger memory size and faster processing speed) and so, can detect the conflict faster. The result can then be pushed onto the mobile client
100
device when done. With static conflict detection, we also need to decide on types of conflicts that we need to detect such as: (a) Whether we only want to detect conflicts which are clearly specified in the policy specification (definite potential conflicts). (b) We want to detect some other conflicts which are not conflicts yet from the policy specification, but they could lead to conflicts if one or more entities are in the space in the right contexts (possible potential conflicts). To include all possible potential conflicts will certainly speed up the performance in responding to the userâ&#x20AC;&#x2122;s requests (as it has detected all possible conflicts). The only drawback is it may use up a lot of system resources (e.g., memory and processing speed), as it has to detect conflicts based on all possible combinations of entities, contexts and services that the system has. Moreover, some of the conflict detection results may never be used as the entities may never be in a context as predicted (hence, the predicted potential conflicts may never occur). Another issue that needs to be taken into consideration is to decide on how often the cached policy detection result needs to be updated (if we want to cache the conflict detection result for future re-use). The detection results may be outdated as perhaps, there are more users registering with the system or some users have modified their policy specifications. To address this issue, several approaches can be incorporated: (a) frequently (i.e., every 5 minutes), (b) periodically (i.e., every Monday) (c) only when the system detects that the user has modified the policy specification or when a new user registers with the system. 2. Dynamic conflict detection Unlike static conflict detection, dynamic conflict detection is performed at run time by dynamically detecting all definite potential conflicts between entities in the given contexts. As dynamic conflict detection is performed some time at run time, the system needs to decide on when to trigger this detection module. We proposed four different strategies about when to dynamically detect conflicts. (a) Reactive based dynamic conflict detection
101
As it is reactive, this dynamic conflict detection is only triggered when there is an explicit request from users. For example, when the user clicks on any action name (start, stop, pause, resume, or submit) from a mobile device to request an action on the service. With the request, the system also collects all the entitiesâ&#x20AC;&#x2122; context information and looks for conflicts between those entities in the given context. This technique is best suited for the situation with only a few requests from users. It takes some time to detect conflicts if there are many requests from users, as each request from users require the system to detect the conflict. In addition, the detection is only limited to the current location, day and time, which are related to the requested action and only between the requested user against all other users in the room (not all users in the system). (b) Proactive based dynamic conflict detection Proactive conflict detection tends to implicitly and automatically detect the conflict by sensing the userâ&#x20AC;&#x2122;s current context (e.g., when the user moves in or out of the room). With this technique, the system automatically detects conflicts regardless of requests from users. This technique is best used in the situation where performance is paramount. The proactive conflict detection detects all the potential conflicts that may occur in the given context and may cache the result for future re-use. The proactive technique is also considered as pessimistic conflict detection. We are pessimistic that there will be a conflict between those entities in the room, as each entity may try to perform different actions for the same shared device. Hence, the system proactively finds all potential conflicts that may occur in the given context for those users in the room. In addition, this technique is considered useful only if the participating entities (i.e., users) are still in the same location context where the conflict is predicted to happen. If one of these entities has moved to a different location, the predicted potential conflict may no longer become an actual conflict (as this type of conflict only occurs if two or more users which have different specifications on the same target service are still in the same space). (c) A combination of reactive and proactive based dynamic conflict detection
102
A combination of these techniques is useful when we want the system to act proactively in certain places (e.g., public places such as in an examination room, and a seminar room) and in other places, reactively (e.g., in the user’s private room). In public places, there might be users moving in and out of the place, and so, it is useful to employ a proactive conflict detection technique here. In the user’s private room, there might usually be only the owner of the room with some other visitors who may not perform many activities, and so, we detect the conflict reactively. A decision to choose whether to perform proactive or reactive search for conflicts can be based on: (i) the location (e.g., reacts proactively in public places and reactively in the private place), (ii) certain day and time (e.g., on Monday at any place, proactively detects the conflict, because, it may be a busy day and many students come to University or at the shopping centre, there may be a lot of visitors visiting the mall, but, other days, we detect the conflict reactively), and (iii) the number of users in the location. For example, if the system detects there are more than five users in the location, a proactive conflict detection technique is used. However, if there are less than five users, the system then detects the conflict reactively. (d) Predictive based dynamic conflict detection Predictive model detects the conflict based on a user’s history file. By analysing the user’s history file, the system can predict the user’s movement and the person who the user is going to meet. For example, from the history file, user A is always going to room B and meeting user B on Wednesday at 12PM. Based on this information, the system may want to compute the conflict detection proactively between these users (user A and B) at room B. This technique is considered useful only if the system prediction is correct (i.e., the user always does the same activity as specified in the history file). However, if the user’s movement and activity are not anticipated by the system (e.g., the user is moving to a different room and meeting different people), there will be a delay in responding to the user’s request. This is due to the conflict detection result which has been previously computed is irrelevant to the user’s current context. Hence, the system
103
will need to re-detect the conflicts based on the user’s current location, day, time and the people whom s/he is going to meet.
3.4.8. Policy Conflict Resolution When there is a potential or actual conflict detected by a conflict detection module, it becomes necessary to resolve the conflict. Four aspects discussed in this section are the goals of policy conflict resolution, when to resolve conflicts, techniques used to resolve conflicts and when to update the cached policy conflict resolution result.
3.4.8.1. Goals of Policy Conflict Resolution The primary purpose of conflict resolution is to resolve conflicts in a minimum amount of time, and so, minimising the user’ wait time. Several sub-goals of policy conflict resolution are: (a) to discover several techniques for resolving conflicts based on the conflicts’ sources and types, (b) to decide when it is the best time to resolve conflicts, (c) to decide how often the conflict resolution result needs to be re-computed, (d) to monitor whether the conflict resolution result satisfies both of the entities involved in the conflict. If the conflict resolution result does not satisfy the entities, we need to think of the best solution that will benefit both of these entities (i.e., allowing the entities to challenge the system and resolving the conflict by taking into account the user’s current situations), (e) to analyse whether the conflict resolution result is useful (i.e., the conflict resolution result will be used at run time, as the predicted potential conflict becomes an actual conflict).
104
3.4.8.2. When to Resolve Policy Conflicts We propose two strategies about when to resolve policy conflicts in pervasive computing environments. (1) At the time when a conflict is detected This is a pessimistic conflict resolution technique. We are pessimistic that some or all detected potential conflicts will become actual conflicts. Hence, the system resolves all conflicts immediately as soon as the system detects them. Depending on the conflict detection technique that the system employs, with this technique, the conflict can be resolved offline (i.e., when users are not in the space yet) or at run time. For example, if we employ a static conflict detection technique, the conflict resolution component resolves all potential conflicts offline, as soon as they are detected. However, if the system employs a dynamic conflict detection (e.g., a reactive technique), the conflict resolution component only resolves conflicts at run time, as the conflicts are only detected at run time. In addition, with this technique, we can further choose which conflicts to resolve based on its type such as: (i) Resolve only a definite potential conflict The technique here resolves only a definite potential conflict, as we are sure that it will become an actual conflict once the entities are in the right contexts for the conflict to happen. With this technique, it only resolves the possible potential conflict, when the contexts for the conflict to happen are met. This technique does not anticipate all conflict resolution results. Hence, there may be a delay in responding to the userâ&#x20AC;&#x2122;s request, especially if the possible potential conflict happens to be an actual conflict at run time. (ii) Resolve both possible and definite potential conflicts The system can also choose to resolve both types of conflicts as soon as they are detected. These potential conflicts are solved, though they have not happened yet to be actual conflicts. This technique would minimize the user wait time, as it has resolved all predicted conflicts prior to becoming actual conflicts. However, if none of the potential conflicts become actual conflicts, this would waste system resources.
105
(2) At the time when a potential conflict becomes an actual conflict (normally at run time) This is an optimistic conflict resolution technique. We resolve the potential conflicts only when they become actual conflicts. We do not resolve these potential conflicts, when we detect them, as we are â&#x20AC;&#x153;optimisticâ&#x20AC;? that the conflicts that we have detected might not become actual conflicts. This is due to several factors such as the user may not be in the context where the conflict is detected to happen or the user does not execute the service in the specific context (e.g., in a specific location, day and time) where a conflict can arise (although, it is clearly a conflict from the policy specification). For example, user A has an obligation on the system to automatically start music A when she is approaching a lounge room. However, user B has a different specification on what music to automatically play at this room (e.g., music B). We are optimistic that the conflict here will not happen, unless these users are in the lounge room at the same day and time.
3.4.8.3. Techniques to Resolve Policy Conflicts As discussed in Section 3.4.6, the conflict happens between two users who have different interests on the same shared resource service. Our system only recognizes the occurrence of conflicts between two users, even if another user enters the space and requests to execute different behaviours. For example, user A enters a lounge room. User A is the first user in this room. She then requests to start music A on machine M. The next moment, user B enters the room and requests to start music B on machine M. At this point, there is already a conflict between user A and user B. The system then resolves the conflict. After this, user C enters the room and requests to start music C on machine M. There is another conflict here, which is between the winner of the previous conflict (e.g., user A) and user C. In summary, we detect and resolve conflicts between two conflicting entities only. This is mainly because, more entities being involved in the conflict requires more complex conflict resolution (e.g., conflicts among users A, B and C). The conflict resolution result needs to be done for user A and user B and then further resolve this
106
conflict with user C. The proposed conflict resolution techniques only handle conflicts between two conflicting users in context-aware pervasive systems. These resolution techniques are: (a) Role hierarchy overrides policy The role hierarchy overrides policy is used if the conflict occurs between users who have different roles; here, a user with a higher role can override the policy that belongs to the user with a lower role. (b) Space holds precedence over visitors This technique is used if a conflict occurs between the owner of the room and visitors. For example, the owner of the room permits visitors to start a service at room A. When the service is already started, suddenly the owner of the room wants to stop the service (e.g., due to unexpected event/activity that happens in the room). This then results a conflict. In order to resolve this conflict, the system uses this technique (i.e., space holds precedence over visitors), where the space (representing its owner) always wins, regardless of the level of role that the visitor has. (c) Obligation holds precedence over rights This technique is used if a conflict occurs between an obligation and right. An obligation describes something that users must do because of a rule. In short, an obligation is a must that forces someone to do something. In contrast, rights describe permission that users can do. Therefore, an obligation carries more weight compared to a right. As a result, an obligation always wins over the right. (d) Maximum execution time policy This technique is used if a conflict occurs between users who have the same role. In order to solve this issue, we apply maximum execution time policy, where the user who has started the service earlier can only be in control for certain duration of time (e.g., 5 minutes). After this, control of resources is given to the next requestor. Another solution to policy conflicts is employing manual social negotiation between conflicting users. However, this approach is not suitable if the number of users in the
107
space is large as a lot of time will be needed to resolve the conflicts, as all conflicting users need to agree with the conflict resolution outcome, and negotiation may not terminate. Moreover, if users are scattered all over the space, it is hard to reach one another and resolve the conflicts - especially if they do not know each other. Social negotiation only helps to solve conflicts if the number of users in the room is small, and negotiation is feasible. Due to the above reasons, this dissertation does not take into account this approach for resolving conflicts but admits it as a possibility.
3.4.8.4. When to Update the Policy Conflict Resolution Result It also would be good to cache the conflict resolution result for future re-use. The question here again, we need to decide when the cached result needs to be updated. One simple solution is to update the result each time the conflict detection module recomputes (when the cached conflict detection results are updated).
3.5.
Summary
In this chapter, we have discussed the MHS view of pervasive computing environments, where the environment consists of logical and physical boundaries. One or more physical spaces are grouped into a logical boundary (domain). One domain consists of several spaces and one space consists of several sub spaces. Having a domain concept and grouping physical spaces into the domain has the following benefits: (a) Provides better management of an environment. Adding or removing spaces (sub spaces) only need to be done in one sub domain (domain) with less impact on other sub domains (domains). (b) Provides better structure of an environment. We can group similar physical spaces under one sub domain or domain. For example, a shopping domain consists of several sub domains such as clothing, grocery, electronic, furniture, etc. Each of these departments or sub domains consists of several physical stores (shops) such as an electronic department consists of several stores which sell electronic items. 108
(c) Shows relationship between domains and spaces. Based on Figure 3.1, we can draw hierarchical relationships among domains and spaces such as campus domain\\office building\\Bob’s office. This means Bob’s office is within an office building and the building is under a campus domain. The ‘\\’ denotes a separator of logical/physical boundaries. In addition, we have presented a high level abstraction of the MHS framework, consisting of MHS services, computing devices, MHS software components and .NET component management core.
This chapter discussed in detail the design of MHS
context-aware services including approaches, criteria that need to be taken into account in modelling context-aware services, issues related to context-aware services and service lifecycle in the MHS system. This chapter also gave a detailed design of context-aware policies in the MHS system. Several policy design aspects that we highlighted are roles of policies in pervasive computing environments, issues in integrating policies in pervasive computing environments, the MHS context-aware policy concepts, and techniques used to detect and resolve policy conflicts. In the next chapter, we present a prototype implementation of the MHS framework that implements the MHS software components mentioned here.
109
CHAPTER
4
4. Implementation of MHS: Detailed Design and Prototype
In Chapter 3 we presented a context-aware regulated services model that delivers context-aware services depending on usersâ&#x20AC;&#x2122; contexts. The model also integrates policy for controlling usersâ&#x20AC;&#x2122; behaviours for accessing services in pervasive computing environments. The prototype implementation of our MHS system as published in [SLS04a; SLS04d; SyL06c; SyL07b] supports the needs of context-aware regulated services by: â&#x20AC;˘
Using a combination of mobile code and a client-server model
This is to perform contextual functionalities that result in overall minimum user wait time. The MHS system supports code on demand execution, which allows a computational component to load code from a remote service repository when needed. Basically, the MHS system retrieves service applications from a service repository on the server side, when there is a request from a user. When the mobile client application
110
finishes downloading and compiling the service application, it then displays the service interface. â&#x20AC;˘
Identifying a high level abstraction of a system
This is done by deriving concrete system components from a pervasive computing environment model. The MHS system logically groups spaces into domains. The system functionalities are stored on the server and client sides. We discuss in detail in Section 4.1.1 and Section 4.1.2 the server and client side component functionalities, respectively. â&#x20AC;˘
Supporting remote execution
The MHS system enables remote execution of a process on one machine from another (e.g., to remotely start a teleporting service that is installed on a desktop machine and controlling this process from a mobile device). â&#x20AC;˘
Supporting a policy mechanism
It is for controlling access to services in particular contexts. This chapter discusses in detail basic components of the MHS system and how the parts interact. The system consists of users with a laptop or handheld device, a Web service that determines the location of a user, a set of contextual-based services and policy components which are published via the system (see Figure 4.1). A handheld device user accesses the system via a mobile client application that has been installed on a device and laptop users access the system via a Web browser. The current implementation of MHS uses the Microsoft .NET framework [ThL01] that natively supports Web services and remote method invocations. The .NET framework targets a number of applications such as a smart device application (e.g., for a pocket PC), a Web application (e.g., for a desktop, or laptop, in which the application is accessible via a Web browser), a mobile Web application (e.g., for a smart phone where the application is viewable via a micro browser) and a stand alone application (e.g., for a desktop device). The .NET framework provides stable development for both a traditional system (e.g., a standalone application) and a distributed system that involves various system components such as a server, client, Internet service and database objects, as well as high interactions between them.
111
This chapter is organised as follows. In Section 4.1, we present the architecture of the MHS framework. In Section 4.2, we discuss our MHS prototype implementation. We discuss how to access non-shared and shared resource services. We present how our run time context-aware policy implementation works. We discuss how to control usersâ&#x20AC;&#x2122; behaviours and partial control between users and the system. In Section 4.3, we briefly discuss steps to add new context-aware services to the system. In Section 4.4, we discuss sample services used in the MHS system. Section 4.5 concludes this chapter.
4.1.
Architecture of the MHS Framework
This section discusses a high level architecture and abstraction of our MHS system. Our system provides an infrastructure that handles interaction between a client device that requests a service and a server which responses to the clientâ&#x20AC;&#x2122;s request via Web service calls. The MHS system simplifies the task of developing and maintaining context-aware applications for mobile clients. The system handles and caches all incoming services or code applications on the client side, as well as executing services when downloaded. This is possible as the MHS software components reside both on the client and server sides and each of them handles and manages a particular task (see Figure 4.1). Design properties in our contextual system include modularity, extensibility, genericity and interoperability. The system is modular as it has a loose coupling architecture. Updating the system functionalities in one component will have minimal impact on the rest of the system components. Moreover, addition or modification of system functionality only needs to be done in one place (e.g., to add a new function to the policy manager, only the policy manager needs to be updated). Our system is extensible as we can still add additional services in the future. This is possible as we store all services on the server side (not on the client side). The service is only downloaded onto the client side when the user is in a particular context where such service is considered useful or when the user requests it. Our system is generic as it can employ existing or new traditional and non-
112
traditional applications. The proposed system is also highly interoperable as we implement all the contextual methods or functionalities of the system as Web services. Implementing system functionalities as Web services allows Web methods to be accessed and invoked easily across disparate platforms and languages via the HTTP protocol. Figure 4.1 illustrates a high level architecture of the MHS system that consists of server software components and client software components.
Service Discovery
Policy Repository
Location Server
Context-Aware Policy Component
Web Service
Context-Aware Service Component Mobile Code Repository
Web Service
Web Service Invocation
Code Server
Invocation
Remoting Service
Mobile Client Manager Code Cache Client Side Software Components
System Manager
Context Component
Registration/ Deregistration component Server Side Software Components
Figure 4.1: A High Level Architecture of the MHS System Our system simplifies interaction between a user and system starting from sensing a userâ&#x20AC;&#x2122;s current context, to downloading and executing a service. Ideally, users do not need
113
to know low level details of matching, selecting, downloading and executing services. All these interactions need to be handled implicitly by a system. The framework exploits services present in the environment, provides functionality to manage, proactively download services from a server side to a client side, and upload the modified information to the server. MHS also supports the ability to control services by having a policy that specifies a set of rules of what services are visible to users and what actions are allowed, prohibited and obligated in particular contexts. Our policy design balances the convenience and compliance aspects of users in the system (as discussed in Section 3.4, Chapter 3). As a result, mobile users still have the convenience in accessing services, although s/he has been bound to a set of rules. We describe eleven main software components in our system as follows.
4.1.1. Server Side Software Components Server side software components are stored on the server. These components continue to monitor a user’s current contexts and obtain relevant services and rules. Each of these software components is discussed as follows:
4.1.1.1. System Manager A system manager manages the interaction between a mobile client manager and server side software components. As soon as the system detects a user’s location, the system manager proactively computes a set of services and actions allowed on a service in the particular context. This is done by first contacting the context collector to gather the user’s current context and then, the policy interpreter is called to parse the relevant policy document and interpret its contents (i.e., permission, obligation and prohibition given). The system manager manages the interaction between a client and the server. It is responsible for retrieving the available set of services in the specific context as well as responding to the user’s request regarding the space policy decision results (e.g., what
114
actions that a user can perform on a target service in the specific context). Figure 4.2 below illustrates how relevant services are retrieved given a set of contexts. //Web method to get a list of services in the space [WebMethod] Public ArrayList GetService (string deviceIP, string userRole) { //Initialisation of ArrayList ArrayList ListOfServices = new ArrayList(); //Add a Web reference to the Location Web service and creates an //instance of it LocationService locationService = new LocationService(); //Add a Web reference to the Policy Web service and creates an //instance of it PolicyService policyService = new PolicyService(); //Call the Location Web service to get the updated user’s location //and store the result in a userLocation variable String userLocation = locationService.getAreaLocation(deviceIP); //Call the policy Web service to get a list of available services //in the space. The input parameters are a user’s current location, //a user’s role, day, and time contexts. If there is a service //found, then assigns the result to ListOfServices variable ListOfServices = policyService.getSpaceAvailableServices (userLocation, userRole, Day, Time); //Finally, return a list of services. return ListOfServices; }
Figure 4.2: Get Service Web Method
4.1.1.2. Code Server Code server refers to a mechanism that handles a user’s request, responding to that request by transferring the relevant mobile code. In this case, the code server retrieves the mobile code that matches with the user’s request and sends it back to the mobile
115
client. Within our system, we employ a Web service method invocation such as Get Mobile Code Web method, in order to retrieve a mobile code application that matches with the service name, returning the particular mobile application to the user’s device. An example of Get Mobile Code Web method on the Code server class is illustrated in Figure 4.3. In addition, the .NET framework provides security guarantees for mobile code [MPS02]. Validity and verifiability ensures that programs can only ‘go wrong’ at runtime in specific, predictable ways. The framework has code access security (CAS), a runtime security system with declarative and imperative develop-time declarations and administrator-controlled policies. CAS stops, for example, .NET applets from accessing the user’s file system by restricting access to sensitive parts of the System.IO API. This simply means that applications downloaded onto the user’s device cannot attack their system. In this case, the user must trust the prototype implementation, the mobile device user must trust the mobile device software to enable an appropriate security policy. For laptop computer users, various security restrictions are imposed by the .NET Framework on the downloaded applications [RCG01]. //Web method to get mobile code based on the requested service [WebMethod] Public void GetMobileCode (Service service) { //Initialisation of MHSMobileCodeService Web Service. //The MHSMobileCodeService Web Service has a function called //GetApps(service name)to retrieve a mobile code from the mobile code //repository. MHSMobileCodeService mhsCode = new MHSMobileCodeService(); //Retrieve a particular mobile code on the server and download it //onto the user’s device String serviceName = service.ServiceName.Trim(); App app = mhsCode.GetApps(serviceName); //Start and execute the mobile code on the device Start(app); }
116
Figure 4.3: Get Mobile Code Web Method
4.1.1.3. Remoting Service Our system permits a remote Web service call from a client device to the server or the server calls a Web service on the client. Using remoting permits remote execution of a process of an application on a specified target machine via a Web service call. Our remoting Web service is developed in the .NET environment using VB.NET and C# languages (as illustrated in Figure 4.8 and Figure 4.9). This remoting service can be easily invoked by other processes which are running on different platforms. Hence, with the addition of .NET Remoting on top of our existing MHS framework, we can integrate an existing traditional application (e.g., a Windows Media Player application) into our system and add context behaviours to it (e.g., specify the location, day and time) about when and where we want this media player application to be executed on the target machine. For example, the MHS system can start the Media Player service as soon as a user enters B3.50 room at 3PM and stops the service when the system detects that the user has walked out of the room. A user can also set a preference of what songs to play and how long to play them. Based on the user’s preference list, the system will automatically play the music. We briefly discuss how our remoting service works in Section 4.2.1.
4.1.1.4. Context Component Contexts are conditions that must be met before a list of services is displayed on a mobile device or before a user’s request to perform an action is approved. In our work, contexts consist of a user’s identity, location, day, and time. Activity information (e.g., activity name=”Meeting”) is derived from a mapping between location, day and time contexts (as illustrated in Figure 3.11). For example, by knowing a user’s current location, day and time, the system can retrieve the activity that is happening in the space. All these information are based on manual inputs by developers and owners of the
117
spaces. An important question in regard to context information is how to obtain or collect context information to enable adaptive service behaviors. One solution is by requiring each service application to independently collect the necessary context information. This technique, however, places a burden on system developers which have to manually add context collector behaviours to every single application that they are developing or will develop in the future. The maintenance is also costly and time consuming as developers need to manually update the same changes on each service application. Another solution is to have a shared software component that handles and collects context information for use by all services in the system. In our system, this is known as a context collector. The context collection process is done by calling the respective Web service. For example, a userâ&#x20AC;&#x2122;s location information is collected on demand by invoking the location Web method. The updated current day and time are obtained by checking the current system day and time. The userâ&#x20AC;&#x2122;s identity is retrieved from the login form, once the user is logged onto the system. Some other static contexts such as a userâ&#x20AC;&#x2122;s preferences of when and where to play his/her favourite music, and display his/her desktop information are stored in an XML database.
4.1.1.5. Context-Aware Policy Component Most existing policy languages have constructs which only include a few pervasive computing principals (i.e., does not use contexts, or services), which we feel makes their direct use in our system difficult. Therefore, we developed a simple policy language that includes some basic principals (i.e., it has a notion of entities, spaces, services and contexts) in pervasive computing environments. We try to keep our policy design as simple as possible so that it can be easily integrated into an existing or future implementation of context-aware services. Moreover, we also focus on the interoperability aspect, in which, all the policy software components need to be easily accessed by the system itself or by external systems that have disparate platforms and languages. Having an interoperable policy system further supports extensibility of the framework as we can easily add more services, entities and policies in the future or 118
perhaps integrate the existing system with some other external systems (assuming they both have similar design and architecture). Allowing users to specify their service preferences would certainly maximize the aim of context-aware pervasive systems, since the service delivered would more likely to be useful to users. Also, users are given privileges to specify things they wish to see or do in particular contexts. However, in some situations, the system may want to be in control, by asking all users to obey the policies (rules) which have been pre-specified. The policy in our system specifies the visibility of services, as well as controlling usersâ&#x20AC;&#x2122; behaviours in accessing services (i.e., what action they can perform) depending on their role and current contexts. The service controls access to devices and information. Our MHS system does not embed a policy document on a client device, instead the policy is stored in a centralized database. This then supports reusability of policy information. In general, there are two approaches used in integrating a context-aware policy into a context-aware system: (a) By embedding a policy document on an executable service application With this approach, a client-side service application enables and disables an action according to the specified rule (e.g., only the permitted actions are enabled). Hence, no policy checking is required. However, this approach requires the system to recompile the client-side service application each time the policy is modified. This does not suit a situation where a policy is dynamic (often changes). The compilation of a service here may take some time depending on the number of services that need to be recompiled and this update has to be propagated to all mobile users. (b) By having a system manager to manage all policies for services in the system This approach allows the policy to be reusable across services, and users. The maintenance is also simple, as any modification only needs to be done in one place. The only issue is that it takes some time to respond to the userâ&#x20AC;&#x2122;s requests, as the policy is stored on the server side. One possible solution to mitigate this issue is by proactively computing a set of relevant policies as soon as the context is sensed, as well as, caching
119
the policy decision results for future re-use (can be on the server or client side). Our MHS system employs this approach in implementing context-aware policy components. We have a system manager that manages all policy software components and documents.
4.1.1.6. Context-Aware Service Component Location context plays an important role in deciding useful services for users. This is mainly due to each physical space having its own purpose and a user tending to be on the move from one physical space to another. Many existing context-aware systems support the delivery of context-aware services by mapping services with contexts only. Our MHS system has extended the initial context-aware services idea by including a policy (rule) that specifies visibility of services and actions permitted on the service. We have illustrated a sample space policy document that shows a mapping between users, contexts, and services in Figure 3.12 and Figure 3.13. Under different context information, different services would be available to different users. Users can also specify how services should be executed in the specific context. Figure 4.4 illustrates a user’s profile document. It is in an XML document. For different services, different features that a user needs to specify (e.g., to specify what tasks to automatically perform on a mobile Media Player service is different from a mobile VNC service). As for a mobile Media Player service, user A specifies music to be played (e.g., instrumental.mp3 song) when she is approaching room B538_Campus. This song will be played continuously, unless explicitly terminated by the user. As for a mobile VNC service, the user specifies his/her source and target machine IP addresses. The system will look for these IP addresses, when a user is approaching room B535_Campus and requesting to start a mobile VNC service. <UserProfiles id=”user01”> <Service name=”MobileMediaPlayerService”> <Location name="B538_Campus"> <MusicToBePlayed>Instrumental.mp3</MusicToBePlayed> <RepeatPlayed>Yes</RepeatPlayed> <TargetMachine>192.168.0.8</TargetMachine> </Location> </Service> <Service name=”MobileVNCService”> <Location name="B535_Campus"> <SourceMachine>192.168.0.1</SourceMachine>
120
<TargetMachine>192.168.0.2</TargetMachine> </Location> </Service> </UserProfiles>
Figure 4.4: A User's Profile Document Our service in the form of mobile code is stored on the server side and only downloaded onto a client device when needed. This supports extensibility of a service, where we can add many services in the future. Our system computes a relevant set of services based on the policy information as specified in the space policy document. In addition, our system categorizes services into two types depending on its target execution. There is a service that is executed and run only on the mobile device (also known as a non-shared resource service). There is also a service that is executed and run on the mobile device; however, it can initiate a process on other computing machines (e.g., a desktop machine) â&#x20AC;&#x201C; also known as a shared resource service. For example, a notepad service would only run and execute on the userâ&#x20AC;&#x2122;s mobile device, as it is only for displaying the userâ&#x20AC;&#x2122;s online note and uploading information back to the server. On the other hand, a mobile Media Player service that allows users to start any music on any nearby target machines or any embedded devices, needs to provide a way for mobile users to control the running music service from a mobile device. The user also needs to be able to initiate a music service on the target desktop machine. The idea of having different types of services (shared and non-shared) was inspired by the aim of context-aware pervasive computing, in which a contextual system needs to assist users in completing their tasks efficiently and effectively by supporting or providing a number of contextual services. We now describe each type of the services in our system: (1) Shared resource services A shared resource service refers to a software tool that runs on a shared machine (e.g., a shared desktop PC machine) and the actions of a service can be controlled by users from their mobile devices. Some examples of these services that we have developed are: (a) Mobile VNC application. It allows mobile users to display their desktop information 121
on any nearby machines that s/he is currently in [SLS04d]. (b) Mobile Media Player application. It allows users to control the execution of the shared music service in a location from the user’s mobile device [SLS04e]. This can be controlling the state of the music such as start, stop, pause and resume. Other sample applications that can be developed as shared resource services are controlling electric appliances (e.g., light, temperature and kitchen equipments from a mobile device using X10 automation software [X1003]) that provide an API to an appliance and calling the service API within our system. This enables users to control the execution of a service from his/her mobile device. This shared resource service can be controlled and accessed by all legitimate users from their mobile devices in that specific location as the system also downloads the service interface for this shared application. (2) Non-shared resource services A non-shared resource service, on the other hand, is a service that is downloaded onto and compiled on a user’s mobile device only. The instance of that service is running on the user’s mobile device and is only controllable by that user (e.g., a Mobile Pocket Pad service). A Mobile Pocket Pad service allows mobile users to leave an electronic note and store it on the server. The e-note can then be pushed onto a client device when the user is in the right context (i.e., right location, day and time where such an e-note is useful). Some other interesting non-shared resource services that we can have are: (a) Handheld Tourist guide application: displays different types of information as a tourist enters different rooms in a museum or areas in a shopping mall. (b) Timetable service: as user B walks into user A’s room, the system proactively displays a list of user A’s activity on the user B’s device. (c) Library service: where the system can guide a user to find the specific book in the library. (d) Lecture information service: as a user walks into a lecture theater, information related to who and what lecture is currently running in the lecture location is displayed on the user’s mobile device. (e) Reminder service: a user records a list of activities or places or times that the user
122
wants the system to notify him/her. The system then notifies the user if the time or place requirement has been met. (f) Device query service: a user can query for the nearest device (e.g., a printer). (g) Navigation service: this helps users to find their way out of a place. (h) Comments/questions service: this helps students to send a comment or question to the lecturer during the lecture without interrupting the lecture process. (i) Automated task service: a service that performs an automatic task on behalf of a user (e.g., automatically executing email programs, automatically downloading lecture materials, automatically downloading the relevant resources for this week’s lecture to all students in the room, etc). The automation task here is considered useful as: •
it hides the complexity of the service by automatically executing the task,
•
it helps users to execute regular tasks,
•
it suggests or provides help to users proactively, even if the user may not know that such services exist, and
•
it avoids redundancy (especially, if we want to send to large number of users at one time). In our current implementation, we assume that the number of services used in a
location is static. As a result, we store a mapping between policies, services and contexts in an XML document. We employ Web service technology to transfer data from a server to a client or vice versa. This is mainly because Web services support interoperability in disparate platforms and languages. The Web service is also used by a client to invoke available services and a server responds to this request by transferring the requested service to a mobile client device via an HTTP protocol (port number 80). An alternative to a Web service is using plain TCP/IP socket connection. A plain TCP/IP socket connection is easy to develop and maintain, but the main drawbacks are: (a) Both client and server need to know and use a certain port number. A Web service uses a default port no 80. (b) Connection between a client and server needs to be maintained at all times. This would consume lots of power resources on the client device. In contrast, Web services
123
only require an Internet connection and the client/server connection can be done in an ad-hoc manner (no constant connection between a server and client). (c) It does not support communication across disparate platforms and languages. This then limits its ability to extensively exchange messages with other systems which are implemented in different platforms or languages. On the other hand, Web services are the proposed standard which is based on a simple text format and therefore, it can be used across platforms and languages.
4.1.1.7. Register and Deregister Component This component is responsible for registering and deregistering services, policies, environments (i.e., domains and spaces), contexts, entities and computing devices to the system. The registration simply means adding new instance of the element to the system (e.g., adding new services). In contrast, deregistration means removing the existing instance from the system. We store a detail that illustrates environments (see Figure 6.4), entities (see Figure 6.5), contexts (see Figure 6.6), services (see Figure 6.7), policies (see Figure 6.8), and devices (see Figure 6.10) in XML documents.
4.1.2. Client Side Software Components Client side software components reside on the client side. Client side software components interact with server components implicitly to help users perform their daily tasks. This section discusses each of the client software components in our system.
4.1.2.1. Mobile Client Manager When a user selects a service, a mobile client manager contacts central Web services and downloads an application for interacting with selected services. The mobile client manager resides on the mobile client side (e.g., on a mobile device, a laptop, or an embedded device) and manages interactions between a client and server such as: (a) Between a mobile client and system manager. This can be retrieving and displaying a 124
list of available (permitted) services on the device and setting permission on the service (i.e., what actions that a user can perform). (b) Between a mobile client and code server. The mobile client manages the incoming mobile code and prepares to execute the service interface on the device. Our mobile client manager also caches services or mobile code for future re-use. Each downloaded application is specialised for interacting with a specific service and can deliver a rich user interface and functionality, even if the device is temporarily disconnected from the network. This is possible as the client device software caches downloaded applications and stores them locally on the mobile device. The cache contains code and metadata describing applications. Hence, if a downloaded application is running, its cache code also exists in the client memory. Our mobile client software application is developed using the Microsoft .NET Compact Framework technology which natively supports XML, SOAP and remote code loading [MPS02]. Users with mobile devices run software that continually polls a central Web service to discover services which are available at the userâ&#x20AC;&#x2122;s location context. The polling for updating a list of services on the userâ&#x20AC;&#x2122;s device is done periodically (i.e., every 10 seconds). This is to anticipate new services which have been added to that location context or perhaps, removal of existing services from that location. An advantage of having client-side polling is client-side control (i.e., clients decide when to poll rather than a server potentially indiscriminate push). When the user selects a service, the mobile client manager contacts the central Web service and downloads an application for interacting with the selected service.
4.1.2.2. Code Cache Code caching refers to mobile code or service applications which are stored on the mobile device for future re-use. In our current implementation, we clear the code cache when there is an explicit request from users. To remove code from the cache implicitly, we need to consider the following function c, where c(current_context, history or preferences)= application_code
125
that remains in the cache. The function c above describes that at some time t, c takes information about the user's current context and history or preferences (depending on how do we compute a set of relevant services), to determine what application code should remain in the cache (i.e., what should be deleted). Some caching policies may also be required to address the above situation. The policy may remove the code: (a) if the user has not used it for a certain period of time (e.g., two days), (b) if the user has not been in the space where the code is useful for two days, (c) if the system predicts (based on the history file and a user set of preferences) that such code will not be used any more. The policy can also decide when the above functions should be evaluated, such as when there is a need to make space for a new mobile code or when the system detects that the user has just updated their service preferences.
4.1.3. Mobile Code Within our framework we employ mobile code to provide a simplified user interface (an endpoint) to a contextually available XML Web service [CoR03]. The highly compact mobile code application is built using the Microsoft .NET Compact Framework technology. It is compact in size and stored on the server side. The code contains data and service functionality. Based on the userâ&#x20AC;&#x2122;s selection, different types of mobile code applications may be downloaded onto the mobile device for execution. Thus the mobile code delivers a responsive user experience and permits remote Web service calls. Several advantages of having mobile code are: (a) it supports code on demand and so, allows code to be downloaded just when a user needs it, (b) it can be treated like an object that contains service information and data associated with it, and (c) it can be shared among target devices (e.g., a pocket PC and laptop) and so, it supports reusability of the service or mobile code within the system.
126
The development of mobile applications that targets resource constrained devices does incur greater development effort. This is further complicated by attempting to build applications that substantially simplify the mobile users’ experience. In our work, a service is aware of a user’s context. As soon as a user enters a place, the right service is delivered onto a user’s device. The visibility of relevant services is governed by a policy. The policy controls what services are visible for users in particular contexts and what actions that they can perform. The service is an executable application that is written in Microsoft .NET and can be run on pocket PC, laptop, and desktop devices that have .NET run time environment. To accommodate device diversity in pervasive computing environments, a code needs to be run on any target devices (e.g., a desktop, a pocket PC device, etc.). This is possible by using an application based or system based adaptation [FGC98; Nob00; LWZ01]. However, this approach often requires degrading or reducing an application’s fidelity (functionalities and complexities) to adapt to limited (resource constrained) mobile devices. Another approach is to re-write the code depending on a target device. However, it is expensive (in terms of performance) to re-write and compile an application at run time (this is related to performance). A paper in [GNM03] addressed this issue by proposing an adaptive infrastructure for distributed execution (AIDE) [MGB02]. They claim this approach can be done without modifying the application and reducing its fidelity. This is done by partitioning the application during run time and migrating part of the application execution to a powerful machine. There are two key decisions that must be addressed in ensuring efficient program execution: (a) When to offload the application, (b) What policies used to select a partition object to offload at run time.
4.1.4. Repository The system repository resides on the server side. We store service applications (mobile code) in a SQL server database; mapping between context, service and policy is stored in an XML document. The temporary cached service is on the mobile device. 127
4.2.
Execution Behaviours of the MHS Prototype
We now discuss in detail how our MHS controls service visibility and usage in particular contexts. Figure 4.5 below illustrates basic components of our MHS system and how the parts interact.
Ekahau Server Location Tracking System
1a. Send access point information
Mobile Client Software
2b.Call the Ekahau server
2a. Get a user’s location
1b. Start tracking Context Collector Web Service
Location Web Service 3. Return the location
Code cache
4. Pass the user’s context information 5. Send a list of services along with the policy decision result for that location context Policy Software Components
6. Request mobile code 7. Get mobile code 9. Return mobile code
Code Server Web Service
8. Send mobile code
Mobile Code Repository
Figure 4.5: The MHS System Architecture We now describe each of the steps in Figure 4.5. 1a. Send access point information As for the implementation purpose, our system employs the Ekahau Positioning Engine (EPE) version 2.0 [Eka00] in order to keep track of a user’s location (e.g., at mobile computing room). Once the Ekahau software client that is installed on a mobile user’s
128
device is switched on, the EPE server then starts tracking the position of the mobile client. The advantage of using Ekahau is that it is a purely software solution that does not require any extra hardware other than wireless access points. At the end, the MHS system only wants to get the symbolic location representation of a user. By calling location sensing system APIs, the EPE starts tracking a user’s location. In general, there are several issues that need to be addressed when sensing a user’s location: (a) accuracy of a user’s current location, (b) minimum delay in retrieving and updating a user’s current location, (c) complexity in interpreting a user’s location. This depends on a location representation modelling which can be geometric (based on coordinates such as x,y,z) or symbolic (based on a name representation such as a mobile computing room), and (d) calibrating and partitioning a space, especially if a boundary of the space is large. 1b. Start tracking Our system provides a login mechanism. The user needs to enter the credentials information such as user name and password. The system then validates these credentials against the user’s information, which is stored in an XML database. The system will only redirect the user to the main service form, if all information that s/he entered is valid. If the user is valid, the system then invokes a Web method of the Context Information Web service called “Start Tracking” by passing the IP address of the device. At this point, the system also knows detail information about the user (e.g., the user’s role, the user’s ownership, and the user’s policy) as stored in an XML document (see Figure 6.5). 2a, 2b and 3. Get a user’s physical location, call the Ekahau server and return the location As discussed in Section 3.1, Chapter 3, we model our pervasive computing environment into logical boundary (domain) and physical boundary (space). One space boundary can consist of several sub spaces. In order to retrieve the user’s current physical location (e.g., at mobile computing room), the system then continues to invoke the “get user
129
location” Web method of the Location Web Service and again passing the IP address of the device to this Web method. The Location Web service then fires the Location Listener Application on the Ekahau Server. The Listener application then continuously listens to the mobile user’s movement. Finally, this Web method returns the most accurate user’s current location to the method caller (i.e., a context collector Web service). The following is a code snippet on how to retrieve context information in the C# .NET language (see Figure 4.6). Public ArrayList GetCurrentContexts(string userID) { String userLocation=””; ArrayList currentContexts = new ArrayList(); System.Current.DateTime dateTime = new System.Current.DateTime(); //retrieve a user’s current location by calling the Ekahau //positioning System userLocation = GetUserLocationContext (userID); //store the value returned to currentContexts Array List currentContexts.Add(userLocation); //retrieve the space current activity by calling space activity //Web method, then stores the value returned to currentContexts //Array List currentContexts.Add(GetSpaceCurrentActivity (userLocation, dateTime)); //retrieve current date and time //then stores the value returned to currentContexts Array List currentContexts.Add(dateTime); return currentContexts; }
Figure 4.6: Get Current Contexts Web Method Besides retrieving the user’s location information, the context collector also retrieves other contexts used in the system (e.g., current day, time, a user’s identity and a space activity). The updated current day and time are obtained by checking the current system day and time. The user’s identity is retrieved from the login form, once the user logs on to the system. In order to retrieve the activity that is currently running in the space, the system then looks for the mapping between a space, contexts and activities information in the context_activity.xml document (as shown in Figure 3.11).
130
4. Pass the current userâ&#x20AC;&#x2122;s context information Once the context collector retrieves all the context information, the context collector Web service then calls the policy software components, passing them the context information. The policy software components need to retrieve the relevant policy document and looks for relevant services and actions permitted based on the given context information. A list of permitted, obligated, and prohibited services along with actions is then returned to a mobile client manager that resides on a mobile client device. This information is updated when the system detects that a user has moved in/out of a space. We discuss in detail in Section 4.2.3 how our run time policy mechanism works. 5. Send a list of services and policy details to the mobile client manager A list of services and its policy details will then be sent to the mobile client device. The mobile client manager then displays the service names as permitted by the space policy. When the policy documents (on the server side) are updated by a developer or the owner of the space, the policy manager then sends the updated policy details to the mobile client manager. We have a windows service that is running on the server side that constantly monitors the policy details. Therefore, when a new policy document is created, or the existing policy is modified, the policy manager is then notified by this windows service. 6, 7, 8, and 9. Request mobile code and return the mobile code When the user chooses a service from this list, the code server Web service is contacted to provide code for invoking the selected service. This returns a mobile code application to the client device. We only download the code for a particular service as requested by the user (as the user needs it), in order to save resources (e.g., memory storage, power and processing speed) on the mobile device. This also reduces processing loads on the server side to find all relevant service code and download them to a client device. Upon its arrival, the mobile client application then compiles and displays the service interface to the user. The run time policy decision checking component only gets called when the service interface has been displayed and the mobile user is requesting to execute a certain action on the service (e.g., by clicking on the start button on the Media
131
Player service interface on the mobile device). This is to check users’ permission in performing actions on the service (see section 4.2.3).
4.2.1. Accessing Shared Resource Services There are more steps involved for executing shared resource services (e.g., a user requests to start an instrumental music on the desktop machine A). This is mainly because a shared resource service involves an execution of a service on the target machine (e.g., a desktop machine) and so, it requires some mechanisms to handle an interaction between a user and an application that is running on the desktop machine or embedded device. Executing a non-shared resource service on the mobile device only requires steps 1 to 9 as discussed in Section 4.2. Figure 4.7 describes a situation where a remoting service is called to execute a shared service on the particular target machine, when the user selects the service functionality (e.g., start mobile VNC service).
2. Get the user’s information based on the service selection. In this case is a user’s Machine IP
3. Search for a user’s information
5. Return the user’s Machine IP 6. Start the contextual service on the target machine 1. A user selects the service name i.e., a mobile VNC service. Then, selects the target machine
User Profiles XML database
User Profiles Web Service 4 Return the user’s information
7. Display a user’s desktop information Mobile VNC Service
Coolcampus machine
Remoting Web Service Mobile Media Player Service
Goalpool machine
Figure 4.7: Starting a Shared Resource Service The following steps are called when a user is clicking on a service name and the service is of a type shared resource service. In our system, a mobile client does not need to have
132
knowledge of the Web service API, the type of service that s/he wishes to execute. All these interactions between a client and server are handled implicitly by the system. In this case, the respective remoting Web service is called upon clicking on the service functionality. We now illustrate in detail how the shared resource service (using the example of a Mobile VNC service) is executed on the target machine once the shared service interface is displayed on the mobile device: 1. A user selects a target machine name As soon as the service (e.g., a Mobile VNC service) is displayed on the mobile device, a user will be able to see a list of target machine names. Here, we assume all the target machines are in the idle state (e.g., none of users have teleported to this machine). We store information regarding the mapping between a room and list of machines in an XML document. By knowing a user’s current location, our system will be able to search and get a list of available machines for that particular room. The profile contains information related to the user and the selected service (e.g., a user’s source machine IP Internet Protocol for Mobile VNC service), favorite music (for Mobile Media Player service), etc. It stores a mapping between a location and all information required for the service (e.g., a mapping between a location and a user’s favourite music), a mapping between a location, user and the user’s machine IP address. The information stored (e.g., a list of songs) is different for each user and space (depending on the user’s preferences). Basically, depending on the selected service, the system will search for relevant information in a user’s profiles document. For example, if a user selects the Mobile Media Player service, a user’s favourite music is returned depending on the user’s current location. 2. Get the user’s machine IP Once the user selects the target machine name that s/he wants his/her desktop information to be displayed on (for Mobile VNC service), our system will then get the user’s desktop machine IP. 3, 4 and 5. Search for the user’s machine IP and return the user’s machine IP This then calls the User Profiles Web service to search for the user’s machine IP from a user profiles XML database. If the mapping is found, the user’s desktop machine IP is 133
then passed on to the remoting Web service. 6. Start the service on the target machine Once it is found, the system will initiate a remote connection to the specified target machine (e.g., starts the VNC service on the target machine by calling a Remoting Web service). Note that, the .NET Remoting client (in the form of .exe file) needs to be run on the target machine before all the communications between a Web service and the target machine can be performed. In addition, the Remote Web service contains code that can perform a task to start or stop the process of the VNC service on the target machine. In .NET Remoting technology, a more robust approach to invoking objects can be achieved by using interfaces to define the contract between a client and a server, where normally an interface and its implementation reside on the client side. Here is a sample of the remoting client that implements the method called remoteVNCStart of the IRemoteVNCForm interface. Once, there is a request from a Remote VNC Web service to execute this method, the VNC process will then be started on the target machine. The code snippet below is written in the VB.NET language. <WebMethod()> Public Function remoteControllerStart(ByVal sourceMachineIP As String, ByVal targetMachineIP As String) As Boolean Try Dim remote As Monash.IRemoteVNCForm = Activator.GetObject(GetType(Monash.IRemoteVNCForm), "tcp://"+ targetMachineIP +":1000/RemoteVNC") remote.remoteVNCStart(sourceMachineIP) Catch Return False End Try Return True End Function
Figure 4.8: A Remote VNC Web Method Figure 4.9 illustrates a sample of a remoting client that implements the method called remoteVNCStart of the IMediaPlayerForm interface. This remoting client in the form of
134
a .exe file resides on the target machine. This remoting client is called if there is a request from a Remote VNC Web service to execute the service on the target machine. As a result, the respective process will then be executed on the target machine (i.e., a VNC process or a Media Player process). The code snippet below is written in the VB.NET language. //This Web method takes an input of a target machine’s IP address Public Sub remoteVNCStart(ByVal machineID As String) Implements IMediaPlayerForm.remoteVNCStart //initialize the System.Diagostics process in order to start the //service i.e., VNC service on the target machine Dim aProcess As System.Diagnostics.Process aProcess = New System.Diagnostics.Process //specify the location of the file aProcess.StartInfo.FileName = "C:\\Inetpub\\wwwroot\\vncviewer.exe" //pass in the user’s machine ID to a System.Diagnostics process aProcess.StartInfo.Arguments = machineID //start the execution of the specified process i.e., a VNC service aProcess.Start() End Sub
Figure 4.9: A Remoting Client Web Method 7. Display a user’s desktop information on the target machine Once there is a request to start an application (e.g., a VNC application), our remoting client that resides on the target machine then starts the application process. This then displays a user’s desktop information on the target machine. We have a generic architecture and shared contextual software components to execute any shared resource services within the system. The steps above are similar for executing other shared resource services (e.g., a Mobile Media Player service, TV, Radio service, etc.). Our remoting Web service here contains general information about a service (i.e., what service to execute, where to execute the service and in which target machine the user wishes to execute this service). Ability to add context-aware behaviours to traditional applications is possible via our system through an application API for complex application functionalities that can control appliances installed in the environment (e.g., a lighting, room temperature and
135
Media Player service). For a simple application that runs on a desktop machine or any embedded device would not be required to have a system API. This can be easily done using “system.diagnostic.process.start” to start this application and to stop it “system.diagnostic.process.stop” (e.g., a VNC service). To process policies, the system uses multiple threads. The threading process will run once the mobile client application is started on the device. This running thread will keep monitoring the current time and location of the user. Once the time and location are detected, our system then automatically downloads and executes the specified service on the mobile device. For example, a system detects that there are two lists of machine names in the room. The system then searches through an XML database of user profiles to find out on which target machine the user wants his/her desktop information to be displayed. Once it is found, the system then calls up the Remote VNC Web service and passes on the user’s desktop machine IP. After this, the steps are the same as steps 6 and 7 above. After describing starting of VNC (or any other applications) on the target machine, we discuss the steps to terminate the application and as VNC (see Figure 4.10). In general, there are two possible reasons why a service (like VNC) needs to be terminated on the target machine: (a) if the system detects that user is no longer in the room i.e., if the user has walked out, and (b) if the time to stop the service in the user’s policy file has been detected. In this case, a user specifies in his/her profile about when to start and terminate the server side process (e.g., VNC). The second option would be viable if there is regularity in the user’s activities. For example, at home, a user always checks his/her email at around 8-9PM and this is done by teleporting to his/her desktop machine at the office and the user usually finishes checking his/her email at around 10PM. By specifying such behaviour in a policy file, the user is freed from performing regular tasks (e.g., to activate and terminate the VNC service and take advantage of the system to do it automatically). 8. Get the user’s updated location and return the updated location Our system uses either of the above two ways to terminate the (VNC) service process on the target machine. Our system first checks whether the user is still in the same room. If
136
the system detects that the user has walked out of the room, the system then continues with step 14. Otherwise, steps 9,10,11,12 and 13 are performed. 9, 10, 11, 12 and 13. Get the user’s policy and return the policy to the mobile client application If the system detects that the user is still in the same room, the system then looks for the user’s policy. If the time to shut down the (VNC) service has elapsed, the system then continues with step 14, otherwise, the system continues to monitor the user’s current location (refer to step 8 above). 14. Shut down the (VNC) service on the target machine If there is a request to shut down a (VNC) service, the remote client that resides on the target machine then needs to kill the running process of the (VNC) service. 15. A (VNC) service is terminated After the (VNC) process associated with the service is killed, the (VNC) application that is displaying a user’s desktop information is then terminated.
Location Web Service
8. Get the user’s updated location
14. Shut down the VNC service on the Coolcampus Machine if the system detects that the user has walked out from the room or the time has come Remote VNC Web Service
9. Return the user’s updated location 10. Get the user’s policy on when to terminate the VNC service Policy Web Service 11. Get the user’s policy
15. A VNC service is terminated 13. Return the user’s policy 12. The user’s policy found
Coolcampus Machine
User Policy XML database
Figure 4.10: Terminate VNC Service on the Target Machine 137
The steps 1-15 described above can be the same for adding context-awareness to other applications such as Media Player, Games, etc. The difference is that instead of the Remote VNC Web service starting the VNC process on the target machine, another type of application process will be started. The user may want to specify different execution and termination policies in the user policy XML database. Other points of control, apart from starting and stopping, can be done if an application has an API to allow control from external processes. In addition, the steps required to terminate the shared resource service on the target machine are much simpler than to start it. Basically, as soon as the system detects the userâ&#x20AC;&#x2122;s selection to terminate the running service, the system then calls the remoting Web service to perform the specified action (i.e., stop the running service).
4.2.2. Policy Conflict Detection and Resolution in MHS As discussed in Section 3.4.7.2, Chapter 3, there are five techniques used to detect policy conflicts. We observed that each of the proposed conflict detection techniques has its own advantages and disadvantages: (a) Static conflict detection This technique finds all potential conflicts that may happen in the future and therefore, speeds up the performance in responding to the userâ&#x20AC;&#x2122;s requests. However, this technique only suits if the number of entities in the system is not many; and the number of policy specifications and number of entities in the system are relatively static. More entities mean more policy specifications which mean more policies to compare. Allowing entities to modify his/her policy document at run time or registering new users, requires the system to update the static conflict detection result which has been previously computed. Hence, it will use up a lot of resources and may be tedious, as it has to redetect the conflict between all entities in the system. (b) Reactive based dynamic conflict detection
138
This technique takes a shorter time to detect potential conflicts in the given context, as it only checks the conflict between the requester and users in the room. It suits any situation (i.e., static/dynamic system elements such as policy documents, entities, services and contexts) as the conflict detection is triggered reactively (i.e., when there is a request from a user to perform an action on the service). The main drawback of this technique is long delays in detecting the conflict between entities, as the system only starts to detect the conflict when there is a request from users. (c) Proactive based dynamic conflict detection This technique accommodates potential conflicts in the given context (hence, reduces the user wait time). It uses less system resources (memory and CPU processing) compared to the static conflict detection technique. This is because it only detects conflicts between entities which are in the same context (not all entities in the system). It suits any situation with static or dynamic system elements (e.g., policy documents, entities, services and contexts used in the system). However, the system maintenance can be challenging, as we need to know the best time to update the conflict detection result. For example, an update can be performed: (a) when the system detects that there is a new user moving in or out of the space, (b) frequently every 5 seconds, or (c) when the system detects there are more than a certain number of users in the space (e.g., more than two users in the room). (d) A combination of reactive and proactive based dynamic conflict detection This is an ideal technique among all other conflict detection techniques. It accommodates all potential conflicts in the given space by using a combination of reactive and proactive techniques. It can be proactive in some situations and reactive in others and so, can further reduce system resources (memory and CPU processing). It suits any situation (with static or dynamic system elements such as policy documents, entities, services and contexts). The only issue is developers need to decide when and under which situations a proactive or reactive behaviour should be performed. (e) Predictive based dynamic conflict detection This technique is more complex to develop and maintain. It also does not accommodate the userâ&#x20AC;&#x2122;s unpredictability. 139
It is imperative to be clear about when to perform the conflict analysis (conflict detection and resolution), as it can be computationally intensive, time and resources consuming. Our MHS system implements only a reactive conflict detection technique. This is because, potential conflicts which are detected at run time using a reactive technique have a higher possibility to become actual conflicts compared to other policy conflict detection techniques (i.e., a proactive, predictive or static conflict detection technique). This is mainly because with the reactive technique, the detection is only performed when there is a request from users and the detection is looking for conflicts only for the current day, time and location. If there is a conflict found, the contexts for the conflict to occur must have been met. On the other hand, a proactive, predictive or static conflict detection technique detects all potential conflicts between users in the particular context, even though the context conditions for the conflict to occur have not been met. Therefore, some of the conflict detection results may never be used as the entities may never be in the context as they are predicted or one or more entities have been deregistered from the system; hence, the predicted potential conflict never becomes an actual conflict. In addition, our MHS system implements four conflict resolution techniques (i.e., role hierarchy overrides policy, space holds precedence over visitors, obligation holds precedence over rights, and maximum execution time policy) as discussed in Section 3.4.8.3, Chapter 3. We summarise the process of selecting the relevant conflict resolution technique based on the sources of conflicts in Figure 4.11. The system first needs to know the source of the conflict such as whether it is between an obligation and right. The obligation holds precedence over rights technique is applied if the conflict happens between an obligation and right, regardless the place of where the conflict occurs and role of conflicting entities. If the conflict occurs other than between an obligation and right (e.g., between permission given to one user and another), the system then checks the place of where the conflict occurs (e.g., in a public space or in a private space). If the conflict occurs in a public space, the system then checks the role of conflicting entities (e.g., whether they have the same role or different roles). If they have different roles,
140
then the system applies the role hierarchy overrides policy. If they have the same role, the system then applies maximum execution time policy.
Figure 4.11: MHS Policy Conflict Resolution Techniques In contrast, if the conflict happens in a private space, the system then needs to check the ownership of a space (e.g., any of the conflicting entities own the space). If one of them owns the space, the system then applies the resolution technique of space holds precedence over visitors. If none of them owns the space, the system then checks the role of conflicting entities. If they have different roles, the system then applies the role hierarchy overrides policy. However, if both of them have the same role, then maximum execution time policy is applied instead.
4.2.3. Controlling Usersâ&#x20AC;&#x2122; Behaviours Our policy language is implemented using XML. XML based standardization is a key to interoperability in many systems and platforms. This is due to the fact that XML is a
141
simple and flexible text format that can be easily read in and manipulated in any languages and platforms. Moreover, many existing languages (e.g., Java, VB.NET and C#) support an XPath query language [W3C99] for XML based documents. With XPath, we can query or search for a particular node or element. Once the result is returned, we then parse XML elements into a local system data representation and manipulate it accordingly. Querying for certain elements can also be done in a minimum amount of time. Our policy document contains a mapping between rules, services and contexts. It shows differences in deontic permission, obligation, prohibition of actions and service visibility depending on the userâ&#x20AC;&#x2122;s role. Our policy document conforms to the policy XML schema (as shown in Appendix). We have illustrated examples of our policy documents in Figure 3.12 and Figure 3.13. Our policy implementation is modular and interoperable. We separated policy tasks according to its functionality such as a policy manager, policy conflict detection, policy conflict resolution and policy execution. Each of these policy functionalities is implemented as Web services. We also separated the implementation of context-aware policy from context-aware services. Our system stores the context-aware policy software components and the policy documents on the server side. This then supports extensibility of the system, as we can add additional policies in the future. In addition, in order to know the relationship between a domain and spaces (e.g., a mobile computing room is within lecture hall building and the lecture hall building belongs to the Caulfield campus sub domain and this sub domain belongs to a campus domain), the policy manager queries the environment document (see Figure 6.18). This relationship information is useful for applying a relevant policy in the space (e.g., what policy document should be used for this space?). As discussed in Section 3.4, Chapter 3, the relevant policy of where the user is currently in, is dominant over a global policy. The global policy refers to the policy which is in the higher hierarchy of an environment (a domain and spaces) structure. For example, if a user is currently in the mobile computing room, the upper environment structure is a lecture hall building, followed by a Caulfield campus sub domain, and lastly, followed by a Campus domain. In this case, if the space does not have a local policy, then the closest global policy is applied. For
142
example, if the mobile computing room does not have a policy document, then the lecture hall building policy is applied in the mobile computing room. We now discuss how our run time policy mechanism works (see Figure 4.12).
Device status
1. Send a query to start a service
5 Mobile client manager
2. Retrieve policy decision results Policy cached results on a mobile device
4b (not allowed) 3a Policy manager
3a 3b 4b
3b and 4b (Allowed)
Policy conflict detection 4a Policy conflict resolution
Policy execution
Figure 4.12: The MHS Context-Aware Policy Implementation The steps in Figure 4.12 above are: 1) Request an action (e.g., start) on a service Once the service interface is displayed on a mobile device (e.g., see Figure 4.13b), a mobile user can request to start music on a Media Player service by clicking on the â&#x20AC;&#x153;play buttonâ&#x20AC;?. 2) Retrieve policy decision results
143
The policy decision checking is computed at run time, just when a user requests to perform certain actions on the service. It is done by a mobile client manager by reading a local cached policy decision result that has been downloaded onto a mobile device (as completed in step number 5 in Figure 4.5. The policy decision checking takes into account a userâ&#x20AC;&#x2122;s current contexts and checks the requested action against the cached policy decision result. The policy decision result is either allowing or disallowing users from performing the requested action. The owner of the space can access and execute any services with any actions that s/he likes in his/her room. We exclude the owner of the space from the policy decision checking. The mobile client manager looks for the policy when a user requests a service (e.g., at Context C, user A is allowed to start service S with any action). In this case, the system will not perform any checking for subsequent action requests on the service. However, if the policy said that user A is only permitted certain actions on Service S (e.g., only allows to start, but not to stop), the system then needs to check for the policy decision result for the subsequent requests. This is possible in situations (e.g., during exam time) where the space only gives students partial control (access) to the service (i.e., a mobile pocket pad service). For example, they can post their notes, but they are not allowed to retrieve their notes. In this case, the policy checking is done per action, where for each action requested, policy checking is executed. We employ two types of policy decision checking: per service and per action depending on the policy decision result. Employing only a single policy decision checking (e.g., checking per action) may not be necessary due to: (1) users clicking on the same action more than once, and (2) for some services (e.g., a mobile VNC service), allowing users to start the service, would also require permission to stop the service. By default, this service gives permission to users to perform any action (i.e., start or stop) on the service. Hence, for this service, checking does not need to be done per action, instead, we check it per service or per collection of related actions on a service. This simply means when the service is allowed, all actions on it are permitted by default. In addition, the requested action is only allowed if there is permission given by a space. If there is no permission given (e.g., service allowed =â&#x20AC;?noneâ&#x20AC;?), this simply means
144
the requested action is not allowed. Our system employs both right and prohibition policy objects to determine the service visibility and actions allowed to users. If the permission does not specify the requested action (absence in the permission) such as service allowed =”a particular service” and users are requesting other services than in the permitted list, the mobile client manager then continues to consult the prohibition rule. If it is prohibited, then the requested service is not allowed. If the prohibition rule does not say anything about the requested service (absence of the prohibition rule) such as service prohibited =”a particular service”, which is not the requested one, then the system permits the user to perform the requested action. We summarise our policy decision checking in Table 4.1. Right
Prohibition
Service Allowed
Service Prohibited
Particular Service
Any
None
Result
Any
None
Particular Service
x
-
-
-
x
-
Any services are visible and users are allowed to access any visible services.
-
x
-
x
-
-
It further checks the prohibition. As it prohibits any, none of services are visible to users.
-
x
-
-
-
x
None of services are visible to users.
-
-
X
-
x
-
Only a particular service (as listed in the right) is visible to users.
-
-
X
-
-
x
Only a particular service (as listed in the right) is visible
145
Any
Right
Prohibition
Service Allowed
Service Prohibited
None
Particular Service
Any
None
Result
Particular Service to users.
Table 4.1: Policy Decision Checking
Our system checks for consistency of rights, obligations and prohibitions of the same activity within the same policy document. This is to avoid unnecessary inconsistent value of permission, obligation and prohibition. For example, things that are permitted, should not be prohibited. Likewise, things that are prohibited should not be permitted. When the internal consistency of policy document is achieved, the system then validates the policy document against the policy schema (as illustrated in Appendix). Our system also checks for the conformance of uOsp against the permission that the space gives to the user in that specific location. This is mainly because our system only allows the user to perform a task which is permitted by the space. For example, if spRui specifies that user i can only start the music service on Monday from 12-2PM, this means that the uiOsp has to satisfy that condition (Monday, from 12-2PM). The user is not allowed to impose an obligation on the system to start a Media Player service other than Monday, 12-2PM (other than the permission given by the space). As they move from one space to another, they need to adapt to rules specified by a space. This is to ensure that the uOsp is still within the scope of the user’s permission. The system will review whether or not the requested user’s obligation is allowed. This is to avoid a conflict between a user and a space, where a user has specified things to automatically perform, but a space does not allow such a task to be executed due to out of scope permission. In addition, our system further checks on the consistency of the value of attribute name “on”. This is to ensure that the rule is imposed to all users in the system (not only to some users). This then helps to avoid the misinterpretation of how the policy object
146
should be interpreted and unnecessary redundancy. The value of attribute on=“any” means the policy object is applied to any users in the system. The value of attribute on=”a particular entity” (e.g., on =”GeneralEntity”) means the policy object is applied only to the specified entity. The value of attribute on=”OtherEntities” means the policy object is applied to other specified entities. Therefore, if developers or owners of the rooms have specified the value of attribute on=”any”, they do not need to explicitly impose the rule for each of the entities. Specifying the rule for each of the entities is considered redundant. Moreover, if they have specified attribute on=”a particular entity”, to specify imposed on other entities, they should use on=”OtherEntities” instead of on=”any”. This simple means for other entities that is absence in the policy object, the system then reads the rights, obligations or prohibitions from on = “OtherEntities”. The attribute on=”OtherEntities” needs to be used in conjunction with attribute on=”a particular entity”. We describe in Table 4.2 the policy consistency checking of the “imposed on” value.
Imposed On value
Imposed On
Imposed On
“Any”
value “A
value
particular
“OtherEntities”
Validity
entity” x
-
-
True
-
x
x
True
x
x
x
False (redundant)
x
x
-
False (redundant)
x
-
x
False (redundant)
-
x
-
False (incomplete. It needs to specify other users in the system too)
-
-
x
False
(incomplete,
other
entities can only be used if
147
Imposed On value
Imposed On
Imposed On
“Any”
value “A
value
particular
“OtherEntities”
Validity
entity” there is a particular entity) Table 4.2: Policy Consistency Checking of “Imposed On” Value As for non-shared resource services, when the service is permitted and the requested action is allowed by a space, the mobile client manager then performs the requested action (e.g., retrieving a user’s information on a Mobile Pocket Pad service), and no further checking needs to be done (i.e., policy conflict detection and resolution). As soon as the system permits a user’s request to perform an action, the mobile client manager then contacts the policy manager. In addition, a mobile client manager also continuously runs the thread that checks the occurrence of a list of obligations which are imposed by a space on a user (spOu). When the time elapses, the mobile client manager then alerts users (if they are currently logged on to the system) by popping up the message box on their computing devices. This acts as a reminder for users to fulfill their obligations. As for obligations which are imposed on the space by a user (uOsp), the system manager (on the server side) periodically checks for a user’s task list (i.e., uOsp) to look for opportunities to automatically provide assistance to users [SLS04a; DCM99]. For example, automatically play a user’s favourite music at room B538 from 12 to 12:30PM, when the context is satisfied. The context information of when and where to perform such tasks can be retrieved from context_activity document (see Figure 3.11). When a system detects that the user (the one who specifies uOsp) is currently approaching the destination space, where the obligation needs to be fulfilled and when the current day and time are matching to the context of uOsp policy object. The system refers to a user’s profile document (see Figure 4.4) to find out the details of the task to be automatically performed. Such details are what music to be played and how to play the music. The details of the task are retrieved by matching the location name.
148
Having a proactive task assistant is considered useful as the information or task that users required are ready before the user reaches the place. The above proactive sample scenario extends the idea of having context based services by allowing the end user to define a rule or policy that specifies when, where and what type of service that s/he wants to be automatically displayed or started at each particular situation. The rules or policies here can also be used to restrict the behaviour of the service in the specific context. For example, start the music at 12PM and pause it for 15 minutes at 12:15PM. It also helps to improve the userâ&#x20AC;&#x2122;s experience, especially if there is regularity in the userâ&#x20AC;&#x2122;s activities. 3a) Call the policy conflict detection The policy manager then calls a policy conflict detection component to detect whether or not there is a conflict when the requested action is performed. As we detect the conflict only at run time, the only way to detect whether or not there is a conflict is by checking the status of the shared resource device (e.g., not running - idle or running - in use). If it is in idle mode, the user is then permitted to start the requested service and action. There is no conflict here. If it is currently in use and a user requests to execute the same service with different actions, this then creates a conflict. The system needs to resolve this conflict by using one of the proposed conflict resolution strategies (as discussed in Section 3.4.8.3, Chapter 3). Policy checking for executing a process or performing an action on the shared resource service involves more steps than a non-shared resource service. This is due to, less or almost no conflicts occuring for non-shared resource services and so, there is no further conflict checking (e.g., between users) required. Hence, it takes a shorter time to respond to users who wish to perform an action on non-shared resource services. 3b) Send the result back to the policy manager and call the policy execution If no conflict is detected when requesting a shared resource service, the conflict detection module then sends a message to the policy manager (e.g., allowing user A to execute the specified action as no conflict has been detected and so, no resolution is required). The
149
policy manager then calls the policy execution to perform the specified action on the service (e.g., start playing “First Noel” at any nearby desktop machine at room A). 4a) Call the policy conflict resolution If there is any conflict detected in step 3 above, the conflict detection result is passed onto the policy conflict resolution component. Our conflict resolution resolves conflicts as soon as they are detected. All conflicts which are detected are actual conflicts, as our system detects conflicts only at run time and the contexts for the conflict to occur have been met (we employ the optimistic conflict resolution technique as discussed in Section 3.4.8.2, Chapter 3). In addition, depending on the result of the policy conflict resolution, the requested action may or may not be permitted. 4b) Send the result back to the mobile client manager and call the policy execution This conflict resolution result is then passed back to the policy manager. If the requested action is permitted, the policy manager then executes the requested action. However, if there is a conflict and the result stated that the user is not allowed to perform the specified action, the policy manager then sends back this message to the mobile client manager. 5) Update the shared device status The shared computing device status only gets updated when there is permission to perform an action and the requested action is permitted. This then changes the state of a service from “not running” to “running” or from “running” to “not running”. This is particularly useful for shared resource services where services can be accessed by many users simultaneously from their mobile devices.
4.2.4. Partial Control between Users and the System As our system supports both a manual and automatic execution of a service, it is important to clearly separate the control between users and systems (i.e., when control should be given to the user and when the system should be in control). The control becomes extremely important, especially when the user performs some odd activities
150
during the day, which is different from the tasks that s/he has specified in the policy document as obligations imposed on the system (i.e., uOsp). For example, a user is having a group meeting at room A (the user’s personal office). He specifies in the policy document to automatically start the music at his office at 3PM. However, what happens if the meeting has not finished at 3PM. As discussed before, as soon as the current time shows it is 3PM, the system will automatically start the music in room A. The system does this automatically by interpreting a user’s policy document and it will not be able to tell whether the meeting is over or not. If such a situation happened, most likely, the user will want to manually stop playing the music from his/her mobile device. This is done through selecting the service name (e.g., remote media player on the mobile device) and a mobile code with respect to this Remote Media Player service will then be downloaded onto the user’s mobile device. Once the service interface is displayed, the user then clicks on the stop button to manually terminate the playing music. Once the system detects that the user is manually performing the task and this task is different from the activity that s/he has specified in the policy document, the full control is now given to the user. The system will not perform any further policy interpretation (and music execution) until the system detects that the user has closed the remote Media Player service form. Once, the form is closed the full control is now returned back to the system. The system then continues to interpret the user’s policy document and automatically start, pause, resume or stop the music. In summary, our current control scheme is as follows: the user takes control of the service by requesting and using the mobile code application (containing the user interface) for the service and control is returned to the system when the user closes this application.
4.3.
Adding New Context-Aware Services
We have developed a context-aware system that delivers useful services to users at the right context and at a high level of abstraction that separates service applications from the system. This makes it easier for developers to add new services in the future. In the
151
past, many context-aware systems embedded the context-aware strategies in the code itself and within the system in a tightly coupled way that complicates both the application’s design and run time adaptation to its change contexts or execution environments. Our system separated the contextual service design and functionalities from its contextual information (i.e., a user’s location, day, and time), and the space policy. From a developer’s perspective, a service means mobile code that consists of service interface and information that helps users accomplish their tasks. There are four steps required to add new services to our MHS system: 1. Creating mobile code Mobile code can be developed by creating a mobile or Web application from Visual Studio .NET tool and by referencing our MHS software component libraries. Basically, developers just need to concentrate on the service functionalities (e.g., a mobile navigation service is to guide users find a specific location). Developers need to know how to provide this navigation feature by taking into account a user’s current location context. All the low level tasks such as caching, downloading code, security and data persistence are handled by our MHS software components. 2. Registering mobile code (a service) Once the mobile code is created, developers then need to register it with the system. Our MHS framework supports registration and deregistration components as described in Section 4.1.1.7. 3. Mapping rule, service and context information Once the mobile code is created, the next step is mapping the rule, service and context information. We store this mapping in XML. The mapping here is done by (a) a developer who specifies a list of services and actions permitted on the service in public spaces (e.g., at tea room, seminar room, printing room, etc. as illustrated in Figure 3.12), (b) a user who owns a private space (e.g., a personal room – H7.38 room) specifies a list of services along with its permitted actions that s/he wants the system to automatically perform; and services that visitors can see and perform in his/her room as illustrated in
152
Figure 3.13, and (c) a user who does not own a space specifies a list of services as well as actions that s/he wants the system to automatically perform (as illustrated in Figure 3.14). When executing this automatic task, the system first checks the userâ&#x20AC;&#x2122;s current contexts (e.g., current location, day and time). The task is only performed when the contexts have been met (e.g., when the user is approaching the room, in the certain day and time). 4. Creating specifications for services As for an automatic task service, a user also needs to specify what, when and how the task gets done. This service specification is stored in a userâ&#x20AC;&#x2122;s profile document (see Figure 4.4). The specification here may be different across domains. Basically, things that need to be defined for an automatic task service are (a) when to start and terminate a service? For example, for a home domain, start the service when a system detects that a user is approaching a living room and terminate the service when the system detects a user is walking out of a living room. However, for a campus domain, start the service when a user is walking towards the corridor at Building B level 3 and terminate the service if the user has walked out of his/her office, and (b) where such a service needs to be executed or terminated? For example, start the service at room B536.
4.4.
MHS Sample Context-Aware Services
This section describes three sample services that we have developed using the MHS framework. Each section discusses in detail the purpose of a service unit and how to use it.
4.4.1. Mobile Pocket Pad Service Mobile Pocket Pad allows users to type in any information and stores the information back to the server. We have implemented a simple interface of our MHS system on laptop and handheld devices (see Figure 4.13a and Figure 4.13b below). After selecting the service name (i.e., a Mobile Pocket Pad service, a managed mobile code for this
153
service is downloaded and executed on the device) as shown in Figure 4.13c. Note only one service is listed but there can be many others. This list of services is specified in the space policy document (see Figure 3.12 and Figure 3.13). As discussed in Section 3.4, Chapter 3, the available services depend on the following contexts: a userâ&#x20AC;&#x2122;s current location, day, time, a userâ&#x20AC;&#x2122;s role and activity that is currently running in the space. When a user is in the different location context (e.g., a lounge room), day, time and a space has a different activity, the user could see different services. Two users could also see different services under the same context. This is due to the fact that, we further customize the available services for users depending on their role.
(a)
154
(b)
(c)
Figure 4.13: (a) Accessing the System from a Laptop Device (b) Accessing the System from a Pocket PC Device and (c) Mobile Pocket Pad Service
4.4.2. Mobile Remote Media Player Service A mobile remote Media Player service is a music service that allows mobile users to initiate any music on a target machine. A user can then control this execution from the user’s mobile device. This service is tailored to perform two different features: (a) Manual execution The user manually selects the type of music that s/he wants to listen to. For example, after selecting the service name (e.g., remote media player – see Figure 4.14a), a managed mobile code for this service is downloaded onto and executed on the user’s mobile device (see Figure 4.14b). When the user selects one of the target machine names (e.g., a Coolcampus machine – see Figure 4.14b), a list of songs on this machine is then displayed. Then, when the user selects the song name and clicks the play button, this song will then be played at the Coolcampus machine. The mobile user can also control the currently running Media Player service from the user’s mobile device. This is
155
because, we implemented a remote Media Player service interface that allows users and software clients to remotely initiate a process of any service (e.g., a Media Player service with processes such as start, stop and pause the music) from a user’s mobile device on the specified target device. (b) Automatic execution Users specify songs to be automatically played in the specific context in their policy documents (user imposes an obligation on the system – uOsp). For example, user A is now at the corridor and walking towards her office. As soon as the system senses that user A is now stepping into her office (e.g., room A), the context-aware remote Media Player service then automatically starts playing the user’s favourite instrumental music (as specified in the user’s profile document – see Figure 4.4) on her desktop machine. This instrumental music will be playing until the system detects that the user has walked out of the room. To support an automatic execution of the service, the system needs to know the information related to the service such as: for a Media Player service, the system needs to know what music that a user would like to listen in the specific contexts (e.g., location, day and time) and on which machine that a user would like to listen to this music. All these information are stored in a user’s profile document. Our sample prototype of the remote Media Player service is illustrated as follows:
156
Figure 4.14: (a) Accessing the System from a Pocket PC Device, and (b) Remote Media Player Service Figure 4.15 shows more than one service available for a user (e.g., user name = “Dave”) at location Meeting Room M.123.
Figure 4.15: The MHS System with More than One Service Available
4.4.3. Mobile VNC Service As mentioned earlier, VNC is a teleporting application that allows users to connect and access their desktop information from any nearby machine in the current location [RFW98]. By adding context sensitivity to a VNC application, we can certainly maximize the user’s experience in using VNC. Besides adding context-awareness to traditionally designed VNC applications, it is also useful to develop mobile code to access the VNC service. This code will be downloaded to the mobile device once the user is in the context where such code is relevant. The ability to, in an ad hoc fashion, download and execute mobile code on the device where the code can be used to control the VNC application (such as selecting the target device on which to display the VNC terminal or stopping VNC) gives the user convenient control over the application.
157
After selecting the service name (e.g., VNC Remoting – see Figure 4.16a), a managed mobile code for this service is downloaded and executed on the device (see Figure 4.16b). When the user selects on one of the target machine names (e.g., a Coolcampus machine), a user’s desktop information is then displayed on the Coolcampus machine (see Figure 4.16c).
(a)
(b)
A user’s desktop information is displayed at a Coolcampus machine
(c) Figure 4.16: (a) Accessing the System from a Pocket PC Device, (b) Mobile VNC Service, and (c) Displaying a User’s Information on a Desktop Machine – VNC Started
158
4.5.
Summary
We have presented a prototype implementation of the MHS system, allowing a mobile device to adapt its functionality to exploit a set of services depending on the space rules that have been specified by a developer or the owner of the space in particular contexts. The system allows users to interact with services on-the-fly without the burden of effortful setup or knowing the Service APIs. MHS provides important abstractions for delivering, downloading and executing a service interface that hides details of interactions with remote services. Our novel approach for contextual services using Web services, highly compact mobile code and policies to govern service execution. We conclude that having a policy in pervasive computing environments is generally useful as it can govern and control foreign entitiesâ&#x20AC;&#x2122; behaviours in accessing services, especially the shared resource services that involve multiple usersâ&#x20AC;&#x2122; executions in particular contexts or situations, where the space only allows a certain user under certain contexts to access the services. Policy can also help users to express actions to be automatically executed (as obligations they impose on the system). In the next chapter, we evaluate the performance of the MHS prototype and we discuss several heuristic based models to improve the performance of the MHS system.
159
CHAPTER
5
5. Evaluation of the MHS Prototype
The implementation of our MHS framework that targets pervasive computing environments was presented in Chapter 4. The MHS system takes into account the concepts proposed in this dissertation to support the delivery of context-aware services that incorporates policy for controlling access to services. The system is based on the context-aware regulated services model. The context-aware regulated services model proposed in Chapter 3 aims to support the delivery of mobile services by using a combination of mobile code and context-aware policy models. The system performs selection of relevant services and delivery tasks based on a userâ&#x20AC;&#x2122;s current contexts. In addition, the system employs seven prefetching techniques to further improve the response times of usersâ&#x20AC;&#x2122; requests based on the results of the prototype system. Minimising the response time is important from the perspective of users and usersâ&#x20AC;&#x2122; behaviours needing to comply with space policies specified in the system. This chapter evaluates three main aspects of the MHS prototype system.
160
(1) Efficiency of the prototype system We evaluate the time that it takes to: •
detect a location context change and update service and policy information as per current location context,
•
activate mobile code, and
•
check policy authorization decisions.
The prototype system needs to be able to respond to users’ requests with little delay or in a minimum amount of time. All requests from clients to a server and information returned from a server to clients needs to be handled and delivered in a minimum amount of time. That way, we can minimize users’ wait time, thereby, allowing them to perform their tasks efficiently and effectively. (2) Scalability of the prototype system This is done by evaluating the system against a number of users. Ideally, the performance results should stay robust regardless of the number of users. (3) Usability of the proposed system Three usability aspects of the system that we briefly discuss are: •
simplicity of our policy language,
•
controlling versus convenience behaviours when employing a policy language, and
•
time that it takes to respond to users’ requests (users’ wait time).
This chapter is organised as follows. In Section 5.1 we present the efficiency of the prototype system. We discuss prefetching techniques to improve the system performance, minimizing users’ wait time. In Section 5.2 we discuss scalability of our system. In Section 5.3 we briefly discuss usability aspects in our system. In Section 5.4, we present discussion on major bottlenecks in our system and how to reduce the delays. Section 5.5 concludes this chapter.
5.1.
Efficiency of the Prototype System
The framework has given promising results in obtaining a list of services, keeping track 161
of a user’s location, downloading, executing the mobile code, as well as checking policy decision authorization results. The user wait time for service execution varies depending on the type of services: shared or non-shared resource services. In general, the user wait time is longer for executing a shared resource service, as it involves extra steps to initiate a service process on the target machine. We illustrate our evaluation aspects from retrieving a user’s location up to service activation and checking the user’s permission in Figure 5.1 below.
Start up of a device
Login
Get the user’s location from the Ekahau System
Get available services based on the location and the user that is currently logged on
Retrieve list of available services and display them on the user’s device
User selects a particular service name from the list displayed
Compile the service
Legend: The first time of service execution through the JIT compiler (assuming the service or mobile code has not been downloaded previously, hence, it needs to be downloaded and compiled prior to use. The second time, third time, etc. of service execution without the JIT compiler, as we are activating the same service (code) that has been downloaded.
Download the selected service onto the user’s device. The service is in the form of a mobile code application.
Generate code in Microsoft Intermediate Language (MSIL)
JIT compiler compiles code from MSIL into Native Code (store the native code in the JIT cache) Get the mobile code from the JIT Cache Display service interface to the user
Check for action permissibility
Action execution
Figure 5.1: Evaluation Stages of the MHS System
162
In our evaluation, experimental results were collected for ten times of service execution on a 206MHz iPAQ on a wireless Wi-Fi network (54Mbps). We employ the Ekahau Positioning System to keep track of a userâ&#x20AC;&#x2122;s location. Our server side software components are stored on a 2.09GHz desktop machine.
5.1.1. System Performance As shown in Figure 5.2 below, as soon as a user moves to another location (i.e., from location A to location B), the Ekahau location system needs to detect the userâ&#x20AC;&#x2122;s current position. The system then updates a list of services and policy decision results for that location. When the user selects a particular service name on a mobile device, the system then downloads the relevant mobile code, compiles it and displays the service interface. After this, the system then checks the space policy to determine whether or not the user is permitted to perform the requested action. This is done by interpreting the relevant space policy document (i.e., the space policy of where the user currently is) for the specific contexts (e.g., current day, time, and activities).
Figure 5.2: Location Context Change Delay, Service Activation and Policy Decision Checking on a Time Line (distances between vertical bars are not indications of time scales) Three main aspects that we evaluate in this section are discussed as follows.
163
(1) Location context change delay As we associated services and policies to a geographical location (i.e., a room), when a user moves from one location to another, the system needs to update two things (a) a list of services on the mobile device and (b) a relevant policy document for the location. Both of these updating processes require a confirmation from Ekahau regarding the user’s current location (i.e., the user’s exact location as s/he moves from one place to another). Hence, the time delay in displaying the updated list of services to users comprises the Ekahau delay in detecting the user’s new location, plus, the time that it takes to update a list of available services on the mobile device. In addition, to update policy decision results on the mobile device, the system first needs to know the user’s current location (the updated one), then retrieving the relevant policy document for that location and downloading it onto the user’s mobile device. We now describe a formula to calculate the time required for updating a list of services on the mobile device. Tlocation
context change delay(s)
=
TEkahau
+
Tget
a user’s location
+
Tget
a list of services
+
Tdisplay
+
Tretrieve
delay
a list of available services on a device or update the policy decision result
Based on the formula above, we conclude that the worst-case scenario to update a list of services on the mobile device and retrieve policy decision results is the first time of service execution (first time of Web service calling i.e., to get a user’s location, to get a list of services), which takes 8.6s (= 2.5 + 3.5+ 0.5 + 0.1+2). The 2.5s is the Ekahau delay in detecting the user’s movement, the 3.5s is the time that it takes to get a user’s current location from the Axis Apache server via a Web service call and the 0.5s is the time that is required to get a list of services and the 0.1s is to display the updated list of services on the device. The 2s is the time to retrieve the policy decision result. The best case scenario (i.e., the minimum time delays to see the updated services for the current location) is in any execution which is not the first. In such a case, the delay
164
time is 6.5s (=2.5+ 2.5 + 0.4 + 0.1+1). Note that 1s is the time to update the policy decision result (assuming the policy has been modified and therefore, the system needs to update the local policy decision result). The time to detect subsequent location context change decreases to 6.5s, because the Web service calls in a subsequent context change re-uses the local proxy object, which has been downloaded and compiled previously. The time delay between the userâ&#x20AC;&#x2122;s selection of a service and the display of the selected service interface varies depending on the execution number (see Figure 5.3). As we cached the downloaded policy decision result for a location on a device, when a user re-visit the space (room) and we have previously cached policy for that location and assuming the policy has not been changed, there is no policy required to be downloaded and so, for subsequent requests, we can reduce the delay from 6.5s to 5.5s (=2.5+2.5+0.4+0.1+0). Replacing Ekahau by some other faster location positioning engines in the future can reduce delays further. (2) Service activation It is necessary to display the service interface in a minimum amount of time. Ideally, the user should be able to see the service interface immediately or with minimum delay, as soon as clicking on the service name. In this section, we measured each of the aspects in executing the mobile code on the handheld device. It starts from retrieving the code, downloading, compiling and up to displaying it on the mobile device. The timing variations in performing each of the service activation aspects are illustrated in Figure 5.3. Based on Figure 5.3, we can see that the time required to call Web services: get a userâ&#x20AC;&#x2122;s location, get a list of available services and download a mobile code, decreases for subsequent Web service calls (2nd, 3rd, 4th, 5th and etc times of service calling). The first call of the Web service takes a longer time, as the system needs to download and compile the local host Web service proxy object on the device. The proxy object allows the Web service to be treated like other .NET classes. The 2nd and subsequent calls to the service will have much shorter times as they re-use the service proxy object which is already on the device. In addition, the amount of time required to display a list of services on the mobile
165
device is consistent throughout the executions as the number of services used for the evaluation is the same. Our system gets an updated service list for each user and location from an XML database. The time required for downloading and displaying the service interface on the device depends on the size of the mobile code itself. The larger the size of the mobile code, the longer it takes to download and execute the service application.
Figure 5.3: Experimental Results Note that the mobile code only needs to be downloaded once to the mobile device; subsequent service executions (i.e., execute the same service application) will reuse the code that has been stored on the device. Therefore, the downloading time for subsequent service executions is zero (for the same service application). However, if the subsequent executions is different from previous runs (i.e., it executes different services which have not been downloaded previously), it would require a client to download the particular mobile code. In this case, it takes around 0.78s to download the mobile code from a server to a clientâ&#x20AC;&#x2122;s device (assuming the code size is 10KB). We have developed several mobile services in our system. For testing, we focus on one mobile code, which is a Mobile Pocket Pad service that is 10 KB in size. As we have
166
kept the size of the mobile code constant in our runs and we have been reusing the same service application throughout the repeated executions, the time to display the service interface remains the same. Moreover, the time required to get the compiled mobile code from the JIT cache is constant throughout the second and subsequent executions (1s). There is no retrieving compiled code from the cache in the first execution (0s) as the first time of service execution directly compiles the code and displays the compiled code interface on the device. Compilation of the code that implements a service in the .NET Framework involves two stages: (1) the framework compiles the source code (e.g., C# or VB.Net) into the Microsoft Intermediate Language (MSIL), (2) when the application gets executed (at run time), the Just In Time (JIT) Compiler compiles the MSIL code into native code and stores this native code in the JIT cache for future re-use. Note that service activation at the first time means causing the relevant downloaded mobile code to be compiled and then when executed, displaying the service interface to the user. Subsequent activations of the previously activated service will not involve the service compilation (the compilation time is 0s). These subsequent activations will retrieve the compiled code from the mobile code storage, i.e., the JIT cache (see Figure 5.1 above). However, if the subsequent activations require a service (code) which has not been previously downloaded on to and compiled on the device, it requires the code to be first downloaded and compiled prior to use. The compilation time here varies depending on the size of the mobile code. The time to compile the code will be longer if the code size is larger. Our framework that supports mobile code and targets mobile devices aims to create a compact mobile code by separating the service interface and functionalities from the system functionalities (i.e., contextual and policy functionalities). In this case, the mobile code only contains the service interface and its functionality. In average, our mobile code sizes (including the mobile VNC and Media Player service) are 10KB and the time it takes to compile the code is similar - 2s. In general, the first time a service is activated (by the user or by the system), a much longer time delay is experienced compared to the subsequent activations. The time delay
167
for subsequent service activations that execute the service that has been previously downloaded and compiled in the previous runs is consistent throughout the subsequent executions.
Moreover, as we are using multi-threading in executing the service
application, we experience additional delay in displaying the service interface. This delay refers to a thread task. Now, we give a formula to measure the service activation: TService
Activation(s)
=
TDownload
+
TCompile
+
TGet
+
TDisplay
+
TThread
mobile code
mobile code
compiled code service interface
task
Based on the testing and evaluation results, we conclude that the worst-case scenario to see the service interface is the first time of service execution which takes 5.1s (=1+2+0+0.9+1.2). The best-case scenario for service activation is any execution number, which is not the first. It takes 3.1s (=0+0+1+0.9+1.2) – assuming the subsequent executions activate the same service application, in which, the mobile code has been downloaded and compiled in the first or previous runs. (3) Policy decision checking In this section, we evaluated several aspects of policy checking starts from detecting a user’s current location, retrieving a policy based on that location, downloading and caching the location policy result on a user’s mobile device, up to detecting whether or not a user is given a permission to perform the requested action, as well as detecting and resolving conflicts with other entities (if any). We also measured the total user wait time in various scenarios such as: (a) How long a user should wait to receive a response from a server regarding the requested action, when it is the first time entering a location and first time Web service call. (b) How about if a user moves to another location, how long does it take to update the
168
policy cached result on the device? (c) How about if a user closes the service application and after some time, the user decides to start the application. How long does it take to respond to a userâ&#x20AC;&#x2122;s request if policy decision results have been previously cached on the mobile device? (d) How about if a location policy gets modified by an owner of a place or a developer, how long does it take to update a copy of that policy on each of a userâ&#x20AC;&#x2122;s device. The policy evaluation results are illustrated in Figure 5.4 below. Based on Figure 5.4, we can see that the time required to call Web services: send a query from a client to the policy manager, retrieve and download a relevant policy decision document, detect conflict between users, resolve conflict dynamically and send back resolution results to the mobile client manager decreases for subsequent Web service calls.
Figure 5.4: Policy Evaluation Results As discussed in the previous section, the first call of the Web service takes longer time, as the system needs to download and compile the local host Web service proxy object on the device. In addition, the first time a Web method on a Web service is called, the SOAP client needs to reflect over the Web service proxy object. To reduce this delay, we declare the Web service object globally within a class and call a simple Web service
169
method asynchronously on the constructor. The subsequent calls of this Web method will not incur this reflection overhead and so, it takes much shorter time to complete the process. Moreover, the subsequent calls of other Web methods on the Web service will not incur downloading and compiling of the Web service proxy object (as it only needs to be done once, when the first time calling a Web service) and so, in general, it also helps reducing the time to call other Web methods on the Web service. When a user moves from one location to another, our system continuously monitors a userâ&#x20AC;&#x2122;s location and retrieves the policy information accordingly (different spaces uses different policies). Based on the testing and evaluation results, the worst case scenario to retrieve a policy decision result is the first time of Web service calling. This means, when the first time a user enters a location and the first time a Web service calling, it takes 2s to retrieve and download the policy decision result onto a userâ&#x20AC;&#x2122;s mobile device. However, as our system has previously called this Web method on the constructor, retrieving the policy decision result upon the MHS client application being loaded, only takes 1s. This can be considered as a subsequent call of this Web method as the first one has been done during the initialization in the constructor. Upon retrieving the location policy document, the mobile client manager stores this temporarily on the local system data set and writes it to an external XML file (e.g., MobileComputingLabPolicy.xml) on a device when a user closes the MHS client application. Storing the policy decision result locally is considered useful in order to speed up the policy decision checking (check against spRu). As a result, the subsequent policy checking does not need to contact the Web server to re-download the relevant policy document and so, no policy needs to be re-cached (0s). Instead, it will just check the local cached policy results. Moreover, when a user moves to another location and the policy decision has not been previously downloaded onto a device (this may be because the user has not visited the location previously), the client then contacts the system to retrieve and download the specified policy decision result. In this case, it takes 1s. In a situation where the user moves back to a location where a policy has been cached, the subsequent policy checking does not incur a policy downloading process, instead it just reads from the local policy result dataset and hence, the checking can be
170
done in a minimum amount of time. In addition, the policy decision result which has been stored on the mobile device only needs to be updated, when the policy for that location is modified by a developer or an owner of the place. In this case, it only takes 1s to retrieve and download the updated policy document from a server to a client (assuming the userâ&#x20AC;&#x2122;s location has been known or detected by the system earlier). In addition, when the user has closed the MHS client application and decided to open it after some time, it takes 2s to read the cached policy XML file. As we also cached the policy decision result and store it as an XML file, the subsequent policy checking after a user closes the application still does not require a policy to be downloaded from the server and so, reduces the user wait time. In general, the time that is required to check an action against the policy depends on the type of services that a user wishes to execute. It takes longer time for executing an action on the shared-resource service compared to a non-shared resource service. This is mainly because there is more checking that needs to be done. The policy checking here is triggered when a user clicks on the action on the service. The policy checking formula comprises: Tpolicy
checking(s)
= Tchecking
against spRu
+ Tchecking
conflicts between entities
Based on the testing and evaluation results, it takes 0.48s to check the policy decision against spRu for the first and subsequent requests. This time remains the same throughout the executions as checking only needs to be done locally and does not involve any Web service calling. The only aspect that influences the amount of time required to check for the policy decision locally is the processing speed of a device and a number of applications running at the time. The faster the speed, the shorter time it takes to complete the checking. Moreover, more applications running during the checking would result a much slower response from CPU to perform the checking. The amount of time required for checking whether or not there is a conflict if the specified action of the service is executed, varies depending on the number of executions. This is mainly because, it is implemented as a Web method and hence, it requires a Web service call to
171
a server. The first time of Web service calling takes much longer (i.e., 1s) than the subsequent requests (i.e., 0.68s). As for executing a non-shared resource service, it only takes 0.48s (=0.48+0) to check policy decision results for the first and subsequent requests. The shared resource service would take 1.48s (=0.48+1) for the first time checking and reduces to 1.16s (=0.48+0.68) for subsequent checking. Our system performs two types of policy checking: per action and per service (as discussed in Section 4.2.3). For example, by allowing users to start the music service with any action, that would allow users to stop, pause and resume the music. Therefore, for subsequent requests (e.g., stop, pause or resume the music), which are related to the requested action (e.g., start the music), we assume we do not require the policy decision checking. This then reduces unnecessary checking for every single requested action. Finally, we present a formula to calculate the total user wait time to request an action on shared or non-shared resource services till the system responds back to the user. This requires a system to detect the userâ&#x20AC;&#x2122;s location, display a list of available services and download the relevant policy document, checking a policy decision result and resolving conflicts if any. As shown in Figure 5.4, to resolve one conflict for the first time of a policy conflict resolution web service called, it takes 0.88s. Resolving subsequent conflicts would take 0.78s. The time to resolve different conflict resolution techniques (e.g., role hierarchy overrides policy, space holds precedence over policy, obligation holds precedence over visitors, and maximum execution time policy) is generally the same, which is 0.88s for the first time policy conflict resolution web service call and subsequent calls take 0.78s. In our test case scenario, we have two users (e.g., a lecturer and a student) with different roles (e.g., a power entity and a general entity). A lecturer specifies policies for a lecture room for his lecture. A student owns a personal room (e.g., room B538). There is one conflict occurring between these users in a public space (e.g., a lounge room), as they want to start the shared resource service (e.g., a music service) with different songs. As illustrated in Figure 4.11, to resolve this conflict, our system then applies a role hierarchy overrides policy. Apart from performing these tasks, a lecturer also starts a
172
non-shared resource service (e.g., a Mobile Pocket Pad service) on his pocket PC device. A student also starts a non-shared resource service (e.g., a Mobile Pocket Pad service) on her pocket PC device. There is no conflict occurs for this non-shared resource service. Therefore, it does not require a conflict resolution for the non-shared resource service (0s). We now present the formula to calculate the userâ&#x20AC;&#x2122;s wait time. Tuser
wait time(s)
= Tlocation
context change delay
+ Tpolicy
checking
+ Tpolicy
conflict resolution
Based on the formula above, we conclude that the worst-case scenario for the user wait time when the user first enters a location (first time calling a policy result Web service) and wishes to perform an action on the shared resource service is the first time of requesting the service, is 10.96s(= 8.6 + 1.48 + 0.88). For a non-shared resource service, it is 9.08s (= 8.6 + 0.48 + 0). The best case scenario (i.e., the minimum time delay to get a response back from the policy manager) is in any execution which is not the first (assuming the location context for subsequent requests is still the same and so there is no need to retrieve or update the policy decision result as well as a list of services). We assume here that there is a conflict between users to execute a shared resource service, requiring a resolution. In such a case, the time delay is 0.48s (=0+0.48+0) for a non-shared resource service and 2.26s (=0+1.48+0.78) for shared resource services. The delay can be minimized as the system does not need to retrieve the updated services and policies as the location is still the same. Here, we only need to check the policy and no location context change is required. The time to detect subsequent requests decrease to 0.48s for non-shared and 2.26s for a shared resource service, because the subsequent requests re-use the local cached of policy decision results which have been previously downloaded (in the first run) for that location and does not need to update the list of services. In addition, when the user moves to another location (e.g., from a lounge room to a seminar room), the user wait time is 6.98s (=6.5+0.48+0) for non-shared services. It
173
takes 7.98s (=6.5+1.48+0) for shared resource service â&#x20AC;&#x201C; assuming here, the policy decision result has not been previously cached on the device as it is the first time a user visits the location and it is considered as a subsequent Web service call. There is also no conflict between users in a seminar room. If there is a conflict, the time to resolve the conflict is 0.78s as it is the subsequent policy conflict resolution calls. In a case where only the policy gets modified and the user is still in the same location, the system only needs to update the policy document. The formula to calculate the user wait time is Tuser
wait time(s)
=
Tretrieve
+
Tpolicy
checking
+
Tpolicy
conflict resolution
or update policy decision result
We assume here, the user has been in the location and requested to perform some actions. Therefore, it is not the first time of calling Web services (i.e., location, policy checking and policy conflict resolution Web services). The best case scenario for user wait time is 3.26s (=1+1.48+0.78) for shared resource services. We assume there is one conflict between users when executing a shared resource service.
It takes 1.48s
(=1+0.48+0) for a non-shared resource service. In addition, in a situation where the policy decision result is already on the device; the user re-visits the location and there is no policy modification, the user wait time for a shared resource service would only be 1.48s (=0+1.48+0) â&#x20AC;&#x201C; assuming, there is one conflict between users when executing a shared resource service. It takes 0.48s (0+0.48+0) for a non-shared resource service.
5.1.2. Prefetching Techniques The user wait time can be reduced by employing seven different heuristics based models. All these models are based on guessing where the user is likely to be and prefetching necessary information or code in anticipation of the userâ&#x20AC;&#x2122;s future whereabouts. The models differ in how much information or code is downloaded. We have implemented and published the first three of the heuristics based models in [SLS04c]. We then
174
extended these models by including other user related aspects such as a user’s schedule information, a user’s current context, a combination of a user’s schedule and other users’ history information, as well as a user’s history file and the logical area. These extended models are only at the idea level and have not been implemented. We now explain each of these models by example of areas as shown in Figure 5.5. (a) Download all the code for all services and all location policies in a large area With this model, as soon as the system detects that a user has entered the first floor (e.g., from an escalator), the system retrieves all services and policies for all the rooms within this floor e.g., services for the rooms in the Printing Area, Lecture Hall Area and Tea Room Area (see Figure 5.5 below). We are assuming here that each of these rooms and areas has their own set of services and the system cannot predict which room the user will eventually enter. After retrieving the list of services and policies for all the rooms, the system then downloads and compiles the service applications (mobile code). With this model, the time delay in displaying the service interface after selection is 3.1s for the first and subsequent calls as the mobile code has already been downloaded and compiled beforehand. The user wait time in requesting an action on the service is also reduced from 9.08s to 0.48s (for non-shared) and 10.48s to 1.48s (for shared). This is mainly because the system has proactively retrieved all policies for all the rooms within the floor and cached these policies locally on the device. Hence, the first and subsequent requests re-use the local cached of policy decision results which have been previously downloaded for that location. We can reduce this context change delay from 8.6s to 6.5s, because the policy for the location has been downloaded previously when the user enters a bigger scope (e.g., first floor). However, this prediction model might waste lots of power and memory storage of the user’s resource-limited mobile device, as the device needs to download all the code regardless of whether the user will use them. (b) Download the code and location policy just before the user reaches the room This heuristic only downloads a list of services in a particular logical area and policy for that location only, as the user moves towards that area. For example, as the user walks towards the Printing area, a list of services for Printing Room 1 and 2, as well as policies
175
for these rooms are downloaded onto and cached on the userâ&#x20AC;&#x2122;s device (see Figure 5.5). These services are then compiled. With this model, we can reduce the context change delay, as the user is approaching the Printing area, the system downloads the Printing Room 1 and 2 services plus policies and then when the user moves towards Printing Room 1, the system then displays a list of services that is relevant to this room only. In this case, the location context change delay will be about 5.1s. We can reduce this context change delay from 8.6s to 6.5s, because as the user moves to the printing logical area, the system has already retrieved all the code that is relevant to the rooms, services within this logical area and as the user moves to the specific room within that logical area, the system then just needs to get and display a list of services for that particular room. Besides that, with this model, the service execution can be reduced from 5.1s to 3.1s for the first and subsequent calls. This is possible as the system has downloaded and compiled the relevant services for each room, as the user approaches the logical area.
Printing Area Printing Room 1
Printing Room 2
Lecture Hall Area Lecture Hall 1
Lecture Hall 2
1st Floor Corridor
Tea Room Area Room 1.33A
Figure 5.5: Logical Area Representation
176
(c) Download the code for some of the services based on a history of the user’s movements This heuristic only downloads and compiles service applications whenever it is needed and based on the system’s prediction of where the user will move next. With this model, less time is required to download and compile code as it only downloads the ones that the user is predicted to need. This model suits dynamic situations where the services for the rooms always change. However, with this system, we have to create a complex history file that logs all the details about the user’s activities (e.g., attend a lecture every Friday at 5PM). The creation of this history file is done by continuously monitoring a user’s daily activities for certain duration of time (e.g., for a week). After a week, the system then needs to finalise the daily activities that the user may perform at regular time. In addition, as part of the maintenance process, the system also needs to update the user’s history file (e.g., every two weeks depending on the system policy) by re-monitoring the user’s activities. With this model, the prediction of the user’s next action is done by computing a function f (current_day, a user’s history file) = a list of prioritised activities The function f above describes that once a user is logged on to the system, the system will then search through the user’s history file to prioritise all activities (e.g., based on the order of the occurrence) that match with the current day. This information is then stored in a temporary file. Once the prioritising is done, the system then continues to watch the time to detect whether or not the time to retrieve a predictive service is reached. If the time is reached, the system then retrieves all the relevant services and policies for this activity and then downloads and compiles these service applications and policies onto the user’s device. Thus, by the time the user steps into the predicted room, the system is ready with the list of services, applications and policies. With this model, we will certainly improve the performance if the system’s prediction is correct and accurate (i.e. when there is regularity in the user’s behaviours).
177
If the prediction is accurate, we are expecting the context change delay to go down from 8.6s to 6.5s. We can eliminate from the user’s wait time (i.e., from 8.6s to 6.5s), the time delay in calling the Web service to update the list of services on the device. This can be done as the system can predict the place the user wants to move next (e.g., room 1.33A). Based on this prediction, the system can spontaneously get the list of available services for this place even while the user is still walking to that place. Ideally, on arrival at that place, the system immediately displays this list and we have zero wait time before the user sees the updated list. However, as Ekahau has an inherent delay in detecting a user’s change in position (of about 2.5s), our system will not be able to display the updated list of services (even if this has been prefetched) until the user’s location has been confirmed by Ekahau. This means that when the user arrives at that place, the user has to wait about 5s before the (prefetched) list is displayed. We can also reduce the time for service execution after user selection from 5.1s to 3.1s. We will only have 3.1s to display the service interface for the first time of execution and the subsequent activations. This is possible as the code for the particular service has been downloaded and compiled beforehand even while the user is moving towards that location. Although this model can reduce the users wait time by 2s, this model does not accommodate the unpredictability of users’ intentions or movements. (d) Download services based on a user’s schedule document A user specifies a list of services that s/he might need in a specific situation or context. As a result, two users may see different set of services, though they are in the same context. This heuristic model anticipates a list of activities as specified in the schedule document. For example, a user specifies during the meeting normally at 3PM every Wednesday, I want the note taking and voice recorder services to be available. After that, I will give a talk in the lecture, so I want my online note service and online browsing services to be available. This anticipation is independent of a user’s location as the prefetching is based on a list of activities that a user might perform. The system starts prefetching all relevant services ahead as specified in the user’s schedule, regardless of the user’s current proximity. For example, the system starts prefetching all necessary services for meeting
178
at 2:55PM, though the user is now still in the car park. Ideally, when the user gets into the place or about to perform the activity (as specified in the user’s schedule document), all services are ready for users to use. However, this heuristic model also does not anticipate other activities which involve different services, other than the ones specified in the user’s schedule document. Hence, the user may experience a delay if entering a location, or performing activities other than in the schedule document. (e) Download services which are related to a user’s current context (compound prefetching) The compound prefetching is based on the guessing of what and where the user is likely to perform or move next from his/her current location. For example, by sensing a user’s current location in a lecture hall, the system proactively prefetches all useful and relevant services for other rooms, which are related to this location such as a tutorial room and a laboratory room. Also, by sensing the user’s current activity (e.g., preparing for meeting), current services will be downloaded for the meeting preparation, as well as all services required for meeting. This heuristic technique requires a complex and systematic relationship from one context to another (e.g., a logical relationship from one room to another, from one activity to another, etc.). This active and dynamic prefetching would accommodate a user’s unpredictability as prefetching is done actively and dynamically by sensing the user’s current location or activities and downloading relevant services that match the user’s current context information, as well as downloading other possible services which are related to the user’s current contexts. (f) A combination of a user’s preferences and by using history information of other users (collaborative filtering) This technique prefetches services based on the user’s preferences, as well as by finding what others are most likely to perform in that particular context. It gives users more choices in terms of services. The system could suggest a list of services that other users are most likely to perform, than just those services as specified in the user’s preferences. For example, by noticing that many people enter the music gallery, this place could be a
179
popular one. The system may want to suggest visitors to enter this place too and download services which are related to this space. This certainly adds an extra value, but may not accommodate the user’s unpredictability other than in the user’s preferences. (g) A combination of a user’s history file and logical area This is a combination of heuristic based models a and c. This heuristic based model does not only download services within a logical area, as some of them may not be useful. It further customizes what services to download within a logical area based on a user’s history file. By only using a history file, the system only downloads the service based on the information listed in the history file (e.g., for level 7 mobile computing lab at 12PM and for level 5 seminar room at 12:20PM). Some of them may be useful and some may not be, as the user may not always perform the same activity as specified in his/her history file. However, by using a combination of these, the system can further analyse whether or not service for level 5 seminar room need to be downloaded, as the user is still at level 7 and it is almost 12:18PM. Each of the above heuristics based models that we have proposed has its own advantages and disadvantages such as: the heuristic model (a) accommodates the user’s unpredictability and is simple to develop and maintain. It suits the situation where unpredictability of a user’s intention or movement is the concern. This model can cater for all possibilities of the user’s activities or movements (as long as within the floor) as the system downloads and compiles the mobile code before the user steps into any particular room within that floor. However, this model is only suitable if there are not too many services in the location and the services and policies are not dynamic. This is mainly because many services mean long delays in downloading and compiling the large number of code applications. Moreover, dynamic services and policies mean that the code and policies which have been prefetched might not be relevant anymore when the user moves to that location. Although the above models (b), (c), (d), (e) and (f) can reduce the users’ wait time, the models do not accommodate the unpredictability of users’ intentions or movements. The user will experience delays if the user’s intention change (i.e., it is not the same as in the history or preference file) or if the system prediction is incorrect. For example, if
180
user A cancels her meeting with user B at 2PM and instead of going to user B’s office, she decides to go to Printing Room to collect her notes. In this case, the system will not be able to detect where the user goes other than User B’s office. Therefore, all services that the system has retrieved, downloaded and compiled for user B’s office will not be relevant as the user decides to go to the Printing Room. Moreover, the user will experience delay in seeing a list of services when she arrives in a new location not anticipated from the historical, preference information or system prediction. The heuristic model (g) anticipates the user’s movement, though not specified in the history file and not wasting resources to download all services for all floors, but only for a specific floor or even specific sub floor or specific rooms within the floor according to the user’s current location (that has been confirmed by the history file).
5.2.
Scalability of the System
We also have tested the scalability of our system by simulating concurrent requests from 100 clients running on pocket PC devices. We simulate the number of clients by creating 100 threads running on 2 pocket PC devices (i.e., 1 pocket PC device = 50 clients = 50 threads). Each of these threads requests the Location Web service 10 times. As we have discussed in the previous section, the first Web service call regardless of the number of concurrent users calling the same Web method at one time is always higher than subsequent calls (as shown in Figure 5.6).
181
Figure 5.6: Average Client Delay for a Location Web Service
Based on Figure 5.6 above, we can see that the performance for the first and subsequent Web service calls would decrease slowly as number of users increase. This is due to a fixed number of threads for our Web service design and architecture, which results in low context switching costs. Hence, the response time increases by the increase in wait time in the queue. Another two factors that affect the delay in responding to the userâ&#x20AC;&#x2122;s request as numbers of users increase are (i) the network/intranet traffic loads, and (ii) Web server workload. The network traffic and Web server workloads are slightly higher as the number of users increase. We can reduce the delay by employing advanced proxy caching on the server or application side, thereby limiting the network traffic and Web server workloads. This demonstrates the scalability of our prototype.
182
5.3.
Usability of the System
A context-aware pervasive system allows users to access services at any time and any location. The notion of context-aware services further enhances the aim of pervasive computing, in which, the system only delivers relevant services to users. In order to provide context-aware services, a rule for mapping between a service and context is required. For example, to display a presentation service only when a user is in the seminar room requires a mapping between a location context and a service. The idea of having a policy (rule) in a context-aware pervasive computing environment has evolved. The policy is not only able to specify the visibility of services in the certain context. It can control a userâ&#x20AC;&#x2122;s behaviours in accessing services; it can also help users perform an automatic task as specified in the policy document (a userâ&#x20AC;&#x2122;s obligation on the system). Three usability aspects which are briefly discussed in this section are: (a) Expressiveness vs. Understandability of policies The question is how complex a policy language should be. Ideally, the policy language should be simple and expressive. The user needs to be able to specify simple behaviours (e.g., given context C allows action A on service S) or complex behaviours (e.g., only allows visitors with the same level of role to start a music service in the particular context). Our policy language allows users to specify both simple and complex behaviours. As discussed in Chapter 3, our policy element consists of contexts, policy objects (i.e., right, obligation and prohibition), imposed by, imposed on, services and action. These are the basic policy system elements, which are required in context-aware systems. In addition, the policy (rule) needs to be precise. Our policy language allows users to specify a particular service with a particular action in the specific context. For example, a user wants to start an Outlook Express application between 2-4PM, only when she enters her office. This is possible, as our policy construct has target service name and context when the specified rule needs to be applied. (b) The userâ&#x20AC;&#x2122;s convenience and control over a system
183
Every action is by default allowed unless explicitly prohibited in the policy. In general, we can not deny having a policy in a context-aware system. Without having a policy, we can not specify a rule for making a service context-aware as well as controlling users’ behaviours in accessing services in the specific context. Our policy design takes into account the aspects of convenience and compliance of users when accessing services. By having a policy, we do not prohibitively or fully restrict a user’s behaviours; the system only controls or restricts users in accessing services in the certain context. In most situations, a user is able to access services as per normal. (c) A user’s wait time The context-aware system needs to respond to users’ request in a minimum amount of time. It is not efficient, if users have to wait for too long to request and access services. Our system addresses the system performance issue by employing heuristics based models as discussed in Section 5.1.2 above.
5.4.
Discussion
We can still improve the system performance by identifying performance bottlenecks and exploring other implementation techniques to address the delays: (1) Delay in detecting a user’s current location Ekahau has an inherent delay of about 2.5s in detecting a user’s movement (a user’s current location). The delay can be minimized by increasing the number of access points in a location and having more tracking points so that Ekahau can track the user’s movement accurately and in minimum amount of time. There is also another delay in transferring the user’s location from the Ekahau server to a client (in this case, our MHS framework). In addition, the Ekahau functionalities are implemented in Java. To allow interoperability between these two platforms, we implemented the Ekahau location tracking listener as a Web service. The 1.8s delay here is mainly because, the MHS framework needs to call the location Web service that is implemented as a Java AXIS apache Web service and this location Web service then needs to talk to the Ekahau
184
server. It requires some time to download the proxy object on the mobile device, as well as to open the connection of the Ekahau server location database for the first Web service call. Hence, the first Web service call always takes longer, than subsequent requests. This delay can be minimized by employing other techniques. One possible technique is to use a publish subscribe model. Currently, the supporting software for handheld devices polls the centralized Web service at a fixed time interval. More frequent polling means that the list of Web services offered to the user is more accurate. But the polling operation is redundant if the user has not moved, because the set of services available at a particular location is relatively stable. The infrequency of polling would cause the list of services to adapt slowly as services entered and left the location. To conserve the limited processing power, memory and battery life of mobile devices, it would be good to reduce the number of redundant polling operations. One simple solution is to increase the time interval when a device detects that it has done a redundant poll. This is effective because once a user has stopped moving, s/he is likely to stay in the same place for a relatively long time. Using a publish-subscribe model instead of continual polling can eliminate redundant Web service calls. When the MHS software client starts on a mobile device, the device is then registered by a device manager. The centralised Web service would then monitor the location of the device and push relevant services onto the device. Applications leveraging this functionality can support ad-hoc collaboration between colocated mobile device users. Moreover, it also maintains client control by client subscribing or unsubscribing as it wishes. As an alternative to Ekahau, there are some potential indoor positioning systems such as Cricket [PCB00], Active Badge [WHF92]. One can continue to investigate the benefits of using these positioning systems in our system, for future work. (2) Delay in retrieving the updated policy decision result Statically computing a policy decision, conflict detection and resolution helps to reduce the user wait time. These results are stored on the server side for future re-use (e.g., for runtime policy checking). Our current policy implementation, detects and resolves
185
conflicts statically, as well as computes each user-location policy decision result. As the computation is done on the server side and all results (e.g., policy decision and conflicts resolution) are stored on the server side, there is delay in retrieving and transferring these updated results onto the mobile client. Our current implementation employs a polling based mechanism to retrieve the updated policy decision results as soon as the user moves to a new location or when the policy document gets modified. The performance can be improved by using a publish subscribe model, in which, all registered clients will get the notification regarding the location as soon as the user moves into a new location and so, automatically updates the policy decision result on the mobile device. Or a notification if a policy document is modified and so, retrieving and downloading the updated policy decision result onto a client device. This performance can be further improved with better processor, higher bandwidth and faster data transfer rates. (3) Context change delay Reducing a context change delay and service execution time is considered important, in order to provide a smooth transition when the user moves from one location to another. While 5s may be acceptable in applications where the user will be in the same area for a long time, ideally, when the user crosses the boundary from one area to another, entering a new area which is offering a different set of services than a previous area, s/he does not have to wait for 5 to 6 seconds before seeing an updated list of services. Moreover, the user should not have to wait about 4 seconds after selecting (or clicking on) a service before seeing the service interface. The user wait time can be improved by employing heuristics based models (thereby, reducing such wait times) as discussed in Section 5.1 above. With this technique, we are able to reduce user wait times by two to three seconds. Although small, we contend that such a reduction is helpful as it affects the userâ&#x20AC;&#x2122;s experience. We believe that by fine tuning and anticipating services and policies earlier would further reduce the userâ&#x20AC;&#x2122;s wait time and so, providing a smooth transition when the user moves from one location to another (i.e., towards zero wait time).
186
5.5.
Summary
We have presented an overview of our work in addressing the performance issues on resource limited mobile devices.
To improve the service performance, we have
discussed the prefetching mobile code mechanism and caching code and policy checking results, together with the heuristic based models. With this technique, we are able to reduce user wait times by two to three seconds. We also see that there is a cost to getting context. In this case, it is the delay in detecting a userâ&#x20AC;&#x2122;s new location. We anticipate that such costs and strategies to reduce the costs need to be considered for context-aware systems. In general, depending on the number of services that need to be prefetched, the heuristic techniques can also take some time to download, compile and execute the services. In the next chapter, we present our guidelines for analysing and designing a system for context-aware regulated services. We also discuss one sample case study that focuses on a pervasive campus computing environment, to evaluate the feasibility of our MHS guidelines.
187
CHAPTER
6
6. Using the MHS Framework: The MHS Methodology
Context-aware software systems automatically initiate communication or exchange information with other embedded or non-embedded computing devices in order to seamlessly help users accomplish their tasks. Context-aware systems promise to be an attractive vision for the future development of computing. To achieve this vision, software developers must build a system that could adapt to constant changes in an environment and deliver only relevant services to users. In general, there are three hurdles to the extensive development and use of systems for context-aware services in pervasive computing environments. (a) There is a lack of a tailored methodology enabling developers to clearly model and structure a contextual system starting from analysing requirements, design to implementation. As a result, system analysis and modelling of a system for contextaware services can be relatively unclear to developers. Different developers would have different understanding of the system concepts and components.
188
(b) There are various target computing environments where a system can be deployed (e.g., a school, health care, shopping environment, etc.). Each of these environments has different system requirements, elements and functionalities. (c) A system for context-aware services involves a variety of conceptual elements and logical
representations or abstractions of system components which often changes
from time to time, compared to building a traditional software system (e.g., a distributed system). For example, a service could be registered or deregistered from a system, a mobile user could move from one location to another, etc. As discussed in Chapter 1, a context-aware system needs to proactively sense, deliver and adapt services to various contexts in the environment. As a result, new thinking in analysis and design methodologies is required to effectively guide developers to build and achieve such visions. This chapter presents processes starting from analysis then design. This chapter presents a methodology (known as the MHS Methodology). It is intended for analysing and designing a system for context-aware regulated services that could adapt to usersâ&#x20AC;&#x2122; needs and using policy to control usersâ&#x20AC;&#x2122; behaviors when accessing services. We have published our earlier work of the MHS methodology in [SyL06b]. Our methodology is built upon the work of the MHS framework (as discussed in previous Chapters) that supports development of context-aware regulated services and targets indoor pervasive computing environments. The idea is that by following our methodology developers could have an idea about what aspects need to be considered and how to design or model the system. This is certainly useful especially if developers want to add context-aware regulated services throughout an environment (e.g., a campus environment, a museum environment, a shopping centre environment, etc.). The MHS methodology is general, and it is not specific to one particular domain. It is comprehensive, in a way that it covers a high level abstraction of pervasive computing environmental and contextual system elements. Our MHS methodology has been evaluated in a pervasive campus domain (see section 6.3). This indicates that our methodology provides enough details to cover necessary concepts and models for building contextual systems in a campus environment. Our methodology also takes into
189
account the modularity aspect, in which we group software system components into a module. We believe by following our MHS methodology, developers could be systematic in building contextual systems in pervasive computing environments. This chapter is organised as follows. In Section 6.1, we give an overview of the MHS methodology including the MHS methodology criteria and its scope. This is followed in Section 6.2 with discussing the details of the MHS methodology. It consists of two phases: analysis and design phases. We further discuss a case study of a pervasive campus domain in Section 6.3. In Section 6.4, we discuss related work on context-aware system guidelines. Finally, section 6.5 concludes the chapter.
6.1.
Overview of the MHS Methodology
The primary purpose of the MHS methodology is to guide different levels of developers (from novice, intermediate to advance) in analysing, constructing and modelling systems that deliver context-aware regulated services. It covers problem descriptions, requirements and modelling of the system. Our methodology follows a software lifecycle model (similar to the â&#x20AC;&#x153;waterfall modelâ&#x20AC;?) that provides sequential phases and guidelines to the development process with a detailed description of each deliverable phase. The MHS methodology takes initial context-aware system characteristics, requirements and then produces a design of MHS functionalities for an environment that can be used for implementation. The modelling in our MHS system uses UML (Unified Modelling Language) [JSR04] that is commonly acknowledged as a standard for object oriented modelling. UML consists of a class diagram, a use case diagram, a sequence diagram, etc. UML is supported by many existing commercial software tools (e.g., VISIO, Rational Rose, etc.) and is understood by many software developers. Each of the system elements (as discussed in Chapter 3) is represented in a standardized template. The template consists of the mapping between system elements. The MHS methodology contains high level concepts and models for analysing and designing a system for context-aware regulated services. The models are grouped into modules (e.g., a contextual software module, environment module, entity module, etc.).
190
Any modification or extension of concepts or models only needs to be updated in one particular module (with less impact on other modules). Our methodology highlights the necessary system components for building context-aware systems. It gives a high-level abstraction of software system elements which are considered generic and may be used across different pervasive computing environments. The methodology is independent of any context-aware system architecture, programming language and platform used for the implementation. Ideally, a contextaware system modeled (using the MHS methodology) could be implemented in many different ways. In summary, our MHS methodology consists of: 1.
A set of modelling concepts that captures situations and requirements of pervasive
computing environments. For example, the MHS methodology has elements such as services, contexts, entities, an environment, computing devices and policies. 2.
A set of templates that represent modelling concepts in a standardized way. Having a
standardized template for representing concepts of system elements would encourage the same interpretation of system elements among developers, thereby supporting collaboration with other developers. 3.
A collection of hints and rules-of thumbs that are used to guide and improve the
system. It is a set of guidelines for analysing and modelling a system. The guideline describes phases which are required to build a context-aware system including tasks that need to be performed in each phase, the fundamental system elements in context-aware systems, and how they can be constructed.
6.1.1. MHS Methodology Requirements In general, there are five main criteria that the MHS methodology should satisfy: 1. simple and can be understood by software developers within reasonable timeframes, 2. can guide developers to achieve better and more reliable results compared to ad-hoc approaches or techniques (this can be achieved by having a standardized graphical class diagram and template to describe system elements),
191
3. generic and applicable in a number of pervasive computing environments (e.g., at home, campus, shopping domain, etc.), 4. guide developers to effectively achieve similar or consistent results during analysis and design of context-aware systems, and 5. can describe a particular environment (e.g., a pervasive campus environment) clearly and represent the elements required in the environment. In addition, the MHS methodology has four useful features: (a) Modularity Modularity can be achieved by grouping similar contextual functionalities into modules. Our MHS methodology supports modularity of system components, as it first identifies the elements and then groups similar system elements and its functionalities into modules. (b) Extensibility A system needs to support additional system elements (e.g., an environment element, policy element, etc.) which may not have been thought of in the current design. Our methodology supports this requirement, as we group system components into modules, and so, adding a new system component in the future can be simply done by creating an extra component on the server/client side and integrating this with the existing software modules. (c) Dynamicity Context-aware system elements are highly dynamic (active). The system elements can be added or modified at run time. Supporting this requirement is crucial in context-aware systems, as users are always on the move, the number of users, services and resources in the environment change from time to time. Our methodology supports this by capturing an updatable property of each system element whose value can be changed from time to time. For example, for an entity element, it has properties such as an entity context property that keeps track of a userâ&#x20AC;&#x2122;s movement, activity, etc., a registration property that keeps track of any addition of a new entity and any modification of an existing entity in the system.
192
(d) Platform independence Platform independence simply means a system design is independent of any technology, operating system and programming language. Our MHS methodology encourages developers to give a system overview, architecture and the required elements, without focusing on a particular language and platform used for the implementation.
6.1.2. Scope of the MHS Methodology The scope of our methodology is the development of context-aware systems that involve mobility of entities, dynamic services, contexts, policies/rules, logical/physical structure of environments and heterogeneous computing devices; for example, context-aware pervasive campus services, context-aware pervasive shopping services, etc. This can be done by using the existing context-aware framework (e.g., the MHS framework or other frameworks that have similar system elements and conceptual view as in MHS such as GAIA [RHC02] and Cerberus [MRC03]). Our methodology does not address issues related to security, wireless networking (architecture and infrastructure), deployment and evaluation of context-aware regulated services.
6.2.
Details of the MHS Methodology
In applying the MHS guidelines, a developer moves from a conceptual overview of a system (abstract concepts), followed by an architectural design to concrete and detailed elements modelling. In conceptual system modelling, the MHS methodology highlights context-aware pervasive services scenarios, requirements and concepts. The next step is architectural system modelling that consists of detailed descriptions of target system elements and their relationships. Based on the review of conceptual and architectural modelling, developers then work on more detailed system modelling. The output of the detailed design is a class diagram for each system element. The analysis and design phases can be considered as a process of developing detailed models that could give developers concrete ideas towards the system implementation. Figure 6.1 illustrates our methodology. 193
Capturing system requirements
System environment
System characteristics
System requirements Analysis Phase Refining scope of a system
System goals
Scope of a system
Architectural design Environment element
Entity element
Contextual task element
Hardware element
Detailed design
Design Phase
Environment (domain and space) model
Entity model
Context task model
Service task model
Policy task model
Computing devices model
Implementation
Figure 6.1: The MHS Methodology Analysis and Design
194
6.2.1. Analysis Phase Our analysis phase consists of capturing system requirements and refining the scope of a system. The objective of this phase is to analyze context-aware services scenarios and its requirements. It is a first step towards modelling a system that gives developers an idea of a target pervasive computing environment. At the end of this phase, we hope developers could come up with requirements and scope of a system. We now describe steps required in the analysis phase: 1. Capturing system requirements This is done by studying and analysing system organisational settings, situations and problems. The output of this phase is an organisational model which includes system requirements. The following is the process of capturing system requirements: (a) Decide on a target system environment An environment is circumstances and physical characteristics surrounding a system that influences concepts, behaviours and interactions between system elements. Some examples of context-aware system environments are a campus system environment, a shopping system environment, a health care system environment, etc. Each of these system environments has different system elements (e.g., different target users, services and context), system architectures and modelling. By identifying the target environment earlier, a developer would have an abstract knowledge about a system (e.g., knowing its purpose and required system elements). This then helps to better architect and model the system. (b) Understand system characteristics System characteristics refer to fundamental features of a system. Eight characteristics of a system for context-aware services are disappear, proactive, autonomous, aware and adaptive, intuitive, anytime and anywhere access to information, mobile, dynamic and heterogeneous. We have discussed each of these system characteristics in Section 1.1, Chapter 1.
195
(c) Analyse system requirements A system setting in pervasive computing environments can be illustrated by creating usecases. As in Object Oriented methodologies, a use-case includes generalized graphical diagrams (e.g., a use case diagram) with sequence text scenarios (e.g., a sequence diagram). The scenario outlines a sequence of interactions between entities (e.g., users) and systems. The system keeps monitoring users’ current context and deliver relevant services to users. We have discussed in detail system requirements for building contextaware services in Chapter 1. 2. Refining scope of a system After understanding the target environment, its characteristics and requirements, we then need to identify the goals and scope of a system. (a) System goals System goals refer to objectives that a developer wants to achieve when building context-aware services. In general, there are three main goals: •
Perform contextual tasks such as: (i) senses entities’ context information, (ii) retrieves (collects) contextual information, (iii) interprets (analyses) contextual information, (iv) delivers relevant contextual services, and (v) retrieves relevant policies.
•
Compute and execute contextual tasks in a minimum amount of time.
•
Ability to access services or information at any time and any place while on the move.
(b) Scope of a system Developers need to clearly specify the scope of a system. The scope determines the boundaries of a system in terms of tasks or functionalities that the system needs to support. For example, a system could focus on sensing and collecting users’ context
196
information, delivering services, controlling usersâ&#x20AC;&#x2122; behaviors in accessing mobile services, etc. In summary, the output of the analysis phase consists of system requirements and scope of a system for context-aware services.
6.2.2. Design Phase There are two steps in designing a system for context-aware regulated services. It starts from an architectural design and goes on to a detailed design. An architectural design focuses on elements in the system. A detailed design discusses the structure, template and interaction of system elements.
6.2.2.1. Architectural Design As discussed in earlier Chapters, system elements refer to key concepts of a system. It is essential to identify a list of key concepts which are required in the system before going on to a detailed modelling. This section discusses essential system elements which are required for building context-aware regulated services. It models a system as a collection of system elements and each of these elements is represented as a module that is independent from other modules. However, these system elements can interact or communicate in order to pass on the information. We recognize four system elements in context-aware regulated systems: (1) Environment element As discussed in Chapter 3, our MHS framework views a pervasive computing environment as a set of logical boundaries (e.g., domains) that may consist of several physical boundaries (e.g., spaces and sub spaces). We have discussed in detail the definitions of a domain, space, as well as the relationship between them in Section 3.1, Chapter 3. There are seven aspects that developers need to consider during the design of this element: (a) Set logical (domain) and physical (space) boundaries of an environment
197
An environment can be a domain or a space (known as an environment type). One domain can have sub domains and a domain/sub domain can have zero or more than one space (as shown in Figure 3.2). One space can only belong to one domain/sub domain. For example, a campus domain consists of several departments (e.g., IT department, Business department, etc.). Each of these departments consists of several buildings (e.g., library, lecture halls, etc.). Each of these buildings consists of several floors and within a floor, it has several rooms. A developer needs to set the boundary of a domain, sub domain, space and sub space. From the above example, we can say that a campus environment is a domain, a department is a sub domain, a building is a space and a room is a sub space. The sub space (e.g., a room) can have sub spaces. When a sub space contains another physical space, the sub space is considered as a space of that sub space. Figure 6.2 below illustrates the domain and space boundaries in pervasive computing environments.
Legend: = a domain = a sub domain = a space
= a sub space
Figure 6.2: Domain and Space Boundaries in Pervasive Computing Environments (b) Group physical boundaries into a logical boundary As discussed in Section 3.1, Chapter 3, we recognize two types of a logical boundary in pervasive computing environments: a geographical boundary and an organization boundary. After grouping the physical spaces within logical boundaries, we hope developers could come up with a list of domains, sub domains, spaces and sub spaces as shown schematically in Figure 6.3.
198
(c) Register logical and physical boundaries with the system After grouping physical spaces into the logical boundary, developers then need to register domains and spaces with the system. The purpose of this registration is to keep track of the domains and spaces in the system. The MHS framework supports the module to register/deregister domains and spaces as shown in Section 4.1.1.7, Chapter 4.
Domain
Sub domain
Space
Sub domain
Space
Sub space Legend = Has domain/sub domain relationship = Has space/sub space relationship
Figure 6.3: Hierarchical Relationships between a Domain and Spaces (d) Represent physical boundaries Developers then need to represent the spaces (e.g., using a physical or symbolic representation) as discussed in Section 2.2.1, Chapter 2 and Section 3.1, Chapter 3. (e) Create a mapping document of a logical boundary and its physical boundaries The mapping between a domain and physical spaces need to be created. The purpose is to store a list of domains with its physical spaces and sub spaces. We present a template that shows the mapping between a logical boundary and its physical spaces in Figure 6.4 The template also shows the mapping between spaces and the associated devices. The mappings are in XML.
199
(f) Create policies (rules) which are specific and relevant to logical and physical boundaries The policy is specific to a logical or physical boundary. Different spaces may have different rules or policies. The policy is to control the visibility of services and tasks that the user can perform in specific contexts (e.g., at certain day, time and activity). We have illustrated samples of policy documents in Figure 3.12 and Figure 3.13, Chapter 3. (g) Calibrate physical boundaries It is for location sensing purposes. The calibration can be done by using a location sensing software tool (e.g., Ekahau 2.0). The calibration is done to improve the accuracy of location sensing. At the end, developers need to fill in the following checklist (see Table 6.1) and the details of each domain and space boundaries. This is to ensure that all the above steps have been completed. The detail of a domain or sub domain is illustrated in Table 6.2. The detail of a space or sub space is illustrated in Table 6.3. Note: the column name “device” in Table 6.3 refers to a computing device element as described in section 5. The column name “policy” in Tables 6.2 and 6.3 refers to the policy document as illustrated in Figure 3.12 and Figure 3.13. We briefly discuss the policy element in section 3 below. Domain ID
Has sub domain
Table 6.1: Detail of an Environment Element
Environment Type
ID
Name
Description
Has sub domain
Has space
Policy Service ID ID
Table 6.2: Detail of a Domain Boundary
200
Environment
ID
Name
Description
Category
Type
Has sub space
Policy ID
Device ID
Table 6.3: Detail of a Space Boundary (2) Entity element As discussed in Chapter 3, a user is an active entity who places requests on a system. The user’s request is computed by a software system that resides on the server side and is executed by a software client that resides on the client side. A software client is a passive entity that performs tasks as requested by users. The software client performs proactive behaviours such as proactively suggesting a list of available services for users and automatically performing tasks on behalf of users (as specified in the user’s profile document). There are four aspects that developers need to consider for this element: (a) Register or deregister an entity The purpose is to keep track of a number of entities in the system. (b) Assign a role to an entity The role determines permission, prohibitions and obligations which are imposed on an entity. Such roles are a super entity, a power entity and a general entity. Users with different roles would have different permission in accessing services, as well as prohibitions and obligations (as shown in Figure 3.12 and Figure 3.13). We illustrated a mapping between an entity and a role in Figure 6.5 below. (c) Register the ownership of an entity This is related to objects that an entity owns (e.g., a room and personal belongings such as a laptop and a pocket PC). The purpose is to keep track of an entity’s personal objects (items). (d) Keep track of a user’s contexts This is to monitor a user’s current contexts. For example, a user’s current location, activity, etc.
201
In addition, there are two tasks that the end-users need to specify. However, they are not compulsory: 1. A set of policies that describes when and how a task needs to be performed. If there is no uOsp, that simply means the system does not need to perform an automatic task on behalf of a user. 2. A set of policies that governs how other users behave when accessing services in their room. This task is only applied to users who own a physical space (e.g., an office room) in the environment. The following is the checklist and detailed information about the entity that developers need to fill in. The detail of an end-user is illustrated in Table 6.5. The detail of a software client is illustrated in Table 6.6. Note that a column named â&#x20AC;&#x153;policyâ&#x20AC;? in Tables 6.5 and 6.6 refers to a policy element. The detail of the policy element is illustrated in Table 6.9. Entity type End-user
ID
Software client
Table 6.4: Detail of an Entity Element
ID
Name History
Role
information
Ownershi
Policy
p
ID
Table 6.5: Detail of a User Element
ID
Description
Role
Policy ID
Table 6.6: Detail of a Software Client Element
202
(3) Contextual task element A contextual software system refers to a system component that may reside on a client or server side for delivering contextual tasks. We recognise three contextual task elements for building context-aware regulated services: I. Context element As discussed in Section 1.2, Chapter 1, a context is a situation that could influence users’ needs. For example, during exam periods, a student would require a set of learning and online services. We have discussed in detail different types of context information in pervasive computing environments in Section 1.2, Chapter 1. There are two aspects that developers need to consider for this element: (a) Decide how often to update the context information It is important to know how often to update the context information. This is because some contexts are dynamic whose values often change (e.g., current weather, time, temperature, a user’s location, etc.). Some contexts are relatively static (e.g., current day, a user’s identity, etc.). In general, context information only needs to be updated when changes occur. (b) Register or deregister context information It is to keep track of a number of contexts used in the system. The following is the checklist that developers need to fill in for a context element. Context ID
Context name
Context description
Context type Static
Dynamic
Table 6.7: Detail of a Context Element II. Service element As discussed in Section 3.3, a service is a software system that is enlisted as users need them. Ideally, as soon as users step into a place, the right service for the user is delivered without the need to request it. The context-aware system must enable users to receive a
203
relevant set of services that fit his/her current contexts, instead of a barrage of irrelevant services. A service is considered relevant to users if the services are enlisted as users need them at the right context. We have discussed in detail samples of context-aware services in Section 4.1.1.6, Chapter 4 and how to add new context-aware regulated services to the system in Section 4.3, Chapter 4. There are six aspects that developers need to consider for this element: (a) Identify lists of services in the system Developers need to identify services which are relevant to the aim of the system. For example, a campus system would require services which are related to education such as an online teaching service, a lecture information service, a lecture recording service, etc. (b) Identify the visibility of each service As discussed in Section 3.3, Chapter 3, there are three aspects that would affect the visibility of a service. These are based on a scope of a service, a userâ&#x20AC;&#x2122;s role and space policies. Developers need to identify which aspect to use. (c) Identify the accessibility of each service Developers need to identify the approach used to access services such as using a proactive or a reactive approach (see Section 3.3, Chapter 3). (d) Specify a service caching policy Developers need to specify a policy (rule) that describes what and when services need to be cached and removed. (e) Create a service application Developers need to create a service application (e.g., in the form of a web page or mobile code). The web page or mobile code has the same name as the service name. The mobile code can be created by using our MHS framework that supports the delivery of the code from a server to a mobile userâ&#x20AC;&#x2122;s device, as well as the execution of the code on the userâ&#x20AC;&#x2122;s mobile device. (f) Register or deregister a service
204
It is to keep track of a number of services in the system. The following is the checklist that developers need to fill in for this element: Service ID
Service
Service type
name
Service
Service
Service
scope
accessibility
visibility
G
L
P
R
Table 6.8: Detail of a Service Element
Note: G = Global L = Local
P = Proactive R = Reactive
III. Policy element As discussed in Chapter 1, the main purpose of having context-aware regulated services is to control usersâ&#x20AC;&#x2122; behaviours in accessing services in pervasive computing environments. In a specific context, a space or a user may need to be in control by restricting behaviours of other entities in accessing services or performing actions on the service. As discussed in Section 3.3, Chapter 3, a policy specifies a set of permission that an entity can do, a set of obligations that must be performed and a set of prohibitions that should not be performed in specific contexts. All entities (e.g., users) within a system are bound to the rules and each action that they perform need to comply with the rules. We have discussed in detail the context-aware policy requirements, issues and design in Section 3.4, Chapter 3. There are four aspects that developers need to consider for this element: (a) Identify a set of policies which are required in the system Developers need to specify policies for public spaces (e.g., a corridor, lecture building, library building, etc.). End-users who own a room specify policies for their private rooms (spaces). They can also impose a set of obligations on a system in specific contexts. We present a policy template in Figure 6.8. The template describes the mapping between
205
contexts, services and rules. (b) Identify a list of contexts which are relevant to the policy As a policy is context-aware, developers need to specify a list of contexts which are relevant and useful for the policy. The context can be location, day, time, and activity. We describe a template that shows a mapping between context information in Figure 6.9. (c) Specify a cached policy This is related to the question of where to cache the policy (e.g., on a server side or a mobile user’s device), when to cache and remove the cached policy. (d) Register or deregister a policy This is to keep track of the policies in the system. The following is the checklist that developers need to fill in for a policy element. The column name “service id“ refers to a service element as illustrated in Table 6.8. The column name “context id” refers to a context element as described in Table 6.7. Policy
Policy
Policy
Policy
Service
Context
ID
description
imposed
object
ID
ID
By
On
Table 6.9: Detail of a Policy Element (4) A computing device element The context-aware system consists of any computing devices (e.g., portable or embedded, networking and sensor devices) in the environment. A wireless connection is crucial in pervasive computing environments. It wirelessly connects all computing devices (e.g., mobile devices, sensing devices, server machines and networking devices) in the environment. The wireless connection is intermittent; ideally, a mobile user could connect to the wireless network at any time. There are two aspects that developers need to consider for this element: (a) Specify a wireless infrastructure
206
A pervasive computing environment may consist of heterogeneous wireless infrastructures such as: Wi-Fi, Bluetooth, Infrared, etc. (b) Register or deregister a computing device It is to keep track of the devices in the system. The following is the checklist that developers need to fill in for a computing device element: Device ID
Device
Device IP address
Device location
description
Table 6.10: Detail of a Computing Device Element Our methodology briefly discusses different types of computing devices in pervasive computing environments. The networking infrastructure is not addressed in this methodology. This is considered important as part of our future work (see section 6.5).
6.2.2.2. Detailed Design: From Design to Implementation This section presents templates which are used for building context-aware regulated services using the MHS framework. A template represents a model of a system element. A template contains a mapping between system elements. It is an XML document that conforms to the XML schema as described in the Appendix. The underline formatting on the tag element (e.g., “SubDomain”), means the occurrence of the element can be more than one. In this case, the element name “HasSubDomain” (see Figure 6.4) can have more than one sub domain. In total, there are six templates that developers need to create. The idea is to guide developers from design to implementation. (a) Environment model Table 6.1 describes the “has relationship” between domains and spaces in pervasive computing environments. The mapping between domains and spaces gives useful information for the system to retrieve a relationship between a domain and its spaces. For example, list of domains in the system, list of spaces or sub spaces under the 207
domain, total number of spaces or sub spaces under the domain, list of sub spaces under the space and total number of sub spaces under the space. The following template describes the details of domains and spaces in the system. Based on the information from Tables 6.1, 6.2 and 6.3, developers can start to fill in the following template. <Environment_Collection> <Environment type="a domain"> <ID> a unique identity of an environment </ID> <Name> name of an environment </Name> <Description> description of an environment </Description> <HasPolicy> <Policy id="a unique identity of a policy"/> </HasPolicy> <HasSubDomain> <SubDomain id="a unique identity of a sub domain"> <Space id="a unique identify of a space"/> </SubDomain> </HasSubDomain> <HasService> <Service id="a unique identity of a service"/> </HasService> </Environment> <Environment type="a space/sub space"> <ID> a unique identity of an environment </ID> <Name> name of an environment </Name> <Description> description of an environment </Description> <Category> a public or private space </Category> <HasPolicy> <Policy id="a unique identity of a policy"/> </HasPolicy> <HasSubSpace> <SubSpace id="a unique identity of a sub space"/> </HasSubSpace> <HasDevice> <Device id="a unique identity of a device"/> </HasDevice> </Environment> </Environment_Collection>
Figure 6.4: A Template of an Environment Element (b) Entity model The following template describes detail of an entity in the system. It is based on the information from Tables 6.4, 6.5 and 6.6. <Entity_Collection> <Entity type="an end user"> <EndUser id="a unique identity of a user" domain="a domain where the user is registered"> <Name> name of an entity </Name> <HistoryInformation> history information of an entity </HistoryInformation>
208
<Role> role of an entity </Role> <Ownership> <Spaces> <Space id="a unique identity of a space"/> </Spaces> <Devices> <Device id="a unique identity of a device"/> </Devices> </Ownership> <HasPolicy> <Policy id="a unique identity of a policy"/> </HasPolicy> </EndUser> </Entity> <Entity type="a software client"> <SoftwareClient id="a unique identity of a software client" domain="a domain where the software client is registered"> <Description> a brief description of a software client </Description> <Role> role of a software client </Role> <HasPolicy> <Policy id="a unique identity of a policy"/> </HasPolicy> </SoftwareClient> </Entity> </Entity_Collection>
Figure 6.5: A Template of an Entity Element (c) Context model Table 6.7 describes detail of a context element. Based on the information from Table 6.7, developers can start filling in the following template. <Context_Collection> <Context id="a unique identity of context information"> <Name> name of context </Name> <Description> description of context </Description> <Type> type of context </Type> </Context> </Context_Collection>
Figure 6.6: A Template of a Context Element (d) Service model The following template describes the detail of a service element. Based on the information from Table 6.8, developers can start filling in the service element template. <Service_Collection> <Service id="a unique identity of a service"> <Name> service name </Name> <Scope> scope of a service </Scope>
209
<Type> type of a service e.g., a shared resource service </Type> <Accessibility> an accessibility of a service </Accessibility> <Visibility> a visibility of a service </Visibility> </Service> </Service_Collection>
Figure 6.7: A Template of a Service Element (e) Policy model Based on the information from Table 6.9, developers can start creating a policy document. The following template describes the mapping between contexts, services and rules. <Rule> <Activity name="activity name"> <Right by="imposed by" on="imposed on"> <Service allowed="service name"> <Action allowed="action name"/> </Service> </Right> <Obligation by="imposed by" on="imposed on"> <Service obligated="service name"> <Action obligated="action name"/> </Service> </Obligation> <Prohibition by="imposed by" on="imposed on"> <Service prohibited="service name"> <Action prohibited="action name"/> </Service> </Prohibition> </Activity> </Rule>
Figure 6.8: A Template of a Policy Element The mapping between an activity and location, day and time contexts is described in the following template. <ContextActivityCollections> <ContextActivity forLocation="a unique identity of a space" createdBy="created by"> <ActivityDetails day="day of the week" startTime="start time" endTime="end time"> <Activity name="activity name"/> </ActivityDetails> </ContextActivity> </ContextActivityCollections>
Figure 6.9: A Template of Mapping between Activity and Context Information
210
(f) Computing device model The following template describes the detail of computing devices in the system based on the information from Table 6.10. <Computing_Device_Collection> <Computing_Device id="a unique identity of a device"> <Description> description of a computing device </Description> <IPAddress> a unique IP address of a device </IPAddress> <Location> the physical location of a device </Location> </Computing_Device> <Computing_Device_Collection>
Figure 6.10: A Template of a Computing Device Element
As part of the detailed design, we now discuss the relationship between system elements.
Figure 6.11: Relationships between System Elements
211
As illustrated in Figure 6.11, a pervasive computing environment has a domain that consists of several physical spaces. In the environment, it has zero to many mobile users who are always on the move (e.g., move between spaces), software components (i.e., a contextual component, policy component and service component) and several computing devices which are wirelessly connected. An environment (e.g., a space) creates a policy to govern users’ behaviours for accessing services within a space in specific contexts. A user could also specify a policy to impose a set of obligations on the system (as discussed in Section 4.4, Chapter 4). In addition, a mobile user can request services and perform actions on the service. The permissibility to execute and perform actions on services depends on users’ roles and current context. The services are executed on a user’s mobile device or any embedded device in the environment. We now summarise the design phase of our methodology: 1. Describe elements of the system. This forms the foundation for the system of context-aware services to be implemented for a domain. We need to have a comprehensive understanding of system elements. For example, as an environment element, a domain in the environment typically corresponds to a logical boundary that offers a unique feature. This logical boundary can be a logical scope/area, an organization itself or a department within an organization. In addition, a system consists of several elements. An element in a system typically corresponds to: •
an actor that plays an important role, or
•
an individual, either within a system or organization or acting independently.
Output: A list of aspects that developers need to consider for each system element. 2. Identify details of tasks within a system element. Output: Systematic steps with a brief description of each task. 3. For each system element, elaborate details of properties within the element. Output: A standardized table with its details of properties (as in Tables 6.1, 6.2, and 6.3 for an environment element). 4. Identify a template to specify required fields (properties) for mapping within a system element.
212
Output: A standardized template as in Figure 6.4 for an environment element. 5. Identify an interaction and relationship between system elements. This gives a high level picture of a pervasive computing environment and its constituents. Output: A relationship model between system elements (as shown in Figure 6.11).
6.3.
Case Study
The scope of a pervasive computing environment is broad. It covers a variety of domains with its spaces and sub spaces. This section presents a case study to evaluate the feasibility of our methodology. The case study presents a real sample of a pervasive campus domain where such a context-aware system might be developed. By following our guidelines, we hope to achieve a system design that is modular, open, dynamic and independent of any platform or language. In general, the fundamental concepts for building context-aware regulated services are the same across domains, each of which has environments, entities, software systems, computing devices and wireless networking that is installed everywhere in the environment. The main differences across domains are the system modelling for each of these elements. This is to suit the need or purpose of a domain. For example, a campus domain has target users: students and staff. All services, context and rules are related to education purposes.
6.3.1. A Pervasive Campus Domain The case study discusses a development of context-aware regulated services in a campus domain. Consider a campus domain, we want to add context-aware regulated services to it [SyL07a]. The MHS methodology guides us in this, by helping us to focus on the key concepts as required. Based on how teaching materials are delivered, a campus domain can be divided into two sub domains (see Figure 6.12): (a) On campus sub domain
213
It involves a direct interaction between lecturers and students. Examples of on campus sub domains are at school, at college and at university. Users (e.g., a student or staff) move around spaces within a campus building that consists of several floors and rooms. They can be in many different campuses at one time. (b) Off campus sub domain There is no direct interaction between lecturers and students (also known as a long distance education), where students study materials by themselves by listening to online lectures. Off campus involves a student who enrolls for a subject and other entities surrounding the student (e.g., colleagues, parents, etc.). Campus domain
On campus
Off campus
Figure 6.12: A Campus Pervasive Domain A context-aware campus system delivers relevant services depending on entitiesâ&#x20AC;&#x2122; contexts. A campus domain is a top hierarchy, where its properties and behaviours are inherited by its sub domains (e.g., on campus and off campus sub domains). The sub domains can further be refined via the inherited properties and behaviours according to the domain purpose. In addition, a campus domain has several target entities: students (undergraduate and postgraduate) and staff (lecturers, administrative staff and technical staff). Each of these target entities has different needs when completing their daily tasks. For example, a student aims to learn new skills and knowledge by attending classes. On the other hand, a lecturer aims to educate students by teaching them useful materials. Therefore, the entities may require different services in different contexts in order to suit their needs. When an entity is in a campus domain, the most relevant services are the local services which are related to a campus environment. For example, a reminder service, a browsing service, a room booking service, etc. Apart from local services, an entity is
214
also able to access other related services (i.e., global services) which are available in other pervasive computing domains. This can be a shopping related service (from a shopping domain), a music service (from an entertainment domain), a health related service (from a health-care domain), etc. The idea is to allow end-users to access any information (e.g., shopping information), though s/he is currently at a campus domain or performing some tasks while on the move, regardless of a userâ&#x20AC;&#x2122;s current location. Ideally, having a logical domain boundary does not restrict entities to access information from another boundary or domain. It is to group system elements under one domain and to allow easier management. For example, user A is now at campus. When she enters a campus domain, all campus related services are delivered such as a campus navigation service, a lecture information service, etc. At lunch time, she wants to browse the restaurant nearest (within walking distance) to the campus. The system then suggests a list of nearby restaurants. This is done by contacting a restaurant system domain that manages all registered restaurants. Ideally, the user does not need to know her current location (e.g., a domain and space that s/he is in), all low level tasks of retrieving the required services and communication/interaction between system domains are handled implicitly by the system. In addition, some services in a campus domain may not be needed by entities at all times. For example, a service that is related to a particular object is only required when an entity would like to know the details about the object. The object can be any computing device or item (e.g., a cup, a painting, etc.) in the environment. This service is delivered only when there is an explicit request from users. We recognize two types of educational systems in campus environments: (a) e-learning system It is a current education system that relies on the Internet connection in distributing teaching materials. The materials are available online and widely accessible from any device that is connected to the Internet. It gives students complete independence to access lecture materials (information) from any location and time. However, current systems generally target desktop PC users with a stable wired Internet connection. Hence, the current learning system still does not support the mobility of students.
215
(b) p-learning system Recent advances in mobile devices, wireless networking and sensing systems are offering new possibilities to develop an advanced learning system that is proactive, adaptive, intuitive and appropriately available for students. Sensor devices and software systems can be invisibly installed in the environment of our everyday lives. This convergence of advanced computing devices and connected software learning systems via wireless technology and the Internet is known as pervasive learning (p-learning). This case study focuses on the concepts and design of a system which can deliver context-aware regulated services in a campus environment.
6.3.1.1. Analysis Phase In this phase, we analyse pervasive campus environments, starting with capturing system requirements and defining scope of a system. Having a clear understanding of a pervasive campus environment and its constituents help to better design and implement the system. (1) Capturing system requirements The target environment is a pervasive campus environment that delivers teaching materials to users depending on their current contexts. The system mainly targets students, lecturers and staff to perform their daily tasks. The system needs to be available to users from any location and time. Ideally, users are able to access learning resources while on the move or in different environments/domains (e.g., at home, shopping domain etc.) We now describe six main requirements in developing a p-learning system: (a) Support interaction between a teacher and students. This is an issue in current learning systems, if the class size grows, as the teacher may not be able to extensively accommodate all students (e.g., their questions) during the lectures. (b) Support awareness and understanding studentsâ&#x20AC;&#x2122; contexts or activities. Current learning systems do not take into account the notion of contexts and services. Having the
216
ability to sense users’ current contexts and delivering relevant information (according to the student’s needs) would certainly motivate students in learning new materials. Perhaps, by taking into account information regarding the student’s preferences on when and where s/he would like to receive such services would be useful. The p-learning system then needs to trigger such services or automatically perform a task (on behalf of students) when the context is satisfied. (c) Support proactivity. The current learning system does not support proactivity and autonomous behaviors. Having a proactive learning system that could sense a student’s current contexts and automatically deliver relevant services would be an advantage. For example, as soon as the p-learning system senses the user’s current location (approaching lecture room), the system proactively retrieves and downloads relevant lecture materials onto students’ mobile devices, and hence, by the time the students enter the lecture room, the material is ready to be read. (d) Anywhere access to information. The current learning system relies on the Internet connection to access the lecture information or other teaching resources. Ideally, the teaching materials need to be available and widely accessible to students at any time and location and so, students can prepare their homework or study for the test at any leisure time while on the move (e.g., on the train). The p-learning system needs to target mobile devices and cache the information for future re-use (and so, enables students to access teaching materials while on the move with or without network connection). (e) Have an intuitive design and target all level of users. A p-learning system needs to target all level of users such as expert users who are familiar with the system and noncomputer literate users who have no or little knowledge about computing. (f) Support policy to control access to services. Having a learning system that can control students’ behaviours in accessing services would also be an advantage. It controls the service visibility and govern service execution in particular contexts. For example, during the lecture, students are not allowed (without prior consent) to access any services (e.g., browsing Internet, chatting with friends, listening to music or playing a game – all these entertainments are in the form of services) other than the lecture material service.
217
This is possible by integrating the p-learning system with policy mechanisms to control and govern mobile services execution in pervasive campus environments. It also allows users to specify their set of preferences and impose a certain task for a system to automatically perform. The following use case diagram describes usersâ&#x20AC;&#x2122; activities (e.g., students and lecturers) in a campus environment.
Access services
<<includes>>
Enter/l eave a space Request services
Student
Access resources Prepare materials ask
Sit for a test respond
Work on assessments
Query
Lecturer
Mark/correct assessments
<<includes>>
Submi t assessments
Figure 6.13: Use Case of Usersâ&#x20AC;&#x2122; Activities in a Pervasive Campus Environment (2) Refining Scope A p-learning system aims to deliver context-aware services to improve current learning activities. The idea is that a user can communicate with any embedded or non-embedded computing devices which are invisibly integrated into the environment as soon as s/he
218
steps into a particular space. It is to enable users (e.g., students, staff and lecturers) to access information at any time while on the move. It also helps users perform contextual tasks automatically. For example, auto downloading lecture notes on Monday at 3PM, as soon as the user (e.g., a student) approaches the lecture theatre A103.
6.3.1.2. Design Phase This section discusses in detail the design of a p-learning system that focuses on delivering context-aware regulated services. (1) Architectural design Our approach for developing a context-aware learning system is different from existing campus systems [Bro01; GBB03; PCC04; WPB03] as we view a pervasive campus environment as a collection of mobile users, mobile services, mobile devices, contexts and policies. The system is able to deliver relevant services onto the userâ&#x20AC;&#x2122;s mobile devices in appropriate contexts. We recognize seven basic system elements for delivering context-aware regulated services in a campus system. (a) A campus environment element We view a campus domain as a top hierarchy that consists of many sub domains such as a collection of faculties and departments (see Figure 6.14).
219
Figure 6.14: A Campus Domain and Sub Domains Within the department itself, we have another sub domain (e.g., school of computer science and software engineering â&#x20AC;&#x201C; SCSSE school and school of network computing). The SCSSE school sub domain also consists of several physical boundaries such as floors and rooms (e.g., meeting rooms, office rooms, etc.). Noted services and contexts are shared across domains/sub domains. Figure 6.15 below further illustrates spaces and sub spaces of a campus domain (e.g., a Berwick campus). The campus consists of several storey buildings (e.g., a lab building, student administrative building, staff building, library building and lecture building). Each of these buildings consists of several floors (e.g., lab building/floor1). Each of these floors further contains several physical rooms and sub rooms (e.g., an engineering lab room that consists of production and testing sub rooms). Moreover, a campus also consists of a single storey building; for example, a car park that consists of several parking lots and Berwick park that consists of several recreation sections (e.g., a tennis court, garden, swimming pool, etc.)
220
Figure 6.15: Monash Berwick Campus Map
In addition, a campus domain consists of two types of physical rooms: a permanent room and temporary room. The physical construction of a permanent room does not change (e.g., a library building and a lecture building). In contrast, a temporary room changes depending on the need of a user (e.g., depending on functions or occasions). For example, for an exam purpose, an exam hall is divided into two sub rooms. The following is a checklist to describe the campus domain and its spaces.
Domain ID
Has sub domain
CampusDomain01 1.Caulfield campus 2.Clayton Campus Table 6.11: Detail of a Campus Domain
221
Table 6.12 describes the detail of each domain and sub domain in a campus environment.
222
Environment type Sub domain
ID Caulfield campus01
Name Caulfield campus
Sub domain
Clayton campus01
Clayton campus
Sub domain
IT Faculty01
IT Faculty
Description
Has sub domain
Has space
A Monash Campus that is located
1. IT Faculty
at Caulfield
2. Business Faculty
St. George library building
A Monash campus that is located
N/A*
See sub domains*
1. SCSSE school
See sub domains
at Clayton
Policy ID
Service ID
Caulfield campus
Service 01
policy
Service 02
Clayton campus
N/A*
policy*
An IT organization
IT faculty policy
2. Network school
Service 01 Service 02
Sub domain
Business Faculty01
Business Faculty
A business organisation
N/A*
See sub domains*
Sub domain
SCSSE school01
SCSSE school
A department of SCSSE
1. Administration
See sub domains
Business faculty
N/A*
policy* SCSSE policy
2. Research 3. Teaching Sub domain
Administration01
Administration area
A
sector
that
Service 01 Service 02
handles
N/A
Administrative room
SCSSE policy
See SCSSE school
A sector that handles research
N/A
Research room
SCSSE policy
See SCSSE school
administrative tasks Sub domain
Research01
Research area
tasks Sub domain
Teaching01
Teaching area
An area that handles teaching tasks
N/A
Teaching room
SCSSE policy
See SCSSE school
Sub domain
Networkschool01
Network school
A Network school
N/A*
See sub domains*
Network school
N/A*
policy*
Table 6.12: Details of a Campus Domain and Sub Domains Note: N/A = Not applicable * = The detail is not discussed in this thesis for simplicity
223
The following table describes the detail of each space and sub space which belong to a domain or a sub domain. The table indicates that the space Administrative01 has two sub spaces which are Administrative room A.1 and Administrative room A.2. Environment type Space
ID
Name
Description
Category
St.George
St. George
A law library
Public
Library01
library
at Caulfield
Has sub space
Policy ID
Device ID
Does not
Caulfield
Device
space
have
campus
01
campus Space
Space
Adminis-
Adminis-
Adminis-
Public
1.Adminis-
SCSSE
Device
trativeRoom
trative
trative rooms
space
trative
policy
02
01
room
at Caulfield
room A.1
campus
SCSSE
Device
Research
Research
Research
Public
2.Administrative room A.2 Does not
Room01
room
rooms
space
have
policy
03
at Caulfield campus Space
Teaching
Teaching
Teaching
Public
Does not
SCSSE
Device
Room01
room
rooms
space
have
policy
04
at Caulfield campus
Table 6.13: Details of Spaces and Sub Spaces in a Campus Domain
(b) Entity element Target users tend to be on the move. Software systems, computing devices and wireless networks are embedded everywhere in the building, floor, and room in order to proactively sense usersâ&#x20AC;&#x2122; contexts and deliver relevant services. Figure 6.16 illustrates activities in the lecture room, where at the beginning, there are only three students in the class and the next moment another student enters the classroom. During the lecture, each student may perform different activities (e.g., reading lecture notes, listening to the lecture, browsing Internet, etc.).
224
Entrance door Wireless network
“Sue is entering a class”
Software systems are embedded in the lecture room
“Prof. Smith is giving a lecture”
“Bob is reading lecture notes”
“Anne is listening”
“Dave is browsing the net”
“Empty workstations”
Figure 6.16: End-Users’ Activities in the Class Room
The following checklist describes entities in the campus system. Entity type End-user
ID
Software client
x
Student01
x
Student02
x
Student03
x
Student04
x
Lecture01 x
SoftwareClient01
Table 6.14: Detail of Entities in a Campus Domain
225
The detail of users in a campus domain is described as follows: ID
Name
History
Role
Ownership
information Student
Sue
01
Policy ID
Sue was at the
General
Own a laptop
Does not
library at
entity
device
have a policy
Bob was at the
General
Does not own any
BobPolicy01
lecture room at
entity
device
Anne was at
General
Does not own any
Does not
Gym at
entity
device
have a policy
Dave was at car
General
Pocket PC device
Does not
park at 1PM,
entity
12.30PM, Monday 18 June 2007 Student
Bob
02
1PM, Monday 18 June 2007 Student
Anne
03
12.30PM, Monday 18 June 2007 Student
Dave
04
have a policy
Monday 18 June 2007 Lecture
Prof.
Prof. Smith was
Super
1. Laptop device
Smithâ&#x20AC;&#x2122;s
01
Smith
at meeting room
entity
2. Pocket PC device policy
at 1PM, Monday 18 June 2007 Table 6.15: Details of Users in a Campus Domain
226
The above table states that Dave is a student with the role “general entity” who owns a pocket PC device and does not have a policy document. Prof. Smith is a lecture with the role “super entity” who owns two devices: laptop and pocket PC devices and has a policy in a campus domain with the policy ID “Smith’s policy”. The detail of software clients in a campus domain is described as follows: ID
Description
SoftwareClient01 Software client that is installed on device01
Role
Policy ID
General
Software
entity
ClientPolicy01
Table 6.16: Details of Software Clients in a Campus Domain (c) Context element Context determines an applicable policy in the space. Useful contexts in a campus environment are a user’s identity, location, activity, day and time. Context can be dynamic (e.g., temperature, activity, preferences, location, etc.) or relatively static (e.g., a user’s identity, day and time). The following is a checklist that describes context information in a campus domain. Context ID
Context name
Context description
Context type Static
Dynamic
Context01
Day
Day of the week
x
Context02
Time
Time of the day
x
Context03
Location
An entity’s current location
x
Context04
Identity
An entity’s identity
x
Table 6.17: Detail of Contexts in a Campus Domain (d) Service element A target service refers to a particular service that a user wants to execute. The pervasive campus system focuses on delivering services to help users perform their activities in the campus (e.g., able to access information while on the move, automatic task service, etc.). Sensing students’ current context information, the system would be able to trigger and 227
deliver relevant set of services, which are considered useful for students in that particular context. There are three types of services in a pervasive campus environment: (i) Education services This service is useful for students and lecturers. It is to assist and motivate students in learning process by providing better interaction/communication between students and lecturers. For example, it helps students to better understand lecture materials by providing an online reference. It can also prohibit students to access/play unrelated tasks during the lecture (e.g., playing game, chatting, etc.). As for lecturers, a service can help to automatically notify students as soon as the lecture information is updated on the subject web site. Some sample education services are: •
Mobile Pocket Pad service allows mobile users to leave an electronic note and store it on the server. The e-note can then be pushed onto a client device when the user is in the right context (e.g., right location, day and time where such e-note is useful).
•
Mobile Lecture Information service: as a user walks towards a lecture theatre, a set of information related to who and what lecture is currently running in the lecture room is displayed on the user’s mobile device. The relevant lecture materials are also downloaded when the user enters the lecture room.
•
Mobile Recording service: it records a lecturer’s voice and downloads it onto each student’s mobile device when the lecture is finished. This is useful in a situation where a class size is large and hence, students who sit at the back of the lecture theatre may not be able to listen or receive the information clearly (due to some noise).
•
Mobile Questions/Comments service: this allows students to send comments or questions online (e.g., during the lecture, or at any time), the lecturer then can answer the student’s questions and reply only to that student or publish the question-answer in the subject forum (accessible for everyone). This service helps to smooth the lecture process (especially, if the class size is large) and encourage all students to ask questions.
228
•
Mobile Reminder service: the system reminds students of important tasks or activities that need to be completed at particular times. This can be from lecturers or the student’s profiles. For example, a lecturer sends a reminder regarding the due date of the assignment to a list of students who enroll in the subject. This reminder will be sent and downloaded onto students’ mobile devices.
•
Mobile Navigation service: it guides students to find a certain place (e.g., a lecture room) in a campus or find a particular book in the library.
•
Mobile VNC service: it allows a student to display his/her desktop information on any nearby machine that s/he is currently at.
•
Mobile Automated Task service: a service that performs an automatic task on behalf of a user (e.g., automatically download lecture notes the night before the lecture or when the user steps into the lecture room).
(ii) Administrative services This type of service is only useful for administrative staff and only accessible to them. Such services are a resource booking service, timetable managing service, online forum service, student/lecturer personal information service, enrollment service, academic record service etc. (iii) Technical services This service is to help technical staff (e.g., a helpdesk staff) enhance the education system. Technical staff maintains computing devices (e.g., a desktop, projector and server) and software systems (e.g., online learning materials). Sample services for technical staff are an email service, notification service, etc. The following is a checklist that describes services in a campus domain. Service ID
Service name
Service type
Service
Service
Service
scope
accessibility
visibility
G
L
P
R
229
Service name
Service type
Service
Mobile Pocket
Non-shared
01
Pad
resource service
Service
Mobile lecture
Non-shared
02
information
resource service
Service
Mobile
Non-shared
03
reminder
resource service
Service
Service
scope
accessibility
x
x
Students, staff
x
x
Students
x
x
Students, staff
service Service
Mobile painting
Shared
04
service
resource
x
x
Students, staff
service Table 6.18: Details of Services in a Campus Domain (e) Policy element By integrating policies into a campus environment, users can specify a set of rules on what services are allowed or prohibited in certain situations. A location context in a campus environment is represented by indoor physical spaces. One space policy may be different from another space policy. This depends on the purpose and activity that is currently running in the space. The space policy for a campus domain can be divided into two types: (d) Policies for a Public space such as a lecture room, corridor, library etc. The system (in this case, a developer) specifies a list of useful services that users may need in certain contexts along with actions that users are allowed to perform, must perform and are prohibited. However, a lecturer who is currently giving a lecture can override this default space policy. Each lecturer can specify how things need to be executed during the lecture (e.g., what services are allowed and not allowed and what to automatically perform during the lecture).
230
In one space, there are many policies written by many lecturers, but which policy to activate depends on what lecture is currently running. This information is retrieved from a booking system. The booking system manages the lecture time slot for a space. For example, Monday, 2-3PM is an Object Oriented (OO) Lecture at lecture hall 1, and hence, the policy written by the OO lecturer is applied at this space during this time. If the OO lecturer does not specify the policy, the system then uses the space policy. If there is no space policy, then a global domain policy is applied in the space. (e) Policies for a Private space such as a student’s or a lecturer’s office room. A private space policy is written by an owner of the room. All visitors (including a colleague) who are visiting a private space are bound to rules specified by the owner of the space and so, they are not allowed to execute any service or perform any action if not permitted by the owner. As for users who do not own spaces, they can also impose a set of tasks on the system to automatically perform (e.g., a lecturer imposes a task on a system to automatically download lecture materials onto students’ mobile devices as soon as they enter a lecture room). A lecturer can specify a rule to govern and control students’ behaviours in accessing mobile services in particular contexts. For example, a lecturer can specify a rule to prohibit access to services other than the lecture materials during the class. In this case, all entertainment services (e.g., a music service, online chatting or game service) are disabled during the class. The following is a table that describes policies in a campus domain. The table specifies that policy with ID “policy01” is imposed by a system on an entity with the role “general entity”. This policy permits entities to start service with ID “service01” under a certain context (in this case, context01). Policy ID
Policy
Policy
description
Imposed By
Policy01
Policy Object
Service
Context
ID
ID
Service01
Context01
On
It is for
A
General
controlling a
system
entity
Right
231
lecture building Table 6.19: Details of Policies in a Campus Domain
(f) Computing devices element This can be a mobile device such as a laptop, or a pocket PC that a user may bring along to access services. There are also computing devices which are installed in the environment such as sensor devices for monitoring users’ contexts, embedded computing devices and server machines. A campus domain supports two types of wireless connections: (a) indoor – inside the building, within floors and rooms, all wireless devices, sensor and software systems are connected using IEEE 802.11 connection, Bluetooth, etc; (b) outdoor (outside the buildings e.g., in the park, car park) mobile users communicate with sensing, software systems via GPS and a satellite connection). With a wireless connection, the user can interact with the system at any time and anywhere on campus. The following is a table that describes computing devices in a campus domain. Device ID
Device
Device IP address
Device location
190.0.0.1
in St.George library
description Device01
A desktop PC
building Device02
A laptop device
190.0.0.2
in the lecture building
Device03
A presentation device
190.0.0.3
In the lecture building
Table 6.20: Details of Computing Devices in a Campus Domain Figure 6.17 describes a high level view of a campus environment and the relationship between system elements. The figure is an elaboration of the “vanilla” Figure 6.11. As 232
discussed in the earlier sections, a campus domain consists of several building spaces. A domain and building spaces has a policy associated with it. A building space that does not have a policy uses a global domain/sub domain policy. The campus policy itself is context-aware, in which each of the policy is associated with a domain or space boundary. The relevant policy is enforced when a user is in the certain boundary. A user (i.e., a student or staff) is mobile who can move freely from one building space to another. Each user has a role. The role is associated depending on the type or position of the user in the campus. Different types of users handle different tasks and perform different activities. For example, activities of a student are to attend a lecture and learn new materials. An academic staff teaches a subject and the subject is managed by administrative staff. Technical staff is responsible for software and hardware related issues within the campus. A user also owns computing devices such as a mobile device or a desktop PC. A user is allowed to request services within the permission given by a space and services are executed on computing devices.
Figure 6.17: Relationships between System Elements in a Campus Domain
233
(2) Detailed design of a Campus Domain This section describes detailed templates of each system element in the campus domain. (a) Environment model Figure 6.18 below describes the mapping between a campus domain, its sub domains, spaces and sub spaces. The information is from Tables 6.11, 6.12 and 6.13. We only illustrate some domains and spaces/sub spaces to simplify the example. Other sub domains such as a “Clayton campus” and its spaces/sub spaces are not shown in this thesis. The mapping for a sub domain “Clayton campus” would be the same as demonstrated in the figure. <EnvironmentCollection> <Environment type="Domain"> <ID>CampusDomain01</ID> <Name>Campus Domain</Name> <Description>a campus environment</Description> <HasPolicy> <Policy id="CaulfieldCampusPolicy"/> </HasPolicy> <HasSubDomain> <SubDomain id="CaulfieldCampus01"> <SubDomain id="ITFaculty01"/> <Subdomain id="SCSSESchool01"/> <SubDomain id="AdministrationArea01"> <Space id="AdministrativeRoom01"/> </SubDomain> </SubDomain> <SubDomain id="ResearchArea01"> <Space id="ResearchRoom01"/> </SubDomain> <SubDomain id="TeachingArea01"> <Space id="ResearchRoom01"/> </SubDomain> <SubDomain id="NetworkSchool01"/> <SubDomain id="BusinessFaculty01"/> <SubDomain id="ClaytonCampus01"/> </HasSubDomain> <HasSpace> <Space id="St.GeorgeLibraryBuilding01"/> </HasSpace> <HasService> <Service id="Service01"/> <Service id="Service02"/> </HasService> </Environment> <Environment type="Space"> <ID>AdministrativeRoom01</ID> <Name>Administration area</Name> <Description>a sector that handles administrative tasks</Description> <Category>Public space</Category>
234
<HasPolicy> <Policy id="SCSSEPolicy01"/> </HasPolicy> <HasSubSpace> <SubSpace id="AdministrativeRoomA.1"/> <SubSpace id="AdministrativeRoomA.2"/> </HasSubSpace> <HasDevice> <Device id="Device01"/> </HasDevice> </Environment> </EnvironmentCollection>
Figure 6.18: A Detailed Template of an Environment in a Campus Domain (b) Entity model As illustrated in Figure 6.17, mobile users can be students such as undergraduate students and postgraduate students, and staff such as researchers, academic staff (e.g., lecturers), administrative staff (e.g., accountants, librarians), and technical staff (e.g., helpdesk staff). The role denotes the permission and responsibility that an entity has. We have illustrated the role and entity mapping in Figure 3.10. Figure 6.19 below illustrates the detail of an entity in the campus domain. <EntityCollection> <Entity type="End user"> <EndUser id="Student01" domain="Campus <Name>Sue</Name> <HistoryInformation> Sue was at the 18 June 2007</HistoryInformation> <Role>General entity</Role> <Ownership> <Spaces> <Space id="Space01"/> </Spaces> <Devices> <Device id="Device01"/> <Device id="Device02"/> </Devices> </Ownership> <HasPolicy>none</HasPolicy> </EndUser> <EndUser id="Student02" domain="Campus <Name>Bob</Name> <HistoryInformation> Bob was at the 18 June 2007 </HistoryInformation> <Role>General entity</Role> <HasPolicy> <Policy id="SuePolicy01"/> </HasPolicy> </EndUser> </Entity> <Entity type="Software client">
Domain"> library at 12.30PM, Monday
Domain"> lecture room at 1PM, Monday
235
<SoftwareClient id="SoftwareClient01" domain="Campus Domain"> <Description>Software system</Description> <Role>General entity</Role> <HasPolicy> <Policy id="SoftwareClientPolicy01"/> </HasPolicy> </SoftwareClient> </Entity> </EntityCollection>
Figure 6.19: A Detailed Template of an Entity in a Campus Domain
(c) Context model There are several types of users with different roles and activities in the campus environment. The system needs to deliver service information depending on the context of users. For example, an undergraduate student who is currently having an exam in the exam room will be getting less permission to access services compared to other students who are in study mode (e.g., not having an exam). We have illustrated a sample mapping between location and activity in Figure 3.11. The following figure illustrates the detail of a context element in the campus environment. <ContextCollection> <Context id=”Context01”> <Name>Day</Name> <Description>Day of the week</Description> <Type>Dynamic</Type> </Context> <Context id=”Context02”> <Name>Time</Name> <Description>Time of the day</Description> <Type>Dynamic</Type> </Context> <Context id=”Context03”> <Name>Location</Name> <Description>A user’s current location</Description> <Type>Dynamic</Type> </Context> <Context id=”Context04”> <Name>Entity identity</Name> <Description>A unique identity of an entity</Description> <Type>Static</Type> </Context> </ContextCollection>
Figure 6.20: A Detailed Template of a Context in a Campus Domain (d) Service model
236
The pervasive campus system explores context-sensitivity and mobile code in order to provide useful services for users with minimal or no effort for service set up prior to use. As the userâ&#x20AC;&#x2122;s context changes, the system proactively computes (i.e., done without user directives) a new set of services which are useful for the user in that context and this list of services is automatically updated on the userâ&#x20AC;&#x2122;s mobile device. As a user selects a particular service name on a mobile device, the highly compact (with respect to limited device resources) mobile code that provides control for the service is then downloaded. The execution of the service on the mobile device needs to be done in a minimum amount of time and so, the user would be able to see the service interface immediately or with minimum delay. <ServiceCollection> <Service id="Service01"> <Name>MobilePocketPad</Name> <Scope>Global</Scope> <Type>Non-shared resource service</Type> <Accessibility>Proactive</Accessibility> <Visibility>All users</Visibility> </Service> <Service id="Service02"> <Name>MobileVNC</Name> <Scope>Global</Scope> <Type>Shared resource service</Type> <Accessibility>Proactive</Accessibility> <Visibility>All users</Visibility> </Service> <Service id="Service03"> <Name>MobileRemoteMediaPlayer</Name> <Scope>Global</Scope> <Type>Shared resource service</Type> <Accessibility>Proactive</Accessibility> <Visibility>All users</Visibility> </Service> </ServiceCollection>
Figure 6.21: A Detailed Template of a Service in a Campus Domain (e) Policy modelling By default, the space imposes certain rights (denoted by spRu), obligations (spOu) and prohibitions (spPu) to users depending on the role that the user has and the physical space that the user visits. While on the move, the user also accesses services from a mobile device. The user can request executing a service or impose a certain obligation on the system (uOsp). This is to automatically perform the userâ&#x20AC;&#x2122;s tasks. We have
237
illustrated in Figure 3.12 and Figure 3.13 examples of public and private space policy documents in the campus environment. (f) Computing device model Figure 6.22 below describes the mapping between devices and its detail in the campus environment. Based on the information from Table 6.20, developers can fill in the following template. <ComputingDeviceCollection> <ComputingDevice id="Device01"> <Description>A desktop PC</Description> <IPAddress>190.0.0.1</IPAddress> <Location>St.George library </Location> </ComputingDevice> <ComputingDevice id="Device02"> <Description>A laptop PC</Description> <IPAddress>190.0.0.2</IPAddress> <Location>Lecture building </Location> </ComputingDevice> <ComputingDevice id="Device03"> <Description>A presentation device</Description> <IPAddress>190.0.0.3</IPAddress> <Location>Lecture building </Location> </ComputingDevice> </ComputingDeviceCollection>
Figure 6.22: A Detailed Template of a Computing Device in a Campus Domain
6.4.
Related Work
This section provides a detailed overview of the research work that has been done to date that also concentrates on providing guidelines in the field of: (a) Software testing methodology The software testing methodology focuses on software testing methods to test software applications [Cou01]. This methodology is known as Graybox methodology that highly depends on a platform debugger. This methodology is not relevant or directly related to our MHS methodology, as we focus more on an analysis and design for building contextaware systems (not on evaluation aspects), (b) Software engineering methodology
238
The methodology discusses ways to model software development processes such as using a waterfall, sashimi, spiral and agile development life cycles [Pre05; Som07]. The most popular software engineering methodology is the waterfall model. It divides development into several stages: analysis, design, implementation, testing and delivery. This waterfall concept is used in many existing software developments (e.g., a distributed system and an agent system). It aids developers in analysing, designing and delivering projects on time and within budget. (c) Object-Oriented methodology This methodology focuses on Object Oriented (OO) concepts such as a class, object, and properties (an attribute and method) [Rum95]. It uses a software engineering methodology (Software Development Life Cycle model) to analyse and model an OO system. The OO concepts are useful for a context-aware system implementation. However, it is not directly related to our MHS methodology, as the context-aware system proactively senses, delivers services and takes full advantage of the convergence of advanced computing devices and connected software systems via wireless technology, the Internet and Web services. (d) Agent methodology The agent methodology provides step by step guidelines for building an agent system that uses belief, desired and intention (BDI) concepts [WoD01; ZJW03; WJK00; JiS02; MYH04; JPS02]. A context-aware system makes use of some agent concepts (i.e., intelligent and proactive behaviours), but the guidelines for context-aware systems is substantially different from an agent approach. This is mainly due to pervasive computing systems typically consisting of other elements that require models and standardised semantic guidelines and templates to be used in pervasive computing environments. One notable guideline for building a context-aware system is by Mazuryk et al. [MPE05]. It focuses on requirements for developing services that takes into account information regarding end-users. However, their work focuses on low-level descriptions and concepts that target a particular system, environment, and platform. This makes it
239
difficult to borrow and apply the concepts for building context-aware systems in other system environments, which may have different system elements, architectures and designs. In addition, their methodology does not take into account the modularity aspect of system design and reusability of guidelines across different pervasive computing environments. Our methodology provides step by step guidelines from analysis to architectural and detailed designs. It covers a variety of required system elements in context-aware systems such as environments, entities, contextual software tasks and computing devices. The MHS methodology is independent of the system architecture, programming language and platform used for an implementation; but maps well to the MHS framework or its equivalent. Ideally, a system that is designed by following the MHS methodology could be implemented in many different ways (techniques) and can be used to design a system that targets a specific computing environment (e.g., a pervasive campus environment, a pervasive shopping environment, etc.). In addition, the MHS methodology provides a modular and clear-cut design by grouping similar system components under different modules. This allows a developer to modify the existing system elements in a particular module only, with less impact on other modules. In the future, we can still add new modules into the system, though not currently specified.
6.5.
Summary
Our methodology consists of a collection of hints and rules of thumb to guide the context-aware regulated services development process. This can be achieved by documenting the experience of building and using a context-aware framework in pervasive computing environments. A common way is by documenting potential issues that may occur when building or using a system; fundamental concepts to record facts which are used to solve recurring and repetitive problems; and common technologies used to build context-aware regulated services. When these solutions are documented, they can be made available to others to reuse. The challenge here is to identify and
240
represent concepts where a system was successful, so that one does not try to reuse solutions in inappropriate contexts. By following our methodology for developing context-aware regulated services, we think that useful systems could be achieved. We have applied our methodology in a campus pervasive computing environment (as discussed in Section 6.3.1 above) and we conclude that our methodology is: (a) Comprehensive It covers a variety of and the necessary system elements for implementing a system for context-aware regulated services. Our design guidelines explain in detail the required system elements in the analysis phase. It captures required concepts in the design and further discusses step by step tasks that developers need to do for each system element. At the end, the guidelines also present templates for mapping required tasks. This gives developers concrete ideas towards system implementation. (b) Reusable We have a general concept of system elements, in which, our concepts of an environment, entity and software system do not focus on one pervasive computing domain (e.g., a campus domain). Instead, we have an abstract view of system elements. This allows reusability of concepts in different pervasive computing environments (e.g., in a health care domain, shopping domain, etc.). (c) Independent Our guideline is independent of any technology, programming language and platform used for implementation. It is not specific to one particular system implementation. It is up to developers to build a system with any low level implementation detail. (d) Simple Our guideline is simple and easy to follow. We clearly divide the guidelines into two main phases (i.e., analysis and design phases). Each phase focuses on certain aspects. For example, an analysis phase focuses on understanding pervasive system scenarios and
241
requirements. The design phase focuses on concepts of a system (system elements) and aspects required for designing the elements. As part of our future work, we will consider the following aspects to improve our existing methodology: •
Heterogeneous network environments. A pervasive computing system needs to cope with intermittent connectivity (on and off connection/ disconnection) and a variety of network providers in the environment.
•
Semantic concepts. Having a semantic representation allows us to represent the same meaning of a system element, even though the implementation is different. For example, all context-aware systems understand the same definition of an entity element which is a target system. However, the instance or type of an entity for each domain may be different. Another example is the same definition of a service, but the behavior of a service is different across pervasive computing domains.
•
Security. Security is another aspect that needs to be carefully considered when designing a context-aware system. This is to ensure that data or information in the system is not tampered with by unauthorized users. It also ensures that an entity’s information or context information is only known by an owner or an authorized user. Security aspects that need to be considered are authentication, cryptography (encryption/decryption) and privacy (related to confidentiality of an entity’s profiles and context information).
242
CHAPTER
7
7. Conclusions and Future Work
In this chapter, we highlight important lessons that are applicable for building a contextaware regulated system. We also identify some possible opportunities for further research in developing more comprehensive context-aware services with policy mechanisms in pervasive computing environments. The MHS framework addresses six main requirements for building a context-aware regulated system as discussed in Chapter 1: â&#x20AC;˘
Use a location positioning system
The MHS system is independent of any indoor location tracking systems. This simply means we can employ any indoor location positioning systems with different sensing techniques (e.g., active badge, radio frequency, etc.). As for the implementation purpose, we employ current version of the Ekahau location positioning system (version 2.0) in order to keep track of a userâ&#x20AC;&#x2122;s location. This is because, the Ekahau does not require any
243
extra hardware for installation and it is based on the signal strength triangulation. •
Proactively capture contexts, discover and deliver relevant services
Our system proactively delivers relevant services upon detecting a user’s location. When a user selects a particular service name on the device, the system proactively downloads, compiles and displays the service interface to the user. The system also caches the service application for future re-use. •
Centralised services
Our system stores services in a centralised place that is accessible by all legitimate users from their mobile devices. This design supports reusability of services across computing devices in pervasive computing environments. •
Generic mobile framework
Our system supports the ability of creating mobile code (mobile service) via the MHS framework and adding existing traditional applications to the system. Having a remoting mechanism enables the system to add existing traditional applications. This is done via a system primitive action execution by using a system.diagnostic.process to start and stop the service or via the application API. •
Interoperable contextual software components
Our system develops contextual software functionalities as Web services. The Web methods are widely accessible from any platform and language. •
Support contextual policy to control access to services
Our system controls behaviours of users in accessing services, through the notion of policy. The policy is a set of rules that specify what an entity can do with services in a specific context. The MHS framework supports policy mechanisms for detecting and resolving conflicts if any, as well as enforcing relevant policies. Each of these policy software components is published via the system as a Web service, in order to support interoperability. Based on the prototype implementation and evaluation results, we found that
244
integrating a context-aware system with a policy mechanism offers several advantages and disadvantages. The main advantage is the system or space having control over users’ (e.g., visitors’) behaviours in accessing services in particular contexts (e.g., specific day, time and location) and hence, can limit conflicts that may occur between users who are trying to access the same service (e.g., a music service) on the same target device with different actions (e.g., one wants to stop and another wants to start the music service). The policy can restrict users from performing prohibited actions in the specific context (e.g., during exam time, all students are not allowed to retrieve their online notes on the “e-note service”). With the specified rule, a system can also help users to perform an automatic task as specified in the user’s profiles. The major drawback is a user would not have as much freedom and flexibility as s/he is used to having in accessing and executing actions on the service. This fundamental drawback in integrating policy with a context-aware system can be solved by balancing the convenience and compliance aspects, where a system has control over users’ actions or activities, but does not overly restrict or control users’ behaviours. Another drawback is a user may experience some delays in performing an action (e.g., needs to wait for some time to start a music service). This is due to authorisation checking, policy conflict detection and resolution that need to be performed before responding to the user’s request. The user is only allowed to perform the requested action if it is permitted by a space policy. This unnecessary delay could hinder the objective of a pervasive system that aims to perform actions on the service proactively and spontaneously. This issue can be addressed by employing efficient prefetching techniques (as discussed in Section 5.1.2, Chapter 5).
7.1.
Summary of Contributions
Pervasive computing environments such as a pervasive campus domain, shopping, etc. will become commonplace in the near future. The key to enhance these system environments with services relies on the ability to effectively model and represent contextual information, as well as spontaneity in downloading and executing the service
245
interface on a mobile device. The system needs to provide an infrastructure that handles the interaction between a client device that requests a service and a server which responds to the clientâ&#x20AC;&#x2122;s request via Web service calls. The system should relieve endusers from low-level tasks of matching services with locations or other context information. The mobile users do not need to know or have any knowledge of where the service resides, how to call a service, what the Service API detail is and how to execute a service once downloaded. All these low level tasks can be handled implicitly by a system. As described in Chapter 1, the aim of this dissertation is to investigate the contextaware regulated services field, propose concepts, design, implement and evaluate the system for context-aware regulated services in pervasive computing environments. In Chapter 2, we highlighted recent work done in location-aware systems, context-aware systems and policy based context-aware systems. In Chapter 3, we proposed the MHS concepts as an abstraction of a vision of context-aware systems and high level modelling to address tighter coupling of technology with people by taking into account contextual service and policy information. In Chapter 4, we presented the detailed developed design, and prototype implementation of the MHS system that provides the ability to execute mobile code (service application) on demand and control entitiesâ&#x20AC;&#x2122; behaviours in accessing services in pervasive computing environments. In Chapter 5, we demonstrated the feasibility of the proposed model. In Chapter 6, we presented the MHS guidelines for building context-aware regulated services. In summary, the main contribution of this dissertation is a high level model of a system for context-aware regulated services which consists of environments (domains and spaces), contextual software components, entities, and computing devices. The system allows users to interact with services on-the-fly without the burden of effortful setup or knowing the service APIs. Our MHS system simplifies the task of developing and maintaining context-aware applications for mobile clients. The system handles and caches all incoming services or code applications on the client side, as well as executing services when they have been downloaded. The applications (services) are user-centric, environment independent, context-aware, controlled via policies, mobile,
246
proactive and adaptive. As a result of deploying the MHS framework in a real pervasive campus environment, we have developed three samples of mobile services (shared and nonshared services) in order to help end-users complete their tasks efficiently. These are mobile Pocket Pad, mobile VNC and mobile Media Player applications. Through these sample mobile services, we gained a better understanding of the strengths and limitations of our concepts, design, and system implementation. In addition, these sample services provide us with a solid basis for evaluating our MHS system design and implementation against the system requirements that we have specified earlier in Section 1.2.1, Chapter 1. Based on the experiences of the MHS prototype system, we have shown that our system architecture: (1) Is comprehensive as it covers necessary contextual components and hides all low level details of interactions and so, enables building of context-aware regulated services that target different levels of users successfully. (2) Is extensible and interoperable as adding new services in the future will not be an issue, as well as the system functionalities can be invoked easily from disparate platforms and languages. It is also significantly easy to program (to add a new contextual functionality, to add a new behaviour on the service and etc.) or even, to modify an existing contextual or policy functionality, as our system separates the service (code) logic from the contextual information (i.e., a list of context that we are using, to retrieve a userâ&#x20AC;&#x2122;s current context and so on). Separating system functionalities from the service logic, as well as storing the system functionalities in an accessible place, makes them reusable across services that we have in the system. (3) Supports the ability to control service visibility as well as actions that users can perform via a policy (e.g., a space policy). The policy in our system is context-aware, in which the applicable policy is selected depending on the contexts. (4) Has acceptable performance in various situations such as: (a) displaying a service interface and activating the service in a minimum amount of time,
247
(b) reacting quickly to location context changes (e.g., when a user moves from one location to another), as well as updates the list of available services and policies on the device in a minimum amount of time, and (c) responding quickly to a userâ&#x20AC;&#x2122;s request (e.g., a request to perform some actions on the service). The request is sent to the policy manager when the user selects on the service name or when the user clicks on the action on the service. The result determines whether a user is allowed to or prohibited from performing an action, and is sent back to the mobile client manager that resides on the client side. For using the MHS framework, the dissertation has presented a guideline for analysis and design of a system for context-aware regulated services. It guides developers through an entire software development lifecycle starting from problem description, system requirements, conceptual design to a detailed design. Our methodology is built upon the work of the MHS system [SLS04a; SLS04b; SLS04d; SLS04e; SyL06c; SyL07b] that supports context sensitivity in an indoor pervasive campus environment. We applied the methodology in the pervasive campus environment as discussed in Section 6.3, Chapter 6.
7.2.
Future Work
This thesis contributed to recognizing and studying the issues related to development of context-aware regulated services starting from understanding system elements, modelling and techniques used to building a prototype. The implementation of the MHS framework is the outcome of a series of iteration cycles (from an analysis to the system implementation) that gives a new dimension to context-aware regulated services, which consists of a collection of environments, contextual software components, entities and computing devices. Based on the initial concept and implementation of our system, there is still room for improvements, to add, enhance and nurture concepts of context-aware regulated systems. This section presents future work involve iterating over the conceptual and logical design model, as well as investigating any other possible approaches to
248
improving the efficiency and effectiveness of the development of context-aware regulated services. (a) Scope of the service The existing context-aware system implementations only sense and deliver relevant services based on a user’s and an environment’s current contexts. Our current implementation only delivers services based on a user’s current contexts in indoor environments. We plan to investigate and develop a larger scope of contextual services that also target outdoor environments. This gives user flexibility in terms of scope of services that users may be able to see, considering a user is within multiple domains at the same time. For example, in a room which is in a Caulfield campus, which in turn, is in the University, which in turn, is in Melbourne. This requires a comprehensive location model (both indoor and outdoor environments) and we may implement a “zooming” model to address the above situation. (b) System caching In general, context-aware regulated systems may want to react intelligently in caching service code on the device and as well as, managing the code caches. This requires a caching policy to intelligently remove code which is no longer used by users. Our current implementation removes code caches on a mobile device just when a user requests so. This is considered useful, as the user knows which code that s/he still needs and which one to remove. Another approach is by employing a proactive mechanism. A proactive approach is performed by a system that proactively guesses which code that a user still needs and which one that is no longer needed. Having a combination of proactive and reactive techniques for removing cached code would be desirable. As part of our future work, we plan to work on these techniques by learning and analysing a user’s contexts (e.g., behaviours, and intentions), and so the system would have an accurate guess of which code needs to remain, which code needs to be removed and when to use the proactive/reactive technique for removing the cached code. (c) Dynamic service discovery
249
We have not as of yet incorporated a dynamic service discovery (e.g., using Jini, UPnP, and JXTA). In the future, this remains as a critical area of the research in the field. (d) Semantic representation The current prototype implementation uses an XML language to represent a mapping between services, contexts and rules. An XML language is a purely text format that does not add any semantic value to its representation. It limits its ability to support complex reasoning such as requests to display a list of students who are currently using a Media Player service and whose supervisor is a professor. Moreover, an XML language does not support reusability of the language in different systems (e.g., security, management, distributed system, etc.). This simply means to include the existing XML elements in other systems, we need to copy and paste whole elements and include them manually. As a result, a comprehensive representation and reasoning of contexts (i.e., using Semantic Web ontology is required). We plan to explore Semantic Web ontology [DCH02; SCV03; Che04; GPZ05] to deal with richer contextual information other than those currently supported by the system. Ontologies allow reusable concepts across domains as well as supporting complex query and reasoning (e.g., to display only a list of shared resource services which have been started earlier by users in room H7.93). (e) System security In our current implementation, the security aspect has not been considered in detail (e.g., hacking or tampering the policy documents). In addition, we have not considered whether message (information) is secured when transfer over the wire, as well as the security in accessing Web services. Integrating the system with security mechanisms is considered important. This is to ensure integrity, confidentially and reliability of resources in the system. This remains as a critical issue that needs to be addressed. We plan to work on a more sophisticated security layer that provides mechanisms to encrypt and decrypt information, and supports secure intra-communication between contextual software components and mobile clients in the system. (f) Graphical user interface We plan to explore different approaches to enable easier service and policy deployment. Our current system supports an intuitive interface for end-users to interact with the
250
system (i.e., via a software client that is installed on the end-userâ&#x20AC;&#x2122;s devices). However, it does not have a graphical user interface for software developers to maintain the system. Addition, modification and removing existing service and policy components need to be done manually from the VS. NET framework. In addition, updating XML documents (e.g., a policy document, role collections, user profiles, etc.) need to be done from a text editor. (g) System evaluation We would like to evaluate our MHS system in a number of pervasive computing domains (e.g., a shopping, a health-care domain, etc.). We plan to include heterogeneous networks, sensor networks, embedded devices and Internet based contextual software systems that targets different types of users, and different services. (h) Policy decision sanction Our current framework supports a context-aware policy development to decide useful and permitted services for users in particular contexts. The policy governs and controls behaviours of entities in accessing services in specific contexts. In our current implementation, all requested user actions are checked against rights given by a space to users. We have not considered any sanction or penalty given to users if they are not obeying the rules (e.g., not performing their obligations). This remains as an open research issue that needs to be addressed in the future. Certainly, we need to bear in mind the aim of context-aware pervasive systems that should free users from performing manual tasks (e.g., manually checking for an email) and not trying to overly restrict usersâ&#x20AC;&#x2122; actions. The idea of having a policy is to balance the convenience and compliance aspects that a user has in the system. (i) Policy decision checking We can further improve our policy checking performance by employing further checking techniques (e.g., a compound policy decision checking). This would mean allowing users to perform actions on one service, also allows users to perform actions on other related services. Consider, an entertainment service that consists of a Media Player service and a speaker volume control service. By allowing users to control the music volume (i.e., high
251
or low), would also allow users to start a music service by default. Or, allowing users to start a music service, would also permit users to control the speaker volume. Hence, policy decision checking does not need to be done on the service which is related to the current service, but on collections of related services. As part of our future work, we will continue to improve system performance by exploring this policy checking technique. (j) Allowing users to challenge policy conflict resolution results As a space gives certain permission to visitors, and by default, if there is a conflict, the space (or the owner of the space) wins the conflict. Visitors are free to challenge the space, if they are not satisfied with the conflict resolution result, considering their current situations. Allowing visitors to challenge the system (e.g., to win conflicts between a space and a user), would give control to visitors in certain situations. By challenging the space, given the current situation of the visitor, the system will re-compute the conflict resolution, and if the reason is sufficient, the challenger may win. For example, user A is a student that is going to give a demonstration and requires starting a teleporting service in seminar room A. By default, the room only allows users with a super user role to start the teleporting service on any day between 12-2PM. This is because, only lecturers (with a super user role) can use the teleporting service during this time. The room does not allow students (with a general user role) to perform any action on the teleporting service between 12-2PM. In this case, students may want to challenge the room, if they are not satisfied with the conflict resolution result (given his/her needs to use the teleporting service between 12-2PM). By analysing the challengerâ&#x20AC;&#x2122;s reason, the room may agree with the challenge and let the challenger starts the teleporting service. (k) Policy conflicts in pervasive computing environments As discussed in Chapter 3, there are many sources of conflicts in pervasive computing environments. As a result, policy conflict detection and resolution components need to be able to handle possible conflicts that may happen in the future. Our current policy conflict detection and resolution components are only limited to the current known conflicts (e.g., a conflict between a user and a space, and a conflict between one user and another). Therefore, there is still some work in context-aware policy components, which 252
need to be investigated in order to enhance the context-aware regulated system. As part of our future work, we will continue to investigate the following points: (1) What is the best technique to detect policy conflicts? Policy conflicts can be detected proactively or reactively. In deciding which technique that is best to use, developers need to consider: •
System performance (e.g., how long it takes to detect conflicts).
•
System resources (e.g., how often we need to update a conflict detection result if the conflict detection has been computed earlier).
•
Scalability (e.g., can the policy conflict detection technique still be used to detect conflicts if the number of entities in the system increases. If so, would it have any impact on the performance?)
•
Extensibility (e.g., can the policy conflict detection technique still be used to detect new conflicts that may happen in the future?)
(2) What is the best way to resolve policy conflicts? We can resolve policy conflicts as soon as the system detects that there is a conflict or resolve it only when the conditions for the conflict to happen have been met. Several considerations in deciding which technique to use are: •
System performance (e.g., how long it takes to resolve the policy conflict).
•
System resources (e.g., do we need to store the policy conflict resolution result for future re-use or remove it from the system memory as soon as it has been used or when a system detects that the conflict resolution result may no longer be relevant for users as the contexts have been updated)
•
Satisfaction (e.g., how do we ensure that the policy conflict resolution technique that we use will satisfy both conflicting entities?)
•
Scalability (e.g., can the policy conflict resolution technique handle a number of conflicts or only a limited number of conflicts at a time?)
•
Extensibility (e.g., can the policy conflict resolution technique resolve new conflicts that may occur in the future due to more services and contexts?)
253
References
[ArM04]
P.G. Argyroudis, and D.O. Mahony. Securing Communications in the Smart Home. Proceedings of the the Embedded and Ubiquitous Computing (EUC) Conference, Aizu-Wakamatsu City, Japan, August 2004, pp. 891-902.
[Atk99]
D. Atkins. Companion Rescue and Avalanche Transceivers: The U.S. Experience. AAAP Avalanche Review, 1999.
[BaP00]
P. Bahl and V. Padmanabhan. RADAR: An in-building RF based user location and tracking system. Proceedings of the IEEE INFOCOM, Vol. 2, March 2000, pp. 775-784.
[BBC97]
P.J. Brown, J.D Bovey, and X. Chen. Context-Aware Applications: From the laboratory to the marketplace. IEEE Personal Communications, 1997, pp. 58-64.
[BCM06]
P. Bellavista, A. Corradi, And R. Montanari. A Mobile Computing Middleware for Location and Context-Aware Internet Data Services. ACM Transactions on Internet Technology, Vol. 6, Issue no. 4,
254
[Bec04]
November 2006, pp. 356-380. C. Becker. System Support for Context-Aware Computing. Habilitation for Computer Science, Fakultät Informatik, Elektrotechnik und Informationstechnik, Universität Stuttgart, November 2004.
[BeD05]
C. Becker, and F. Durr. On Location Models for Ubiquitous Computing. Pers Ubiquit Comput, 2005.
[BeS04]
M.Y. Becker, and P. Sewell. Cassandra: Flexible Trust Management, Applied to Electronic Health Records. Proceedings of the 17th IEEE Computer Security Foundations Workshop, 2004, pp. 139-154.
[BGS01]
M. Beigl, H.W. Gellersen, and A. Schmidt. Mediacups: Experience with Design and Use of Computer-Augmented Everyday Objects. Computer Networks, March 2001, pp. 401-409.
[Blu01]
Bluesoft Incorporated. 2001. Available Online: http://www.bluesoftinc.com/, Date accessed October 10, 2006.
[Bro97]
R. A. Brooks. The Intelligent Room Project. Proceedings of the 2nd International Cognitive Technology Conference (CT'97), Aizu, Japan, August 1997.
[Bro01]
J.A. Brotherton. e-Class: Building, Observing, and Understanding the Impact of Capture and Access in an Educational Setting. PhD Thesis, Georgia Institute of Technology, Atlanta, GA, December 2001.
[Cap03]
L. Capra. Reflective Mobile Middleware for Context-Aware Applications. PhD thesis, University of London, October 2003.
[CCC03]
R.. Chadha, Y-H. Cheng, T. Cheng, S. Gadgil, A. Hafid, K. Kim, G. Levin, N. Natarajan, K. Parmeswaran, A. Poylisher, and J. Unger. PECAN: Policy-Enabled Configuration Across Networks. Proceedings of the 4th International Workshop on Policies for Distributed Systems and Networks, June 2003, pp. 52-62.
[CDM00]
K. Cheverst, N. Davies, K. Mitchell, A. Friday, and C. Efstratiou. Developing a context aware electronic tourist guide: some issues and experiences. Proceedings of the CHI 2000. The Hague, The Netherlands, 2000, pp. 17–24.
[CEM03]
L. Capra, W. Emmerich, C., and Mascolo. CARISMA: Context-aware reflective middleware system for mobile applications. IEEE Trans. Software. Engineering, Vol. 29, Issue no.10, 2003, pp. 929–945.
[CFZ02]
M. Covington, P. Fogla, Z. Zhan and M. Ahamad. A Context-Aware 255
Security Architecture for Emerging Applications. Proceedings of the 18th Annual Computer Security Applications Conference, December 2002, USA, pp. 249-258. [Che04]
H.L.Chen. An Intelligent Broker Architecture for Pervasive ContextAware Systems. PhD Thesis, University of Maryland Baltimore County, 2004.
[ChK00]
G. Chen, and D. Kotz. A Survey of Context-Aware Mobile Computing Research. Dartmouth Computer Science Technical Report TR2000381. Available Online: ftp://ftp.cs.dartmouth.edu/TR/TR2000-381.pdf, Date accessed December 10, 2003.
[ChK02]
G. Chen, and D. Kotz. Solar: An Open Platform for Context-Aware Mobile Applications. Proceedings of the First International Conference on Pervasive Computing (Pervasive 2002), Switzerland, June 2002, pp. 41-47.
[CLS01]
M. Covington, W. Long, S. Srinivasan, A.K. Dey, M. Ahamad, and G.D. Abowd. Securing Context-Aware Applications using Environment Roles. Proceedings of the 6th ACM symposium on Access control models and technologies SACMAT '01, May 2001, pp. 10-20.
[CMC04]
C. Shankar, J.A-Muhtadi, R. Campbell, and M.D. Mickunas. A Middleware for Enabling Personal Ubiquitous Spaces. Proceedings of the Workshop on System Support for Ubiquitous Computing, in conjunction with Sixth Annual Conference on Ubiquitous Computing (UbiCompâ&#x20AC;&#x2122;04), Nottingham, England, September 2004.
[CMC05]
S. Chetan, J. A-Muhtadi, R. Campbell, and M.D. Mickunas. Mobile Gaia: A Middleware for Ad-hoc Pervasive Computing. Proceedings of the IEEE Consumer Communications & Networking Conference (CCNCâ&#x20AC;&#x2122;05), Las Vegas, January 2005, pp. 223-228.
[CML00]
A. Corradi, R. Montanari, E. Lupu, M. Sloman, and C. Stefanelli. A flexible access control service for Java mobile code. Proceedings of the 16th Annual Computer Security Applications Conference, 2000, New Orleans, LA, pp. 356-365.
[CMR02]
R. Campbell J. Al-Muhtadi, A. Ranganathan, and M. D. Mickunas. A flexible, privacy-presevering authentication framework for ubiquitous computing environments. Proceedings of the 22nd International Workshop on Smart Appliances and Wearable Computing, Vienna, Austria, 2002, pp. 771-776
[CMZ01]
L. Capra, C. Mascolo, S. Zachariadis, and W. Emmerich. Towards a 256
Mobile Computing Middleware: a Synergy of Reaction and Mobile Code Techniques. Proceedings of the 8th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS 2001), Bologna, Italy, pp. 148-154. [CoK04]
K. Connelly, and A. Khalil. On negotiating automatic device configuration in smart environments. Proceedings of Perware 2004 Workshop, 14-17 March 2004, Orlando, USA, pp. 213-218.
[CoR03]
D. Cooney, and P. Roe. Mobile Agents Make for Flexible Web Services. Proceedings of the 9th Australasian World Wide Web (AUSWEB) Conference, 2003. Available Online: http://ausweb.scu.edu.au/aw04/papers/refereed/cooney/paper.html, Date accessed October 10, 2006.
[Cou01]
A.C. Coulter. Graybox Software Testing in Real Time in the Real World. White Paper. Revision 17 October 2001. Available Online: http://www.cleanscape.net, Date accessed October 18, 2003.
[DAW98]
A.K. Dey, G.D. Abowd and A. Wood. CyberDesk: A Framework for Providing Self-Integrating Context-Aware Services. Journal of Knowledge Based Systems, Vol. 11, September 1998, pp. 3-13.
[DCH02]
M. Dean, D. Connolly, V.F. Harmelen, I. Horrocks, D. McGuinnes, P.F. Scheneider, and L.A. Stein. OWL Web Ontology Language 1.0 Reference. W3C Working Draft, July 2002.
[DCM99]
N. Davies, K. Cheverst, K. Mitchell, and A. Friday. Caches in the Air: Disseminating Tourist Information in the Guide System. Proceedings of the 2nd IEEE Workshop on Mobile Computer Systems and Applications (WMCSAâ&#x20AC;&#x2122;99), New Orleans, USA, 1999, pp. 11-19.
[DDL01]
N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The Ponder Policy Specification Language. Proceedings of the 2nd International Workshop on Policies for Distributed Systems and Networks, 2001, Bristol, UK, pp.18-38.
[DeA99]
A.K. Dey, and G.D. Abowd. Towards a Better Understanding of context and context-awareness. Technical Report GIT-GVU-99-22. Georgia Institute of Technology, College of Computing, June 1999.
[DeA97]
A.K. Dey, and G.D. Abowd. CyberDesk: The Use of Perception in Context-aware Computing. Proceedings of the 1997 Workshop on Perceptual User Interfaces (PUI '97), Banff, Alberta, October 1997, pp. 26-27.
257
[DeA00]
A.K. Dey, and G.D. Abowd. CybreMinder: A Context-Aware System for Supporting Reminders. Proceedings of the 2nd International symposium on Handheld and Ubiquitous Computing (HUCâ&#x20AC;&#x2122;00), Bristol, UK, pp. 172-186.
[Dey00]
A.K. Dey. Providing Architectural Support for Building ContextAware Applications, PhD Thesis, College of Computing, Georgia Institute of Technology, 2000.
[Dey01]
A.K. Dey, A. K. Understanding and using context. Springer J. Person. Ubiquitous Comput., Vol. 5, Issue no.1, 2001, pp. 4-7.
[DSA01]
A.K. Dey, D. Salber, and G.D. Abowd. A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interaction (HCI) Journal, Vol. 16, 2001, pp. 97-166.
[DSS06]
A.K. Dey, T. Sohn, S. Streng, and J. Kodama. iCAP: Interactive Prototyping of Context-Aware Applications. Proceedings of the 4th International Conference on Pervasive Computing. Dublin, Ireland, May 2006, pp. 254-271.
[DSA99b]
A.K. Dey, D. Salber, G.D. Abowd. A Context-based Infrastructure for Smart Environments. Proceedings of the 1st International Workshop on Managing Interactions in Smart Environments (MANSE '99), Dublin, Ireland, December 1999, pp. 114-128.
[Edw96]
W.K. Edwards. Policies and Roles in Collaborative Applications. Proceedings of the ACM Conference on Computer supported cooperative work, Boston, USA, 1996 pp. 11-20.
[Eka00]
Ekahau Positioning Engine TM 2.0, Developer Guide. Available Online: http://www.ekahau.com/, Date accessed October 18, 2003.
[Els99]
J. Elson. A Survey of Localisation Methods. Presented to CS694, November 1999.
[EnB05]
C. Endres, and A. Butz. A Survey of Software Infrastructures and Frameworks for Ubiquitous Computing. Mobile Information Systems Journal, January-March 2005, IOS press, Amsterdam.
[Fed06]
Federal Communications Commission. Enhanced 911. 2006. Available Online: http://www.fcc.gov/e911/, Date accessed February 18, 2007.
[FGC98]
A. Fox, S.D. Gribble, Y. Chawathe, and E.A. Brewer. Adapting to 258
Network and Client Variation using Active Proxies: Lessons and Perspectives. Proceedings of the IEEE Personal Communications, Special issue on adapting to network and client variability, August 1998. [FMP02]
S. Fischmeister, G. Menkhaus, and W. Pree. MUSA-Shadow: Concepts, Implementation, and Sample Applications; A LocationBased Service Supporting Multiple Devices. Proceedings of the Pacific TOOLs Conference, 2002.
[FMS03]
S. Fischmeister, G. Menkhaus, A. Stumpfl. Location-detection strategies in pervasive computing environments. Proceedings of the 1st IEEE Conference on Pervasive Computing and Communications, 2003. (PerCom 2003). Proceedings of the First IEEE, March 2003, pp. 273278.
[FPV98]
A. Fuggetta, G.P. Picco, and G. Vigna. Understanding Code Mobility. Proceedings of the IEEE Transactions on Software Engineering, Vol. 24, Issue no. 5, May 1998, pp. 342-361.
[FPJ00]
M. Flynn, D. Pendlebury, C. Jones, M. Eldridge, and M. Lamming. The Satchel system architecture: Mobile access to documents and services. Mobile Networks and Applications, Vol. 5, Issue no. 4, December 2000, pp. 243â&#x20AC;&#x201C;258.
[FSC96]
H. Feinstein R. Sandhu, E. Coyne and C. Youman. Role-based access control models. IEEE Computer, Vol. 29, Issue no. 2, 1996, pp. 38â&#x20AC;&#x201C;47.
[GBB03]
W.G. Grisworld, R. Boyer, S.W. Brown, and T.M. Truong. A Component Architecture for an Extensible: Highly Integrated ContextAware Computing Infrastructure. Proceedings of the ICSE Conference, May 2003.
[GHJ00]
P. Godefroid, J.D. Herbsleb, L. Jagadeesan, D. Li. Ensuring Privacy in Presence Awareness Systems: An Automated Verification Approach. Proceedings of the 2000 ACM conference on Computer supported cooperative work, Philadelphia, Pennsylvania, USA, 2000, pp. 59-68
[GiI97]
L. Giuri, and P. Iglio. Role templates for content-based access control. Proceedings of the 2nd ACM Workshop on Role Based Access Control, Virginia, USA, 1997.
[GKF01]
S. Gavrila, D. R. Kuhn, D. F. Ferraiolo, R. Sandhu, and R. Chandramouli. Proposed nist standard for role based access control. ACM Transactions on Information and System Security, Vol. 4, Issue
259
no. 3, 2001, pp. 224-274. [GNM03]
X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, and D. Milojicic. Adaptive Offloading Inference for Delivering Applications in Pervasive Computing Environments. Proceedings of the 1st IEEE International Conference on Pervasive Computing and Communications (Percomâ&#x20AC;&#x2122;03), March 2003, pp. 107-114.
[GoM02]
S. Godik and T. Moses. OASIS eXtensible Access Control Markup Language (XACML). OASIS Committee Specification cs-xacmlspecification-1.0, November 2002.
[GPZ05]
T. Gu, H.K. Pung, D.Q. Zhang. A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, Vol. 28, Issue no. 1, January 2005, pp.1-18.
[GSB02]
H.W. Gellersen, A. Schmidt, and M. Beigl. Multi-Sensor ContextAwareness in Mobile Devices and Smart Artifacts. Proceedings of the Mobile Networks and Applications (MONET), October 2002.
[HAK03]
H. Harroud, M. Ahmed, and A. Karmouch. Policy-Driven Personalized Multimedia Services for Mobile Users. IEEE Transactions on Mobile Computing, Vol.2, Issue no.1, January-March 2003.
[Han97]
Handheld Device Markup Language specification, Unwired Planet, Inc., Redwood City, CA (1997)
[Hen03]
K. Henricksen. A Framework for Context-Aware Pervasive Computing Applications. PhD Thesis, The University of Queensland, Australia, September 2003.
[Hen05]
U. Hengartner. Access Control to Information in Pervasive Computing Environments. PhD Thesis, Carnegie Mellon University, Pittsburgh, PA, August 2005.
[HHS99]
A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster. The anatomy of a context-aware application. Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom 1999), Seattle, WA, August 1999, pp. 59-68.
[HiB01a]
J. Hightower, and G. Borriello, G. A survey and taxonomy of location systems for ubiquitous computing. IEEE Computer Society, August 2001.
[HiB01b]
J. Hightower and G. Borriello. Location sensing techniques. Technical
260
report UW-CSE-01-07-01, University of Washington, Computer Science and Engineering, Seattle, WA, July 30, 2001. [Hig03]
J. Hightower. From Position to Place. Proceedings of the International Workshop on LoCA 2003, pp.10-12, 2003.
[Hil99]
A. Hills. Wireless Andrew. Journal of IEEE Spectrum, Vol. 36, Issue no. 6, 1999, pp. 49-53.
[HKL99]
F. Hohl, U. Kubach, A. Leonhardi, K. Rothermel, and M. Schwehm. Next Century Challenges: Nexus - An Open Global Infrastructure for Spatial - Aware Applications. Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiComâ&#x20AC;&#x2122;99), Seattle, Washington, WA, 1999, pp. 249255.
[HoK99]
T.D. Hodes, and H.R. Katz. Composable ad hoc location based services for heterogeneous mobile clients. ACM Wireless Networks Journal, Vol. 5, Issue no. 5, October 1999, pp. 411-427. Available Online: http://daedalus.cs.berkeley.edu/publications/servicesWINET.ps.gz, Date accessed October 18, 2005.
[HWB00]
J. Hightower, R. Want, and G. Borriello. SpotON: An indoor 3d location sensing technology based on RF signal strength. Technical Report UW-CSE 00-02-02, University of Washington, Department of Computer Science and Engineering, Seattle, WA, February 2000.
[JaS97]
M. Jazayeri, and H. Schauer. Understanding Code Mobility. IEEE Transactions on Software Engineering, Vol. 24, Issue no. 5, May 1998, pp. 342-361
[JiS02]
C. Jiang and P. Steenkiste. A Hybrid Location Model with a Computable Location Identifier for UbiquitousComputing. Available Online: http://www2.cs.cmu.edu/afs/cs.cmu.edu/project/aura/www/docdir/ubic omp02.pdf. Date accessed October 10, 2006.
[JPS02]
T. Juan, A. Pearce, and L. Sterling, L. ROADMAP: Extending the Gaia Methodology for Complex Open Systems. Proceedings of the AAMAS, Bologna, Italy, 2002, pp. 3-10.
[JRG98]
T. Jordan, M. Raubal, B. Gartrell, and M. Egenhofer. An Affordancebased Model of Place in GIS. Proceedings of the 8th International Symposium on Spatial Data Handling (SDHâ&#x20AC;&#x2122;98), Vancouver, Canada, July 1998, pp. 98-109. 261
[JSR04]
N. Jardim, B. Selic, A. Rodrigues da Silva, and A. Toval Alvarez (Editions). UML Modelling Languages and Applications, Lisbon, Portugal, October 11-15, 2004.
[Kag02]
L. Kagal. Rei: A Policy Language for the Me-Centric Project. Technical Report HPL-2002-270. HP Laboratories, Palo Alto, September, 2002.
[Kag04]
L. Kagal. A Policy-Based Approach to Governing Autonomous Behavior in Distributed Environments. PhD Thesis, University of Maryland Baltimore County, USA, 2004.
[Kar03]
A.H. Karp. E-Speak E-Xplained. Communications of the ACM. Vol. 46, Issue no.7, July 2003, pp. 112-118.
[KBM00]
T. Kindberg, J. Barton, J. Morgan, G. Becker, D. Caswell, P. Debaty, G. Gopall, M. Frid, V. Krishnan, H. Morris, J. Schettino, B. Serra, and M. Spasojevic. People, places, things: Web presence for the real world. Proceedings of the 3rd IEEE Workshop on Mobile Computing Systems and Applications, Monterey, CA, USA, 2000, pp. 19.
[KeC03]
J. Keeney, and V. Cahill. Chisel: A Policy-Driven, Context-Aware, Dynamic Adaption Framework. Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks (POLICYâ&#x20AC;&#x2122;03), 2003, pp. 3-14.
[KFJ01]
L. Kagal, T. Finin, and A. Joshi. Trust-Based Security in Pervasive Computing Environments. IEEE Computer Magazine, December 2001.
[KhK05]
M. Khedr, and A. Karmouch. ACAI: Agent-Based Context-aware Infrastructure for Spontaneous Applications, Journal of Network & Computer Applications, Vol. 28, Issue no.1, 2005, pp. 19-44.
[KoD04]
K. Kolodziej, and J. Danado. In-Building Positioning: Modelling Location for Indoor World. Proceedings of the 15th International Workshop on Database and Expert Systems Applications (DEXAâ&#x20AC;&#x2122;04), Zaragoza, Spain, 2004, pp. 830-834.
[Kor00]
M. Korkea-aho. Context-Aware Applications Survey. Helsinki University of Technology, 2000. Available Online: http://users.tkk.fi/~mkorkeaa/doc/context-aware.html, Date accessed October 10, 2006.
[Kru00]
J. Krumm, S. Harris, B. Meyers, B. Brumitt, M. Hale, and S. Shafer. Multi-Camera Multi-Person Tracking for Easy Living. Proceedings of the 3rd IEEE International Workshop on Visual Surveillance, Dublin,
262
Ireland, 2000, pp. 3-10. [LaF94]
M. Lamming, and M. Flynn. Forget-me-not: Intimate Computing in Support of Human Memory. Proceedings of the FRIEND 21: International Symposium on Next Generation Human Interfaces, Tokyo, 1994, pp. 125-128.
[Leo98]
U. Leonhardt. Supporting Location-Awareness in Open Distributed Systems. PhD Thesis, Imperial College of Science, Technology and Medicine, 1998.
[LSD02]
H. Lei, D. Sow, J. Davis II, G. Banavar, and M. Ebling. The Design and Applications of a Context Service. ACM Mobile Computing and Communications Review (MC2R), Vol. 6, Issue no. 4, October 2002, pp. 45-55.
[LKA96]
S. Long, R. Kooper, G.D. Abowd, and C.G. Atkeson. Rapid Prototyping of Mobile Context Aware Applications: The Cyberguide Case Study. Proceedings of the 2nd ACM International Conference on Mobile Computing and Networking (MobiComâ&#x20AC;&#x2122;96), New York, USA, 1996, pp. 97-107.
[LLS04]
L. Lymberopoulos, E. Lupu, and M. Sloman. PONDER Policy Implementation and Validation in a CIM and Differentiated Services Framework. Proceedings of the 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004), Seoul, Korea, May 2004, pp. 31-44.
[Lok07]
S. Loke. Context-Aware Pervasive Systems. Auerbach Publications, 2007.
[LYH84]
J. Lucas, A. Young, and P.M. Hinds, VHF Omni-range navigation system antenna, 1984. Available Online:http://www.freepatentsonline.com/4451830.html, Date Accessed: 8 August, 2005.
[LWZ01]
E.Lara, D.S. Wallach, and W. Zwaenepoel. Puppeteer: Component based Adaptation for Mobile Computing. Proceedings of the 3rd USENIX Symposium on Internet Technologies and Systems 2001, March 2001.
[Mal26]
E. Mally. The Basic Laws of Ought: Elements of the Logic of Willing, 1926.
[Mat04]
Y. Matsuo. Social Knowledge for Ubiquitous Environment â&#x20AC;&#x201C; Human Network and Spatial Semantics. Proceedings of International 263
[MBH00]
Symposium on Life World Semantics and Digital City Design, 2004, pp. 254-268. H. Mahon, Y. Bernet, S. Herzog, and J. Schnizlein. Requirements for a policy management system. 2000. IETF Internet Draft. Available Online: http://www.ietf.org/Internet-drafts/draft-ietf-policy-req-02.txt, Date accessed October 10, 2004.
[MCA00]
M. J. Moyer, M. J. Covington, and M. Ahamad. Generalized role-based access control for securing future applications. Proceedings of the 23rd National Information Systems Security Conference. (NISSC 2000), Baltimore, Md, USA, October 2000.
[MCL05]
R. Masuoka, M. Chopra, Y. Labrou, Z. Song, W.I. Chen, L. Kagal, and T. Finin. Policy-based Access Control for Task Computing Using Rei. Proceedings of Policy Management for Web Workshop in Conjunction with WWW2005, Chiba, Japan, May 2005. Available Online: http://cs.umbc.edu/pm4w/papers/masuoka10.pdf, Date accessed October 8, 2005.
[MeR03]
S. Meyer, and A. Rakotonirainy. A Survey of Research on ContextAware Homes. Proceedings of the Workshop on Wearable, Invisible, Context-Aware, Ambient, Pervasive and Ubiquitous Computing 2003, Australian Computer Society, Inc., Adelaide, Australia, 2003, pp. 159168.
[Mic06]
Microsoft Corporation. Windows Media Player. Available Online: http://www.microsoft.com/windows/windowsmedia/default.aspx, Date accessed October 3, 2006.
[MIT04]
Massachusetts Institute of Technology. The Trusted Software Proxies project. 2004. Available Online: http://oxygen.csail.mit.edu/Network.html#k21, Date accessed October 10, 2005.
[Mit05]
K. Mitchell. Supporting the Development of Context-Aware Mobile Systems. PhD Thesis, Lancaster University, England, U.K., January 2002.
[MGB02]
A. Messer, I. Greenberg, P. Bernadat, D. Milojicic, D. Chen, T.J. Guili, and X. Gu. Towards a Distributed Platform for Resource Constrained Devices. Proceedings of IEEE 2nd International Conference on Distributed Computing Systems (ICDCS 2002), Vienna, Austria, July 2002, pp. 43.
[MLH05]
K. Muthukrishnan, M. Lijding, and P. Havinga. Towards Smart Surroundings: Enabling Techniques and Technologies for Localisation. 264
Proceedings of LoCA, 2005, pp. 350-362. [MoT02]
R. Montanari, and G. Tonti. A Policy-based Infrastructure for the Dynamic Control of Agent Mobility. Proceedings of the IEEE Policy Workshop, 2002, pp. 206.
[MoS93]
J.D. Moffett, and M.S. Sloman. Policy Hierarchies for Distributed Systems Management. IEEE Journal on selected areas in communications, Vol.11, Issue no.9, December 1993, pp. 1404-1414.
[MPS02]
C. Morris, A. Polshaw, S. Sivakumar, and P. Stanski. .NET Compact Framework. Wrox Press, 2002.
[MPE05]
L.K. Mazuryk, G.J.Poulisse, and P. V. Eck. Requirements Engineering for Pervasive Services 2005. Available Online: http://www.ics.uci.edu/~lopes/bspc05/papers/kolos.pdf, Date accessed December 10, 2006.
[MRC03]
J. Muhtadi, A. Ranganathan, R. Campbell, and D. Mickunas. Cerberus: A Context-Aware Security Schema for Smart Spaces. Proceedings of PerCom 2003, Dallas-Fort Worth, Texas, March 2003, pp. 489-496.
[MYH04]
K. Matsuzaki, N. Yoshioka, and S. Honiden. Development methodology for location-aware mobile agent. Proceedings of International Workshop on Mobility Aware Technologies and Applications (MATAâ&#x20AC;&#x2122;04), Florianopolis, Brazil, October 20-22, 2004, pp 13-26.
[Nob00]
B. Noble. System Support for Mobile, Adaptive Applications. IEEE Personal Communications, Issue no. 1, February 2000.
[NoC02]
B.D. Noble, and M.D. Corner. The case for transient authentication. Proceedings of the 10th Workshop on ACM SIGOPS European workshop, September 2002, pp. 24-29.
[OrA00]
R. J. Orr, and G. D. Abowd. The smart Floor: A mechanism for natural user identification and tracking. Proceedings of the 2000 Conference on Human Factors in Computing Systems (CHI 2000), The Hague, Netherlands, April 2000. Available Online: http://www.cc.gatech.edu/fce/pubs/floor-short.pdf, Date accessed October 9, 2004.
[Pad06]
A. Padovitz. Context Management and Reasoning About Situations in Pervasive Computing. PhD Thesis, Monash University, Melbourne,
265
Australia, 2006. [PCC04]
C. Peiper, E. Chan, R. Campbel, J. Bresler and J. Al-Muhtadi. Expanding Education through Active Space Collaboration. Percom Workshop, 2004, pp. 236-240.
[PCB00]
B. N. Priyantha, A. Chakraborty and H. Balakrishnan. The cricket location-support system. Proceedings of MOBICOM, Boston, MA, August 2000, pp. 32-43.
[Pin02]
Pinpoint. Available Online: http://www.pinpointco.com, Date accessed October 12, 2005.
[Pre05]
R. Pressman. Software engineering: a practitioner’s approach. Proceedings of the 6th edition. McGraw-Hill, Dubuque, IA, 2005.
[PRM97]
G.P. Picco, G.-C. Roman, and P.J. McCann. Expressing Code Mobility in Mobile UNITY. Proceedings of the Sixth European Software Engineering Conference held jointly with the Fifth ACM SIGSOFT Symposium Foundations of Software Engiennering, (ESEC/FSE‘97), 1997, pp. 500-518.
[PRM99]
J. Pascoe, N.S. Ryan, and D.R. Morse. Issues in Developing ContextAware Computing. Proceedings of the International Symposium on Handheld and Ubiquitous Computing, Karlsruhe, Germany, September 1999, pp. 208-221.
[PTH03]
T. Pilioura, A. Tsalgatidou, and S. Hadjiefthymiades. Scenarios of using Web Services in M-Commerce. ACM SIGecom Exchanges, Vol. 3, Issue no. 4, January 2003, pp. 28-36.
[Pul01]
Time Domain Corporation. PulsON Technology: Time Modulated Ultra Wideband Overview, 2001.
[Ran05]
A. Ranganathan. A Task Execution Framework For Autonomic Ubiquitous Computing, PhD Thesis, University of Illinois, 2005.
[RBS79]
F. Raab, E. Blood, T. Steiner, and H. Jones. Magnetic position and orientation tracking system. IEEE Transactions on Aerospace and Electronic Systems, Vol. 15, Issue no. 5, September 1979, pp. 709-717.
[RCG01]
S. Robinson, O. Cornes, J. Glynn, B. Harvey, C. McQueen, J. Moemoka, C. Nagel, M. Skinner, and K. Watson. Professional C#. Wrox Press, 2001.
[RCR02]
A. Ranganathan, R.H. Campbell, A. Ravi and A. Mahajan. ConChat: A 266
Context-Aware Chat Program. IEEE Pervasive Computing, 2002. [RFW98]
T. Richardson, Q.S. Fraser, K.R. Wood, and A. Hopper. Virtual Network Computing. IEEE Internet Computing, Vol. 2, Issue no.1, January 1998, pp. 33-38.
[RHC02]
M. Roman, C. K. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell, and K. Nahrstedt. Gaia: A Middleware Infrastructure to Enable Active Spaces. IEEE Pervasive Computing, October 2002, pp. 74-83.
[Rin02]
M. Ringwald. Spontaneous Interaction with Everyday Devices Using a PDA. Swiss Federal Institute of Technology, Zurich, Switzerland. Proceedings of Supporting Spontaneous Interaction in Ubiquitous Computing Settings Workshop in conjunction with Ubicomp Conference, Goeteborg, September 2002. Available Online: http://www.vs.inf.ethz.ch/publ/papers/ringwald-interaction.pdf, Date Accessed: 18 August 2004
[RJF06]
D.Ray, A. Juhola, J.S.Fernandez, and A.Galis. Fast and Efficient Context-Aware Services. John Wiley, 2006.
[RMW99]
J.B. Rhodes, N. Minar, and J. Weaver. Wearable Computing Meets Ubiquitous Computing: Reaping the best of both worlds. In Proceedings of The Third International Symposium on Wearable Computers (ISWC '99), San Francisco, California, USA, October 1999, pp. 141-149. Available Online: http://xenia.media.mit.edu/~rhodes/Papers/wearhive.html, Date accessed October 8, 2003.
[RoB03]
P. Robinson, and M. Beigl. Trust Context Spaces: An Infrastructure for Pervasive Security in Context-Aware Environments. Proceedings of the 1st International Conference on Security in Pervasive Computing, 2003, pp. 157-172.
[RoC00]
M. Roman and R.H. Campbell. Gaia OS: Active Spaces. Proceedings of the 9th ACM SIGOPS European Workshop 2000, Kolding, Denmark, September 2000.
[Rom03]
M. Roman. An Application Framework for Active Space Applications. PhD Thesis, University of Illinois, USA, 2003.
[Rum95]
J. Rumbaugh. What is a Method? Journal of Object Oriented Programming, Vol. 8, Issue no. 6, 1995, pp.10-16.
267
[SaM03]
D.Saha, and A. Mukherjee. Pervasive Computing: A Paradigm for the 21st Century. IEEE Computer, Vol. 36, Issue no. 3, March 2003, pp. 2531.
[Sam05]
G. Sampamane. Access Control for Active Spaces. PhD Thesis, University of Illinois, USA, 2005.
[San98]
R.S. Sandhu. Role-based Access Control. Advances in Computers. Vol. 48. Academic Press 1998.
[SAT99]
A. Schmidt, K.A. Aidoo, A. Takaluoma, U. Tuomela, K.V. Laerhoven, and W.V.de. Velde. Advanced interaction in context. Proceedings of the 1st International Symposium on Handheld and Ubiquitous Computing (HUC'99), Karlsruhe, Germany, September 1999, pp. 89101.
[Sat00]
I. Satoh. MobileSpaces: A Framework for Building Adaptive Distributed Applications Using a Hierarchical Mobile Agent System. Proceedings of the IEEE International Conference on Distributed Computing Systems (ICDCS’2000), April 2000, pp.161-168.
[Sat01]
M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications, August 2001, pp. 10-17.
[Sat04]
I. Satoh. Linking Physical Worlds to Logical Worlds with Mobile Agents. Proceedings of the International Conference on Mobile Data Management (MDM’2004), San Francisco, USA, January 2004, pp.332 - 343.
[Sat05a]
I. Satoh. A Location Model for Pervasive Computing Environments. Proceedings of the IEEE 3rd International Conference on Pervasive Computing and Communications (PerCom’05), March 2005, pp. 215224.
[Sat05b]
I. Satoh. A World Model for Smart Spaces. Proceedings of the 1st International Symposium on Ubiquitous Intelligence and Smart Worlds (UISW2005), Japan, December 2005, pp.31-40.
[SAW94]
B. Schilit, N. Adams, and R. Want. Context-aware computing applications. Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, California, December 1994, pp. 85-90. Available Online: http://seattleWeb.intel-research.net/people/schilit/wmc-94-schilit.pdf, Date accessed October 3, 2003.
268
[SBM03]
D. Scott, A. Beresford, and A. Mycroft. Spatial Policies for Sentient Mobile Applications. Proceedings of the IEEE Policy Workshop, Italy, June 2003, pp. 147.
[Sch95]
B.N. Schilit. A Context-Aware System Architecture for Mobile Distributed Computing. PhD Thesis, Columbia University, USA, May 1995.
[Sco93]
R. S. Scowen: Extended BNF - A generic base standard. Software Engineering Standards Symposium, 1993.
[SCV03]
N.M. Sadeh, T-C. Chan, L. Van, O.B. Kwon, and K. Takizawa. A Semantic Web Environment for Context-Aware M-Commerce. Proceedings of ACM Conference on Electronic Commerce 2003, San Diego, California, USA, June 2003, pp.268-269.
[SLS04a]
E. Syukur, S.W. Loke, and P. Stanski. Hanging Services: An Investigation of Context-Sensitivity and Mobile Code for Localised Services. Proceedings of the IEEE International Conference on Mobile Data Management, Berkeley, USA, 19-22 Jan 2004, pp.62-73.
[SLS04b]
E. Syukur, S.W. Loke, and P. Stanski. The Mobile Hanging Services Framework for Context-Aware Applications: the Case of Context Aware VNC. Proceedings of WIS (Wireless Information Systems) Workshop, Porto, Portugal, April 2004, pp. 81-88.
[SLS04c]
E. Syukur, S.W. Loke, and P. Stanski. Performance Issues in an Infrastructure for Mobile Hanging Services. Proceedings of the First International Conference on Mobile Computing and Ubiquitous Networking (ICMU) 2004, NTT DoCoMo R&D Center, Yokosuka, Japan, 8-9 Jan 2004, pp. 32-37.
[SLS04d]
E. Syukur, S.W. Loke, and P. Stanski. The Mobile Hanging Services Framework for Context Aware Applications: An Experience Report on Context Aware VNC. Technical Report no:151/2004, Monash University, Australia.
[SLS04e]
E. Syukur, S.W. Loke, and P. Stanski. A Policy based framework for Context Aware Ubiquitous Services. Proceedings of the Embedded Ubiquitous Computing Conference, Aizu-Wakamatsu, Japan, Vol. 3207, 2004, pp. 346-355.
[SLS05]
E. Syukur, S.W. Loke, and P. Stanski. Methods for Policy Conflict Detection and Resolution in Pervasive Computing Environments. Proceedings of Policy Management for Web Workshop in Conjunction with WWW2005, Chiba, Japan, May 2005, pp. 13-20. Available 269
Online:http://www.csee.umbc.edu/pm4w/papers/syukur8.pdf, Date Accessed: August 18, 2005. [SNC02]
G. Sam, P. Naldurg, and R.H. Campbell. Access Control for Active Spaces. Proceedings of the 18th Annual Computer Security Applications Conference (ACSACâ&#x20AC;&#x2122;02), Las Vegas, Nevada, December 2002, pp. 343.
[Sne01]
E. Snekkenes. Concepts for Personal Location Privacy Policies. Proceedings of the 3rd ACM Conference on Electronic Commerce, Tampa, Florida, USA, October, 2001, pp. 48-57.
[Som07]
I. Sommerville. Software engineering. 8th edition. Publisher: New York:Addison-Wesley, 2007.
[SSS00]
J. Small, A. Smailagic, and P.D. Siewiorek. Determining User Location for Context-Aware Computing Through the Use of a Wireless LAN Infrastructure 2000. Available Online: http://www2.cs.cmu.edu/~aura/docdir/small00.pdf, Date accessed October 3, 2003.
[SyL06a]
E. Syukur, and S.W. Loke. Context-Aware Regulation of ContextAware Mobile Services in Pervasive Computing Environments. Proceedings of the 2nd International Workshop on Ubiquitous Web Systems and Intelligence (UWSI 2006) in conjunction with ICCSA Conference 2006, Glasgow, 8-11 May 2006, pp. 138-147.
[SyL06b]
E. Syukur, and S.W. Loke. The MHS Methodology: Analysis and Design for Pervasive Context-Aware Systems. Proceedings of the 3rd IEEE International Workshop for Software Technologies for Future Embedded and Ubiquitous Systems (SEUS 2006) in conjunction with IEEE International Symposium on Object-oriented Real-time Distributed Computing (ISORC 2006), Gyeongju, Korea, April 2006, pp. 6-14.
[SyL06c]
E. Syukur, and S.W. Loke. Implementing Context-Aware Regulation of Context-Aware Mobile Services in Pervasive Computing Environments. Proceedings of the International Journal of Web and Grid Services (IJWGS), Inderscience Publisher, Vol. 2, Issue no. 3, 2006, pp. 260-305.
[SyL06d]
E. Syukur, and S.W. Loke. Augmenting Everyday Objects with Context-Aware Services. CoolCampus summer projects, December 2005 â&#x20AC;&#x201C; March 2006. Available Online: http://www.infotech.monash.edu.au/promotion/coolcampus/summer/su 270
mmerproj05-06/index.html, Date accessed August 18, 2007. [SyL07a]
E. Syukur, and S.W. Loke. MHS Learning Services for Pervasive Campus Environments. Proceedings of the 5th IEEE International Workshop on PervasivE Learning (PerEL 2007) in conjunction with Percom2007 Conference, New York, USA, March 2007, pp. 204-210.
[SyL07b]
E. Syukur, and S.W. Loke. Policy based Control of Context-Aware Pervasive Services. Journal of Ubiquitous Computing and Intelligence (JUCI), Vol. 1, Issue no.1, April 2007, American Scientific Publishers, pp.110-131.
[TAK04]
A. Tripathi, T. Ahmed, D. Kulkarni, R. Kumar, and K. Kashiramka. Context-Based Secure Resource Access in Pervasive Computing Environments. Proceedings of the 2nd IEEE Percom Workshop (PERCOMWâ&#x20AC;&#x2122;04), location, 2004, pp. 159-163.
[ThL01]
T.L. Thai, and H. Lam. .NET Framework Essentials. O'Reilly Programming Series, 1st edition, June 2001. ISBN no. 0596001657.
[UBH03]
A. Uszok, J. Bradshaw, P. Hayes, R. Jeffers, M. Johnson, S. Kulkarni, M. Breedy, J. Lott, and L. Bunch. DAML reality check: A case study of KAoS domain and policy services. Proceedings of the International Semantic Web Conference (ISWC 03), Sanibel Island, Florida, 2003. Available Online: http://www.ihmc.us/research/projects/KAoS/SemanticWeb03.pdf, Date Accessed: August 20, 2005.
[Vhf05]
VHF omnidirectional range. Available Online: http://en.wikipedia.org/wiki/VHF_omnidirectional_range, Date accessed October 3, 2006.
[Wei91]
M. Weiser. The Computer for the 21st century. Scientific American, September 1991, pp. 94-104.
[WHF92]
R. Want, A. Hopper, V. Falcao, and J. Gibbons. The active badge location system. ACM Transactions on Information Systems, Vol. 10, Issue no. 1, 1992, pp. 91-102.
[Wie94]
R. Wies. Policies in network and system management - Formal definition and architecture. Journal of Network System Management, Vol. 2, Issue no.1, 1994.
[WJK00]
M. Woolwridge, N.R. Jennings, and D. Kinny. The Gaia Methodology
271
for Agent Oriented Analysis and Design. Kluwer Academic Publishers, Boston, 2000, pp. 285-312. [WoD01]
M.F. Wood, and S.A. DeLoach. An Overview of the Multi agent Systems Engineering Methodology. Proceedings of the 1st International Workshop on Agent Oriented Software Engineering, Ireland, June 2000, pp. 207-222.
[WPB03]
T. Wentling, C. Peiper, P. Bristow and J.H. Park. Validation of eFuzion: a Wireless Classroom Technology. Proceedings of the World Conference on E-Learning in Corp. Govt., Health and Higher Edition, Vol. 3, Issue no. 1, 2003, pp. 343-350.
[WSA95]
R. Want, B.N. Schilit, N. Adams, R. Gold, K. Petersen, D. Greenberg, J. Ellis and M. Weiser. An Overview of the ParcTab Ubiquitous Computing Environment. IEEE Personal Communications, Vol. 2, Issue no. 6, 1995, pp. 28-43.
[W3C99]
W3C. XML Path Language (XPath). Version 1.0. Available from http://www.w3.org/TR/xpath, Date accessed October 3, 2003.
[Xia03]
W. Xiaohang. The Context Gateway: A Pervasive Computing Infrastructure for Context-Aware Services. Research Proposal. Nanyang University of Singapore and Context-Aware Dept., Institute for Infocomm Research, November 2003. Available Online: http://www.comp.nus.edu.sg/~wangxia2, Date Accessed: 8 May, 2004.
[X1003]
X10.com. X10 Home Automation Solutions. 2003. Available from: http://www.x10.com/x1Oactivehome.html, Date accessed December 18, 2004.
[YIS06]
N. Yamada, Y. Isoda, K. Sakamoto, S. Tanaka, G. Kunito, and K. Yamazaki, Automatic Identification of Location Semantics based on Environmental Entities. Handbook on Mobile and Ubiquitous Computing: Innovations and Perspectives, 2007, American Scientific Publishers.
[YLS96]
N. Yialelis, E. Lupu, and M. Sloman. Role-based security for distributed object systems. Proceedings of the 5th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICEâ&#x20AC;&#x2122;96), 1996, pp. 80.
[ZGL03]
W. Zhuang, Y.-S. Gan, K.-J. Loh, and K.-C. Chua. Policy-based QoS management architecture in an integrated UMTS and WLAN
272
environment. IEEE Communication Magazine, Vol. 41, Issue no. 11, 2003, pp. 118â&#x20AC;&#x201C;125. [ZhP05]
G. Zhang, and M. Parashar. Context-Aware Access Control Mechanism for Ubiquitous Applications. Proceedings of the 3rd International Atlantic Web Intelligence Conference, AWIC 2005, Lodz, Poland, June 6-9, 2005, pp. 236-242.
[ZJW03]
F. Zambonelli, N.R. Jennings, and M. Wooldridge. Developing Multiagent Systems: The Gaia Methodology. Proceedings of ACM Transactions on Software Engineering and Methodology (TOSEM), Vol. 12, Issue no. 3, July 2003, pp. 317-370.
273
Glossary
Context-aware pervasive system is a system that takes into account a user’s context information in discovering, selecting and delivering relevant services.
The MHS framework is a tool for building context-aware pervasive systems with additional policy mechanisms for controlling users’ behaviours in accessing services in particular contexts.
Context is a set of parameters or a condition that is used by a system to suggest on behalf of users what services are useful and relevant with respect to the user’s situation.
Policy is a set of rules that governs entities’ behaviours in accessing services in particular contexts.
274
Service is a software application that is enlisted to help users perform their daily tasks. The dissertation focuses on context-aware regulated services, where the service is context-aware, and has rules associated with it.
Domain is a logical boundary that consists of several physical spaces (e.g., a campus domain that consists of a library building, lecture building, etc.).
Space is a physical location that is visible and conceivable such as a building, room, corridor, etc.
Entity is an end-client who is a target of a system. An entity can be a software client or a mobile user.
Device is a computing device that can be a mobile device (e.g., a pocket PC, a laptop, a mobile phone, etc.) or a stationary/embedded device (e.g., a workstation, a sensor device, etc.) in the environment.
The MHS Methodology is a set of procedures (from analysis to design) that guides developers for building context-aware regulated services in pervasive computing environments.
275
Appendix
We now present our XML Schemas. Each of the XML documents in our system is validated and well-formed according to its schema.
1. XML schema for a Synonym of Actions document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="ActionType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="Synonym"/> </xs:choice> <xs:attribute name="Name" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Any"/> <xs:enumeration value="None"/> <xs:enumeration value="Pause"/> <xs:enumeration value="Resume"/> <xs:enumeration value="Start"/>
276
<xs:enumeration value="Stop"/> <xs:enumeration value="Submit"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:element name="ActionSynonymDescription"> <xs:complexType> <xs:sequence> <xs:element name="Action" type="ActionType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Synonym"> </xs:element> </xs:schema>
277
2. XML schema for a Role Collections document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="Instance"> </xs:element> <xs:complexType name="DomainType"> <xs:sequence> <xs:element name="Role" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element ref="Instance" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="GeneralEntity"/> <xs:enumeration value="PowerEntity"/> <xs:enumeration value="SuperEntity"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="RoleCollections"> <xs:complexType> <xs:sequence> <xs:element name="Domain" type="DomainType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
278
3. XML schema for a Context Activity Collections document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="ActivityType"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="ActivityDetailsType"> <xs:sequence> <xs:element name="Activity" type="ActivityType"/> </xs:sequence> <xs:attribute name="day" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Monday"/> <xs:enumeration value="Tuesday"/> <xs:enumeration value="Wednesday"/> <xs:enumeration value="Thursday"/> <xs:enumeration value="Friday"/> <xs:enumeration value="Saturday"/> <xs:enumeration value="Sunday"/> <xs:enumeration value="Any"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="startTime" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="1AM"/> <xs:enumeration value="2AM"/> <xs:enumeration value="3AM"/> <xs:enumeration value="4AM"/> <xs:enumeration value="5AM"/> <xs:enumeration value="6AM"/> <xs:enumeration value="7AM"/> <xs:enumeration value="8AM"/> <xs:enumeration value="9AM"/> <xs:enumeration value="10AM"/> <xs:enumeration value="11AM"/> <xs:enumeration value="12PM"/> <xs:enumeration value="1PM"/> <xs:enumeration value="2PM"/> <xs:enumeration value="3PM"/> <xs:enumeration value="4PM"/> <xs:enumeration value="5PM"/> <xs:enumeration value="6PM"/> <xs:enumeration value="7PM"/> <xs:enumeration value="8PM"/> <xs:enumeration value="9PM"/> <xs:enumeration value="10PM"/> <xs:enumeration value="11PM"/> <xs:enumeration value="12AM"/> <xs:enumeration value="Any"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="endTime" use="required">
279
<xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="1AM"/> <xs:enumeration value="2AM"/> <xs:enumeration value="3AM"/> <xs:enumeration value="4AM"/> <xs:enumeration value="5AM"/> <xs:enumeration value="6AM"/> <xs:enumeration value="7AM"/> <xs:enumeration value="8AM"/> <xs:enumeration value="9AM"/> <xs:enumeration value="10AM"/> <xs:enumeration value="11AM"/> <xs:enumeration value="12PM"/> <xs:enumeration value="1PM"/> <xs:enumeration value="2PM"/> <xs:enumeration value="3PM"/> <xs:enumeration value="4PM"/> <xs:enumeration value="5PM"/> <xs:enumeration value="6PM"/> <xs:enumeration value="7PM"/> <xs:enumeration value="8PM"/> <xs:enumeration value="9PM"/> <xs:enumeration value="10PM"/> <xs:enumeration value="11PM"/> <xs:enumeration value="12AM"/> <xs:enumeration value="Any"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ContextActivityType"> <xs:sequence> <xs:element name="ActivityDetails" type="ActivityDetailsType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="forLocation" use="required"> </xs:attribute> <xs:attribute name="createdBy" use="required"> </xs:attribute> </xs:complexType> <xs:element name="ContextActivityCollections"> <xs:complexType> <xs:sequence> <xs:element name="ContextActivity" type="ContextActivityType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
4. XML schema for a Policy Document
280
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="ActionTypeAllowed"> <xs:attribute name="allowed"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Any"/> <xs:enumeration value="None"/> <xs:enumeration value="Start"/> <xs:enumeration value="Stop"/> <xs:enumeration value="Pause"/> <xs:enumeration value="Resume"/> <xs:enumeration value="Submit"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ActionTypeProhibited"> <xs:attribute name="prohibited"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Any"/> <xs:enumeration value="None"/> <xs:enumeration value="Start"/> <xs:enumeration value="Stop"/> <xs:enumeration value="Pause"/> <xs:enumeration value="Resume"/> <xs:enumeration value="Submit"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ActionTypeObligated"> <xs:attribute name="obligated"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Any"/> <xs:enumeration value="None"/> <xs:enumeration value="Start"/> <xs:enumeration value="Stop"/> <xs:enumeration value="Pause"/> <xs:enumeration value="Resume"/> <xs:enumeration value="Submit"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="ActivityType"> <xs:sequence> <xs:element name="Right" type="RightType" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="Obligation" type="ObligationType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Prohibition" type="ProhibitionType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/>
281
</xs:complexType> <xs:complexType name="ObligationType"> <xs:sequence> <xs:element name="Service" type="ServiceTypeObligated" minOccurs="0"/> </xs:sequence> <xs:attribute name="by" type="xs:string"/> <xs:attribute name="on" type="xs:string"/> </xs:complexType> <xs:complexType name="ProhibitionType"> <xs:sequence> <xs:element name="Service" type="ServiceTypeProhibited" minOccurs="0"/> </xs:sequence> <xs:attribute name="by" type="xs:string"/> <xs:attribute name="on" type="xs:string"/> </xs:complexType> <xs:complexType name="RightType"> <xs:sequence> <xs:element name="Service" type="ServiceTypeAllowed" minOccurs="0"/> </xs:sequence> <xs:attribute name="by" type="xs:string"/> <xs:attribute name="on" type="xs:string"/> </xs:complexType> <xs:element name="Rule"> <xs:complexType> <xs:sequence> <xs:element name="Activity" type="ActivityType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="ServiceTypeAllowed"> <xs:sequence> <xs:element name="Action" type="ActionTypeAllowed"/> </xs:sequence> <xs:attribute name="allowed" type="xs:string"/> </xs:complexType> <xs:complexType name="ServiceTypeProhibited"> <xs:sequence> <xs:element name="Action" type="ActionTypeProhibited"/> </xs:sequence> <xs:attribute name="prohibited" type="xs:string"/> </xs:complexType> <xs:complexType name="ServiceTypeObligated"> <xs:sequence> <xs:element name="Action" type="ActionTypeObligated"/> </xs:sequence> <xs:attribute name="obligated" type="xs:string"/> </xs:complexType> </xs:schema>
5. XML schema for a User Profiles document
282
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="LocationType"> <xs:sequence> <xs:element ref="MusicToBePlayed" minOccurs="0"/> <xs:element ref="RepeatPlayed" minOccurs="0"/> <xs:element ref="SourceMachine" minOccurs="0"/> <xs:element ref="TargetMachine" minOccurs="0"/> </xs:sequence> <xs:attribute name="name" use="required"> </xs:attribute> </xs:complexType> <xs:element name="MusicToBePlayed" type="xs:string"/> <xs:element name="RepeatPlayed" type="xs:string"/> <xs:complexType name="ServiceType"> <xs:sequence> <xs:element name="Location" type="LocationType"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:element name="SourceMachine" type="xs:string"/> <xs:element name="TargetMachine" type="xs:string"/> <xs:element name="UserProfiles"> <xs:complexType> <xs:sequence> <xs:element name="Service" type="ServiceType" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:schema>
6. XML schema for an Environment Collection document
<?xml version="1.0" encoding="UTF-8"?>
283
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="DeviceType"> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="EnvironmentType"> <xs:sequence> <xs:element ref="ID"/> <xs:element ref="Name"/> <xs:element ref="Description"/> <xs:element ref="Category" minOccurs="0"/> <xs:element name="HasPolicy" type="HasPolicyType"/> <xs:element name="HasSubDomain" type="HasSubDomainType" minOccurs="0"/> <xs:element name="HasSpace" type="HasSpaceType" minOccurs="0"/> <xs:element name="HasService" type="HasServiceType" minOccurs="0"/> <xs:element name="HasSubSpace" type="HasSubSpaceType" minOccurs="0"/> <xs:element name="HasDevice" type="HasDeviceType" minOccurs="0"/> </xs:sequence> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="Domain"/> <xs:enumeration value="Space"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:element name="EnvironmentCollection"> <xs:complexType> <xs:sequence> <xs:element name="Environment" type="EnvironmentType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="HasDeviceType"> <xs:sequence> <xs:element name="Device" type="DeviceType"/> </xs:sequence> </xs:complexType> <xs:complexType name="HasPolicyType"> <xs:sequence> <xs:element name="Policy" type="PolicyType"/> </xs:sequence> </xs:complexType> <xs:complexType name="HasServiceType"> <xs:sequence> <xs:element name="Service" type="ServiceType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="HasSpaceType"> <xs:sequence> <xs:element name="Space" type="SpaceType"/> </xs:sequence> </xs:complexType> <xs:complexType name="HasSubDomainType">
284
<xs:sequence> <xs:element name="SubDomain" type="SubDomainType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="HasSubSpaceType"> <xs:sequence> <xs:element name="SubSpace" type="SubSpaceType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="ID" type="xs:string"/> <xs:element name="Name" type="xs:string"/> <xs:element name="Description" type="xs:string"/> <xs:element name="Category" type="xs:string"/> <xs:complexType name="PolicyType"> <xs:attribute name="id" type="xs:string" use="required"> </xs:attribute> </xs:complexType> <xs:complexType name="ServiceType"> <xs:attribute name="id" type="xs:string" use="required"> </xs:attribute> </xs:complexType> <xs:complexType name="SpaceType"> <xs:attribute name="id" type="xs:string" use="required"> </xs:attribute> </xs:complexType> <xs:complexType name="SubDomainType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="SubDomain" type="SubDomainType"/> <xs:element name="Subdomain" type="SubdomainType"/> <xs:element name="Space" type="SpaceType"/> </xs:choice> <xs:attribute name="id" type="xs:string" use="required"> </xs:attribute> </xs:complexType> <xs:complexType name="SubSpaceType"> <xs:attribute name="id" type="xs:string" use="required"> </xs:attribute> </xs:complexType> <xs:complexType name="SubdomainType"> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> </xs:schema>
285
7. XML schema for an Entity Collection document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="Description" type="xs:string"/> <xs:complexType name="EndUserType"> <xs:sequence> <xs:element ref="Name"/> <xs:element ref="HistoryInformation"/> <xs:element ref="Role"/> <xs:element ref="Ownership" minOccurs="0"/> <xs:element name="HasPolicy" type="HasPolicyType"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="domain" type="xs:string" use="required"/> </xs:complexType> <xs:element name="EntityCollection"> <xs:complexType> <xs:sequence> <xs:element name="Entity" type="EntityType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="HasPolicyType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Policy" type="PolicyType"/> </xs:choice> </xs:complexType> <xs:element name="HistoryInformation" type="xs:string"/> <xs:element name="Name" type="xs:string"/> <xs:element name="Ownership"> <xs:complexType> <xs:sequence> <xs:element name="Spaces"> <xs:complexType> <xs:sequence> <xs:element name="Space" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Devices"> <xs:complexType> <xs:sequence> <xs:element name="Device" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence>
286
</xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="PolicyType"> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> <xs:element name="Role" type="xs:string"/> <xs:complexType name="SoftwareClientType"> <xs:sequence> <xs:element ref="Description"/> <xs:element ref="Role"/> <xs:element name="HasPolicy" type="HasPolicyType"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="domain" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="EntityType"> <xs:choice> <xs:element name="EndUser" type="EndUserType" maxOccurs="unbounded"/> <xs:element name="SoftwareClient" type="SoftwareClientType" maxOccurs="unbounded"/> </xs:choice> <xs:attribute name="type" type="xs:string" use="required"/> </xs:complexType> </xs:schema>
287
8. XML schema for a Context Collection document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="ContextType"> <xs:sequence> <xs:element ref="Name"/> <xs:element ref="Description"/> <xs:element ref="Type"/> </xs:sequence> <xs:attribute name="id" use="required"> </xs:attribute> </xs:complexType> <xs:element name="ContextCollection"> <xs:complexType> <xs:sequence> <xs:element name="Context" type="ContextType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Description" type="xs:string"/> <xs:element name="Name" type="xs:string"/> <xs:element name="Type"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Dynamic"/> <xs:enumeration value="Static"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:schema>
288
9. XML schema for a Service Collection document
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="Accessibility" type="xs:string"/> <xs:element name="Name" type="xs:string"/> <xs:element name="Scope" type="xs:string"/> <xs:element name="Type" type="xs:string"/> <xs:complexType name="ServiceType"> <xs:sequence> <xs:element ref="Name"/> <xs:element ref="Scope"/> <xs:element ref="Type"/> <xs:element ref="Accessibility"/> <xs:element ref="Visibility"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> <xs:element name="ServiceCollection"> <xs:complexType> <xs:sequence> <xs:element name="Service" type="ServiceType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Visibility" type="xs:string"/> </xs:schema>
289
10. XML schema for a Computing Device document <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:complexType name="ComputingDeviceType"> <xs:sequence> <xs:element ref="Description"/> <xs:element ref="IPAddress"/> <xs:element ref="Location"/> </xs:sequence> <xs:attribute name="id" use="required"> </xs:attribute> </xs:complexType> <xs:element name="ComputingDeviceCollection"> <xs:complexType> <xs:sequence> <xs:element name="ComputingDevice" type="ComputingDeviceType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Description" type="xs:string"/> <xs:element name="IPAddress" type="xs:string"/> <xs:element name="Location" type="xs:string"/> </xs:schema>
290