a Samsung Pentium III laptop at 600MHz that hosts a. Siemens I-Gate PCMCIA ... machines is the Linux. Mandrake 7.2 distribution with the Linux Kernel 2.2.17.
Enabling Mobile WAP Gateways using Mobile IP Stefan Aust, Nikolaus A. Fikouras and Carmelita Görg Department of Communication Networks (ComNets) Center for Information and Communication Technology (IKOM) University of Bremen, Kufsteiner Straße NW1, 28359 Bremen, Germany Ph.: + 49 421 218 3339, Fax: + 49 421 218 3601, email: {aust|niko|cg}@comnets.uni-bremen.de, http://www.mobileip.org ABSTRACT The Wireless Application Protocol (WAP) is a protocol stack with a focus on wireless environments designed to work optimally with all wireless bearers. However, WAP does not provide any considerations for any of its architectural components (Client, Server or Gateway) to be roaming between network operators and Internet administrative domains. In this study it is experimentally shown that mobile WAP Gateway can be realised with the help of Mobile IP. 1. INTRODUCTION The recent years have brought a proliferation of Internet services and mobile communications. Their integration has been identified as a very important milestone in the history of communication systems. There have been different approaches to this problem with the Wireless Application Protocol (WAP) receiving the most support from the manufacturer community. As mobility is becoming the watchword of modern civilisation it is becoming increasingly important for everyone and everything to be mobile [1]. Traditionally, communication infrastructure components such as routers, servers and WAP Gateways were considered strictly stationary. Now, this tradition too is being challenged. It is envisioned that in the future, mobile individuals might wish to host their own WAP Gateway in order to provide WAP services to themselves or those around them. Given the mobile property those individuals will roam between providers even across bearers while not interrupting active communications. Such functionality has not been foreseen in the standardisation of WAP. WAP has risen as a response to the inability of the Internet protocol (IP) [2] to dominate in wireless environments as it has in wireline environments. This was due to its lack of considerations for low bandwidth and high latency (thin) networks [3] as well as disregard for mobility management. WAP introduces a new protocol stack focused on wireless environments [4]. In order to best address the needs of the widest possible population of users WAP considers a range of current and future air interfaces (bearers). However, roaming between these bearers has not been addressed by WAP. The WAP architecture extends the client/server architecture by placing an additional entity called the WAP Gateway between the client and server [5]. The WAP Gateway is required to provide operator specific services as well as perform content and protocol
translation when the WAP Client is accessing an external WAP Server. In spite of the incompatibilities between the WAP and IP stacks, WAP relies on IP for packetisation and routing when the underlying bearer is IP capable. As such, if IP can be brought to provide mobility management then WAP could directly and seamlessly benefit from this. A solution to this problem can be provided with the Mobile IP. The Mobile IP is an extension of the basic Internet protocol design for Internet mobility management [6], [7]. Providing a functionality that resembles the postoffice forwarding service Mobile IP enables Internet mobile nodes to roam without compromising their permanent IP address and without loosing connectivity. Mobile IP was designed with the fundamental requirement of transparency to higher and lower layers [8]. In this manner and by taking advantage of WAP’s dependence on IP for packetisation and routing it has been shown that roaming services between providers and heterogeneous bearers can be transparently provided to WAP Clients with the help of Mobile IP [9]. This study goes one step further and experimentally shows that through Mobile IP even parts of the WAP infrastructure such as the WAP Gateway can be made mobile. That is, it will be experimentally shown that with the help of Mobile IP, ordinary WAP Gateways such as the “Kannel” WAP Gateway [10] can perform Internet roaming beyond the boundaries of a provider’s network while providing WAP services to WAP Clients without any further modification on the clients themselves. Realising mobile WAP Gateways opens the possibility for mobile terminals to host their own WAP Gateway. Apart from enabling private users to provide WAP services to those around them this development can have a significant impact on the security of mobile transactions. Currently, the security model supported by WAP for wireless data transmission, called Wireless Transport Layer Security (WTLS), requires that a WAP Gateway is involved between the client/server peers seeking a secure communication. Bypassing any third person may lead to a more efficient end-to-end security scheme. 2. WIRELESS APPLICATION PROTOCOL (WAP) The Wireless Application Protocol (WAP) is a protocol stack with a focus on wireless environments developed by the WAP Forum. Through wide manufacturer commitment representing more than 90% of the world market, WAP is considered the de facto standard for the
Internet model HTML / JavaScript
WAP layer model (Application Layer, WAE)
Other applications
(Session Layer, WSP)
HTTP (Transaction Layer, WTP)
TLS - SSL
(Security Layer, WTLS)
TCP/IP
(Transport Layer, WDP)
UDP/IP
Current and future mobile networks, e.g. GSM, IS-95, PDC, TETRA, UMTS etc.
Figure 1: Comparison between the Internet and WAP protocol stacks
presentation and delivery of wireless data on mobile phones [4]. Figure 1 shows the comparison between the Internet and WAP protocol stacks. The WAP protocol stack consists of five different layers optimised for low bandwidth communication links via mobile network systems [5]. In addition, WAP defines the Wireless Markup Language (WML) and WMLScript for mobile applications that address the limitations of small displays in mobile clients. WAP takes into consideration a range of current and future air interfaces (bearers) such as GSM (Global System for Mobile communications), GPRS (General Packet Radio Service), TETRA (Terrestrial Trunked Radio) and UMTS (Universal Mobile Telecommunications System). However, roaming considerations between heterogeneous bearers and network providers have not been addressed by WAP [9]. User interaction with the WAP Client is initiated through the WAP browser. All user requests are then relayed from the WAP Client to the WAP Gateway. The role of the WAP Gateway is presented in the following section. 3. THE WAP GATEWAY The WAP architecture introduces the WAP Gateway to the Internet client/server architecture [5]. The purpose of a WAP Gateway is to provide operator specific services or content and protocol translation between TCP/IP (Transport Control Protocol/Internet Protocol) and WAP. Figure 3 illustrates the WAP communication model. It is shown that the WAP Gateway receives all WAP Client requests while terminating the WAP communication. All requests are then relayed to the WAP Server through a separate TCP/IP communication between the WAP Gateway and the Server. The same model is also observed in the return path where the response is returned to the Client. The WAP Gateway is also required to perform binary compilation to the data received from the WAP Server in order to match the bandwidth limitations that are typical of mobile phone Request WAP
WAP Client
Response Mobile Network
WAP GW WAP Gateway
Request TCP/IP Response Internet
WAP Server Application Server
Figure 3: WAP communication model
networks. The existence of two different communications has been experimentally observed in this study and is presented in detail in later sections. In order to better comprehend the role of a WAP Gateway one needs to observe the protocol profile of a WAP communication illustrated in Figure 2. The presented scenario assumes a GSM WAP Client as GSM is the most popular WAP bearer. Dial-in access facilities are provided through a modem attached to the Remote Access Server (RAS). For link connectivity over GSM Circuit Switched Data (GSM-CSD) PPP (Point-to-Point Protocol) is required to establish, configure and test the data link connection. The Interworking Function (IWF) provides the modem functionality along with access to the Public Switched Telephone Network (PSTN) [11]. The WAP Gateway and the RAS server may be located within the intranet of the same network operator. However, it is possible for a WAP Client to select a WAP Gateway outside its operator’s network. In any case, communication between the entities presented in Figure 2 is based on Internet infrastructure. This can be derived by the presence of an IP layer in every protocol stack. Consequently, if mobility management can be provided transparently at the Internet layer then WAP can seamlessly and directly benefit from this. This can be managed through Mobile IP that is described in the following sections. WAE / App. WTP
WTP
UDP IP
IP
PPP GSM
IP
subnet
subnet
PPP
CSD-RF
CSD-RF
GSM WAP Client
Application
UDP IP
PSTN Circuit
PSTN Circuit
PSTN
subnet
RAS
Interworking Function
Remote Access Server
WAP
ISP
WAP GW
Internet
WAP Gateway
WAP Server WAP Server
TCP/IP
Figure 2: WAP communication protocol profile For the issue of switching between bearers while communicating, Mobile IP could be used in order to maintain a single point of attachment to the Internet after a switch between bearer systems or domain networks has been undertaken. That is, transferring a WAP communication between different bearer systems or domains, as the WAP Gateway is changing the network access, might require the mobility support by Mobile IP for IP based network systems. In the Internet suite each communication is identified by a 5-tuple that consists of the protocol type along with the respective sender and receiver Internet addresses and contains the port numbers. Should any of this information change during the course of a communication, then it would be unable to proceed. A change to this information might be imposed when a WAP Gateway roams between Internet administrative domains or when a WAP Gateway decides to switch between different bearer networks while communicating.
Moreover, the communication 5-tuple does not specify any requirements as far as the air interface is concerned. As such, a WAP Gateway that maintains different access interfaces such as GSM or WLAN has no power over which interfaces will be utilized for a given communication. However, each access interface may maintain QoS (Quality of Service) such as bandwidth, cost and jitter could be considered by determine the access interface for the WAP Gateway based on mobile user requirements.
IP Security (IPSec) become applicable and acquire particular importance. The investigation of new security schemes for mobile WAP Gateways as well as the impact of mobile WAP Gateways to the WAP security model is reserved as the subject of future research. In the following sections the investigated scenario along with the experimental tests undertaken is presented, followed by a presentation of the acquired results.
4. THE MOBILE INTERNET PROTOCOL The Internet Protocol (IP) was originally designed without any mobility support [2]. The routing mechanisms of IP assume that a terminal maintains a point of attachment to the Internet, indicated by its IP address. Should a mobile terminal change its point of attachment and move to a new location incompatible with its IP address, it would be unable to send or receive traffic. A solution to the problem of Internet mobility can be provided through the Mobile IP (MIP) [6], an extension of IP. MIP introduces three new network entities, namely the Home Agent (HA), Foreign Agent (FA) and mobile terminal [7]. Alternative MIP configurations may omit the FAs by distributing their functionality amongst the mobile terminal and the network infrastructure. Every mobile node such as a mobile WAP Gateway is permanently allocated an IP address in its home network where also the HA resides. For the mobile WAP Gateway, the home network is considered the Intranet of its operator. Every time that the mobile WAP Gateway moves, it is required to register its current point of attachment to the Internet with its HA. The most basic functionality of Mobile IP resembles the post-office forwarding service [8]. For every roaming WAP Gateway the HA is required to act as a proxy in the home network, intercept all incoming traffic either from a WAP Client or WAP Server and redirect it to the mobile WAP Gateway’s most recently registered location. As a result, the WAP Gateway can change its location while remaining reachable on a permanently allocated IP address and without having to interrupt active communications. When the mobile WAP Gateway is returning traffic it may bypass the HA ad send packets directly to the WAP Server or Client. It is noted that the transparent manner by which mobility management support is provided to WAP by Mobile IP does not require any further modifications to WAP Clients or Servers in order for them to access mobile WAP Gateways. An important advantage of realising mobile WAP Gateways is that it opens the way for mobile devices to host their own WAP Gateways. Enabling each subscriber to maintain her own WAP Gateway not only simplifies the WAP communication model by reducing it to plain client/sever but is especially important for providing secure communications. Excluding the operator owned WAP Gateway from the communication path renders obsolete the WAP security model, whereby the subscriber is required to trust the operator. In that case, existing Internet end-to-end security schemes such as Secure Socket Layer (SSL) or
5. EXPERIMENTAL SETUP The purpose of this study is to experimentally demonstrate that mobile WAP Gateways can be realised with the help of Mobile IP. For this, the topology illustrated in Figure 4 was constructed. The investigated topology is consisted of a RAS that is attached to a V. 90 compliant modem. This allows for a single WAP enabled mobile phone to dial-in and receive network connectivity through GSM Circuit Switched Data (GSM-CSD). The WAP Client used for the purposes of this investigation is a Siemens S-35 WAP enabled mobile phone with a standard Phone.Com WAP browser version 4.18c. The RAS is in turn connected with the WAP Server and WAP Gateway through an Intranet that has been provided with Fast Ethernet. On the Intranet are also attached a Mobile IP Home Agent (HA) and a Foreign Agent (FA), each managing its own IP administrative domain (IP network). Network connectivity in each of those networks is provided through two Siemens I-Gate IEEE 802.11b compliant access points. The WAP Gateway is a Samsung Pentium III laptop at 600MHz that hosts a
WAP Client
Mobile Network
PSTN/ ISDN
Modem
AP
HA
AP
FA
WAP GW
RAS
Intranet/ Internet
WAP Server
Figure 4: Experimental Setup Siemens I-Gate PCMCIA IEEE802.11b compliant interface and is in the position to roam between the access points and hence between the IP networks. All other machines are AMD Athlon Thunderbird at 800 MHz. The operating system on all machines is the Linux Mandrake 7.2 distribution with the Linux Kernel 2.2.17. The Mobile IP functionality has been provided with the Sun Microsystems Mobile IP implementation [12] while the WAP Gateway functionality was provided with Kannel WAP Gateway implementation [10]. The WAP Server is an Apache Web server [13] that hosts a simple WML (Wireless Markup Language) site illustrated in Figure 5. Network monitoring was performed with the ethereal network analyser [14]. The purpose of the experiments undertaken in this study is to show that the WAP architecture is not violated when WAP is integrated with Mobile IP. For this, two different scenarios where investigated. One in
Figure 5: Screen shot of the WML test site roaming and resides in the foreign network. The sequence of events of a single WAP communication was monitored as the WAP Client attempted to access a WML site on the WAP Server in both scenarios. These are presented in sequence graphs in the next section. 6. EXPERIMENTAL RESULTS For the purposes of this study two different scenarios were investigated. In the first scenario the mobile WAP Gateway was placed in the home network while the WAP Client initiated a request to access a WML site located on the WAP Server. In the second scenario the mobile WAP Gateway performs roaming and is located in the foreign network. As in the first scenario the WAP Client issues a request for the same WML site. The WML site conducted for the purposes of this study was kept very simple. A screenshot of how this site is displayed on the screen of a WAP Client can be seen in Figure 5. Its main attributes are that it maintains a size significantly smaller than 1400 octets which is the default Wireless Session Protocol (WSP) Service Data Unit (SDU) size and that it does not contain any further links reducing to a minimum the amount of data that needs to be downloaded to the WAP Client. The results of the investigated scenarios are presented in the form of sequence graphs. The first investigated scenario assumes that the mobile WAP Gateway is located in the home network. In that case, no intervention to routing is required by the HA which plainly routes packets to the mobile WAP Gateway. Figure 6 illustrates the data flow between the WAP Client and the WAP Server for the described scenario. In order to simplify the sequence graph the HA has been included twice. The arrows in the sequence graph represent the traffic exchanged between the WAP Client, RAS, Mobile IP Agents as well as the mobile WAP Gateway and the WAP Server as it was captured with the ethereal network analyser software. The sequence graph is divided into two main areas covered in the graphs with two different shades of grey. One of them presents the WAP packets exchanged between the WAP Client and mobile WAP Gateway while the other shows the TCP/IP packet exchange between the WAP Gateway and the WAP Server. This signifies that in every WAP transaction there are two communications that are terminated at the WAP Gateway where relay as well as translation between the two is performed.
In Figure 6 it can be seen that initially a WSP session is initiated by the WAP Client through the exchange of WSP/WTP (Wireless Session Protocol/Wireless Transport Protocol) Connect Request and Reply messages with the mobile WAP Gateway. Such messages are transported over the third transaction service class of the Wireless Transport Protocol (WTP) that requires for double acknowledgements [15]. As such, the WSP/WTP Connect Request is followed by a WSP/WTP Connect Reply which is “piggybacking” a WTP acknowledgment for the first message. Finally, the WSP/WTP Connect Reply is succeeded by an additional WTP acknowledgment which signifies the successful receipt of the reply by the WAP Client. Following the establishment of the WSP session the WAP Client issues a WSP/WTP Get message that contains the location of the requested WML site. Subsequently, the mobile WAP Gateway initiates a TCP/IP communication with the WAP Server. This is presented in the graph by the exchange of TCP synchronisation (SYN) messages. Once the TCP communication has been established HTTP (Hyper Text Transport Protocol) delivers the WML test site from the WAP Server to the Gateway. This transaction completes with the HTTP 200 OK message which contains the requested data as well as notifies the mobile WAP Gateway that the request to the WAP Server has been serviced. Following that, the mobile WAP Gateway returns the requested WML site to the WAP Client with a WSP/WTP Reply message. For this transaction the second WTP transaction service class is used that dictates single acknowledgements. As such, the WSP/WTP Reply message is followed by a single WTP acknowledgement. WAP Client
Home Agent
RAS (WTP+
WAP Gateway
Home Agent
WAP Server
WSP)
WSP C onnect ly ect Rep nn o C WSP WSP) (WTP+ (WTP+
WSP) WTP A CK (WTP+ WSP) WSP G et (TCP) S YN K YN, AC (TCP) S (TCP) A CK (HTTP /1.1) G et test. wml
Time
which the mobile WAP Gateway is within the home network and one in which the WAP Gateway is
CK (TCP) A OK .1) 200 (HTTP/1 (TCP) A C
K
eply WSP R WSP) (WTP+ (WTP+
WSP) WTP A CK K IN, AC (TCP) F (TCP) A
Legend:
CK
WTP+WSP Traffic (WAP Client / WAP Gateway) TCP Traffic (WAP Gateway / WAP Server)
Figure 6: Sequence graph of WAP communication with mobile WAP Gateway in home network
At this point the WSP session is completed, however the WAP Client does not issue a WSP Disconnect Request. For this reason the mobile WAP Gateway does not disconnect its TCP communication even thought the WAP Server abolishes its part of the communication with a TCP FIN message. Figure 7 illustrates the sequence graph for the second investigation scenario. It assumes that the mobile WAP Gateway is performing roaming and finds itself within a foreign network. In that case, according to Mobile IP, the HA is required to intercept all incoming traffic for the mobile WAP Gateway and redirect it to the corresponding FA. In turn, the FA delivers all traffic to the mobile WAP Gateway. In the return path, the mobile WAP gateway may bypass the HA and send traffic directly to WAP Server or Client. This behaviour can also be observed in the sequence graph. In order to reduce its complexity both Mobile IP agents (HA and FA) have been included twice. The first thing that can be observed in Figure 7 is that it illustrates the same sequence of events as Figure 6. The principal difference is that due to Mobile IP all messages directed to the mobile WAP Gateway have to be routed first through the HA and FA. An additional difference is that the WSP/WTP Connect Request is not succeeded by an immediate WSP/WTP Connect Reply rather by a plain WTP acknowledgement. In WTP it is WAP Client
Home Agent
RAS
Foreign Foreign WAP Agent Gateway Agent
(WTP+W SP) W SP C
Home Agent
onnec t
TP ACK SP) W (WTP+W (WTP+W
SP) W TP AC K
Reply nnect SP Co SP) W (WTP+W (WTP+W S (WTP+W P) WTP ACK SP) W SP Get
TP A SP) W (WTP+W
SP) W TP AC K
Time
(WTP+W
CK
(TCP) SYN
CK SYN, A (TCP) (TCP) A (HTTP CK /1.1) G et test .wml
CK (TCP) A 0 OK 1.1) 20 (HTTP/ (TCP) ACK
(WTP+
WSP)
WSP R
eply
(WTP+W SP) W TP A
CK
FIN (TCP)
, AC K
foreseen that if, for any reason, the WAP Gateway can not issue an immediate respond it has to transmit a WTP acknowledgement instead. This prohibits the WAP Client from repeating its request. As can be seen shortly after the second WTP acknowledgement the mobile WAP Gateway issues its WSP/WTP Connect Reply. In the experimental setup the WAP Gateway has demonstrated both behaviours (immediate or delayed responds) an equal number of times and in a random fashion. The exact reason that causes the Kannel WAP Gateway implementation [10] to stagger and avoid issuing an immediate respond is unknown. It is suspected that this effect may be accredited to internal processing or access to hard disk information which tends to be comparatively slow. Mobile IP introduces new overheads such as network layer hand-offs, triangle routing and tunneling that bring new challenges in the provision of quality of service (QoS), protocol performance as well as security and privacy. To consider QoS requirements there are several parameters that play an important role for the use of mobile WAP Gateways. The investigation of QoS parameters such as delay has been shown that is difficult to synchronize the network time with the mobile phone which is outside of the network system and disallow time synchronization. The QoS investigation of the network including the mobile WAP Gateway has been shown that there is no significant latency of data transmission when the mobile WAP gateway is still roaming between network access interfaces. In this case the mobile WAP Gateway supports WAP requests from the mobile phone and the response from the WAP Server without service or data interrupt. No service interrupt while the mobile WAP Gateway is roaming is essential for the use of such Gateways so there is no requirement for restart WAP services or WAP downloads. However, the mobile WAP Gateway supports the QoS requirements similar to generic WAP Gateways for mobile users. The experiment has been shown that mobile users can also use the mobile WAP Gateway by entering the Gateway settings into the mobile phone like IP address, port number and dialing number. The mobile WAP Gateway supports the user requests with the same QoS and provides Internet content to the mobile client without any quality loss. The results presented in this section have demonstrated that mobile WAP Gateways can be made feasible with the help of Mobile IP. The main attributes of this approach are that Mobile IP mobility management facilities are provided to the mobile WAP Gateway in a transparent fashion and no quality loss, so that no modification is required to the WAP Gateway software nor the WAP Clients or Servers need to modify in any way.
(TCP) A CK
Legend:
WTP+WSP Traffic (WAP Client / WAP Gateway) TCP Traffic (WAP Gateway / WAP Server)
Figure 7: Sequence graph of WAP communication with mobile WAP Gateway in foreign network
7. SUMMARY AND CONCLUSIONS In this study it has been shown that mobile WAP Gateways can be realised with the help of Mobile IP. In spite of the incompatibilities between the WAP and TCP/IP protocol stacks, WAP relies on IP infrastructure for packetisation and routing. As such, when Mobile IP is used to provide mobility management support to the
Internet layer then WAP can directly and seamlessly benefit from this. To prove the validity of this hypothesis an experimental topology was constructed and two distinct scenarios were investigated. The first scenario assumed that the mobile WAP Gateway was stationed in the home network while in the second scenario the mobile WAP Gateway was performing roaming and was positioned in a foreign network. It was determined that without any modifications to the WAP Client or Server it was possible for the WAP Client to retrieve through the roaming mobile WAP Gateway resources located in the WAP Server. REFERENCES [1] UMTS Report – An Investment Perspective. Durlacher Research Ltd. http://www.durlacher.com. June 2001. [2] Internet Engineering Task Force (IETF). http://www.ietf.org/rfc. [3] S. Dawkins, M. Kojo, V. Magret, N. Vaidya, “Long Thin Networks”, rfc2757, Internet Engineering Task Force, January 2000. [4] Wireless Application Protocol – WAP 2.0 Technical White Paper, WAP Forum, August 2001 http://www.wapforum.org [5] Wireless Application Protocol Architecture Specification, Version 12-July-2001, WAP Forum, http://www.wapforum.org/ [6] C. E. Perkins. IP Mobility Support. Request for Comment (Proposed Standard) 2002, Internet Engineering Task Force, 1996 October. [7] Charles E. Perkins, Mobile IP - Design Principles and Practices, Addison-Wesley Wireless Communications Series, 1998. [8] James D. Solomon, Mobile IP – The Internet Unplugged, Prentice Hall Series in Computer Networking and Distributed Systems, 1998. [9] D. Fritsch, N. A. Fikouras, and C. Görg. Enabling WAP Hand-offs between GSM and IEEE 802.11 bearers with Mobile IP. In Proceedings of the Fourth International Symposium on Wireless Personal Multimedia Communications (WPMC), Aalborg, Denmark, September 2001 [10] Kannel: Open Source WAP and SMS gateway. http://www.kannel.3glab.org [11] R. Ludwig and B. Rathonyi. Link Layer Enhancements for TCP/IP over GSM. In Proceedings of the Conference on Computer Communications (IEEE Infocom), New York, USA, March 1999. [12] Networking and Security Center Sun Microsystems Laboratories. Mobile IP. http://playground.sun.com. [13] Apache Server. Apache Software Foundation. URL: http://www.apache.org [14] G. Combs. ethereal - (version 0.8.19). URL: http://www.ethereal.com. [15] Wireless Application Protocol. Wireless Transmission Protocol (WTP). http://www.wapforum.org
