WAP Gateway

Written assignment in the course InternetWorking [2G1305] Thomas Pettersson

d95-tpe@nada.kth.se 2000-03-03

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

2(9) 2000-03-03

Contents
1 INTRODUCTION ___________________________________________________________________________ 3 2 WHAT IS WAP______________________________________________________________________________ 3 3 WAP GATEWAY ____________________________________________________________________________ 3 4 WAP LAYERS ______________________________________________________________________________ 4 4.1 WIRELESS APPLICATION ENVIRONMENT (WAE) __________________________________________________ 4 4.2 WIRELESS SESSION PROTOCOL (WSP) __________________________________________________________ 4 4.3 WIRELESS TRANSACTION PROTOCOL (WTP) _____________________________________________________ 5 5 WAP DEVICE - WAP GATEWAY _____________________________________________________________ 5 5.1 WSP PRIMITIVES __________________________________________________________________________ 5.1.1 S-Connect ____________________________________________________________________________ 5.1.2 S-Disconnect __________________________________________________________________________ 5.1.3 S-MethodInvoke _______________________________________________________________________ 5.1.4 S-MethodResult ________________________________________________________________________ 5.1.5 S-Suspend and S-Resume ________________________________________________________________ 5.1.6 Push facility __________________________________________________________________________ 5 5 5 6 6 6 6

6 WAP GATEWAY - WEB SERVER _____________________________________________________________ 7 7 THE WHOLE WAY__________________________________________________________________________ 7 8 END TO END ANALYSIS_____________________________________________________________________ 8 8.1 LANGUAGE CONVERSIONS ___________________________________________________________________ 8.2 SECURITY ISSUES __________________________________________________________________________ 8.3 DELIVERY GUARANTEES _____________________________________________________________________ 8.4 TIME ISSUES ______________________________________________________________________________ 8 8 8 8

9 CONCLUSIONS _____________________________________________________________________________ 9 10 REFERENCES _____________________________________________________________________________ 9

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

3(9) 2000-03-03

1 Introduction
Ever since Internet became accessible and popular with consumers the number of users have increased exponentially and the accessibility will just grow and become better and better. Nowadays people wish to surf the Internet whether or not they have a computer nearby. The WAP Forum, a consortium that was started by Ericsson, Nokia, Motorola and Phone.com (formerly Unwired Planet), is making this wish come true. Today most of the biggest telecommunication companies are members. The consortium's task and purpose is to control and develop the WAP specifications. To make the accessibility better and make it possible to build the Wireless communication upon already functioning technology, such as HTTP, a WAP gateway is introduced which purpose is to decode/encode the request/response from the WAP client and WWW server respectively. The job for the gateway is to interpret between the two languages HTML and WML. The gateway place is between the WAP client and the WWW server.

2 What is WAP
WAP (Wireless Application Protocol) is a protocol that makes it possible to surf the Internet from a cellular phone or other handheld wireless devices. Many of us that surf the Internet from home with a 56kbps modem thinks that is slow and a cell phone only uses 9.6kbps so WAP have to take the lesser bandwidth into consideration. Some other disadvantages are the small display that a web page has to fit into, in the cell phone, and the few buttons to interact with. It's not possible to achieve a HTML page directly to the cell phone, it wouldn't fit and the download time should be too long and costly.

3 WAP Gateway
The WAP Forum solves the problems with the small display and the narrow bandwidth by introducing a gateway between the cell phone and the WWW server. The cell phone can't communicate with a WWW server directly but instead it goes through a gateway that decodes the requests from the cell phone and encodes the answers to the cell phone. The gateway talks to the WWW server and delivers the answer to the cell phone. The language the micro browsers in the cell phones understand is WML (Wireless Markup Language) so the gateway's job is to translate the HTML response from the web server to a WML response and send the answer to the phone. WML is pretty similar to HTML but with many restrictions because of the limited display and bandwidth. By using a WAP gateway instead of communicating with a WAP server directly increases the usability though all pages in HTML-format can be accessed without being converted to WML-format. The pages is being converted in the gateway but the responsible people for the web server doesn't need to write all the HTML pages in WML format also. This will probably speed the deployment and industry-acceptance of WAP.

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

4(9) 2000-03-03

4 WAP Layers
The WAP architecture follows the OSI layering model and consists of five layers but I will only discuss the three top most layers here. These layers are the Application Layer (WAE), the Session Layer (WSP) and the Transaction Layer (WTP) (protocols abbreviations in parenthesis).

Figure1. WAP architecture

4.1 Wireless Application Environment (WAE)

WAE is the top most layer in the WAP architecture. The WAEs main purpose is to establish an interoperable environment that will allow operators and service providers to build applications and services that can reach a wide variety of different wireless platforms in an efficient and useful manner. WAE includes the micro browser that is used to interact with the rest of the world. The browser should contain the following functionality: The micro browser should understand Wireless Markup Language (WML) - a markup language similar to HTML but with less functionality and optimised for handheld devices. WMLScript - a Script language similar to JavaScript but with less complexity. Wireless Telephony Application (WTA) - telephony services and programming interfaces. Content Formats - a set of well-defined data formats which includes images, phone book records and calendar information among other things.

4.2 Wireless Session Protocol (WSP)

WSP provide connection-based services to the application layer. Basically a session is started, content is exchanged and later on the session is closed. The session can also be suspended and resumed but for now we just look at the simple case with no suspensions or resumes. WSP is the WAP equivalent of HTTP and is based on HTTP/1.1. Within WSP (and HTTP) is the concept of a request and a reply, each consisting of a header and body. The header is metadata and consists of name-value pairs that specify information about the particular request or response. The body is the payload for the WAE and typically consists of tokenised WML, compiled WMLScript or images but can also contain raw WML text. WSP also defines a server "push" transaction where the server can send information to the client without the client requesting it. This may be used for broadcast messages or for real-time services such as stock quotes or news headlines. WSP as with other WAP layers specifies compression techniques to provide efficient transmission for the request and response. Some of the primitives that are supported by WSP are discussed later in this paper, under section 5.1 WSP Primitives.

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

5(9) 2000-03-03

4.3 Wireless Transaction Protocol (WTP)

WTP is the WAP equivalent of TCP or UDP. WTP operates efficiently over secure or non-secure wireless datagram networks. When the connection is unreliable WSP is responsible for retransmission to make the connection reliable. WTP is responsible for packet segmentation and reassembly and for acknowledgment of packets and retransmission of lost, unacknowledged or corrupt packets. WTP numbers packets so that a retransmitted packet is not mistaken for a new packet, which would cause duplication.

5 WAP device - WAP gateway

First of all we have to be able to connect and disconnect to the gateway. That is the first step for us to retrieve information from an origin web server.

5.1 WSP Primitives

So, what do a mobile device have to do, to be able to connect to the WAP gateway, communicate and finally disconnect from it. The client uses a set of primitives, which is sent in a certain order. A few of them are discussed briefly in this section. 5.1.1 S-Connect S-Connect is a primitive that is used to initiate session establishment and to notify of its success. It also provides one-way capability negotiation with the client being the initiator and the server being the responder. The primitive contains, among other things, the server and client address that identifies the peer and the originator respectively of the current session. A successful session establishments timeline can look like it does in Figure 2.
Client S-Connect.req S-Connect.ind S-Connect.res S-Connect.cnf Gateway

Figure 2. A successful session establishment

1. 2. 3.

A S-Connect request from the client, i.e. the mobile device. The server i.e. WAP gateway examines the request and returns a result, hopefully an acknowledgement of a successful establishment. The client receives the acknowledgement and can begin to send Method Invoke requests (i.e. ask for web pages or other information), discussed in 5.1.3. The client can begin to request information before it receives an acknowledgement for the session establishment but if there is a failure in the establishment some cleaning in the cache has to be done.

This is all it is to it, but the real fun stuff starts when we also have a connection from the gateway to a web server, but first we take a look at the timeline for the disconnection. 5.1.2 S-Disconnect There is another primitive called S-Disconnect that is used when either of the sides wants to close the session. Before the disconnect indication, the session service provider must abort all incomplete method and push transactions. After the indication further primitives associated with the session must not occur. A disconnect indication generated by the service provider can occur at any time during the session. The service user must be prepared for the session being disconnected at any time. If it wishes to continue communication, it has to establish the session again and retry the method invocations that may have been aborted. The S-Disconnect induction is received either when a connection is refused or when a connection is closed by the gateway.

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

6(9) 2000-03-03

5.1.3 S-MethodInvoke This primitive is used to request an operation to be executed by the server. It can only be used together with another primitive, namely S-MethodResult. The S-MethodInvoke consists of, among other things, identification numbers for the client and server to distinguish between pending transactions. Another information the primitive contains is what kind of method the client wants to invoke on the server: either an HTTP method or one of the extension methods established during capability negotiation. The S-MethodInvoke request is sent and when a confirmation is received from the server the client waits for the requested data. The data is received in a primitive called S-MethodResult. 5.1.4 S-MethodResult This primitive is used to return a response to an operation request made by a preceding SMethodInvoke request. The S-MethodResult primitive consists of identification numbers that must match the corresponding S-MethodInvoke primitive. This can be and is used to distinguish between pending transactions. A complete transaction consists of the primitives ordered as in figure 3.
Client S-MethodInvoke.req S-MethodInvoke.ind S-MethodINvoke.res S-MethodInvoke.cnf S-MethodResult.ind S-MethodResult.res S-MethodResult.cnf S-MethodResult.req Gateway

Figure 3. A complete transaction

If one or other reason aborts a transaction, an S-MethodAbort.indication will be delivered to the service user. If this happens no further primitives related to the transaction can occur. 5.1.5 S-Suspend and S-Resume These primitives work together but only in the obvious order: S-Suspend before s-Resume. A suspension typically would be requested when the client know it will not be able to respond to data pushes. The suspension can be broken either by a S-Resume or a S-Disconnect. 5.1.6 Push facility There is several primitives that handle the server push function, used for pushing unrequested data from the server to the client, but no further discussion about them is taken here.

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

7(9) 2000-03-03

6 WAP Gateway - Web server

Now we can establish a connection to the WAP gateway from the WAP device, but the gateway also have to talk to the origin web server for us to get the information we want. This communication is done as in the ordinary World Wide Web (WWW) model. Version 1.1 of HTTP can handle multiple requests in one and the same session that is an improvement from version 1.0 where only one transaction can be executed per session. For example, a HTML page with <img>-tags must establish a new connection for every image the browser want to retrieve, in HTTP/1.0. Here is an example of a communication in HTTP/1.0. 1. The gateway sends a connection request to the http port (i.e. 80) on the server. 2. The server responds to the connect request with a connect response. 3. The gateway acknowledges this response and sends the first bytes of the real request. 4. The server acknowledges the first part of the request, but doesn't send any data yet. 5. The gateway can send the a couple of more request before receiving a response from the server, so it sends two more request and is done, now the gateway just have to wait. 6. The server acknowledges the second and third request and sends the first real data that has been requested. 7. For every data the gateway receives it sends an acknowledgement or it can wait for a couple of packets and acknowledge them all in one message. 8. The server sends the rest of the data in as many packets that is needed and the final packet contains a flag indicating that the connection is being closed. 9. The gateway acknowledges the data and sends a message announcing that it too is closing the connection. 10. The server acknowledges the close. Step 1-3 is called a three-way handshake. The gateway sends a connection request, the server responds and finally the client acknowledges the response. In HTTP/1.0 this connection establishment and the disconnection (step 9-10) have to be done for every transaction and this cost extra time.

7 The whole way

Now we know how to establish a connection from the mobile device to the gateway, and from the gateway further on to a web server. If we put all this together we have a connection from a WAP device to a web server and the WAP device can retrieve information to its display from the www server. How this is done we take a closer look at in this section. First of all we must have a connection between the mobile device (i.e. cell phone) and the WWW server via a WAP gateway. This connection is done in two steps, first with a S-Connect request from the cell phone to the gateway and then a connection from the gateway to the server; the latter is done in an ordinary TCP/IP way. When we now have a connection the cell phone can start sending SMethodInvoke primitives and retrieve data from the WWW server. Between the WWW server and the cell phone the WAP gateway decodes the requests from the client and encodes the responses to the client. This encoding and decoding made by the gateway is not the cell phone aware of, despite the extra long response time.

Figure 4. The WAP model

When all information is retrieved the client sends a S-Disconnect primitive and the connection is closed from the clients point of view. The gateway continues to close its connection to the WWW server.

http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

8(9) 2000-03-03

8 End-to-end analysis
The WAP user does not need to be aware of the WAP gateway between itself and the WWW server. From the users point of view he or she has a direct connection from the wireless mobile device to the WWW server. In this section I will discuss the end-to-end behaviour experienced by a user of a mobile client when browsing web pages from a Web server via a WAP gateway. While the user surfs the Internet and encounter problems, such as missing information or bad data rate, the user, in an end-to-end discussion, only complain at the WWW server though he is not aware of the gateway. Without the gateway, as an interpreter, between the two endpoints there should not be possible to communicate at all because they do not understand the same language. The WWW server understands HTML while the WAP client talks WML. So how is the conversion done?

8.1 Language conversions

Today there are only a few gateways that are able to do the conversion and there are a few problems. The fact that HTML is a kind of non-standard language, due the fact that third part developers (Netscape and Microsoft) has implemented tags that only is supported in their own software/webbrowsers (Netscape and Explorer respectively), is a big problem in the conversion part. The HTML language is a much bigger language than WML and not all tags in HTML have a meaning in WML. How should we for example handle frames? Different wireless devices have different kinds of terminals and different interactive possibilities. By sending information about the client possibilities with the URL request the gateway can convert the HTML page to a WML page that suites the specific client. This will lead to more complexity in the WAP gateway and every client will not be supported by every gateway. Another problem is the fact that a HTML page is designed for desktop computers (or other devices with a relatively big screen) and assumes a greater bandwidth than 9.6kbps. This means that a HTML page may consist of long texts and different kinds of image types. These pages are almost impossible to display on a small display without loosing significant information and/or the structure that you can experience on a big screen. For the moment the only image type that WML support is WBMP (Wireless Bitmap) in a monochromatic manner. Image types in a HTML page such as GIF or JPG is very hard (read impossible) to display in a cell phone display with an accurate and desired result.

8.2 Security issues

If we have a secure transmission between the two endpoints, does this mean that we have a secure transmission the whole way? In the WAP gateway the packet has to be unpacked and here we may have a security leak. It is obvious that security issues have to be taken care of in the gateway to ensure a secure transmission in the end-to-end system.

8.3 Delivery guarantees

The packets requested by the client he or she want to be delivered correctly and with all information there is to it. WTP is responsible for making this happened on the clients side of the gateway. On the other side TCP is the responsible protocol as in the ordinary WWW model. Every transaction has an identification number that are used for control of duplicate packets. The delivery guarantees are also limited to the type of bearer network. When I have discussed clients in this paper I often have assumed that GSM is the bearer and a cell phone is the mobile device. As we all now GSM is not a foolproof medium, not even for voice, so how good quality can we expect?

8.4 Time issues

The extra time it takes for the gateway to interpret between the two languages, WML and HTML, is also the extra time the client has to wait for a response to his request. Although the bandwidth today only is 9.6kbps the conversion time will not be a bottleneck.

8.5 Summary
As a summary of the effect that the WAP gateway has on the end-to-end behaviour, between the client and the origin server, we can conclude that it will take some extra time to receive the information you have requested due the translation which has to be done, but without the gateway you should not be able to surf web pages from a web server that only supports HTML pages via HTTP. Other issues are delivery reliability and the security. http://www.d.kth.se/~d95tpe/school/wap.pdf

Written assignment in the course InternetWorking [2G1305], VT00 Thomas Pettersson, d95-tpe@nada.kth.se

9(9) 2000-03-03

9 Conclusions
For the WAP to be a real hit the cost of mobile phoning must decrease otherwise the customers cannot afford it and therefore don't use it. The real problem today, I have heard from people that have tried it, are the establishment of a connection. When you finally get a connection the service is quite good due the fact that you only got 9.6kbps to play with and the bearer is GSM. There are still problems in converting HTML to WML and the development will continue but it is a nice idea to build WAP upon existing Internet standards and that will probably speed the deployment and industry-acceptance of WAP. So far there is not so many WAP servers or WAP gateways but we have only seen the beginning of the WAP era.

10 References
Saltzer J.H, Reed D.P, Clark D.D. End-to-end Arguments in System Design. URL: http://web.mit.edu/Saltzer/www/publications/ [printed 2 Feb 2000] Wireless Application Protocol Forum. Apri1 998. Wireless Application Protocol Architecture Specification. URL: http://www.wapforum.org/ [Version 30-Apr-1998] Wireless Application Protocol Forum. Apri1 998. Wireless Application Environment Overview. URL: http://www.wapforum.org/ [Version 04-Nov-1999] Wireless Application Protocol Forum. Apri1 1998. Wireless Transport Layer Security Protocol. URL: http://www.wapforum.org/ [Version 11-Jun-1999] Wireless Application Protocol Forum. Apri1 1998. Wireless Session Protocol. URL: http://www.wapforum.org/ [Version 05-Nov-1999]

http://www.d.kth.se/~d95tpe/school/wap.pdf