Dynamic Service Reconfiguration for Wireless Web Access

Siu-Nam Chuang

Alvin T.S. Chan

Jiannong Cao

Ronnie Cheung

Department of Computing

The Hong Kong Polytechnic University

Hung Hom, Kowloon, Hong Kong, SAR, China

Abstract

This paper describes a dynamic service reconfiguration model where the proxy is composed of a chain of service objects called mobilets (pronounced as mo-be-lets), which can be deployed onto the network actively. This model offers flexibility because the chain of mobilets can be dynamically reconfigured to adapt to the vigorous changes in the characteristics of the wireless environment, without interrupting the service provision for other mobile nodes. Furthermore, mobilets can also be migrated to a new proxy server when the mobile node moves to a different network domain. We have realized the dynamic service reconfiguration model by crafting its design into a programmable infrastructure that forms the baseline architecture of the WebPADS (short for Web Proxy for Actively Deployable Services) system.

Keywords

Wireless Web Access, Dynamic Service Reconfiguration, Active Services, Wireless Environment Adaptation

1. Introduction

Mobile computing enables the creation of a new class of distributed applications that seek to leverage on the important benefits of mobility, while providing unconstrained and continuous accessibility to information. With the explosive growth of the Internet, driven largely by the popularity of the WWW, there is a natural desire for the delivery of Web accessibility over a mobile environment. The WAP [1] system is a good example of accessing Web information over a wireless network in a mobile environment by employing existing cellular technology that bridges to the Internet. In general, the underlying technologies driving the WWW are largely based on the assumption of wired communication. However, unlike the case of a wired environment, the assumptions of large bandwidth availability, low error rates and always-on connectivity are invalidated in a wireless environment [2] [3]. The mismatches in these assumptions, and the continuous drive towards mobile access and Web traffic, have motivated us to address the challenges of Web access in a mobile environment.

Efficient Web access over a wireless network is challenging because of the varying characteristics of the wireless environment and the adverse interactions among HTTP, TCP and the wireless network. These lead to problems that significantly degrade the user-experienced performance of the Web accessed through the wireless network [4]. The mechanisms for solving these problems are well-researched, and many proposed solutions demonstrated promising results [5] [6]. However, most proposed solutions lack the following features that we deem to be important for supporting a robust Web service architecture operating over a wireless environment.

Active Deployment. Although many mechanisms have been developed to accomplish optimized Web performance in a wireless network, related mechanisms for flexibly managing the new services are relatively immature. Existing solutions are static in that they require prior installation and configuration on the Web server or the Web proxy and the mobile host. As such, the mobile host is unable to benefit from the new services when it moves to a foreign network that does not provide the specified services. As there has been an increasing demand for adding new services to the network or to customize existing network services to match new application demands, it is necessary to develop a flexible service framework for Web traffic to allow rapid development and introduction of new services, and enjoy the benefits of the new services anywhere at any time.

Dynamic Reconfiguration. Mobile devices are typically scarce in resources: they have little or no disk space, limited battery life, small screen size and constrained keyboards. On the other hand, a docked mobile device can have access to much richer resources, such as wired network, unlimited power, extra storage, secondary displays, and improved input devices such as a full-size keyboard and mouse. The architecture should be able to detect and adapt to these changes so that the services can be reconfigured to exploit the maximum efficiency of the mobile device, and to achieve context-awareness in computation.

Migration. Mobility management is another concern in mobile computing. The mobility problem needs to be handled explicitly when a mobile node moves from place to place while having to maintain the ongoing communication session and state synchronization. The architecture should be able to migrate its services to trace the mobility of the mobile node, and to maintain the ongoing service provision as the mobile node moves across different domains.

In this paper, we propose, design and implement the Web Proxy for Actively Deployable Services (WebPADS), which seek to exploit the desirable features to enhance Web access experience while operating over a wireless network.

2. WEBPADS ARCHITECTURE

The WebPADS architecture [7] [8] exploits the idea of injecting active service into an agent-proxy model for enhancing service provision for wireless Web access. We introduce the mobilet as the entity of an active service that allows service deployment, reconfiguration and migration. To realize the design, we have chosen Java as the programming language because it is robust, portable, multithreaded, language-dynamic and network-aware. Such properties match the requirements for the implementation of the WebPADS system and the mobilets.

Figure 1. An agent-proxy model

2.1 An Active Service Architecture

The service architecture of WebPADS is derived from an agent-proxy model, which also is used in existing systems such as Mowgli [9] and WebExpress [10]. As shown in Figure 1, the idea is to place an agent in the mobile node and another agent in the fixed network, where all HTTP requests/responses are intercepted, transformed and optimized for transformation over a wireless network. The agent-proxy model has been shown to improve the performance of HTTP over a wireless network. In particular, efforts have been directed toward applying specific services to alleviate the poor performance of Web applications in a wireless environment. Importantly, these services are static in nature because they require prior installation and deployment. As a result, updating and adding functionalities to the agent-proxy architecture can be complicated. However, as the number and variety of services being provided through the Web continue to grow, a static client-proxy architecture that offers fixed functionality will not be able to cope with the increasing demands placed upon these applications. Moreover, the inherent mobility of the mobile node makes it important for the mobile node and all the agents on the fixed network to become capable of being updated dynamically with the newly upgraded functionalities to ensure compatibility and consistent operations. More importantly, the effects of varying characteristics in a wireless environment require the dynamic counteraction of an agent-proxy. As such, it is important that the agent-proxy can dynamically reconfigure the services that best match the wireless operating environment.

Based on the need for dynamic service updating, we introduce an active service model that extends the agent-proxy model to support dynamic service reconfiguration. In this active service model, the proxy is composed of a chain of service objects called mobilets. This model offers flexibility because the chain of mobilets can be dynamically reconfigured to adapt to the vigorous changes in the characteristics of a wireless environment, without interrupting the service provision for other mobile nodes. Furthermore, mobilets can migrate to a new proxy server when the mobile node moves to a different network domain. We have realized the active service model by crafting its design into a programmable infrastructure that forms the baseline architecture of WebPADS.

2.2 Mobilet Service Model

A Mobilet (pronounced as mo-be-let) is a service entity that can be downloaded, pushed or migrated to a WebPADS platform for execution within an environment. The name, mobilet, bears a strong resemblance to applet. Applets are active codes executed within Web browsers whilst mobilets are active mobile codes that run within the agent-proxy WebPADS environment.

Mobilets exist in pairs: a master mobilet resides at the WebPADS client and a slave mobilet resides at the WebPADS server. A pair of mobilets cooperate to provide a specific service. A typical case would be: while a slave mobilet shares a major portion of the processing burden, the master mobilet instructs the slave mobilet what actions to take and it also presents the processed output to the WebPADS client.

The mobilets are chained together on the client in a specified order, and the corresponding peer mobilets are chained together in a nested order on the server-side. The service chaining model of mobilet supports a general service composition paradigm that enables utmost flexibility in deploying service aggregation, while providing ease of re-configuration in response to the varying characteristics of a wireless environment. A consistent synchronization and data flow model can be established through the abstraction of channel objects and the employment of data encapsulation between services.

In order to support robust service configuration, all mobilets can be dynamically deployed across a WebPADS proxy client and server. In other words, it is possible for a mobile node to carry with it relevant mobilets as it travels across foreign domains. As the need arises, mobilets from the client can be dynamically pushed to a WebPADS proxy server and configured to operate in a coordinated manner. Conversely, it is possible for a WebPADS server to push mobilets to a WebPADS client to actively install new services to operate across a wireless link. To provide support for usability of a client as it moves across network domains, it is necessary for WebPADS to facilitate migration of services. That is, to adapt to changes in locality, network condition and server availability, mobilets can migrate from one WebPADS server to another. Through service migration, changes in a wireless environment cause minimal interruption to service provision.

2.3 WebPADS System Overview

The WebPADS platform, as shown in Figure 2, is an object-oriented system based on the agent-proxy architecture, comprising system components and mobilets. The core system components provide essential services for the deployment of an agent-proxy that forms a unit of service executing under the WebPADS execution environment. The unit of service is implemented as an agent-proxy mobilet that provides value-added services to the wireless environment. The system components also provide generic facilities that serve mobilets, which in turn provide services that enhance the Web-browsing experience. These services can be added, removed and updated dynamically. A series of mobilets can be linked together to form a processing chain, allowing WebPADS to benefit from the aggregated functionality of a group of services.

Figure 2. The WebPADS system architecture

The components of the WebPADS system are briefly described as follows:

Configuration Manager: The configuration manager is responsible connection negotiation between the proxy client and the proxy server. It also contains a service controller for initializing, interconnecting and managing the services objects.

Service Migration Manager: The service migration manager manages the process of importing and exporting services objects between the WebPADS server and the WebPADS client. It also cooperates with the service directory to activate, store and keep track of the changes made to the active service objects.

Service Directory: The service directory records all the known service types. The object codes are stored in a service repository, which is used for service activation and service migration.

Event Register: The event register allows objects to register for event sources. When an event occurs, the objects that have registered for that event source are notified. Event sources include various changes in network status, machine resources status and connectivity status.

Channel Service: The channel service provides virtual channels for the service objects to communicate. Instead of opening separate TCP connections for each message, messages are multiplexed into a single persistent TCP connection, which then eliminates the overheads of opening new TCP connections and avoids the slow-start effect on overall throughput [2].

3. DYNAMIC RECONFIGURATION

The mobile computing environment is known to be not only more constrained in computation and communication resources, but also the changes in its characteristics are much more dynamic compared with the wired environment. Service provision in the wireless environment must take into account the continuously changing operating environment. As a result, after the service composition is established on the WebPADS platform, the whole service composition and the individual mobilets that are running must be able to automatically re-configure to adapt to changes in the operating environment. Importantly, the dynamic reconfiguration of the mobilet services aims to drive WebPADS to operate at an optimum setting based on the constrained environment.

Figure 3. Adaptation to bandwidth change

To illustrate the concept of dynamic reconfiguration, an example is given in the following discussion. Figure 3 shows the adaptation of the WebPADS system to the change in bandwidth. In step 1, two pairs of mobilets provide HTTP services running in the service composition, operating over a wireless link of 100kbps. In step 2, the bandwidth of the wireless link drops to 10kbps, which leads to the user experiencing significant delays in Web access. This change is detected by the WebPADS system, which decides to modify the service composition to adapt to the bandwidth change. During step 3, to adapt to the decrease in bandwidth, an image transcoding mobilet is inserted into the service composition. Using transcoding, the data volume of all images going through the service composition are reduced to achieve a much faster transfer time over the wireless link, which in turn reduces the delay experienced by the user.

Figure 4. Dynamic service composition reconfiguration

As shown in Figure 4, the dynamic service reconfiguration process is coordinated by the service controller of the configuration manager at the WebPADS client side. On initialization of a reconfiguration process, the event and the new service chain map are forwarded to the WebPADS server. When a dynamic service reconfiguration takes place, the mobilets specified in the new service chain map will first go through the source code loading procedures, so that the sources of all the new mobilet classes are located. This process takes place simultaneously at both the WebPADS client and the WebPADS server. When all the new mobilet classes are ready, the current service composition will undergo a service deletion-addition process, which will be illustrated in the next section. During a deletion-addition process, the current service composition is reconfigured to match the description of the new service chain map. Once the current service composition is updated, the execution threads of mobilets will be resumed, and service provision will re-commence.

3.1 Configuration Description

To regulate the service configuration policies, the WebPADS system maintains a configuration description file utilizing XML. To dynamically adapt to the changes in the environment, WebPADS employs the environment monitor and event system to monitor and communicate the changes. An environment element consists of one or more conditions, where each condition specifies an event and a relational value that will fulfill that condition.

When a WebPADS client starts, a default service composition is created that is based on the description of the XML configuration file. At the same time, a number of alternative reconfiguration service chain maps are also created. Each map is attached to an environment monitor, which regulates the time and conditions for the service reconfiguration to take place. When all the conditions monitored by a specific environment monitor are fulfilled, the current service composition will be reconfigured to the service chain map attached to that environment monitor.

Table 1 shows a portion of a configuration file, which contains the service composition reconfiguration description. Lines 2 to 17 specify the default service chain map for the WebPADS client initialization. Lines 3 to 8 describe the environment element which specifies that when the event called BandwidthChecker reports a value less than 5120 (which is used to report the current bandwidth of the network connection, in bps), then the chain map will come into effect. However, since a default chain map is constructed upon initialization of the WebPADS client, the conditions specified by this environment element are (initially) ignored. Only when the service composition is reconfigured into another chain map will the environment monitor of the default chain map come into effect, and the default chain map will behave in the same way as the other chain maps.

Table 1. Partial list of a configuration file, specifying service chains reconfigurations

  1. <RECONFIGURATION>
  2.     <CHAIN_MAP default="true">
  3.         <ENVIRONMENT>
  4.             <CONDITION>
  5.                 <EVENT> BandwidthChecker </EVENT>
  6.                 <RELATION operator="LESS_THAN"> 5120 </RELATION>
  7.             </CONDITION>
  8.         </ENVIRONMENT>
  9.          <CLIENT_CHAIN_MAP>
  10.              <MOBILET codebase="Service/" code="HttpRelayMaster.class">HttpRelayMaster</MOBILET>
  11.              <MOBILET codebase="Service/" code="CompressionMaster.class">CompressionMaster</MOBILET>
  12.         </CLIENT_CHAIN_MAP>
  13.         <SERVER_CHAIN_MAP>
  14.             <MOBILET codebase="Service/" code="HttpRelaySlave.class">HttpRelaySlave</MOBILET>
  15.              <MOBILET codebase="Service/" code="CompressionSlave.class">CompressionSlave</MOBILET>
  16.          </SERVER_CHAIN_MAP>
  17.     </CHAIN_MAP>
  18.      <CHAIN_MAP>
  19.         <ENVIRONMENT>
  20.             <CONDITION>
  21.                  <EVENT> BandwidthChecker </EVENT>
  22.                  <RELATION operator="GREATER_THAN"> 5120 </RELATION>
  23.              </CONDITION>
  24.              <CONDITION equivalent="true">
  25.                  <EVENT> WpsEvent1 </EVENT>
  26.                  <RELATION operator="EQUAL"> true </RELATION>
  27.              </CONDITION>
  28.              <CONDITION>
  29.                 <EVENT> WpsEvent2 </EVENT>
  30.                 <RELATION operator="NOT_EQUAL"> 1000 </RELATION>
  31.             </CONDITION>
    <!--it means:(BandwidthChecker>5120)OR((WpsEvent1==true)AND NOT(WpsEvent2==1000))-->
  32.         </ENVIRONMENT>
  33.         <CLIENT_CHAIN_MAP>
  34.             <MOBILET codebase="Service/" code="HttpRelayMaster.class">HttpRelayMaster</MOBILET>
  35.          </CLIENT_CHAIN_MAP>
  36.          <SERVER_CHAIN_MAP>
  37.              <MOBILET codebase="Service/" code="HttpRelaySlave.class">HttpRelaySlave</MOBILET>
  38.          </SERVER_CHAIN_MAP>
  39.      </CHAIN_MAP>
  40. </RECONFIGURATION>

Lines 18 to 39 show another chain map, which serves as an alternative reconfiguration chain map to the service composition. Lines 19 to 32 show the constitution of an environment element for this alternative reconfiguration chain map. This environment element indicates the activation conditions of this service are:

The equivalent representation is:

(BandwidthChecker > 5120) OR [(WpsEvent1 = true) AND NOT (WpsEvent2 = 1000)]

3.1.1 Service Deletion Synchronization

The deletion-addition process reconfigures the current service composition to match the description of the new service chain map. The service deletion process checks each mobilet in the current service composition against the new service chain map. Any mobilet that does not exist in the new service chain map is removed. To remove a pair of mobilets, a service deletion synchronization process is introduced to guarantee a smooth message flow. As there may be unprocessed messages in the message queues of a mobilet pair that is to be deleted, as well as messages in transit that are generated by this mobilet pair, such messages must be handled before the mobilet pair is destroyed; otherwise, data may be lost.

As shown in the example in Figure 5, to start the service deletion synchronization process, the client service controller commands the master mobilet B (referred to as mobilet B in the following discussion) to enter the half-delete state by sending the message SET_HALF_DELETE. At the same time, it also informs the server service controller to delete slave mobilet B' (referred as mobilet B' in the following discussion), which in turn takes the same steps as mobilet B.

Figure 5. Service deletion synchronization process

After finishing the onTerminate() method call, mobilet B returns a SERVICE_TERMINATE_READY message to the client service controller, which can then destroy mobilet B. Similarly, mobilet B' reports to the server service controller, which in turn informs the client service controller about the deletion of mobilet B'. At this point, the deletion of B and B' is completed.

As the service deletion synchronization process ensures data integrity and does not interfere with the operations of other mobilet pairs, deletions of multiple mobilet pairs can be carried out simultaneously. This means that the half-delete state and the onTerminate() method call of different mobilet pairs can overlap with each other to operate concurrently. Moreover, the service deletion synchronization process does not require a suspension of the service chain, which further minimizes the overhead during dynamic service reconfiguration.

3.1.2 Service Suspension

After all the unwanted mobilets have been removed, the service composition is suspended for service addition. The need for suspension arises because a new pair of mobilets have to be added to the service composition simultaneously. Otherwise, without the corresponding mobilet acting at the receiving end, the messages generated by the new mobilet will be meaningless. One thing worth noting is that, during suspension, a mobilet is still free to receive messages using its message queue, thus avoiding message loss and the blocking of other components.

3.1.3 Service Addition

The service addition takes place first at the WebPADS client side. The new service chain map will be used to check against the current service chain. Any newly required mobilets will be initialized, together with their new connectors, and then inserted into the current service chain. After completing the client side reconfiguration, the client service controller instructs the server service controller to carry out the corresponding service addition of the peer mobilets. Once the server service controller completes the service addition, it will resume the service chain operation and inform the client service controller to resume its service chain operation too. In which case, the execution threads of all the mobilets will be resumed, and service provision will recommence.

3.2 Mobilet Reconfiguration

Simply adding or removing mobilets to and from the service composition is not adequate for adapting to the changes in the wireless environment. To allow finer-grained adaptation, the WebPADS programming platform should allow reconfiguration at the individual mobilet level. To develop a reconfigurable mobilet, mobilet developers can extend the event system and environment monitor. They can subscribe a mobilet to an event and allow it to react to the event messages by adjusting its internal parameters to best adapt to the changes in the environment. An example is an image transcoding service that has different levels of compression ratio. It uses a different compression ratio based on the reported bandwidth from a bandwidth checking event source. Consequently, the image transcoding service can keep optimizing the transcoding performance for the varying bandwidth.

Table 2 shows the simplified pseudo code listing of the image transcoding mobilet pair. In this figure, line 1 to line 24 show that the ImageTranscodingMaster implements three methods of the mobilet base class, the onStart(), onResume() and messageHandler(). In the onStart() method, the mobilet master begins by subscribing to the BandwidthChecker event by registering with the WebPADS event service. This signals to the WebPADS runtime to generate the appropriate event message, EVENT_BANDWIDTH_CHANGED, whenever there is a change in the underlying wireless bandwidth. On subscribing to the event, the mobilet master acquires the bandwidth information from the system by accessing the BandwidthChecker handler and referencing to its primeValue. In the event when the mobilet is suspended and resumed, it may gather the most updated bandwidth information via the same handler, which is done in the onResume() method. Lines 20 to 23 show how the mobilet master reacts to the bandwidth change event, in the messageHandler() method. All three methods invoke the adaptBandwidth() method that translates the current bandwidth into a image-resize factor, which represents the extent of the dimensions of the images being resized.

Table 2. Pseudo-code of the image transcoding mobilet pair

  1. Class ImageTranscodingMaster inherits Mobilet {
  2.      Method adaptBandwidth (integer bandwidth) {
  3.           If the bandwidth is less than 100 kbps,
  4.                then set image-resize-factor to 0.5.
  5.           If the bandwidth is more than 100 kbps,
  6.                then set image-resize-factor t“o 0.75.
  7.           If the bandwidth is more than 1 Mbps,
  8.                then set image-resize-factor to 1.
  9.           send the message "CHANGE_RESIZE_FACTOR" to the slave mobilet to update the image-resize-factor.
  10.      }
  11.     Method onStart () {
  12.         Subscribe the BandwidthChecker event.
  13.         get the current bandwidth by reading BandwidthChecker.primeValue.
  14.         adapt the network bandwidth by calling adaptBandwidth(BandwidthChecker.primeValue).
  15.     }
  16.     Method onResume () {
  17.         get the updated bandwidth by reading BandwidthChecker.primeValue.
  18.         adapt the network bandwidth by calling adaptBandwidth(BandwidthChecker.primeValue).
  19.     }
  20.     Method messageHandler (WpsMessage message) {
  21.         If message.command equals "EVENT_BANDWIDTH_CHANGED",
  22.             then call adaptBandwidth(message.new-bandwidth).
  23.     }
  24. }
  25. Class ImageTranscodingSlave inherits Mobilet {
  26.     Method messageHandler (WpsMessage message) {
  27.         If message.command equals "CHANGE_RESIZE_FACTOR",
  28.             then set the image-resize-factor to the message.new-resize-factor, and exit this method.
  29.         If message.command equals "HTTP_RESPONSE", then {
  30.         If message.content-type equals "image/jpeg",
  31.             then convert the message.content-type to "image/gif".
  32.         If message.content-type equals "image/gif",
  33.             then convert the message.content to gray scale,
  34.             and scale down the image size using the image-resize-factor.
  35.         }
  36.         Pass the message to the next mobilet.
  37.     }
  38. }

Lines 25 to 38 of Table 2 show that the ImageTranscodingSlave mobilet which only implements the messageHandler() method, where all the logical processing are located. In this method, it can recognize the CHANGE_RESIZE_FACTOR message sent by its peer - the ImageTranscodingMaster, and adjust the image-resize-factor accordingly. The method is also responsible for processing HTTP_RESPONSE messages. If the message content is a JPEG or GIF image, the content will then be transcoded to grayscale GIF and the image dimension will be resized. Messages of other type are ignored and forwarded to the next mobilet. It is not the intention of this section to present a detailed implementation of the mobilet services; rather we want to give a high level overview of the pseudo-code and architecture. This overview demonstrates the benefits and ease of configuring and deploying mobilet services over WebPADS, in order to facilitate rapid development of augmented service operating over wireless Web environment.

Figure 6 shows the Web page of "http://www.polyu.edu.hk/its/" retrieved through direct Internet connection (top) and through the WebPADS system (bottom). The images in the Web page retrieved through the WebPADS system show lower resolution than those retrieved directly, which reflects the actions of the mobilets in image transcoding to reduce the data size. The image transcoding mobilet resizes the dimension of the images, but as the HTML code of the Web page enforces the images to be displayed with specific dimensions, the retrieved images are correspondingly enlarged to fit within the frame of the original size, such that lower image quality is observed.

Figure 6. A Web page retrieved through direct Internet connection (top) and through the WebPADS system (bottom)

4. Experimental Methodology and Test Bed

One of the major concerns about the WebPADS architecture is that it may lead to high computational overheads during various service provision stages. This may overshadow the advantages of the WebPADS system in providing dynamic service reconfiguration in a wireless Web environment. Realizing the importance of obtaining accurate measurements, we have conducted experiments that are based on a complete setup of the WebPADS system operating in an emulated wireless environment. Importantly, the complete setup provides us with the unique opportunity to truly exercise the interactions between the hardware and software within the WebPADS framework.

As shown in Figure 7, the setup includes the use of three PCs: one acts as the WebPADS server residing on the wired departmental LAN, a second acts as the mobile node and the third is configured to act as a wireless router to emulate a wireless operating environment. The WebPADS server and the Linux router are located on the same fixed LAN (158.132.11) within the campus network. Any requests to hosts outside the campus have to go through the transparent campus proxy server. The mobile node is connected to the second network interface of the Linux router using a different network identification (10.0.0).

The NIST Net network emulator [11] is a general-purpose tool for emulating performance dynamics in IP networks. The tool is designed to allow controlled and reproducible experiments with network performance adaptive applications and control protocols in a simple laboratory setting. By operating at the IP level, NIST Net can emulate the critical end-to-end performance characteristics imposed by various wide area network situations (e.g., congestion loss) or by various underlying sub-network technologies (e.g., the asymmetric bandwidth situations of xDSL and cable modems).

NIST Net is implemented as a kernel module extension to the Linux operating system and as an X Window System user interface application. The tool allows an inexpensive PC-based router to emulate numerous complex performance scenarios. These includes: tunable packet delay distributions, congestion and background loss, bandwidth limitation, and packet reordering and duplication.

Figure 7. Experimental setup for the WebPADS system

4.1 Experimental Results

To test the efficiency of dynamic service reconfiguration, a series of experiments have been conducted based on the experimental setup described in the previous section. In this section, we focus on the initialization time that is required for a WebPADS client to begin to serve a user once it has been invoked. Specifically, initialization time is measured as the time interval between a user invoking a WebPADS client and the time the user can actually start to use the service provided by the WebPADS client.

Dynamic reconfiguration aims to maximize the performance of Web access under a vigorously changing wireless environment. However, the reconfiguration process of service composition brings a certain amount of performance penalty that is unavoidable. It is important to justify the use of reconfiguration so that the operations overhead is comparatively insignificant to the performance gain in the reconfigured service composition. In this section, our focus is on the reconfiguration time and the suspension time. Reconfiguration time indicates the responsiveness to the environment. In particular, reconfiguration time is the time taken for the WebPADS system to adapt to the changes in the wireless environment. Suspension time is the duration for which all execution threads of the mobilets are paused, and the service provision of the service composition is temporarily suspended. In another word, suspension time is the amount of time that a user will find the WebPADS system inactive due to reconfiguration.

4.2 Reconfiguration and Suspension Time

In this experiment, we have a WebPADS server that has already started running, and at the Linux router the RTT between the WebPADS client and the WebPADS server is set to 100 ms. The WebPADS client is then started, which will set up a service composition by coordinating with the WebPADS server. Then the WebPADS client initiates the reconfiguration process, which is shown in Figure 4.

The reconfiguration process involves the following factors:

Thus the total reconfiguration time (T2) can be represented as:

T2 = 2 + max (m1, 2, ..., i, .., j) + 2 RTT ...(Equation 1)

In this experiment, since the tested mobilets are null mobilets[1], the deletion time of every mobilet is almost the same. A similar effect is seen for the addition time of every mobilet. Therefore, Equation 1 can be rewritten as:

T2 = 2kn + m + 2 RTT ...(Equation 2)

The service composition maintains the service provision throughout the whole dynamic reconfiguration process, except for the addition phase. Therefore, the suspension time (S2) is the time of the addition phase:

S2 = 2kn + RTT ...(Equation 3)

4.3 Measurement Analysis

As shown in Table 3, we have measured reconfiguration time under different bandwidths, for different mobilet sizes and different numbers of mobilets to be deleted and added. We tested the system under the bandwidth of 20 kbps, 50 kbps, 200 kbps and 1 Mbps. Mobilets with sizes of 5 KB are used.

In the experiment, the deletion time, addition time and total reconfiguration time are measured, which are shown in Table 3. Based on these three data items, we deduce the system overhead.

Table 3. Reconfiguration time under different bandwidth, with different number of mobilet deletion and addition

Bandwidth 20 kbit/s 50 kbit/s 200 kbit/s 1 Mbit/s
Reconfiguration [mobilets of 5 KB x (5 deletions + 5 additions)]
deletion time 0.903 0.711 0.618 0.570
addition time 0.522 0.437 0.390 0.376
System Overhead 0.448 0.341 0.329 0.258
Total time 1.873 1.489 1.337 1.204
Reconfiguration [mobilets of 5 KB x (2 deletions + 2 additions)]
deletion time 0.803 0.611 0.518 0.470
addition time 0.462 0.377 0.337 0.316
System Overhead 0.443 0.334 0.342 0.251
Total time 1.708 1.322 1.197 1.037


Figure 8. Cumulative time for reconfiguration for mobilets of 5 KB x (5 deletions + 5 additions)

Figure 9. Cumulative time for reconfiguration of mobilets of 5 KB x (2 deletions + 2 additions)

This experiment has two parts, and the results are plotted in Figures 10 and 11 corresponding to the following arrangements:

Figures 10 and 11 show that the reconfiguration time is relatively insensitive to variations in bandwidth. Such a characteristic is due to the fact that during the reconfiguration process, only a few control messages are exchanged over the network, and these messages are small in size. The measured system overhead is relatively constant between 21.4% and 28.5% of the overall reconfiguration time.

The service suspension time, which is represented by the service addition time, is between 0.522 seconds to 0.316 seconds. Such a short suspension time is barely noticeable by users.

4.3.1 Minimal Reconfiguration Time Interval

It is desirable to have the WebPADS system adapt to the changes in the environment as soon as possible. However, there are cases when a continuously changing environment leads to frequent service reconfigurations, which may affect the quality of service provision due to an extreme oscillation. To prevent this, an element in the configuration file specifies the minimal time interval between two consecutive service reconfigurations. Throughout the experiments, this minimal time interval is arbitrarily set to be a constant 10 seconds. The optimal value of this minimal time interval is highly dependent on the variability of the operating environment. If the interval is set too high, then this will make WebPADS unresponsive to the changing operating environment.

5. A CASE EXAMPLE USING WEBPADS

In this section, in order to demonstrate the use of the WebPADS framework, we now present a case example on the development of a set of HTTP mobilet services that exploits the benefits of the WebPADS framework, and to introduce augmented services for operating over a wireless environment. Experiments are carried out to investigate the efficiency of these HTTP services.

5.1 HTTP Relay Mobilets

To facilitate the development of mobilets that enhance wireless Web access, a pair of HTTP relay mobilets is developed to provide an augmented interface for accessing and manipulating HTTP request and response messages. The HttpRelayMaster mobilet and the HttpRelaySlave mobilet are a normal mobilet pair located at the two endpoints of a service composition serving HTTP connections (see Figure 10).

To test the service composition of the mobilets, as shown in Figure 10, two mobilets for HTTP services were also developed:

Figure 10. Service composition of HTTP mobilet services

5.2 Experimental Setup

One of the major concerns on the WebPADS architecture is that the advantages introduced by WebPADS might not justify the overheads incurred. Initial measurements were taken to investigate the overheads incurred by the architecture. Measurements were taken using three PCs. The WebPADS server and the Linux router were located at the same fixed LAN within the campus network. The Linux router is configured with a NIST Net network emulator to emulate wireless connections. The mobile node was connected to the second network interface of the Linux router using a different network ID. The mobile node also runs a script-controllable Java Web browser called the MiniBrowser, which was created solely for the purpose of this experiment. The MiniBrowser is HTTP/1.1 compatible, and behaves like a normal Web browser. Figure 11 shows the MiniBrowser in scripting mode, where it retrieves a list of scripted Web pages, together with all the embedded images, and logs the time taken.

Figure 11. MiniBrowser in scripting mode

The procedures of the experiment are as follows:

  1. A student is asked to achieve two tasks using a normal Web browser: First, find the current UV index in Hong Kong; Second, find the opening hours of the campus library and computer laboratories. The student can start from any Web page to find the desired information.
  2. The pages visited by the student are recorded and compiled into a list of sixteen URLs.
  3. This list of URLs is added to the MiniBrowser, which is set to retrieve the Web pages one by one, and the time taken for each page to download is recorded.
  4. The bandwidth of the NIST Net is set to 1 Mbps.
  5. The MiniBrowser is then scripted to retrieve the Web pages through the WebPADS proxy, which is configured with the HttpRelay mobilet pair and the text compression mobilet pair.
  6. Step 5 is repeated, but this time the image transcoding mobilet pair is added to the service composition.
  7. Step 5 is repeated again, but this time using a direct connection to the Internet, instead of using the WebPADS proxy server.
  8. Steps 5, 6 and 7 are repeated five times, so that the use of the WebPADS system is interleaved.
  9. Step 8 is repeated four times, but with the bandwidth of NIST Net set to 500 kbps, 100 kbps, and 50 kbps.
  10. Step 9 is repeated four times within two days, twice at 00:00 (midnight), when the Internet traffic is off-peak, and twice at 12:00 (noon), which is the peak hour of Internet traffic.

5.3 Measurement Analysis

Table 4 shows the measured time for retrieving the sixteen Web pages using WebPADS and using a direct Internet connection.

Table 4. The average total retrieval time (seconds)

  Direct
Connection
WebPADS with
text compression
WebPADS with text
compression and
image transcoding
1 Mbps 10.716 11.57 12.474
500 kbps 16.266 13.99 13.677
100 kbps 32.484 20.678 16.64
50 kbps 49.268 33.328 21.676

Figure 12. The average retrieval time of the sixteen URLs

Figure 12 shows the retrieval time of the direct Internet connection is fastest at 1 Mbps bandwidth. The reason is that the 1 Mbps connection is large enough so that bandwidth is not a limiting factor in the retrieval time. Therefore, optimization of the data transfer over the connection does not justify the system overhead caused by the layer of indirection added by the WebPADS system. As it turns out, image transcoding incurs the highest overhead at 1 Mbps bandwidth.

At 500 kbps, as the experiment starts to fully utilize the bandwidth, the optimization of data transfer by the WebPADS system starts to show its beneficial effect. The system overhead factor starts to diminish, so that the WebPADS system starts to perform better than a direct Internet connection. This means that the overheads created by the WebPADS system are becoming less significant for bandwidth under 500 kbps.

At 100 kbps and 50 kbps, the WebPADS setting with both text compression and image transcoding performs notably better. Under low bandwidth conditions, optimizing the data transfer is much more beneficial compared with other system resources, such as memory and CPU time.

6. CONCLUSIONS

In this paper, we describe the development of the dynamic service reconfiguration model, upon which the WebPADS system is built. The WebPADS system intercepts Web traffic at both ends of a wireless link; the Web traffic is then transformed and optimized for more efficient use of the wireless link. Services provided by the WebPADS system can be migrated from one WebPADS server to another located on a different network domain. This allows the system to track the mobility of the mobile node and to serve it continuously. Furthermore, the constituents of the services provided to any user can be dynamically reconfigured to adapt to vigorous changes in the characteristics of a wireless environment.

The complete framework has been successfully implemented using Java as the execution platform, which supports a highly portable system to operate across heterogeneous environments. The experiments conducted with the system have revealed promising results that demonstrate its robustness of dynamic service reconfiguration over a mobile environment. The results show that the overall reconfiguration time is relatively insensitive to bandwidth variations, and the system overhead is relatively constant between 21.4% and 28.5% (of the overall reconfiguration time). The service suspension time is also well below 0.6 seconds.

On the WebPADS system, a set of HTTP services was developed, which served as a fully functional example to verify the feasibility of the WebPADS framework. Interestingly, as noted in our experiments, the WebPADS system did not incur unnecessary overheads, and it is able to effectively mitigate the effects from the hostile characteristics of a wireless environment.

7. ACKNOWLEDGEMENTS

This project is jointly supported by The Hong Kong Polytechnic University Research Grant G-T 201 and the Departmental Research Grant 4-Z040 of Department of Computing.

8. REFERENCES

[1] WAP Forum, 2002. http://www.wapforum.org/

[2] H. Balakrishnan, V. Padmanabhan and R. Katz. "The Effects of Asymmetry on TCP Performance". Mobile Networks and Applications, 1999.

[3] C. E. Perkins. "Mobile networking in the Internet". Mobile Networks and Applications, vol. 3, 1998, pp. 319-334, 1998.

[4] B. Krishnamurthy and J. Rexford. Web protocols and practice: HTTP/1.1, networking protocols, caching, and traffic measurement. Addison-Wesley, Boston, 2001.

[5] R. Caceres and L. Iftode. "Improving the Performance of the Reliable Transport Protocols in Mobile Computing Environments". IEEE Journal on Selected Areas in Communications, 13(5), June 1994.

[6] H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni, R. Floyd, B. Housel and D, Lindquist. “Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express”. Proceedings of the third ACM/IEEE Conference on Mobile Computing and Networking (Mobicom97), September 26-30, 1997, The Palace of the Hungarian Academy of Sciences, Budapest, Hungary, 1997.

[7] S. N. Chuang, T. S. Chan and J. Cao. "Dynamic Service Composition for Wireless Web Access". Proceedings of the International Conference on Parallel Processing (ICPP 2002), 18-21 August 2002, Vancouver, British Columbia, Canada, 2002.

[8] S. N. Chuang, T. S. Chan and J. Cao. "An Active Framework Supporting Wireless Web Access". Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC2002), 17-21 March 2002, Orlando, Florida, U.S.A. pp. 630-634, vol. 2, 2002.

[9] M. Kojo, T. Alanko, M. Liljeberg and K. Raatikainen. Enhanced Communication Services for Mobile TCP/IP Networking. University of Helsinki, Department of Computer Science, Series of Publications C, No. C-1995-15. April 1995.

[10] B. Hausel and D. Lindquist. "WebExpress: A System for Optimizing Web Browsing in a Wireless Environment". Proceedings of the ACM International Conference on Mobile Computing and Networking (MobiCom96), Rye, New York, USA, November 1996.

[11] Nist Net, 2002. http://snad.ncsl.nist.gov/itg/nistnet/