MHS: pervasive services

Transcription

1 The current issue and full text archive of this journal is available at MHS: a context-enabled regulated framework for pervasive Evi Syukur School of Computer Science and Software Engineering, The University of New South Wales, Sydney, Australia, and Seng Wai Loke Department of Computer Science and Computer Engineering, La Trobe University, Melbourne, Australia Abstract Purpose Pervasive computing environments such as a pervasive campus domain, shopping, etc. will become commonplaces in the near future. The key to enhance these system environments with relies on the ability to effectively model and represent contextual information, as well as spontaneity in downloading and executing the service 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 s request via Web service calls. The system should relieve end-users from low-level tasks of matching 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. The aim of this paper is to investigate the notion of context-aware regulated, and how they should be designed, and implemented. Design/methodology/approach The paper presents a detailed design, and prototype implementation of the system, called mobile hanging (MHS), that provides the ability to execute mobile code (service application) on demand and control entities behaviours in accessing in pervasive computing environments. Extensive evaluation of this prototype is also provided. Findings The framework presented in this paper enables a novel contextual infrastructure that allows 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 in the environment. In addition, a range of contextual is developed to illustrate different types of used in the framework. Originality/value The main contribution of this paper is a high-level model of a system for context-aware regulated, which consists of environments (domains and spaces), contextual software components, entities and computing devices. Keywords Codes, Computer software, Modelling, Context-sensitive languages, Systems and control theory Paper type Research paper MHS: pervasive Introduction Pervasive computing is the next generation of software systems, computing devices and environments with information, 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 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 International Journal of Pervasive Computing and Communications Vol. 6 No. 1, 2010 pp # Emerald Group Publishing Limited DOI /

2 IJPCC 6,1 48 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 an user needs to manually turn on/off the light. 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 environment, etc.). Although 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,, 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. In addition, context awareness in conjunction with pervasive software applications is emerging as intuitively suitable for being delivered as context-aware pervasive (Schilit et al., 1994, 1995; LKAA96; Dey et al., 1998; CDM þ 00; Gellersen et al., 2002; Noble, 2000; Henricksen, 2003; Ranganathan, 2005; DSS þ 06). This paper investigates the delivery of context-aware pervasive onto a mobile device and proposes a novel context-aware regulated model to address the specific infrastructure for pervasive computing requirements imposed on context-aware pervasive systems, by using policy (rule)-based access to govern user s behavours in accessing and executing. We have implemented a prototype system for a campus environment that validates our approach and architecture for building a context-aware policy system. Our prototype system supports code on demand (run time delivery onto and execution of the code on a mobile device), Web for contextual and policy functionalities (Syukur et al., 2004a; Syukur and Loke, 2006b). We have discussed in Syukur et al. (2004a) how our mobile hanging (MHS) system supports contextual and functionalities in pervasive computing environments. We also have discussed in Syukur et al. (2004b, c) and Syukur and Loke (2006a), our initial policy work, where we illustrate the usefulness of having policy via scenarios to govern the execution of mobile. This paper greatly extends our previous work, emphasizing the modelling of MHS from, policies, to pervasive computing environments. The paper also discusses in detail the MHS context-aware policy system s design, implementation and evaluation. This paper focuses on the development of an indoor context-aware regulated system that controls users behaviours in accessing context-aware in pervasive computing environments. The issues of design, infrastructure and interaction between software components that supports the discovery, delivery and execution of contextaware regulated are considered in great detail. This paper introduces the MHS framework. The MHS framework supports awareness of both and policies, in which the applicable and policies would completely depend on surrounding contexts in the environment. A service in our system provides access to resources

3 (e.g. devices in the environment) and data/information. The system controls access to 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 paper are twofold: (1) The MHS view of pervasive computing. The paper proposes a novel model of context-aware regulated 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. 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 domains consists of several physical spaces. The model provides comprehensive design for context-aware regulated. (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. This framework enables a novel contextual infrastructure that allows 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 in the environment. In addition, a range of contextual are developed to illustrate different types of used in the MHS framework. Our conception of the MHS system employs a location sensing system (e.g. using the Ekahau Positioning system, 2000), 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 principles, which can move between hosts during their execution lifetime and support sharing of applications between laptop computers and handheld devices. MHS: pervasive 49 Figure 1. The MHS view of pervasive computing

4 IJPCC 6,1 50 The rest of this paper is organized as follows. Section 2 provides the background necessary for context-aware regulated. It reviews related research from the context of the work related to this paper. Section 3 presents a high-level abstraction of MHS system modelling including issues in developing localized contextual in pervasive computing environments. The novel context-aware regulated model proposed and developed in our research is then presented. We then provide our conceptual model and introduce our approach to building an advanced contextual system. Section 4 discusses techniques used to implement such a system as discussed in Section 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 at specific contexts. A policy specification language is then presented. Section 5 presents the experimental results of our MHS framework. We 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 authorization decision. Finally, we conclude in Section 6, where lessons learnt are presented, key research contributions are highlighted and future directions of this research are discussed. 2. Related work Many existing policy projects focus on implementing access control in the field of distributed Internet systems (Godik and Moses, 2002; Uszok et al., 2003; Sandhu, 1998; Yialelis et al., 1996; Damianou et al., 2001; Mahon et al., 2000; Moffett and Sloman, 1993; Edwards, 1996; Hengartner, 2005; Keeney and Cahill, 2003). A policy defines a set of activities that authorized users can perform (permission), cannot 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 (Gavrila et al., 2001). 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, and resources in the system are assigned permission subset for each role (and its role subset). To select relevant access 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 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.

5 There are some notable existing policy work in pervasive computing environments, however, they focus on different types of contexts such as context of an agent (SBM03; Masuoka et al., 2005; Montanari and Tonti, 2002; Corradi et al., 2000), networking (Lymberopoulos et al., 2004; Zhuang et al., 2003; Wies, 1994; Chadha et al., 2003), authorization (Covington et al., 2001; ZhP05; Gavrila et al., 2001; Giuri and Iglio, 1997; Moyer et al., 2000; Feinstein et al., 1996) and security (Kagal et al., 2001; Covington et al., 2002; Al-Muhtadi et al., 2003; Noble and Corner, 2002; Tripathi et al., 2004; Massachusetts Institute of Technology, 2004; Campbell et al., 2002; Becker and Sewell, 2004). There is a little policy work done in pervasive systems, especially in the field of context-aware pervasive. Nine closely related policy projects that deal with users contexts are discussed as follows. The Automatic device project (Connelly and Khalil, 2004) 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). The Satchel system (Flynn et al., 2000) provides mobile access to documents via. 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 (Unwired Planet, 1997 )) 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 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 (Harroud et al., 2003) proposed a system that supports personalized multimedia 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, 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. MHS: pervasive 51

6 IJPCC 6,1 52 The purpose of security control in the Active Space project (Sam et al., 2002; Sampamane, 2005) 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. Ether (Argyroudis and Mahony, 2004) 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 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 a printer machine). Cerberus (Al-Muhtadi et al., 2003) 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 contextaware security policies unobtrusively in ubiquitous environments. Cerberus consists of three major components: (1) service access (authentication and authorization), (2) security policy documents; and (3) a reasoning engine that performs automated reasoning and enforces security policies. 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 ). The Rei Policy Language was developed by some researchers at HP Lab (Kagal. Rei, 2002; Kagal, 2004). The aim of the Rei policy language is to provide flexible constructs based on deontic concepts (Mally, 1926) that are reusable across domains (such as networking and access control security). Task computing (Masuoka et al., 2005) uses Rei (Kagal. Rei, 2002) as a policy engine for enforcing the authorization decision (e.g. whether to permit or prohibit a user from the requested action to use a printer at Fujitsu Lab). Trust Context Spaces (Robinson and Beigl, 2003) 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

7 consists of a group of people and various tasks: three audiences, one presenter and one narrator. Many existing projects focus only on one or a few elements of a pervasive computing system as discussed in the previous sections. 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, contextual service and contextual policy. Two notable projects are GAIA (Roman et al., 2002) with Active Space (Sam et al., 2002) and Cerberus (Al-Muhtadi et al., 2003) with Rei (Kagal. Rei, 2002). Having introduced the concept, design and operation of a system for context-aware regulated, we present a model that illustrates the operations of such a system in the next section. 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. MHS: pervasive Conceptual design of MHS Our pervasive computing system consists of entities (e.g. mobile users and software clients), logical boundaries (domains), physical boundaries (spaces), contextual, policies and computing devices. A pervasive computing environment is dynamic; a new domain, space or subspace 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 as soon as users step into a particular space in the environment. The discussion in section 2 concluded with the motivation to include policy (rule) for controlling users behaviours in accessing 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 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. From our investigation of context-aware architectures and systems in section 2, it was found that context-aware regulated systems that control visibility of, as well as users behaviours in accessing are useful for operation in dynamic and heterogeneous environments, where are aware of users contexts. This is especially important as more than one mobile user can access and control running on public devices. The public device is a shared device that is accessible to all authorized users in the system. This then results in conflicts, if there is no proper management in terms of who, what and when can be accessed. In this paper, we present the MHS model that addresses the requirements of systems for context-aware regulated in pervasive computing environments. Our MHS explores user-centricity, context-sensitive information, service-awareness, policyawareness and a pervasive computing environment model, in order to provide contextaware regulated for users with minimal or no effort for service set-up prior to use. It is a context-aware regulated framework that assists developers with

8 IJPCC 6,1 54 development of context-aware along with policies for controlling visibility of, as well as access to in certain contexts. 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 subspaces. Our view of a pervasive computing environment is not only limited to one domain (see Figure 2). 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. Samples of domains are a campus domain, shopping domain, home domain, etc. (as shown in Figure 2). These domains offer unique that differentiate them from each other. For example, 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 subdomains of a park domain. A domain also consists of one or many physical spaces (see Figure 3). Figure 2. MHS pervasive computing environments Figure 3. A pervasive computing domain and its spaces

9 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 subspaces (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 t 1, a user can be at a lecture room (within a campus domain) and at time t 2, 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. 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 subdomain, residential house subdomain, etc.). The idea is that mobile users do not need to manually specify their locations to the system when accessing, instead, the system needs to proactively detect the users current locations and find the mapping of relevant for users in that particular context. MHS: pervasive The design of MHS context-aware 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. In this case, a user who is a subject of a system, can say I want to print my paper in colour (single sided) by 10 a.m. on Friday. Upon receiving this command, the service then places the paper document in a queue, configures the printer according to the user s preferences and prints it out before Friday, 10 a.m. 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 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 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, ing the owner of the cup, etc.). The service in our system is context sensitive, mobile and regulated by policies (rules). Having context-aware regulated 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, 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. The users could access as per normal before and after exam time. This example shows how and policies can be aware of (or vary depending on) contexts. Our system supports the creation of that targets mobile devices (e.g. pocket PC, and laptop devices) and desktop devices. Ideally, users do not need to know where

10 IJPCC 6,1 56 s/he is (or under what domain s/he currently is), relevant 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 : (1) Without the need to download the service onto users devices. For example, as soon as the system senses 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. (2) 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 as in approach no. (2). The service provides a way of controlling the running 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. These can be based on the scope of, a user s role, a history log file, a user s preferences and space policies. Each of the aspects that affect visibility of is described as follows: (1) The scope of. A service is visible only within a certain scope (boundary). As illustrated in Figure 4, depending on the boundaries, different 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. (2) A user s role. Users with different roles would see different in the same contexts (e.g. location, day and time). A user with a higher role would generally see more compared to users with a lower role. For example, a lecturer in the campus could see more (e.g. an exam service, a lecture note service, a student mark service and a student attendance service) compared to students. (3) 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 associated with those places. This history information is useful for computing a set of that would be useful to the user at time t. This computation can be modelled as a function f, where f ðcurrent context; historyþ ¼ a new set of (4) The user s preferences. A user specifies a list of that s/he might need in a specific situation or context. As a result, two users may see different sets of, although they are in the same context. This is due to different sets of

11 MHS: pervasive 57 Figure 4. The visibility of depends on the boundary preferences that they have specified. System management for this technique is quite complex, as the system needs to maintain all users preferences and display differently for each user depending on his/her preferences. (5) Space policies (rules). Developers and owners of physical spaces could set policies (rules) that specify list of 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. Our MHS system uses a combination of a user s role and space policies in determining visibility of in the space. We discuss in detail in Section 4 how context-aware policies control the visibility of in pervasive computing environments. 3.3 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 2 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 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

12 IJPCC 6,1 58 where activity occurs). Instead, we store the context and activity mapping separately in an external XML file. The mapping here works like a scheduling system, where it stores a list of spaces activities in particular contexts. In addition, our policy system controls behaviours of 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. MHS differs from all other approaches in its ability to specify the policy strategies (mapping between policy, context information and ) at a high level of abstraction. It also supports policy conflict resolution during application execution at run time (Syukur and Loke, 2007, 2006b). 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 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 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 in specific contexts. In designing a policy, there are several questions that need to be addressed, such as: (1) Who are we trying to control (e.g. the system, end-user)? (2) What are we protecting (e.g. resources, network information, )? (3) What are the different policy objects (e.g. permission, obligation, prohibition) used in the policy system? (4) What is the target computing environment (e.g. networking, distributed, pervasive computing environment, etc.)?

13 3.4 MHS context-aware policy concepts Figure 5 illustrates an overall picture of policy concepts in our system and how these concepts are related. Four main policy concepts are described below: (1) 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 authorization) 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 authorization that does not allow an entity to perform the action as requested in the given context. (2) 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. 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. MHS: pervasive 59 Figure 5. MHS context-aware policy concepts

14 IJPCC 6,1 60 Our system stores a semantic definition of an action, as one action could have different names, but, the purpose is the same (see Figure 6). 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 6). Therefore, it is not an issue if the number of actions employed increases in the future. Figure 6 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 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. (3) Target. Target service refers to a particular service that a user is allowed to access or obligated to access or prohibited from accessing. Our MHS Figure 6. Synonyms of actions in the MHS system

15 system deals with two types of : shared resource and nonshared resource. (4) 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 recognizes 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 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 available in the context compared to the user with lower role. Figure 7 illustrates the role and entity mapping in our system. As shown in Figure 7, 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. MHS: pervasive Implementation of MHS: detailed design and prototype The prototype implementation of our MHS system as published in Syukur et al. (2004a), cand Syukur and Loke (2006b, 2007) supports the needs of context-aware regulated by:. 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 Figure 7. Role collections document in a campus domain

16 IJPCC 6,1 62 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 finishes downloading and compiling the service application, it then displays the service interface.. 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.. 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).. Supporting a policy mechanism. It is for controlling access to in particular contexts. This paper 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 and policy components which are published via the system (see Figure 8). A handheld device user Figure 8. A high level architecture of the MHS system

17 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 (Thai and Lam, 2001) that natively supports Web 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. MHS: pervasive 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 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 or code applications on the client side, as well as executing 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 8). 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 in the future. This is possible as we store all 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 nontraditional applications. The proposed system is also highly interoperable as we implement all the contextual methods or functionalities of the system as Web. Implementing system functionalities as Web allows Web methods to be accessed and invoked easily across disparate platforms and languages via the HTTP protocol. Figure 8 illustrates a high-level architecture of the MHS system that consists of server software components and client software components. Our system simplifies interaction between a user and system starting from sensing a user s current context, to downloading and executing a service. Ideally, users do not need to know low-level details of matching, selecting, downloading and executing. All these interactions need to be handled implicitly by a system. The framework exploits present in the environment, provides functionality to manage, proactively download from a server side to a client side and upload the modified information to the server.

18 IJPCC 6,1 64 MHS also supports the ability to control by having a policy that specifies a set of rules of what 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 a result, mobile users still have the convenience in accessing, although s/he has been bound to a set of rules. We describe 11 main software components in our system as follows 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 and rules. Each of these software components is discussed as follows 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 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 in the specific context as well as responding to the user s request regarding the space policy decision results (e.g. what actions that a user can perform on a target service in the specific context). Figure 9 illustrates how relevant are retrieved given a set of contexts 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 Figure 9. Get service web method

19 sends it back to the mobile 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 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. This remoting service can be easily invoked by other processes which are running on different platforms Context component. Contexts are conditions that must be met before a list of 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. 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 spaces 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 ), 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, 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. 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, entities and policies in the future or perhaps integrate the existing system with some other external systems (assuming they both have similar design and architecture). MHS: pervasive 65 Figure 10. Get mobile code web method

20 IJPCC 6,1 66 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, as well as controlling users behaviours in accessing (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: (1) 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 that need to be recompiled and this update has to be propagated to all mobile users. (2) By having a system manager to manage all policies for in the system. This approach allows the policy to be reusable across, 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 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 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 Context-aware service component. Location context plays an important role in deciding useful 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 by mapping with contexts only. Our MHS system has extended the initial context-aware idea by including a policy (rule) that specifies visibility of and actions permitted on the service. Figure 11 illustrates a user s profile document. It is in an XML document. For different, 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) on the target machine, 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

21 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. 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 in the future. Our system computes a relevant set of based on the policy information as specified in the space policy document. In addition, our system categorizes 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) also known as a shared resource service. For example, a notepad service would only run and execute on the user s mobile device, as it is only for displaying the user 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 Register and deregister component. This component is responsible for registering and deregistering, 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 ). In contrast, deregistration means removing the existing instance from the system Client side software components. This is the second component of our MHS system. 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 Mobile client manager. When a user selects a service, a mobile client manager contacts central Web and downloads an application for interacting with selected. 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:. Between a mobile client and system manager. This can be retrieving and displaying a list of available (permitted) on the device and setting permission on the service (i.e. what actions that a user can perform). MHS: pervasive 67 Figure 11. A user s profile document

22 IJPCC 6,1 68. 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 or mobile code for future re-use. Each downloaded application is specialized 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] 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 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 ), to determine what application code should remain in the cache (i.e. what should be deleted) Mobile code. Within our framework we employ mobile code to provide a simplified user interface (an endpoint) to a contextually available XML Web service (Cooney and Roe, 2003). 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 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 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 Controlling users 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 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 (W3C, 1999) 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, and contexts. It shows differences in deontic permission, obligation, prohibition of actions and service visibility depending on the user s role.

23 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. We also separated the implementation of context-aware policy from context-aware. 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 subdomain and this subdomain belongs to a campus domain), the policy manager queries the environment document. This relationship information is useful for applying a relevant policy in the space (e.g. what policy document should be used for this space?). 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 subdomain, 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 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. The steps in Figure 12 are: (1) Request an action (e.g. start) on a service. Once the service interface is displayed on a mobile device, a mobile user can request to start music on a Media Player service by clicking on the play button. MHS: pervasive 69 Figure 12. The MHS context-aware policy implementation

24 IJPCC 6,1 70 (2) Retrieve policy decision results. 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. The policy decision checking takes into account a user 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 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 (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 ¼ none ), this simply means 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 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 summarize our policy decision checking in Table I. 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

25 Right Prohibition Service allowed Service prohibited Particular Particular Any None service Any None service Result MHS: pervasive x x Any are visible and users are allowed to access any visible. x x It further checks the prohibition. As it prohibits any, none of are visible to users. x x None of 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 to users. 71 Table I. Policy decision checking system then validates the policy document against the policy schema (as illustrated in the 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 spru i specifies that user i can only start the music service on Monday from 12 to 2 p.m., this means that the u i Osp has to satisfy that condition (Monday, from 12 to 2 p.m.). The user is not allowed to impose an obligation on the system to start a Media Player service other than Monday, 12-2 p.m. (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 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 II the policy consistency checking of the imposed on value. As for non-shared resource, when the service is permitted and the requested action is allowed by a space, the mobile client manager then performs the

26 IJPCC 6,1 Imposed on value Any Imposed on value A particular entity Imposed on value OtherEntities Validity 72 Table II. Policy consistency checking of imposed on value 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 there is a particular entity) 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 (Syukur et al., 2004a; Davies et al., 1999). For example, automatically play a user s favourite music at room B538 from 12 to 12:30 p.m., when the context is satisfied. The context information of when and where to perform such tasks can be retrieved from context activity document. 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 11) 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. 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 by allowing the enduser 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 12 p.m. and pause it for 15 min at 12:15 p.m. It also helps to improve the user s experience, especially if there is regularity in the user 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

27 (3b) (4a) 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. Send the result back to the policy manager and call the policy execution. Ifno 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 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). 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. 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. The mobile client manager then notifies the user that the requested action is not allowed. (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 where can be accessed by many users simultaneously from their mobile devices. MHS: pervasive Evaluation of the MHS prototype The MHS system takes into account the concepts proposed in the previous sections to support the delivery of context-aware that incorporates policy for controlling access to. The system performs selection of relevant and delivery tasks based on a user s current contexts. This paper evaluates 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.

28 IJPCC 6,1 74 The framework has given promising results in obtaining a list of, keeping track 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 : shared or non-shared resource. 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 13. In our evaluation, experimental results were collected for ten times of service execution on a 206 MHz ipaq on a wireless Wi-Fi network (54 Mbps). We employ the Ekahau Positioning System to keep track of a user s location. Our server side software components are stored on a 2.09 GHz desktop machine. 5.1 System performance As shown in Figure 14, 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 s current position. The system then updates a list of and policy decision results for that location. When the user selects a particular service name on a mobile device, the system then Figure 13. Evaluation stages of the MHS system

29 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). Three main aspects that we evaluate in this section are discussed as follows. (1) Location context change delay. As we associated 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 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 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 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 on the mobile device. MHS: pervasive 75 T location context change delayðsþ ¼ T Ekahaudelay þ T get a user0 s location þ T get a list of þ T display a list of available on a device þ T retrieve or update the policy decision result Based on the formula above, we conclude that the worst-case scenario to update a list of 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 ), which takes 8.6 s (¼2.5 þ 3.5 þ 0.5 þ 0.1 þ 2). The 2.5 s is the Ekahau delay in detecting the user s movement, the 3.5 s 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.5 s Figure 14. Location context change delay, service activation and policy decision checking on a time line (distances between vertical bars are not indications of time scales)

30 IJPCC 6,1 76 is the time that is required to get a list of and the 0.1 s is to display the updated list of on the device. The 2 s is the time to retrieve the policy decision result. The best case scenario (i.e. the minimum time delays to see the updated for the current location) is in any execution which is not the first. In such a case, the delay time is 6.5 s (¼2.5 þ 2.5 þ 0.4 þ 0.1 þ 1). Note that 1 s 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.5 s, 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 s selection of a service and the display of the selected service interface varies depending on the execution number (see Figure 15). 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.5 to 5.5 s (¼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 15. Based on Figure 15, we can see that the time required to call Web : get a user s location, get a list of available and download a mobile code, decreases for subsequent Web service calls (second, third, fourth, fifth, 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 Figure 15. Experimental results

31 allows the Web service to be treated like other.net classes. The second 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 on the mobile device is consistent throughout the executions as the number of 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. 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 which have not been downloaded previously), it would require a client to download the particular mobile code. In this case, it takes around 0.78 s to download the mobile code from a server to a client s device (assuming the code size is 10 kb). We have developed several mobile 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 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 (1 s). There is no retrieving compiled code from the cache in the first execution (0 s) 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); and (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 0 s). These subsequent activations will retrieve the compiled code from the mobile code storage, i.e. the JIT cache (see Figure 15). 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 MHS: pervasive 77

32 IJPCC 6,1 78 sizes (including the mobile VNC and Media Player service) are 10 kb and the time it takes to compile the code is similar 2 s. 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 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: T Service ActivationðsÞ ¼ T Download mobile code þ T Compile mobile code þ T Get compiled code þ T Display service interface þ T Thread 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.1 s (¼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.1 s (¼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). The policy evaluation results are illustrated in Figure 16. Based on Figure 16, we can see that the time required to call Web : send a query from a client to the policy manager, retrieve and download a relevant policy decision document, detect conflict Figure 16. Policy evaluation results