The Internet and mobile communication are revolutionizing software services and development. The wireless application protocol (WAP) forum proposed a series of protocols on wireless Internet data presentation and transmission. The WAP gateway is the key component standing between the mobile handset and web servers. Accessing the Internet using mobile phones becomes feasible through the WAP gateway. However, a lack of performance models and evaluation tools causes difficulties in analyzing the wireless applications and wireless gateway environment. This paper introduces our experience of turning an HTTP proxy server into a wireless Internet gateway.
Instead of building a WAP gateway from scratch, we transformed an HTTP proxy into a WAP gateway by modifying each of the two systems. The original HTTP proxy was designed and implemented by the object-oriented principles. The converted WAP gateway inherits the structure of HTTP proxy. To have a high-performance WAP gateway, we considered the following issues during the conversion process: (1) the interaction among major components, (2) the requirement of various applications, and (3) the consumption of resources.
Comparing the HTTP with the corresponding WAP wireless session protocol (WSP), the two major improvements of WSP are (1) coded headers, and (2) push operation supporting. WAP uses coded headers to reduce the amount of data that must be transmitted over the air interface. To translate the traditional HTTP requests and replies into the coded forms, a mapping table is required. Because our HTTP proxy server is designed with coded HTTP header to enhance the internal operation speed, by replacing the internal operation code with WSP header code, the mapping table is implemented. Following the newly announced WAP push protocols, the right information will be delivered to the handset on time. To support the push capability, we are analyzing the related protocols and propose a possible push operation sequence. To investigate the performance of the gateway, a WAP test-bed is under development.
The number of mobile phone holders has grown significantly in the past few years, and the trend will continue in the coming years. This implies that mobile phones will be a popular client system in the network. Facing such great demands, the WAP forum proposed a series of protocols that permit Internet access through mobile phones.
There are two possible ways to access the Internet in a WAP environment: the first way is based on WSP /HTTP exchange via a WAP gateway. The alternative is direct access over pure WSP. Although many WAP protocols have been finalized, some WAP gateway related protocols are still in development.
Instead of building a WAP gateway from scratch, we transformed an HTTP proxy into a WAP gateway by modifying each of the two. The coded header and push operation of WAP are two major improvements over HTTP.
WAP uses coded binary data to improve transmission efficiency. The header and content are compactly compiled. For the traditional HTTP network, the packet header is in string format. In order to adapt to the WAP network, encoding and decoding techniques are required. To translate the traditional HTTP requests and replies to the coded forms, a mapping table is required. Because our HTTP proxy server is designed with a coded HTTP header to enhance the internal operation speed, by replacing the internal operation code with WSP header code, the mapping table is implemented.
Push operations deliver the right information to the handset on time. To support the push capability, we are analyzing the related protocols and propose a possible push operation sequence. To investigate the performance of the gateway, a WAP test-bed is under development.
This paper addresses our experience on turning an HTTP proxy into a WAP gateway. Section 2 illustrates the operation sequences of an HTTP proxy and a WAP gateway. The converted gateway architecture is introduced. In Section 3, the push operation of a push proxy gateway (PPG) is proposed. Our test-bed structure is illustrated. Conclusion and future works are given in Section 4.
This section illustrates the structure of a WAP gateway. First, we describe the operation of the HTTP proxy and the WAP gateway. Then, the functionality of each module of the WAP gateway is introduced. Finally, the tasks involved in converting an HTTP proxy into a WAP gateway are discussed.
Because of the rapid growth of the Internet population, insufficient network bandwidth has become a major problem. HTTP proxy is the most effective and widely adopted mechanisms to shorten the response time.
Figure 1. Traditional HTTP Proxy operation.
Figure 1 shows the request and response sequence between a client and web sever through an HTTP proxy. The sequence is consisted of following six steps, as shown by the six labels in the figure.
In general, a WAP gateway is expected to complete three tasks: header translation, push operation, and content compilation. The header translation allows the client system to access Internet via a different protocol. The push operation allows the server to send the right information to the client. The content compiling compacts the data for low-bandwidth support.
To turn an HTTP proxy into a WAP gateway, header translation is the first task to be done. The push operation will be discussed in Section 3. Content compiling is not addressed in this paper.
In WAP, the WSP headers are defined in binary format, but the HTTP headers are in string type. In order to enable a handset to access the Internet Protocol (IP) network, translation of the coded WSP and traditional HTTP requests and replies is needed.
Figure 2. WAP Gateway operation sequence.
The operation sequence chain between a mobile phone and web server through a WAP gateway is shown in Figure 2, and the six steps listed here are shown as labels in the figure.
Notice that the WAP client side environment is different from that of traditional HTTP proxy. The network domain of client system in Figure 2 has been changed to WAP domain, and the protocol used between client and gateway is now WSP. Also, caching is an optional operation in the WAP gateway.
This subsection introduces the design and implementation of our WAP gateway. We have finished the header translation part, and the push operation part is designed and ready to be implemented. Thus, we focus the description on the header translation here. Figure 3 shows the our WAP gateway system architecture.
Figure 3. WAP gateway architecture.
The architecture is composed of six modules: Dispatch , State, Request Thread, Request Decode, Proxy Connection, and Reply Encode. The functionality of each module is as follows
When a client sends a request to our WAP gateway, the gateway establishes a socket connection and puts the socket into a listen queue. The dispatcher itself is a thread, and it keeps a server socket, which can get the socket connection. Then the dispatcher forwards the request by calling RunSet method to record the request's state and start the request thread module.
To allow the gateway to run smoothly even under busy conditions, we set the dispatcher with low priority. This means that CPU spends much more time on handling requests than dispatching them. The CPU can handle numerous input requests smoothly while dispatching fewer requests.
State module is implemented as an object-oriented class. The state binds the resources with the request. It puts the data-gram packet into a PushbackInputStream object from the standard JDK. The state module also handles the request thread, request line, request header, proxy connection, reply line, and reply header for client request tasks.
The major part of the request thread is a run method that accomplishes all tasks from receiving a client request to sending a reply.
These six tasks are part of the thread request module:
The request decoding module includes two parts: request line decoding and request header decoding. The request line parser gets the transaction ID (TID), PDU type, and uniform resource identifier (URI) of the request packet. Then it translates the PDU type to a string format by using a defined mapping table.
The request header parser gets the well-known header values and translates them to the string type header's names by using a defined mapping table. According to those values, the parser calls the corresponding method to get string type header's values.
The mapping table mentioned above can be found in WSP specifications.
After the WAP Gateway has decoded a request message, it must forward this request to the original Web server that holds the content. Thus, the WAP gateway connects the Web server using this proxy connection module. This module first gets the resource processed and bound in the state module. Then it connects to the Web server. Finally, the WAP gateway rewrites an HTTP request and sends to the Internet.
Another task of the proxy connection module is writing the response message to the client. When the WAP gateway receives the reply message from the Web server, the WAP gateway encodes the message for WSP adapting. Then, the proxy connection module writes the reply message to the session created by the WAP gateway and the client to finish the primary request.
The reply encoding module includes two parts: response status line encoding and response header encoding. The response status line parser gets the version, response status code, and reason of the reply packet. Then it encodes this information in a binary format by using a defined mapping table.
The response header parser gets the string type header's names and translates those to the well-known header values by using a defined mapping table. According to these values, the parser calls the corresponding method to get the binary format header's values.
The mapping table mentioned above can be found in the WAP WSP specifications.
The example below illustrates the translation of headers.
WSP coded data:
|01 40 25 68 74 74 70 3a 2f 2f 77 65 63 6f 2e 63 73 69 65 2e 66 6a 75 2e 65 64 75 2e 74 77 2f 69 6e 64 65 78 2e 77 6d 6c 81 ea 81 84 80 94 80 95 80 a1 80 9d a9 4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 33 62 65 74 61 00|
Decoded HTTP data:
.wap.wmlscriptc ,image/vnd.wap.wbmp ,image/gif
|WSP code||WSP Value(Hex.)||Filed Name||HTTP Value|
|(The following 37 bytes)
68 74 74 70 3a 2f 2f 77 65 63 6f 2e 63 73 69 65 2e 66 6a 75 2e 65 64 75 2e 74 77 2f 69 6e 64 65 78 2e 77 6d 6c
|4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 33 62 65 74 61 00||Header Value||Nokia-WAP-Toolkit/1.3beta.|
For this example, a WSP coded header is sent to the WAP gateway. Then the request decode module parses the data and translates them to an HTTP value by using a mapping table.
This subsection explains the current testing environment of our WAP gateway. This testing environment is part of the WAP test-bed.
In the client system, we use the Nokia WAP Toolkit 1.3beta, which simulates a mobile phone and supports WAP content development.
The Toolkit can send a request through two different paths: HTTP over TCP, and WSP over UDP. When using HTTP, the Toolkit connects directly to the Web server as a traditional Web connection. When using WSP via the GSM platform, the Toolkit is not a real phone set; thus UDP is chosen to simulate the WAP connection.
On the server side, we use the MS-IIS 4.0 Web server. We put WML/WML-Script contents on the server, and set MIME type to make the Web server aware of the content type. WML/WML-Script contents can be built using the Nokia WAP Toolkit or a pure text editor. The MIME type about WAP content type must follow WAP WSP specifications. The complete WAP test-bed structure is given in Section 3.2.
An HTTP proxy can be converted to a WAP gateway by adding some mechanisms, as shown in Figure 4.
Figure 4. HTTP Proxy working with WAP
On the client side, a header decoder and a header encoder for protocol translation are attached. On the server side, we add a content compiler for content compacting. When a WSP request is sent to an HTTP proxy, the header decoder converts the request to a normal HTTP one. Then the HTTP proxy does its regular work. After replying with an HTTP response, the content compiler compiles WML/WML-Script decks or cards. Before the reply is sent to the client, the header encoder translates the normal HTTP reply to a WSP reply.
This section proposes a possible push operation sequence and illustrates our test-bed structure in order to examine the performance of the gateway.
A push operation in WAP occurs when a push initiator transmits content to a mobile client. However, the push operation is not directly between the push initiator and the mobile client. The initiator is on the Internet, and the mobile client is in the WAP domain. Thus, the push proxy gateway (PPG) is needed.
The Internet-side PPG access protocol is called push access protocol (PAP ), which is on top of HTTP. The WAP-side over-the-air (OTA) delivery protocol on top of WSP is called push over-the-air protocol (Push OTA Protocol ). These two protocols define the required elements of the push operation.
The push operation sequence is shown in Figure 5:
Figure 5. Push operation with PPG.
Each step in the above push operation sequence is a required operation. This sequence omits the optional operation part from the WAP push specification.
In order to investigate the performance of our WAP gateway, a WAP test-bed is under development. The test-bed structure is illustrated in Figure 6.
Figure 6. WAP Test-bed
There are two major behaviors in the WAP test-bed: pull and push. In the pull condition, the pull event generator simulates a great number of clients and sends requests to gateway. Then gateway does its regular work and sends response packets to the packet filter. The packet filter records the information about packets such as amount of data. In the push condition, the push event driver starts a scheduled push delivery with push messages according to the subscriber list. After the gateway parses the push messages, the packets are sent to the packet filter. The packet filter classifies these packets and records the related information respectively. Finally, according to the recorded information, the statistic analysis is completed.
In this paper, we first convert the internal operation code of our HTTP proxy server to WSP header code and construct a WAP gateway. On the basis of this experience, it seems that turning an HTTP proxy server into a WAP gateway by adding some mechanisms is feasible. Next, a possible push operation sequence is proposed. Finally, the developing WAP test-bed is illustrated.
Now our WAP gateway can conduct protocol translation but it lacks the management and an estimation of running efficiency. Besides, the push operation part is not completed. For future work, we will (1) continue implementing the functionality of our WAP push gateway; (2) complete the WAP test-bed and investigate the gateway performance; (3) estimate the rationality of the proxy caching operation within a WAP gateway.