Abstract

A pervasive computing system (PCS) requires that devices be context aware in order to provide proactively adapted services according to the current context. Because of the highly dynamic environment of a PCS, the service adaptation task must be performed during device operation. Most of the proposed approaches do not deal with the problem in depth, because they are either not really context aware or the problem itself is not thought to be dynamic. Devices in a PCS are generally hand-held, that is, they have limited resources, and so, in the effort to make them more reliable, the service adaptation must take into account this constraint. In this paper, we propose a dynamic service adaptation approach for a device operating in a PCS that is both context aware and limited resources aware. The approach is then modeled using colored Petri Nets and simulated using the CPN Tools, an important step toward its validation.

1. Introduction

The main goal of a PCS is to provide adapted services proactively (i.e., without explicit intervention of the user) to both users and applications, according to the current context. By “provide adapted services,” we mean that the services must be delivered according to the current context, which requires a good understanding and use of that context. One important characteristic of a PCS environment is highly dynamic change, caused by the mobility of users and devices. In order to support the user in his everyday tasks, devices must become more autonomic, requiring minimum or no human intervention. Several approaches have been proposed for service adaptation, some of them using the classic strategy of specifying a set of rules for each service and associating them with every possible context configuration. The disadvantage of such approaches is that the rules are set out before putting the system into operation (static, rather than dynamic application). In addition, the developer has to predict all possible context configurations, which may not be evident at the time. Other approaches are based on a weak specification of context elements, and this has a great impact on the adaptation task. Moreover, the existing service adaptation methods are not considered to be context-aware, and context awareness is a key feature of a PCS. Even existing context-aware service adaptation approaches are superficial and do not deal with the issue in depth, because they are either specific to a particular domain or based on an inappropriate definition of context. Moreover, related work does not consider the very limited resources of a device operating in a PCS (which is, in general, hand-held), like battery charge, memory, processing capacity, and so forth, whereas service adaptation in a PCS must take into account these constraints. With the aim of overcoming the problems and limitations of these other methods, we propose a dynamic approach for service adaptation in a PCS, which is both context aware, based on our definition of context in a previous work [1], and limited resources-aware. The adaptation system is modeled using the colored Petri Net formalism [2] and simulated using the CPN Tools [3] based on typical scenarios of a device operating in a PCS.

The rest of this paper is organized as follows: Section 2 presents the related work in service adaptation. Section 3 presents the principles of context and context awareness in a PCS. Section 4 presents our approach of dynamic context-aware and limited resources-aware service adaptation. Section 5 describes the modeling and simulation of the proposed approach. Section 6 presents our conclusions and perspectives on our future work.

In computing, there are four main kinds of adaptation: (a) content adaptation, (b) behavior adaptation (services), (c) presentation (or interface) adaptation, and (d) software component adaptation [411]. We will restrict our adaptation approach to context-aware service adaptation. The need for service adaptation has long been recognized, and both manual and automatic approaches to service adaptation have been proposed. Autili et al. [12] proposed a conceptual model for adaptable context-aware service in their work on the PLASTIC project. The model is based on a two-layer approach combining services and components. However, they do not give a precise definition of context according to which the adaptation is to be performed. Their model looks rather like a software component adaptation than a service adaptation. Kirsch-Pinheiro et al. [13] have proposed an interesting context-aware service selection method using graph matching. This method consists of selecting among the available compatible services, the most appropriate using similarity measures, considering the current context, and taking into account the incompleteness of context information. Their approach is based on Dey’s [14] definition of context, which is fairly specific to the human-computer interaction domain. In addition, dynamic adaptation consists of executing a graph-based algorithm each time the adaptation is needed, which exhausts the resources of the devices. Yang et al. [15] worked on the Pervasive Service Platform (PSP), which is the platform that adds pervasiveness to all the services deployed in the Daidalos network (a large European research project that is developing a PCS for a mobile environment). Such an environment should help in the selection of the most appropriate services for any particular user, and employment of the most relevant devices and supporting networks. The architecture of the PSP comprises six main components: context manager, rule manager, event manager, personalization, pervasive service manager, and security and privacy manager. They defined context as the set of information that describes an identity’s preferences, profiles, and current situation. The approach is based on the use of rules and policies for making the composition decisions. It is concerned with how personalization is involved in service composition and decomposition, and how personalization adapts services to user context and requirements in this dynamic process. Although the proposed approach is very interesting and highly promising, particularly in the dynamic selection and composition of the required service, it is not based on a clear and adequate definition of context (not really context-aware) and does not take into account the limited resources of devices in a PCS. Cao et al. [16] proposed a context-aware service adaptation method based on designing a policy selection mechanism using fuzzy logic for formulating the service and introducing some fitness functions in order to select the policy with the highest fitness level. In their approach, the authors did not specify the elements of the context according to which the adaptation is used. Moreover, the method requires a great deal of processing. Choi [17] proposed, in their work involving the adoption of the workflow model into ubiquitous computing environments for context-aware and autonomous services, a context-aware workflow system, which can apply changes in the user’s service demand or situation information to an ongoing workflow without a break in its operation. The proposed system represents contexts described in a workflow as an RDF-based DI (Document Instance) tree. When a change in a user’s situation information happens, the system can dynamically reconstruct a workflow by modifying only the subtrees affected by the change. This means that the system does not obstruct the flow of an earlier ongoing context-aware service. The service adaptation approach seems quite? smart and can be easily applied, according to the user’s situation (context); however, it is not based on a clear and concise definition of context (general definition) and also presupposes that devices (in particular, hand-held) can provide a service at any time without considering their limited resources. Houssos et al. [18] introduced a conceptual model for context-aware adaptive services based on Dey’s [14] definition of context and adding a categorization of context entities in three domains. Their adaptation method is purely static, which contradicts the nature of a PCS and also the definition of context, like Dey’s, as previously mentioned. There are other service adaptation approaches, but most of them suffer from the same limitation as the approaches cited in this section. Hirschfeld and Kawamura [19] combined aspect-oriented programming with computational reflection and late binding to adapt services and service platforms when changes actually require that this be done, as late as possible and preferably without disruption of service. They proposed a layered architectural platform with its constituents built on top of one another, which makes it possible to both implement their basic service logic and adapt this service logic to additional requirements and unforeseen circumstances if necessary. The adaptation is a dynamic one, but context awareness is not really addressed and it is focused rather on content adaptation.

In our previous work [20], we proposed a dynamic context-aware service adaptation approach in a PCS, however the proposed approach did not take into account the limited resources of hand-held devices in a PCS. An interesting work is made by Hamadi and Benatallah [21]consisting of a Petri net-based algebra for composing and modeling web services, which is helpful for verification and properties and the detection of inconsistencies both within and between services. They proposed a web services modeling tool rather than a dynamic service adaptation approach. Hansen et al. [22] introduced Flamenco/CPN tool (a part of the Hydra middleware [23]), which addresses middleware and application challenges in self-managed PCS. The approach combined high-level Petri Nets with the capability of distributed communication among nets. The tool is built in correspondence with the Kramer and Magee [24] reference model for self-managed systems and with event-based communication using the publish/subscribe paradigm. The autonomic system is modeled and implemented as communicating, high-level Petri Nets.

Both [21, 22] did not deal with neither context awareness nor limited resources of hand-held devices, which are key concepts for PCS.

3. Context Awareness

A PCS is composed of computer devices communicating and collaborating to provide proactively adapted services to both users and applications according to the current context. This reveals the importance of the concept of context, which requires a good understanding and a precise establishment of its components. Context is defined as the information needed to interpret something, but this definition is very general and does not provide a good understanding. Moreover, it is not useful for computing [17]. Many researchers have proposed definitions of context, some of which were based on listing contextual information (localization, nearby people, time, date, etc.) like those proposed by [18, 19, 25]. Others were based on providing more formal definitions in order to abstract the term, like that proposed by Dey [14]. Most of these definitions were specific to a particular domain, such as human-computer interaction and localization systems. In our previous work [1], we have made a survey of existing definitions of context and proposed a service-oriented definition of context for a PCS as follows: “Any information that triggers a service or changes the quality (form or mode) of a service if its value changes.” This definition is sufficiently abstract and helps to limit the set of contextual information. In the same way and based on the concept of service, we have provided the following definition of context awareness: “A system is said to be context aware if it can automatically change the form of its services or provide a service in response to the change in the value of information or a set of information that characterizes those services.” Unlike other definitions of context awareness [17, 2628], our definition explains awareness more generically, as a reaction of the system to modifications to information values in terms of triggering a service or changing its form independently of the application. We have also classified contextual information in two categories: (a) triggering information, a change in value of which causes automatic release of a service and (b) form-changing information, a change in value of which causes the change in a service’s form. We believe that this categorization is more expressive: it is simple, because it contains just two classes, and it is complete, because it covers all aspects of context, which facilitates the task of adaptation.

4. Dynamic Service Adaptation

Dynamic service adaptation consists of providing both manually and automatically triggered services according to the current context and by taking into account the limited resources of the device. This adaptation must be applied in a transparent way to the user and during operation of the system (dynamic). The main idea is to provide services without exhausting the limited resources of the device. As soon as a service has been triggered (manually or automatically) and may exhaust a limited resource, the system seeks another configuration of the services provided, which prevents the exhaustion of the limited resource, in turn increasing the device’s operational lifetime. The proposed adaptation system is made up of three basic components: a context-aware services trigger, a limited resources monitor, and the adaptor, as shown in Figure 1.

In describing our approach, we will detail each component of the architecture of the adaptation system and the communication flow between them.

4.1. Context-Aware Service Trigger

One of most important components of the adaptation system architecture is the context-aware services trigger (CST). This component dynamically collects contextual information using the device’s sensors and is based on our previous definition of context in a PCS. The developer’s task consists of determining, for each device, the set of services it can provide, and, for each service, the set of forms (or modes) in which the service can be provided. For example, a laptop computer provides an internet connection in two forms: wired and wireless.

There are two categories of contextual information: (a) triggering information, a change in value of which causes the automatic release of a service and (b) form-changing information, a change in value of which causes a change in a service’s form (Figure 2 and Table 1).

There are two types of service: services triggered manually by the user and services triggered automatically according to the current context. To differentiate between these two service types, the CST uses a control bit, denoted ( for the automatically triggered service and for the manually triggered service). The CST uses another control bit, denoted , to memorize the current state of each service ( for the currently inactive service and for the currently active service). The CST also uses another control bit, denoted , for each form of service to indicate whether or not this form is currently active ( means that the form is currently active and means that it is currently inactive). This bit is automatically marked 0 for all the forms of a service if this latter is currently inactive. Moreover, the CST contains, for each form of a service, the set of the device’s limited resources affected (consumed) and indicates which limited resources have been consumed if a service is provided in a particular form. Figure 3 shows the structure of the CST.

A service will be automatically triggered when some context information of this service takes some values, in other words when the service triggering logical expression is evaluated to be true. The triggering logical expression is a logical combination of a subset of the service context element values (e.g., if ( AND ), then the service will be triggered knowing that a and b belong to the contextual information set service). When triggered, the service is provided in its default form or in another form if the form-changing logical expression (which has a similar structure to the service triggering logical expression) of that form is evaluated to be true.

The structure of the CST can be formulated according to the following notation.(i)Set of contextual information; can be the location of a person, the speed of an Internet connection, date, hour, and so forth.(ii)Set of limited resources of a device; , can be the charge level of a battery, Internet connection, capacity of an integrated memory, and so forth.(iii)Set of values of contextual information; is a value associated with a context element.

Example 1 (localization, university). (i)Set of utilization ratios (%) of the limited resources; is a percentage of use of a limited resource.

Example 2 (internet connection, 80). (i)Set of services provided by a device. (ii)Set of service forms ; is the set of forms of the service ;: the form of the service and .(iii)Each service uses a set of contextual information.. (iv)Each service uses a set of limited resources.. (v)Each service has a logical triggering expression . is a logical combination (AND, OR, NOT) of where .(vi)Each form of a service has a form-changing logical expression and . is a logical combination (AND, OR, NOT) of , where .(vii)Each form of a service uses a set of limited resources and .(viii)Each form of a service has a state according to and ,(ix)Each service , , has a state according to (2) If a service is active, then the state of one and only one of its forms will be marked 1 or 2.(x)A service is represented by where and .

The default state of the CST is asleep, in order to reduce resource consumption. Once a context element (triggering information or form changing information) changes its value, the CST wakes up and reacts by triggering a service or by changing the form of a service.

4.2. Limited Resources Monitor

A PCS is composed of a set of computer devices where each device provides a set of services. Each service has several forms, and one of them is the default form of that service. The adaptation task consists of automatically triggering a service or changing its form according to the current context and by taking in account the available resources. Most devices in a PCS are hand-held and mobile (e.g., a cellular phone, a laptop computer, etc.). We can classify the resources of such devices into two categories: unlimited and limited. We can define the unlimited resources as a category which is less likely to have an availability problem once used (e.g., the hard disk of a desktop machine). By contrast, limited resources can be defined as those that should be employed carefully because their availability decreases rapidly (e.g., charge level of a cellular phone battery, the bandwidth of an Internet connection, etc.).

It is the adaptation system developer that considers whether a resource is limited or unlimited for each device and according to the application domain. Unlimited resource allocation is not considered a problem compared to the allocation of limited resources. Consequently, we will restrict ourselves to addressing limited resources here. We will suppose that each device has its own sensors, which provide a measure of the availability of its limited resources (e.g., the battery charge of a cellular phone). The adaptation task consists in large part of providing a service in a form which affects (consumes) as little as possible the limited resources of a device to avoid exhausting them. That is why we include a limited resources monitor (LRM) as the second component in our adaptation system architecture, which continuously provides the availability ratio of each limited resource for each device. For example, a cellular phone LRM can be represented as shown in Table 2. In this example, we consider the battery charge and the integrated memory as limited resources.

4.3. Adaptor

The adaptor is the third component of the architecture. Its principal task is to dynamically adapt the services provided according to the current context and the availability ratio of the limited resources. The adaptor has access to the contents of the CST to identify the set of currently active services, their forms, and their types (automatically triggered service or manually triggered service). It is also in communication with the LRM, using the model subscription/notification, in order to be notified each time the available quantity of a limited resource becomes null (the resource has been completely exhausted). The default state of the adaptor is asleep, in order to reduce the consumption of resources. Once notified by the LRM, it becomes active. Manually triggered services have priority over those that are started automatically, because they are triggered by the user, which means that they constitute an immediate need on the part of the user. The main aim of context awareness in a PCS is to satisfy the user’s needs initially. The system must put all the necessary limited resources into providing these manually services triggered: this is the principal task of the adaptor. We can distinguish between two operational situations, depending on the currently active service types:(i)Situation 1: all the currently active services are triggered automatically (according to the current context);(ii)Situation 2: one (or several) of the currently active services is (are) triggered manually by the user.

Strategy 1
All the currently active services are triggered automatically, according to the current context. In this case, all the services have the same priority degree. The adaptor executes the following steps:
For each resource entirely-used , we have the following steps.
Step 1. Seek the forms of currently active services that employ the resource by accessing the contents of the CST and by using the control bits .Step 2. Limit the set of currently active services that can be provided in another form which does not employ the resource . If that is not possible, randomly choose an active service and deactivate it, and then go to Step 3.Step 3. Randomly choose one of these services, and randomly choose one of its other forms which does not use the resource Send a command to the CST in order to update its contents according to the actions of the adaptor.
Once the adaptor has been notified by the LRM by a message indicating which limited resource has become entirely used up (availability becomes null), it wakes up and reacts according to the following two strategies and the current situation.

Strategy 2
In this case, there are one or more currently active services triggered manually by the user. The system must then provide all the necessary limited resources to satisfy the needs of the user. The adaptor executes the following steps:
For each entirely-used resource , we have the following steps.
Step 1. Seek the forms of currently active services that use the resource by accessing the contents of the CST and by using the control bits .Step 2. Limit the set of currently active services (only those triggered automatically) to those that can be provided in another form which do not employ the resource . If this is not possible, then seek the currently active forms of services (triggered manually) that employ the resource .Step 3. Choose the services that can be provided in another form which does not use the resource , propose a service to the user, the form of which should be changed by the system change, and go to Step 4.Step 4. Randomly choose one of these services, and randomly choose one of its other forms which does not use the resource . Send a command to the CST in order to update its contents according to the actions of the adaptor.
The adaptor operates as a regulator in a closed loop for the CST, where LRM information is used to adjust its output.

5. Modeling and Simulation

In this part, we model and simulate the two possible situations of the limited resources-aware adaptation approach, which is sensitive to those resources. The steps of each strategy are modeled using the colored Petri Net formalism and simulated using the CPN Tools.

5.1. Strategy 1: All Currently Active Services Are Triggered Automatically
5.1.1. Modeling

Figure 4 shows the simplified hierarchical model of the adaptation system, which contains three steps. Figure 5, Figure 6, and Figure 7 show the detailed models of Steps 1, 2, and 3, respectively. The set of declarations used for the construction of the model of situation 1 is given by Algorithm 1 as follows.

colset UNIT = unit;
colset INT = int;
colset BOOL = bool;
colset STRING = string;
val NS=5;
colset Resource=STRING;
colset E=with e;
colset ResList=list Resource;
colset Form=STRING;
colset ResAmt=product Resource*INT;
colset Service=STRING;
colset SerStat=product Service*ResList*INT;
colset FormRes=product Form*ResList*INT;
colset FormList=list FormRes;
colset SerFormList=product Service*FormList;
colset SerForm=product Service*FormRes;
var r: Resource;
var q,p,i,n:INT;
var s,sr:Service;
var y:ResList;
var fl:FormList;
var fr:Form;
var rl:ResList;

5.1.2. Scenario Simulation and Results

To validate our model of situation 1, we employed a typical scenario, the details of which are as follows.

A computer device has six limited resources, one of them having a 100% utilization ratio (resource “b”). We represent this information by the couple: (resource name, utilization ratio (%)). Let us consider the following example: (“a”,50), (“b”,100), (“c”,10), (“d”,35), (“e”,80), and (“f”,45).

Five services provided by the computer device, four of which are active (triggered automatically according to the current context). Each service uses a set of limited resources. We represent this information by the triplet:

(Service name, [list of limited resources used], state), where Let us consider the following situation:(“S1”,[“a”, “c”, “e”],0), (“S2”,[“a”, “b”, “e”, “d”],1), (“S3”,[“b”, “c”, “d”],1), (“S4”,[“c”, “f”, “e”, “b”],1), (“S5”,[“a”, “f’, “e”],1).

Each service has a set of forms under which it is provided, and each form uses a set of limited resources. If a service is currently active, then the state of one of its forms is marked according to (1). We define the triplet in this manner:

(Service name, [[(form name, [list of used resources], state)]]).

Let us consider the following situation: (“S1”,[(“F11”,[“a”, “e”],0), (“F12”,[“c”, “e”],0), (“F13”,[“a”],0)]), (“S2”,[(“F21”,[“a”, “b”],1), (“F22”,[“b”, “e”],0), (“F23”,[“a”, “d”, “b”],0)]), (“S3”,[(“F31”,[“b”, “c”],0), (“F32”,[“c”, “d”],1), (“F33”,[“c”],0), (“F34”,[“a”, “b”],0)]), (“S4”,[(“F41”,[“b”, “c”, “e”],1), (“F42”,[“b”, “e”, “f”],0), (“F43”,[“c”, “e”],0)]), (“S5”,[(“F51”,[“a”, “e”],1), (“F52”,[“f”, “e”],0)]).

In this scenario, the two services (S2 and S4) have an active form that uses the exhausted resource (b). After running the simulation, we obtained a new active form (F43: form 3 of service 4), which does not use the exhausted resource. The service S2 cannot be provided in another form, since all its forms use the exhausted resource.

We made several modifications to the scenario parameters (number of services, number of limited resources exhausted, list of limited resources used by each service, number of forms of each service, number of active services, etc.), and each time we obtained the expected results.

5.2. Strategy 2: Currently Active Services Are Triggered Both Manually and Automatically
5.2.1. Modeling

Figure 8 shows the simplified hierarchical model of the adaptation system, which contains four steps. Figure 9, Figure 10, Figure 11, and Figure 12 show the detailed models of Steps 1, 2, 3, and 4, respectively. The set of declarations used for constructing the model of situation 2 is given by Algorithm 2.

colset UNIT = unit;
colset INT = int;
colset BOOL = bool;
colset STRING = string;
val NS=5;
colset Resource=STRING;
colset E=with e;
colset ResList=list Resource;
colset Form=STRING;
colset ResAmt=product Resource*INT;
colset Service=STRING;
colset SerStat=product Service*ResList*INT;
colset FormRes=product Form*ResList*INT;
colset FormList=list FormRes;
colset SerFormList=product
Service*FormList;
colset SerForm=product Service*FormRes;
colset SerNum=product Service*INT;
colset SerFormRes=product
Service*FormRes*Resource;
var r: Resource;
var k,q,p,i,n,m:INT;
var s,sr:Service;
var y:ResList;
var fl:FormList;
var fr:Form;
var rl:ResList;

5.2.2. Scenario Simulation and Results

To validate our model of situation 2, we employed a typical scenario, the details of which are as follows.

A computer device has six limited resources, with one of them having a 100% utilization ratio (resource “b”). We represent this information by the couplet: (resource name, utilization ratio (%))Let us consider the following example:

(“a”,50), (“b”,100), (“c”,10), (“d”,35), (“e”,80), (“f”,45)

Five services provided by the computer device, three of which are active (triggered automatically according to the current context) and two of which are active and triggered manually by the user. Each service uses a set of limited resources. We represent this information by the following triplet:

(Service name, [list of limited resources used], state), where the state is marked according to (2).

Let us consider the following situation: (“S1”,[“a”, “c”, “e”],1), (“S2”,[“a”, “b”, “e”, “d”],1), (“S3”,[“b”, “c”, “d”],2), (“S4”,[“c”, “f”, “e”, “b”],1), (“S5”,[“a”, “b”, “f”, “e”],2).

Each service has a set of forms under which it is provided, and each form uses a set of limited resources. If a service is currently active, then the state of one of its forms is marked according to (2). We define the triplet in this manner:

(Service name, [[(form name, [list of used resources], state)]]).

Let us consider the following situation: (“S1”,[(“F11”,[“a”, “e”],1), (“F12”,[“c”, “e”],0), (“F13”,[“a”],0)]), (“S2”,[(“F21”,[“a”, “b”],1), (“F22”,[“e”],0), (“F23”,[“a”, “d”],0)]), (“S3”,[(“F31”,[“b”, “c”],2), (“F32”,[“c”, “d”],0),(“F33”,[“c”],0), (“F34”,[“a”, “b”],0)]), (“S4”,[(“F41”,[“c”],1), (“F42”,[“e”, “f”],0), (“F43”,[“c”, “e”],0)]), (“S5”,[(“F51”,[“a”, “e”, “b”],2), (“F52”,[“f”, “e”],0)]).

In this scenario, there are three services (S2, S3, and S5), the active form of which utilizes the exhausted resource (b). The service S2 is triggered automatically according to the current context, while the services S3 and S5 are triggered manually by the user. After executing the simulation, we obtained a new active form (F23: form 3 of the service 2), which does not use the exhausted resource. As mentioned above for strategy 2, the system must initially seek a form that does not use the exhausted resource among the automatically triggered services. If it does not find the suitable form among these services, then it disables the active form that uses the exhausted resource of the automatically triggered service. Otherwise, it goes to the services triggered manually to perform the same treatment.

We made several modifications to the scenario parameters (services, exhausted limited resources, list of limited resources used by each service, forms for each service, automatically triggered active services, number of active services triggered manually, etc.), and each time we obtained the expected results that the system must provide.

6. Conclusion

Devices operating in a PCS must provide proactively adapted services to both users and applications. The adaptation task must be performed according to the current context (context aware) and by considering the limited resources in PCS devices, which are generally hand-held. Existing approaches to service adaptation suffer from three main limitations: (a) they are not thought to be really context-aware, (b) they are not dynamic, that is, the adaptation is not applied during operation of the system, and (c) they are not suitable for devices with limited resources. In this paper, we have proposed a dynamic context-aware and limited resource-aware service adaptation system for devices in a PCS. The adaptation system was modeled using the formalism of colored Petri Nets and simulated using the CPN Tools. Future work would involve implementing the adaptation system for one device first, and then implementing it for a set a devices operating in a PCS.

Acknowledgment

The authors acknowledge the funding of the Natural Sciences and Engineering Research Council (NSERC) of Canada.