Internetworking/Internetteknik is a 4 point course at the Dept. of Teleinformatics (IT).
Paper of Jean Louis Berthou (x99_jlb@e.kth.se)This paper gives an overview of the effect of the Wireless Application Protocol (WAP) Gateway on the end-to-end behavior experienced by a user of a mobile client when browsing Web pages from a Web server (supporting only access to HTML pages via HTTP) attached to the fixed Internet. Therefore, after having drawn a general overview of this protocol, we examine with more attention some problems that have to be treated by the gateway, that among these are for example the transformation from HTML to WML, the decoding/coding task as well as the protocol translation of HTTP to WSP. The information is based on the current WAP specifications available on the Wapforum.
The following informations are treated :
In the past ten years, one has seen an explosion of data communication. Further than the broad success of the Web, there has appeared a strong public desire for mobility. Host mobility is indeed becoming an important issue due to the recent proliferation of notebooks and palmtop computers, the development of wireless network interfaces, and the growth in global internetworking.
If connectivity has actually been achieved in the past years, mobile web surfing remains however disppointing due to long response times and excessive communication paths.
WAP, short for Wireless Application Protocol, is a collection of languages, tools and an infrastructure for implementing services for mobile phones that is now emerging in order to partly remedy to the problems addressed above while providing wireless internet-like services and information to handled devices with limited display and data capabilities, such as pagers, cell phones...
The WAP specifications are controlled and developed within the WAP Forum.
Unlike marketers claim, WAP does not bring the existing content of the Internet directly to the phone. Too many technical problems are still encountered when trying to perform this, indeed : first of all the Internet content is mainly written in the form of HTML pages that require fast connections, fast processors, large memories, large screens, audio output etc. However mobile phones such as those currently used nowadays have slow processors, very little memory, small and intermittent bandwith, small displays etc.
In the Internet World-Wide Web (WWW) architecture, applications and content are presented in standard formats, and are browsed by applications known as web browsers.
There are three classes of servers :
WAP uses special gateway proxies to convert data from HTTP to WAP, and vice versa, so that any conventional web server may be used as the document origin server with WAP. The programs in the web server are not directly programmed in WML but in standard HTML which is converted to WML by the proxy server. The proxy converts client's WAP requests into HTTP requests understood by the standard web server and then converts its output to WAP formats such as WML and WMLScript, and compresses them to packed binary for sending to the client. Beside our core problem, let us notice that gateway- and origin servers may be integrated into a single WAP server directly delivering WML data for WAP requests.
We will now deepen some more our description of WAP architecture in order to analyze the actual effects of the WAP Gateway on the mobile client.
The concept of WAP is very simple : it should allow to do limited Web surfing from a mobile client when getting news, information on sports, traffic and weather, restaurants or cinema. One may also be able to use some e-commerce transactions or banking services facilities (checking one's bank account or stocks quotes).
The basic model for WAP is that of the Web, namely a user makes a request for information using a URL (that may be presented to him as a hyperlink). The information is then retrieved and presented to that user. Thus, at either end of the WAP system is a user and a content. However WAP scenario differs from the classical Web scheme because the client device requests content through a Gateway and all communication takes place via this Gateway which retrieves the content, reformats it and returns it to the mobile device.
It was likely since the beginning of WAP's specification that this scenario using a gateway would be the initial embodiment of WAP since it had to be deployed parallely to existing industry standards.
Then, observing client-server communication, two situations can occur.
If the WAP server provides WAP content (WML) the WAP Gateway retrieves it directly from the web server. If the web server provides WWW content (such as HTML) a filter is used to translate the WWW content into WAP content (HTML to WML).
The WAP architecture follows the OSI layering model and consists of three major layers :
Each of the layers of the protocol stack is accessible by the layers above, as well as by other service applications. Different configurations are allowed with respect to the architecture depicted below.
WAP consists of wireless equivalents of HTTP and HTML. The HTTP-like component (WSP - Wireless Session Protocol) defines the communication protocol between the handled device and a server or Gateway. The HTML-like component (WML - Wireless Markup Language) defines new markup and scripting languages for displaying information to and interacting with the user. This component of the protocol is highly focused on the limited display size and limited input devices available on the small devices handled by the mobile client.
The application layer is mainly based on WAE whose main client interface consists of a micro-browser environment. There exists a Wireless Telephony Application (WTA) situated as the top most layer of the protocol stack as well.
WAE and WTA specify a markup language, a scripting language and a telephony interface. WAE consists of WML and WMLScript ; WTA is a separate, standalone function, out of the scope of our study : thus we will no refer to it anymore, all the more that the telephony features are much less mature than other aspects of WAP.
WML is the new markup language for WAP-WAE. It is the WAP equivalent of HTML. WML formalizes a concept of cards and desks as follows : since a WAP client is expected to have a limited display size, the basic display unit of WAP content is a "card" that can be thought as one screen of information or one part of a fill-in form. It is up to the client device to determine how to display the cards (e.g. using scrolling). Since several cards may be required for a single application or service, WAP defines a content file as a group of cards, called a "deck" ; when a deck is retrieved, the first card is automatically displayed unless otherwise specified in a refrence field of the URL.
WMLScript is the scripting language for WAP-WAE. It is the WAP equivalent of JavaScript. WMLScript is a high level language that allows a content provider to implement arbitrary functions that may be required by individual WML decks, for example, to verify form input prior to submtting it to a server. It is quite verbose and therefore makes transmission more efficient using a compression/compilation scheme.
WSP and WTLS are the session layer of the WAP architecture. They provide connection-based services to the application layer. Basically, a session is started, content is exchanged, and the session is later closed. Additionally, the session can be suspended and resumed.
WSP is the WAP equivalent of HTTP. Within both is the concept of request and reply. As with other layers in WAP, WSP specifies compression techniques to provide efficient transmission of the request and response. It also allows for negotiation of capabilities between client and server.
WTLS provides security using cryptographic techniques negotiated when the connection is established. It handles crypting, decrypting, user authentication and data integrity checking. WTLS is based on the fixed network Transport Layer Security Protocol (TLS) formerly Secure Sockets Layer (SSL).
Wireless Transport Protocol (WTP) is he WAP equivalent of TCP or UDP. It is responsible for packet segmentation and reassembly, and for acknowledgement/retransmission of packets.
We have described the global communication architecture of the WAP protocol. Its keystone appeared clearly as being the WAP Gateway so far, that is the interface between mobile client and origin server. Wherever it may be situated in the network ("physical" or distributed, "software" implementation) it always performs three main actions when the mobile client is browsing a HTML document. They are listed and described below.
Beside this, we must also point out that these actions only take place once achieved a negotiation between client and Gateway, at the beginning of the communication session. It is indeed performed at the WSP level, but has strong influence on the behavior experienced by the final user because it defines its environment, depending on its intrinsic hardware and software characteristics.
Then session is normally hold ; the gateway is in charged of keeping track the informations regarding the client : protocol versions and transactions abilities, technical features. Thanks to this information, it will be able to deliver the content retrieved from the server in a format matched to the client's characteristics.
HTTP is too inefficient for wireless use. The WAP Gateway was born of the whish to make things more efficient when implementing the same type of services. Therefore WAP uses a semantically equivalent with binary and compressed format, thus reducing the protocol overhead to a few bytes per request instead of up to hundreds of bytes.
The WAP gateway talks to the phone using the WAP protocol stack, and translates the requests it receives to normal HTTP in order to communicate with the server. Thus, the content providers can use any HTTP servers.
To be more precise, let us draw the timeline of a session initiated by the client : the mobile client establishes a WSP connection with the WAP Gateway (that is now in charge of the session and stores its characteristics) and requests a HTML content on the remote server. The WAP Gateway forwards this request but translates WSP to HTTP. Then the request accomplishes several hops and reaches the final server where the expected content is retrieved and a HTTP reply issued that is sent back to the WAP Gateway. Once the Gateway has received all the TCP packets, it can perform the remaining tasks (encoding...) and send the translated content to the client.
As we see, an important number of operations take place that may result in delays experienced by the mobile client.
WAP defines a new markup language, the Wireless Markup Language (WML), simpler and more stricly defined than HTML. It also defines a scripting language, WMLScript. To make things simpler for phones, it defines its own bitmap format : Wireless Bitmap (WBMP).
The biggest problem to be treated by the Gateway when it translates HTML into WML is to deliver a WML page that may have the same visual effect and information content as the original HTML document, without loss of sense or content. This is easier said than implemented since HTML is intended for large user facilities, whereas WML has to keep up with extremely limited facilities (especially concerning the limited size and colors of the screen).
As we said previously, a HTML page is therefore "fragmented" in a set of WML cards and decks that make it easier to manipulate by the final user. Ideally there should exist a bijection between HTML and WML : neither alteration of the initial content, nor introduction of new elements should be introduced by the WAP Gateway that only plays the role of a translator.
Another acute problem is the way images are handled by the translation, because they are the first element of the page's visual effect. WAP defines one official type of image that has to be supported by all implementations of the protocol : WBMP (Wireless BMP), not compressed and monochromatic. An image translated to WBMP will obviously lose some of its original effect but this is the only current proposed standard. A polychromatic support would of course greatly improve the "translation" but the standard is still to be developed.
An interesting illustration of WAP Gateway functionalites is given at the URL http://waptunnel.com/architecture.html. It is an excellent summary of the WAP Gateway features.
Waptunnel.com is a free service for bridging WAP-enabled devices to the web. Any WAP device including mobile phones can communicate via its tunnel to the web servers hosting HTML and WML content. Waptunnel.com will be launched in March 2000.
The aim of this paper was to perform an analysis of the mechanisms set in action when a WAP client is browsing HTML pages from a server supporting only HTTP. We described the main features, operations and an example of implementation of the WAP Gateway that is the keystone of the WAP protocol and should make it efficient. It is indeed designed to take advantage of the cumulative experiences of web technologies (HTML and HTTP) by eliminating the difficulties and improving the strong points ; it pays a particular attention to transmission times proper to handled devices and tries to save transmitted bits to achieve savings in roud-trip delay, using coding suited to wireless communication.
Thus, the WAP Gateway improves transmission delays ; dealing with end-to-end behaviour, it is also to notice that the Gateway is in charge of translating documents originally intended for the web to a form appropriate for handled devices. That is the reason why it conditions the success of WAP, since usability considerations may prime once overcome the technical problem : will the consumer, with expectations built up from traditional web surfing, accept the limited capability of WML decks ?
HTML : Hypertext Markup Language
HTTP : Hypertext Transfer Protocol
TLS : Transport Layer Security
URL : Unified Resource Locator
WAE : Wireless Application Environment
WAP : Wireless Application Protocol
WBMP : Wireless BMP
WDP : Wireless Datagram Protocol
WML : Wireless Markup Language
WMLScript : Wireless Markup Language Script
WSP : Wireless Session Protocol
WTA : Wireless Telephony Application
WTLS : Wireless Transport Layer Security
WTP : Wireless Transaction Protocol
WWW : World-Wide Web
Jerome H. Saltzer, David P. Reed, and David D. Clark.
End-to-End Arguments in System Design.
Second International Conference on Distributed Computing Systems
(April, 1981) pages 509-512. Published with minor changes in ACM
Transactions in Computer Systems 2, 4, November, 1984, pages
277-288. Reprinted in Craig Partridge, editor Innovations in
internetworking. Artech House, Norwood, MA, 1988, pages 195-206. ISBN
0-89006-337-0. Also scheduled to be reprinted in Amit Bhargava,
editor. Integrated broadband networks. Artech House, Boston,
1991. ISBN 0-89006-483-0.
URL : http://people.qualcomm.com/karn/library.html
Information on the WAP Gateway available on the Wapforum and especially sections 6.1 and 6.2 of
Wireless Application Protocol Architecture
Specification.
URL : http://www.wapforum.org
Diazrob, Wireless Application Protocol (WAP), 1998.
URL : http://wwwiit.edu/~diazrob/wap.html.
Information on the WAP Gateway available on the website of Waptunnel.com
URL : http://waptunnel.com