QoS-aware Self-adaptation of Communication Protocols ... - CiteSeerX

QoS-aware Self-adaptation of Communication Protocols in a Pervasive Service Middleware Weishan Zhang1

Klaus Marius Hansen2 João Fernandes1 Julian Schütte3 4 Francisco Milagro Lardies 1 Department of Computer Science, Aarhus University, Aabogade 34, DK-8200 Århus N 2 Department of Computer Science, University of Copenhagen, Universitetsparken 1, DK-2100 København Ø 3 Fraunhofer Institute for Secure Information Technology, Rheinstrasse 75, DE-64295 Darmstadt 4 Telefonica I+D, PT Walqa Ed 1., ES-22197 Huesca [email protected] [email protected] [email protected] [email protected] [email protected]

Abstract Pervasive computing is characterized by heterogeneous devices that usually have scarce resources requiring optimized usage. These devices may use different communication protocols which can be switched at runtime. As different communication protocols have different quality of service (QoS) properties, this motivates optimized selfadaption of protocols for devices, e.g., considering power consumption and other QoS requirements, e.g. round trip time (RTT) for service invocations, throughput, and reliability. In this paper, we present an extensible approach for selfadaptation of communication protocols for pervasive web services, where protocols are designed as reusable connectors and our middleware infrastructure can hide the complexity of using different communication protocols to upper layers. We also propose to use Genetic Algorithms (GAs) to find optimized configurations at runtime to achieve selfadaption of web service transport protocols (TCP, UDP and Bluetooth), taking into consideration QoS requirements. Our tests show that protocol switching involves little performance overhead and runs efficiently. Our evaluations also show that the proposed approach for achieving selfadaptation for communication protocols is effective where optimized configurations of protocols can be obtained with acceptable performance and quality by GAs.

1

Introduction

Pervasive computing systems [19] are characterized by heterogeneous devices with different resources and communication capabilities, where wired connections or wire-

less connections such as WiFi1 , Bluetooth (BT)2 , or Zigbee3 may be used. Some devices may be powered by external electricity, and some are running on batteries. Despite the power supply a device can have, it is always important to run services efficiently in terms of power consumption, latency, and reliability. These parameters are dependent on the communication protocol(s) used between devices as different protocols have different QoS (Quality of Service) properties. Therefore, QoS is an important factor when providing services to a user, in which the communication protocols used play an important role [21]. A large number of pervasive computing devices are equipped with multiple communication capabilities, which then can be utilized to adapt for different QoS requirements at runtime. This is an important feature of selfadaptation for self-management [11] in pervasive systems. Self-management includes a rich set of features, such as self-configuration, self-adaptation, self-optimization, selfprotection, and self-healing. We have reported our former work on self-healing [24], self-configuration [23], and selfprotection [27]. In this paper, we will concentrate on QoSaware (including the awareness of power consumption) selfadaptation of communication protocols. There has been some work on designing new adaptive communication protocols for pervasive computing [22], and research on testing the performance of existing protocols [2][1]. Because devices on the market most probably will not support new designed protocols, it is equally important, if not more, to make full use of the existing protocols in a self-adaptive manner, i.e., to use different protocols on a device for different QoS requirements dynamically. This is especially important for pervasive service computing, where 1 http://www.wi-fi.org/ 2 http://www.bluetooth.com/ 3 http://www.zigbee.org/

services are designed to integrate existing devices and applications. To the best of our knowledge, there is very scarce work in this area. In this paper, we will first quantify the performance and power consumption for pervasive web service (SOAP4 based) transportation using TCP, UDP and BT, which then will be utilized as context for achieving optimized selfadaption of these protocols. We explore self-adaptation in the pervasive web service middleware of the Hydra project5 , which uses different transport protocols (currently TCP, UDP, and BT) to transport web services requests and responses. These protocols are designed as reusable software connectors and the Hydra project middleware infrastructure can hide the complexity of using these different communication protocols, which can be switched at runtime. To make a pervasive system running in a globally optimized manner, we also propose to use multi-objective optimization using Genetic Algorithms (GAs) to find optimized configurations at runtime, to achieve transportation protocol self-adaption taking into consideration of power consumption and other QoS requirements. The tests and evaluations show that our approach is effective. The rest of the paper is structured as follows: Section 2 presents a scenario for self-adaption usage. Then in Section 3 we present our measurements for QoS parameters for different platforms and protocols. The design and implementation of the infrastructure support for communication protocol self-adaptation are shown in Section 4. In Section 5 we present the design of GAs to find optimized protocol configurations at runtime. Section 6 presents the tests of performance overhead, and the performance for obtaining the optimized configurations using GAs. We compare our work with the related work in Section 7. Conclusions and future work end the paper.

2

A scenario for self-adaption of communication protocols

In the following scenario, device services are using web service proxies for the sensor/actuator devices running JSE platform. Communication between devices can use TCP, UDP, and Bluetooth to transport pervasive web services requests and responses. John owns a SmartHome system, which is equipped with self-managed heating, ventilating and home surveillance subsystems. While he is abroad for an academic conference, his home security system automatically turns on to the highest security level when detecting he is far away from home, and the whole SmartHome system is self-configured and self-adapted to minimize power consumption. All the 4 http://www.w3.org/TR/soap/ 5 http://www.hydramiddleware.eu/

devices used for the SmartHome system are equipped with both WiFi and Bluetooth support. These devices include 5 surveillance IP cameras, 10 motion detectors, 10 sound detectors, 10 ventilators, 10 heating controllers, and 10 thermometers. The SmartHome also has a management controller running on a gateway device that connects to the Internet either using WiFi or a wired connection. This device is also able to communicate using Bluetooth. John has a mobile phone with him and can use it to check that everything is fine at home, this includes retrieving captured pictures from all surveillance IP cameras within one seconds, and reading the ventilating and heating conditions to make sure that his cat is living a comfortable life while he is away. Our experiments [21] show that different communication protocols have different QoS properties, in terms of power consumption, throughput, reliability, etc. Here, reliability is defined as the number of successful calls divided by the total number of calls. It is also obvious that the local optimal configurations of protocols are not necessarily globally optimal. In the above scenario, to save energy, it seems natural to use Bluetooth for all devices. But this choice may not meet reliability and/or latency requirements for getting information on the status of the SmartHome system. The objectives for high reliability, low power consumption, low latency are conflicting: from our experiments, Bluetooth has low power consumption but also a high latency. Therefore, we need to find a global optimization for configuring the underlying system at runtime to meet all QoS requirements.

3

Quantifying power consumption and performance for transport protocols

We have tested the power consumption and performance for BT 1.2/2.0, WiFi (TCP/UDP), and wired network to transport pervasive web services, on mobile phones (Nokia 6630, Nokia N95) and laptops (Thinkpad T61p, T61) running JSE/JME/OSGi platforms. The Nokia Energy Profiler6 and a WaveTek Meterman 38XR7 were used to retrieve raw data for measuring power consumption. The details on test procedures and other equipments can be referred in [21]. We list some test results in Table 1. Some data (BT2.0 to BT1.2, W-TCP to W-TCP and W-UDP to W-UDP) are going to be used in this paper (“W-TCP” stands for TCP communication using WiFi, “W-UDP” stands for UDP communication using WiFi, “BT” stands for Bluetooth, UDP stands for UDP communication on wired network). In the table, “Net.” stands for network,“Plat.” stands for platform, “Rel.” stands for reliability,“(S)” stands for power consumption for a server side, “(C)” stands for power consumption for a client side, sometimes only the client or 6 http://forum.nokia.com/info/sw.nokia.com/id/324866e9-0460-4fa4ac53-01f0c392d40f/Nokia_Energy_Profiler.html 7 http://www.tequipment.net/Wavetek38XR.html

the server power consumptions can be measured due to the hardware and software tools restrictions [21]. Table 1. Part of QoS properties Client Net. BT1.2 BT2.0 BT2.0 BT2.0 W-TCP UDP W-UDP

Plat. JSE JSE JSE JME JSE JSE JSE

Server Net. BT2.0 BT1.2 BT1.2 BT2.0 W-TCP W-UDP W-UDP

Plat. JSE JSE OSGi JME JSE JSE JSE

RTT(ms) 39.76 70.1 65.94 193.39 25.99 8.16 7.5

Power(W) 0.183(C) 0.041(S) 0.039(S) 0.285(S) 0.643(C) 1.360(S) 1.359(S) 1.361(S) 1.361(S)

Rel. 97.29% 100% 100% 100% 100% 99.93% 99.90%

From these tests, we can see that the OSGi-based implementation of a web service has more or less the same performance and power consumption as the JSE based implementation. We can also see TCP connections have the best reliability at 100% for our tests, worse throughput and RTT than UDP, and obviously, higher power consumption than Bluetooth. These QoS properties are parts of context for selfmanagement, encoded in a QoS ontology (Figure 1), as one ontology in a set of self-management ontologies called the SeMaPS ontologies, which are used to achieve contextawareness based self-management [26][25], including selfadaptation. The QoS ontology contains the concepts and instances for QoS properties, most importantly for this paper: PowerDrain is used to model the power consumption, RTT time is used to model the round trip time, ResponseTime8 is used to model the execution time for a service, and Reliability is used to define the percentage of successful calls with respect to the total calls for a connection, also Reliability models a service’s capability to answer calls all the time. Figure 1 shows these concepts and some of the instances. The provision of the QoS context is realized as SQWRL9 queries, as presented in the former work [27].

4

Infrastructure support for switching communication protocols

To make the self-adaption of communication (transport) protocols possible, these protocols must be reusable and changeable at runtime. At the same time, as we are targeting pervasive web service environments, the underlying infrastructure must be able to know the changes of protocol, as well the new locations of the services. With this information all middleware components can perform necessary changes and hence hide the underlying protocol changes to the upper layers, where end users will not notice these changes. In the 8 RTT

is measured with the time taken from the client send request, and then the client get the response from the server, i.e., first the current time is noted when the client sends a request(T1), then another one when the server receives the request (T2), another before the server sends the response (T3), and finally when the client receives an answer(T4). Then the RTT = T4-(T3-T2)-T1, and response time is ResponseTime=T3-T2 9 http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL

Figure 1. structure of the QoS ontology next section, we will show how we handle these issues by implementing protocols as software connectors, enhancing services to be capable of protocol switching, and also designing infrastructure to support the corresponding changes resulted from protocol switching.

4.1

Implementing web service transport protocols as connectors

The idea of software connectors is well-recognized to create reusable software [13]. In pervasive service environments, the behavior of a transport protocol using a clientserver architecture can be modeled as a connector which connects both clients and services. Typically a server follows the cycle of: create a connection, receive a request, send a response, close the connection, and a client sends a request and gets the response from the server. These operations in a client-server architecture, are independent of specific transport protocols used by both servers and clients to communicate with each other. Therefore, we can generalize the operations a protocol supports for both server sides and client sides. For the server sides a transport protocol will provide the following operations: • void createConnectors(int port): Creates a new connection. • String receive(): This operation waits until a request arrives and returns the request received. • void send(String result): Sends the given result to the client. • void closeConnection(): Closes a connection.

From the client side, a transport protocol has to implement the following operation to be able to interact with a server: • String communicateWithServer(String request, String host, int port): This operation sends the request given as parameter to the given host and port. This operation returns the response returned by the server.

To facilitate the usage of different protocols for pervasive service, we are using the pervasive web service compiler [8, 9] to generate web service code that can use different transport protocols, e.g., the developer can generate web services that use TCP, UDP and/or Bluetooth as transport protocol(s). The behaviors of these protocols are realized by the operations mentioned above, where the protocols have to implement a ServerProtocol interface for server sides and a ClientProtocol interface for client sides. The design of protocols as connectors is extensible. If a device supports a protocol other than TCP/UDP and Bluetooth (these are currently specified in web service compiler), it can be easily supported by adding the protocol to the web service compiler, through an implementation of the ClientProtocol and ServerProtocol interfaces (ref. Figure 2).

4.2

Positioning services for self-adaptation of communication protocols

In order to be capable of switching communication protocols, a device has to provide a Web Service interface that allows an external component to trigger the switching of protocols. This service is part of self-management services and it provides, in general, the following basic operations: • String changeProtocol(String newProtocol): Performs a protocol change for a service the device is currently providing. The new protocol can be "TCPProtocol", "UDPProtocol" or "BTProtocol". This method returns the name of a service that has changed its protocol and the new endpoint of that service. For example after changing to Bluetooth protocol for a thermometer, you may get the following end point for a thermometer service: ThermometerService=btspp://001C26E6D5E6:1;name=th03. And of course, you can change protocols to all the services a device is currently providing at the same time, as shown in the following list for services provided by a thermometer after changing to Bluetooth. – ThermometerService=btspp://001C26E6D5E6:1;name=th03 – SelfManagementService=btspp://001C26E6D5E6:1;name=SelfManagement – HydraService=btspp://001C26E6D5E6:1;name=hydra

• String getSupportedProtocols(): Returns all the supported protocols of the device. • String getCurrentProtocol(): Returns the currently used protocol. Figure 2 shows the details of relationships of the server side protocols, and the corresponding operations, using a thermometer (called TH03) service that provides getTemperature and getStatus operations. Two threads are used to achieve the separation of handling different concerns: one

is used for the handling of actual device services, and the other one is dedicated for the handling of protocol switching.

4.3

Support for communication protocol switching with SOAP tunneling

The Network Manager and SOAP Tunneling [12] components of the Hydra project middleware build an overlay P2P network [20] and provide mechanisms for service registration, discovery and consumption over this P2P network through different communication protocols, such as TCP, UDP or BT, allowing devices to offer and consume services in a Web Service compliant form. For registering a service in the Network Manager, the device requests the creation of an identifier (called HID – Hydra Identifier), providing the real endpoint of the service. The HID allows the service to be uniquely addressed and consumed over the Hydra project middleware overlay network. The real endpoint of the service is used by the Network Manager for the last mile service invocation. This endpoint represents the actual location where the service is deployed and is, in contrast to the HID address, protocol-specific. When a service invocation arrives to a Network Manager from the P2P network, the SOAP Tunneling component forwards the service request to the correct endpoint with which that service was previously registered. In the Hydra project middleware, the protocol switching service of a device is called by the Self-Management component [25, 27]. In case of protocol changes, the SelfManagement component will notify the Service Discovery Manager that the device’s services are now available in different endpoints. In order to achieve this the SelfManagement component makes use of the Event Manager which uses a topic based publish/subscribe style [7], by publishing an event with a topic that the Service Discovery Manager is a subscriber to. After receiving this event, the Device Discovery Manager needs to update the information about the device’s services in the Network Manager, by calling the method renewHIDInfo(String hid, String endpoint), providing the new endpoint on which the service will be addressable. The device information (endpoints) is now updated in the network and the services can now be addressed at their new endpoints. This is shown in Figure 3.

4.4

Policy-based triggering of self-adaptation

Self-adaptation may either become necessary at a regular time interval or may be triggered by changes of the current situation. For example, when new devices join the network, a re-configuration of all network protocols can reduce the overall power consumption, or QoS requirements changed and new configurations are needed as in our scenario in Sec-

Figure 2. Details of protocols relationship and enabling service for protocol switching Thermometer

getBattery()

Thermometer

getWSEndpoint() NetworkManager

ThermometerClient

getTemperature()

)

ServiceDiscoveryManager

renewHIDInfo()

EventManager

HydraStandard

changeProtocol(”BTProtocol”)

No tify (e ve nt

Publish(”/protocolchange”,event)

SelfManagement

SelfManagement

NetworkManager

Figure 3. Infrastructure support for selfadaptation

tion 2. For triggering self-adaptation actions such as a protocol switching, we use Complex Event Streaming (CEP) to recognize event patterns of interest and event-conditionaction policies to trigger the actual changes. The CEP engine retrieves events from the Event Manager (e. g. raw sensor data or network events), and aggregates them to semantically rich event patterns. Conditions are specified in Prolog and can refer to triplets from the self-management ontologies while actions are realized by Java classes implementing an Action interface. If the event pattern is triggered and the condition is evaluated to true, an action is invoked, sending a reconfiguration request to the Self-Management

component, which will first use GAs to obtain an optimized configuration of communication protocols used by all channels, and make the corresponding changes as necessary to all protocols.

5

GA-based optimization of service transport

Figure 4 shows the topology of device connections for the scenario introduced in Section 2, which is a typical star pattern. All sensor/actuator devices are connected to a gateway node, and this gateway node connects to the Internet. For this simple topology, there are 355 possible configurations of communication protocols (referring to TCP/UDP/BT), a scale that is well suited for genetic algorithms to find optimal solutions. Here we are not considering the link from the Gateway to the Internet, as it should use TCP/UDP. Furthermore, as seen from Table 2, the power consumption, the gateway service execution time and its service reliability depend on the channels connected from these 55 devices to the gateway. Considering the power needed for a camera to take picture/video, heating control and other consumption, we present the power consumption for all devices used in our scenario in Table 2. This is based on the data in Table 1. These power consumption values reflect a device that is in operational mode. We also show the service execution time on devices and also the service reliability which are the same for a device irrespective of the protocols used (except the gateway).

Thermometer

Camera

ventilator

heater

T

Motion sensor Sound sensor

Motion

under consideration is calculated as:

Sound

L

max((L1 + T1 , L2 + T2 , . . . , Li + Ti , . . . , LK + TK ) ·

=

Communication link

C(i, j) + Lg )

(2)

Internet

Here C(i, j) = 1 if a communication protocol j is used for channel i (with a scope of [1, K]) that has latency of Li is selected, otherwise C(i, j) = 0. Here i also denotes the sequence number of a device that is connected to the gateway node, where Ti represents the service execution time (ResponseTime in Figure 1). j represents the sequence number of a concrete communication protocol with a scope of [1, m]. In our case, there are 55 channels if not considering the one where the gateway connects to the Internet. Lg represents the service execution time on the gateway, which depends on what are the protocols used as shown in Table 2. The reliability can be calculated in a similar way as the latency objective. In order to uniformly minimize all three objectives, we calculate the un-reliability (the U r objective) instead as follows, considering the topology of our system:

Figure 4. Topology of the example scenario

Table 2. QoS data used for our scenario W-TCP X X X

W-UDP X X

BT X

Power E-Time Reliability 2.9 360 99.993% 2.7 346 99.999% X 2.6 356 99.993% Gateway X X 2.6 356 99.993% X 1.3 364 99.93% X 2.5 348 99.999% X 2.5 348 99.999% X 0.5 230 99.990% Camera X 1.7 X 1.7 X 0.3 200 99.999% Motion X 1.5 X 1.5 X 0.3 200 99.999% Sound X 1.5 X 1.5 X 0.3 210 99.999% Thermometer X 1.5 X 1.5 X 0.7 240 99.993% Ventilator X 1.9 X 1.9 X 0.6 260 99.998% Heating X 1.8 X 1.8 “X” stands for that protocol will be used, “E-Time” stands for service execution time (response time).

Ur

Optimization objectives and constraints formulation in GAs

The power consumption of a system (the P objective) is calculated by the sum of each node’s power consumption as: P =

n X m X

Pi · C(i, j)

1 − min((R1 · S1 , R2 · S2 , . . . , Ri · Si , . . . , RK · SK ) · C(i, j) · Rg )

We have explored using GAs for selecting optimized self-configuration [23] and self-protection [27]. The selfadaptation problem has a much bigger problem space than the former work (i.e., (310 − 1) times bigger than that of the self-protection problem presented in [27]).

5.1

=

(1)

(3)

Here C(i, j) = 1 if a communication protocol j is used for channel i (with a scope of [1, K]) that has reliability of Ri is selected, otherwise C(i, j) = 0. Here i also denotes the sequence number of a service running on a device that is connected to the gateway node, where Si represents the service reliability. j represents the sequence number of a concrete communication protocol with a scope of [1, m]. Rg represents the service reliability on the gateway, which depends on what are the protocols used as shown in Table 2. We also have restrictions for the overall system’s communication configurations (referring to all 55 channels): • Reliability should be maximized (highest value is 1 for a channel) • Latency must not exceed 700 ms (leave 300 ms for the connection from the gateway to John through Internet) • Power operation power consumption should be minimized, not more than 50 Watts for the whole system

i=1 j=1

Here C(i, j) = 1 if a communication protocol j is used for node i (with a scope of [1, n]) that has power consumption Pi is selected, otherwise C(i, j) = 0. j represents the sequence number of a concrete communication protocol with a scope of [1, m]. In our scenario, n = 55 and m = 3. The latency will be considered for the channels created between the sensor/actuator devices and the gateway node. It is calculated as the maximum of the latency from these channels plus the gateway service execution time which depends on the overall protocol configurations as shown in Table 2. Therefore the latency (the L objective) of the system

5.2

Chromosome encoding and fitness evaluations

A chromosome in a GA stands for a unique solution in the solution space. GAs can typically make use of booleans, real numbers and integers to encode a chromosome. For our case, as explored in self-configuration [23] and selfadaptation [27], we represent a chromosome using integers (starting from 0). More specifically, an integer vector is used to represent a solution: V = [V1 , V2 , ...Vi , ..., Vn ] (where n is the number of decision variables – in our case 55) to represent a solution found by a GA. Vi is a natural

number, acts as a pointer to the index of the communication protocol of the ith protocol. For example, a chromosome [0,1,2,1,2,0,1,1,2,1...] represents a solution which chooses Bluetooth for channel 1, W-TCP for channel 2, W-UDP for channel 3, and so on. Based on the chosen protocols, the GAs then decide fitness using the introduced objective equations, and will at the same time evaluate constraints mentioned in Section 5.1.

5.3

milliseconds) taken to finish a switch. A number of tests have been conducted and part of tests is shown in Table 4. We can see that the overhead for switching back and forth to TCP and UDP is more or less 0 ms (occasionally it takes 16 ms to be prepared), and the switching to Bluetooth takes 81 ms in average, because of wireless unit/radio initialization. In general, this is quite acceptable in pervasive web services environment, especially considering that it may take more than 200 ms to answer a web service call.

Pareto front for the self-adaptation problem Table 4. Overhead of protocol switching

As recommended in our evaluation of GAs’ usability in self-management planning [23], we use multiple GAs, including NSGA-II [5], MOCell [14], and FastPGA [6] (in which FastPGA is a new GA added to our Self-Management component) to find the Pareto frontfront/set10 for our problem. A very interesting thing is that for our problem there are only four points in the front, that is to say we have a very big problem space, but a very small solution space instead. This makes the further investigation of the GA usage for our problem worthwhile as it is a different case from our former exploration. The time consuming process of getting a Pareto front is not necessary, if you do not want to evaluate solution quality but just use our recommended parameters [23] for finding optimized configurations.

Table 3. Pareto front for the scenario problem

6

L objective

P objective

Ur objective

686.1 694.1 666.1 670.1

27.6 25 44.4 43.5

0.000170009592771581 0.000799946582317412 0.000170009592771581 0.00108992285954035

Evaluation and Performance

To make sure that the protocol switching during the selfadaption process will not incur too much overhead, we will first test the corresponding performance overhead in the server side. Second, we need to evaluate the performance to find optimized configurations of protocols, and investigate whether we have new recommendations of parameters settings for the new problem.

6.1

Performance overhead for switching protocols

We have used the thermometer web service to test the performance of protocol switching, with a continuous chain of protocol changes from BT to TCP, then to UDP, then back to BT, and then to UDP, and so on. We measure the time (in 10 http://www-new.mcs.anl.gov/otc/Guide/OptWeb/multiobj/

6.2

UDP to BT

to UDP

to TCP

To BT

to UDP

to TCP

78 93 32 109 78

0 0 0 0 0

0 0 0 0 0

31 62 109 109 109

0 0 0 0 0

16 0 0 0 0

Performance of finding optimized protocols configuration

We have extensively tested the performance for all the three GAs for the self-adaptation problem, following the parameter settings as recommended [23], and with extra tests where max evaluations are lower (2000, 3000, 40000) considering the bigger problem space. We also tested crossover probability of 1. We now show a part of these tests in Table 5. As we noticed, although MOCell runs faster than NSGA-II and FastPGA, in a normal setting (for example, cross-over probability equals to 1, population size 80, and maximum evaluations 3000), NSGA-II gets much higher quality of solutions than that of MOCell and FastPGA, where FastPGA performs the worst in terms of the Hyper Volume quality indicator [28]. FastPGA [6] is normally used for computationally heavy situations, therefore as expected it did not show any advantages over other two GAs as our problem does not involve such operations. Because the problem space is bigger than that in selfconfiguration [23] and self-protection [27], it takes longer time for both MOCell and NSGA-II (e.g. 1294 ms vs. 357 ms) to find optimized solutions which is reasonable. We can also see that the cross over probability of 1 for NSGA-II obtain better quality of solutions than other setting, but without significant increase of the running time needed, therefore we would now recommend to use this in the future.

6.3

Discussion

For a larger problem space, we would expect that for the same parameter setting, GAs will run slower, and this is consistent with what we show in Table 5. From the new tests as in Table 5, we recommended that for NSGA-II, which remains the best algorithm for all the tested self-management

Table 5. Performance of GAs population

evaluations

CVP

HVM

HVN

HVF

TM

TN

TF

64 64 64 64 64 64 64 64 80 80 80 80 80 80 80 80 80 80 80 80

2000 2000 2000 2000 3000 3000 3000 3000 2000 2000 2000 2000 3000 3000 3000 3000 5000 5000 5000 5000

1 0.9 0.8 0.7 1 0.9 0.8 0.7 1 0.9 0.8 0.7 1 0.9 0.8 0.7 1 0.9 0.8 0.7

0.025797 0.035784 0.031123 0.036949 0.030458 0.039944 0.034951 0.039445 0.031456 0.036116 0.044605 0.03828 0.030291 0.041942 0.044272 0.047268 0.04527 0.035784 0.040943 0.044771

0.179251 0.169099 0.152954 0.1438 0.184411 0.168932 0.161775 0.163273 0.188405 0.172261 0.163773 0.14613 0.203717 0.197226 0.184743 0.175922 0.211872 0.202053 0.191234 0.183412

0.013481 0.014147 0.01165 0.010652 0.016144 0.012483 0.014313 0.012483 0.01914 0.019473 0.014979 0.012316 0.020638 0.018308 0.01165 0.008488 0.018974 0.016311 0.013648 0.012316

200 197 199 197 295 290 290 290 199 196 196 194 299 297 293 292 494 495 488 485

412 408 408 404 616 618 615 620 509 501 498 499 764 771 791 792 1292 1294 1295 1298

416 415 419 418 669 665 663 663 564 567 576 577 914 914 929 935 1629 1638 1645 1636

problems. In the table, “CVP” stands for cross over probability, the average Hyper Volume is denoted as HVN for NSGA-II, HVM for MOCell, HVF for FastPGA, average execution time for a run is represented as TN for NSGA-II, TM for MOCell and TF for FastPGA, all are in ms. As consistent with our former recommendations in [23] and [27], population size of 64-100 is recommended for NSGA-II (cross over probability should be 1 instead - we did not test this setting before). For a bigger problem space as in our case, the max evaluations should be lowered down to 2000 to 3000, in which we will get performance in between 412 ms to 642 ms, where average Hyper volume will be 0.179 to 0.188. There may be very few points in a Pareto front for a practical self-management problem from our experience. For example, in a first attempt to optimize the self-adaptation configurations, we did not consider the reliability and execution time in the gateway node (ref. Table 2). We found that there are only two points that formed the Pareto front (using all three GAs but there probably some points can not be found with our two days running of these GAs). For only two points, the Hyper volume quality indicator is not usable, but this does not affect the usage of GAs to find optimized solutions using the recommended parameter settings.

7

Related work

As previously mentioned, there has been focus on creating new protocols for pervasive computing [3, 22]. Barr et al. [3] used the AODV protocol [15] for ad hoc routing. Wu et al. [22] presents a variant of a quorum protocol where mobile stations cycle through wake-up and sleep modes to increase energy efficiency. Our work differs in that we assume the existence of a set of available protocols out of which we need to choose among others to optimize energy usage and also other QoS properties at runtime. But this work will be considered in our approach as part of our future work to consider the dynamism of power efficiency.

Pervasive computing has always been a motivation for self-management and autonomic computing in particular [11] using a variety of approaches. There are explorations for using auction algorithms to dynamically resolve policy conflicts during context changes in the CARISMA middleware [4]. Poladian et al [16] used an analytical approach similar to combinatorial auctions in project Aura to adaptively support everyday tasks of users. We are also working on including this in the self-management planning layer, as auction algorithms can find local optima if required. But in general, from our experiences of preliminary tests, we will still use GAs as the main approach for finding global optimized solutions as it can find better quality of solutions with reasonable performance than the auction algorithms. Genetic algorithms are being used in self-managing systems in which configurations are encoded as utility functions and where the problem of finding a (Pareto) optimal configuration becomes a multi-objective optimization problem [10, 18]. A recent approach within pervasive computing is the MUSIC middleware[17]. In MUSIC, components have QoS characteristics and the assumption is that QoS of a composition can be computed. In contrast to our work, MUSIC focuses on external Service Level Agreements (SLAs) and the fulfillment of those. Furthermore, it is not clear whether the proposed design is implemented and how planning will be realized.

8

Conclusions and future work

Pervasive computing has intrinsic heterogeneity of the involved devices where multiple communication protocols can be used, which possess different QoS properties at runtime. This fact can be utilized to realize different QoS requirements at runtime through the self-adaption of communication protocols, where different protocols for different channels can be configured in a global optimized manner using GAs and/or CAAs. As a key part of self-adaption of protocols, we design and implement these protocols as reusable software connectors which can be changed dynamically at runtime. Other parts of the middleware then help to make these changes transparent to the end user, but also addressable through new web service endpoints. From our tests, we can see that the overhead of protocol switching is quite acceptable in a pervasive web service computing environment. We have also evaluated the usage of three GAs, namely NSGA-II, MOCell, and FastPGA. As consistent with our initial evaluations, NSGA-II is still the best recommendation for the usage of self-management problem optimization. In the future, we will test the self-adaption of protocols for the mobility in the pervasive systems where service end points suddenly disappear and come back again. We will investigate the usage of distributed GAs and com-

binatorial auctions for their potentials to be used to solve our problem. Currently only synchronized request/reply are supported, and only Bluetooth, Wired/Wireless TCP/UDP are supported, in the future, we will add the support for asynchronous calls, and add the support for other protocols. Also the QoS values used (for latency, power consumption etc.) are static, and as they may change at runtime, we will taken this issue into account in the future.

Acknowledgements The research reported in this paper has been supported by the Hydra EU project (IST-2005-034891).

References [1] A. Anand, C. Manikopoulos, Q. Jones, and C. Borcea. A quantitative analysis of power consumption for locationaware applications on smart phones. In IEEE International Symposium on Industrial Electronics, 2007. ISIE 2007, pages 1986–1991, 2007. [2] S. Avancha, V. Korolev, A. Joshi, T. Finin, and Y. Yesha. On experiments with a transport protocol for pervasive computing environments. Computer Networks, 40(4):515 – 535, 2002. [3] R. Barr, J. C. Bicket, D. S. Dantas, B. Du, D. T. W. Kim, B. Zhou, and E. G. Sirer. On the need for system-level support for ad hoc and sensor networks. SIGOPS Oper. Syst. Rev., 36(2):1–5, April 2002. [4] L. Capra, W. Emmerich, and C. Mascolo. CARISMA: Context-Aware Reflective mIddleware System for Mobile Applications. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, pages 929–945, 2003. [5] K. Deb, A. Pratap, S. Agarwal, and T. Meyarivan. A fast and elitist multiobjective genetic algorithm: NSGA-II. Evolutionary Computation, IEEE Transactions on, 6(2):182–197, 2002. [6] H. Eskandari and C. Geiger. A fast Pareto genetic algorithm approach for solving expensive multiobjective optimization problems. Journal of Heuristics, 14(3):203–241, 2008. [7] P. Eugster, P. Felber, R. Guerraoui, and A. Kermarrec. The Many Faces of Publish/Subscribe. ACM Computing Surveys, 35(2):114–131, 2003. [8] K. M. Hansen, W. Zhang, and J. Fernandes. OSGi based and Ontology-Enabled Generation of Pervasive Web Services. In 15th Asia-Pacific Software Engineering Conference, pages 135–142, Beijing, China, Dec. 2008. [9] K. M. Hansen, W. Zhang, and G. Soares. Ontology-enabled generation of embedded web services. In Proceedings of the 20th International Conference on Software Engineering and Knowledge Engineering, pages 345–350, Redwood City, San Francisco Bay, USA, Jul. 2008. [10] O. Hassan, L. Ramaswamy, J. Miller, K. Rasheed, and E. Canfield. Replication in Overlay Networks: A Multiobjective Optimization Approach. In 4th International Conference on Collaborative Computing: Networking, Applications and Worksharing (COLLABORATECOM-2008), Orlando, FL, USA, Nov 2008.

[11] J. Kephart and D. Chess. The vision of autonomic computing. IEEE Computer, pages 41–50, 2003. [12] F. M. Lardies, P. A. Rafael, J. Fernandes, W. Zhang, K. M. Hansen, and P. Kool. Deploying pervasive web services over a p2p overlay. In WETICE ’09: Proceedings of the 2009 18th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises, pages 240–245, Groningen (The Netherlands), 2009. IEEE Computer Society. [13] N. Mehta, N. Medvidovic, and S. Phadke. Towards a taxonomy of software connectors. Proceedings of the 22nd international conference on Software engineering, pages 178– 187, 2000. [14] A. J. Nebro, J. J. Durillo, F. Luna, B. Dorronsoro, and E. Alba. Mocell: A cellular genetic algorithm for multiobjective optimization. International Journal of Intelligent Systems, pages 25–36, 2007. [15] C. Perkins, E. Belding-Royer, and S. Das. RFC3561: ad hoc on-demand distance vector (AODV) routing. Internet RFCs, 2003. [16] V. Poladian, J. Sousa, D. Garlan, B. Schmerl, and M. Shaw. Task-based adaptation for ubiquitous computing. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Special Issue on Engineering Autonomic Systems, 36(3), 2006. [17] R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S. O. Hallsteinsen, J. Lorenzo, A. Mamelli, and U. Scholz. Music: Middleware support for self-adaptation in ubiquitous and serviceoriented environments. In B. H. C. Cheng, R. de Lemos, H. Giese, P. Inverardi, and J. Magee, editors, Software Engineering for Self-Adaptive Systems, volume 5525 of Lecture Notes in Computer Science, pages 164–182. Springer, 2009. [18] R. Rouvoy, F. Eliassen, J. Floch, S. Hallsteinsen, and E. Stav. Composing Components and Services Using a PlanningBased Adaptation Middleware. LECTURE NOTES IN COMPUTER SCIENCE, 4954:52–67, 2008. [19] M. Satyanarayanan. Pervasive computing: vision and challenges. Personal Communications, IEEE [see also IEEE Wireless Communications], 8(4):10–17, 2001. [20] R. Schollmeier. A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. Peer-to-Peer Computing, IEEE International Conference on, 0:0101, 2001. [21] P. Sperandio, S. Bublitz, and J. Fernandes. Wireless Device Discovery and Testing Environment. Technical Report D5.9, Hydra Consortium, Dec. 2008. IST 2005-034891. [22] S. Wu, M. Chen, and C. Chen. Fully Adaptive Power Saving Protocols for Ad Hoc Networks Using the Hyper Quorum System. In Distributed Computing Systems, 2008. ICDCS’08. The 28th International Conference on, pages 785–792, 2008. [23] W. Zhang and K. Hansen. An Evaluation of the NSGA-II and MOCell Genetic Algorithms for Self-management Planning in a Pervasive Service Middleware. In 14th IEEE International Conference on Engineering Complex Computer Systems (ICECCS 2009). IEEE Computer Society Washington, DC, USA, 2009. 192-201. [24] W. Zhang and K. M. Hansen. An OWL/SWRL based Diagnosis Approach in a Web Service-based Middleware for

[25]

[26]

[27]

[28]

Embedded and Networked Systems. In The 20th International Conference on Software Engineering and Knowledge Engineering, pages 893–898, Redwood City, San Francisco Bay, USA, Jul. 2008. W. Zhang and K. M. Hansen. Semantic web based selfmanagement for a pervasive service middleware. In Second IEEE International Conference on Self-Adaptive and SelfOrganizing Systems (SASO 2008), pages 245–254, Venice, Italy, Oct. 2008. W. Zhang, K. M. Hansen, and T. Kunz. Enhancing intelligence and dependability of a product line enabled pervasive middleware. Pervasive and Mobile Computing, In Press, Corrected Proof:–, 2009. W. Zhang, J. Schutte, M. Ingstrup, and K. M. Hansen. Towards optimized self-protection in a pervasive service middleware. In 7th International Conference on Service Oriented Computing, Joint ICSOC&ServiceWave 2009 Conference, pages 404–419, Stockholm, Sweden), November 2427 2009. Springer LNCS 5900. E. Zitzler and L. Thiele. Multiobjective evolutionary algorithms: a comparative case study and the strength Pareto approach. IEEE transactions on Evolutionary Computation, 3(4):257–271, 1999.