by Tobias Eidem, e96_tei@e.kth.se
This paper deals with ”the effect of the WAP
(Wireless Application Protocol) 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.” The purpose of this paper is really to point out what role the WAP
Gateway has to the end-to-end behaviour of a WAP network. To be able to understand
these issues we must have a pretty good knowledge of what WAP really is, what
end-to-end behaviour is about, and what happens when browsing web pages from a
web server on a mobile WAP client. First we look a little bit on what WAP is.
WAP is a set of protocols that has inherited
its functionality and characteristics from the existing standards in the
wireless and Internet area. The WAP standard was created because the world’s
leading companies in the business of telecommunication saw the need for a
global standard for wireless communication with extended services on a small
handheld device. WAP combines two techniques; wireless communication and the
Internet. Since the Internet was built for stationary computers, WAP has to
deal with the fact that wireless devices, has much lower clock frequencies,
less memory (both primary and secondary) compared to stationary computers, and
their connections has lower bandwidth and less stability. Therefor WAP has its
own sets of protocols (instead of using the existing protocols like TCP/IP),
that should be able to cope with these problems, which leads us to the WAP
architecture.
Following here is a brief summary of the WAP
architecture. For a more complete description of the different parts, please
visit the WAP specification suite at WAP Forum (http://wapforum.org). Created
with the OSI model (Open System Interconnection model) in mind, WAP is designed
to be scalable, flexible and extensible. The WAP-stack is divided into six
different layers:
Wireless Application Environment (WAE)
WAE is based on a combination of Mobile
Telephony and World Wide Web technologies. Its task is to establish an
interoperable environment that allows service providers and operators to build
different kinds of useful applications and services that can reach a lot of
different wireless platforms. WAE also includes a micro-browser environment
that contains the following parts:
*WML (Wireless Markup Language) - a markup
language quite similar to HTML. WML is an XML application.
*WMLScript - a scripting language that is a
JAVAScript derivate. The code must be precompiled to run a WMLScript, and WML
doesn’t contain WMLScript, just references to WMLScript URLs.
*WTA, WTAI (Wireless Telephony Aplication) -
programming interfaces and telephony services.
*Content Formats- Images,calendar information,
phone book records and more in well-defined data formats.
Wireless Session Protocol (WSP)
This layer offers mainly two session services;
connection session and connectionless session. The connectionless session is a
thin layer that WAE uses when there’s no need
for reliable delivery of messages. The most important task of the
connection mode of WSP is to set up a session between a wireless client and the
WAP Gateway. This session handles communication interrupts and capability
negotiation. It can be suspended and later resumed, as opposed to being
disconnected when no connection is needed for a while. This lessens the traffic
load since no new capability negotiation will be needed when the session is
resumed. It also supports asynchronous handling of requests. WSP’s equivalent
in the Internet environment is HTTP.
Wireless Transaction Protocol (WTP)
WTP provides a light-weight
transaction-oriented protocol that is suitable for mobile clients. It runs on
top of a datagram service and operates both on non-secure and secure wireless
datagram networks and provides asynchronous transactions, three classes of
transaction service, and more. The equivalent of WTP in the Internet
environment is HTTP.
Wireless Transport Layer Security (WTLS)
WTLS is based on the industry-standard TLS
(Transport Layer Security) protocol, is optimised for use over narrow-band
communication channels and is intended to be used with the WAP transport
protocols. It features authentication, privacy, data integrity and more.
WTLS can also be used for secure
communication between terminals, for
example authentication of electronic business card exchange.TLS’ equivalent in
the Internet environment is TLS, formerly known as SSL.
Wireless Datagram Protocol (WDP)
WDP operates above the data capable bearer
services and offers a consistent service to the upper layer protocols in the
WAP architecture and communicate transparent over one of the available bearer
services. WDP’s equivalent in the Internet environment is TCP/IP.
Wireless bearers. The WAP protocol suite is
designed to operate over a variety of bearer services, like SMS, CDMA, CSD and
more. Each bearer offers its own level of quality of service with respect to
delays, throughput and error rate. The WAP protocol suite is of course designed
to tolerate or compensate for these
differing levels of service.
So now we know a little more about the WAP
protocol suite. Let’s take a look at the core of the WAP network, the WAP
Gateway.
The WAP Gateway is a device for converting the
TCP/IP protocols to the different WAP protocols and vice versa. It is able to
translate HTML to WML. The WAP Gateway is often a proxy server, meaning that it
acts both as server and client for the purpose of making requests on behalf of
other clients. In this case it resides between WAP clients and web servers
often supporting only access to HTML pages via HTTP. These clients and servers
have no means of direct communication, which is really the whole problem with
the WAP technology. For instance the gateway will lie behind a firewall, that
is, the same as the web servers, but there is no firewall that protects the
area between the WAP client and the gateway. There are solutions where the
gateway is an origin server. That is probably a more convenient solution,
though it’s not the issue that should be discussed in this paper.
The end-to-end concept is dealing with choosing
the proper boundaries for functions. That could mean figuring out where to for
instance put the translation of HTML to WML in a WAP network. The end-to-end
effect of a specific device in a certain system simply means: how will this
device have an effect on the whole system, and specifically on the systems two
terminal points.
Imagine a simple WAP network, with a web server
supporting only access to HTML pages via HTTP, a WAP Gateway, and a WAP client.
The WAP client wants to browse some pages lying on the web server. The wap
client sends a simple WSP request that is translated to a GET or POST request
(in this case an HTTP GET URL) at the gateway. The gateway usually has an built
in browser, sometimes called a web wrapper, that browses the requested page and
gathers the corresponding HTML document from the web server. The gateway then
converts the HTML document to WML, caches the page and sends it to the WAP
client in binary form.
So that’s briefly what happens. Now let’s take
a look at the issues we should deal with, namely how the gateway affects the
end-to-end performance of the network. To start with we could look at some
problems.
There are some obvious places where things
could go wrong during this procedure:
1.The connection between the client and gateway
may be lost or eavesdropped..
2.The gateway could translate from HTML to WML
incorrectly or have other errors, both in hardware and in software.
3.A packet may be lost, altered or delivered to
many times to (for example) the client.
4.The different systems could go down during a
transaction.
5.The gateway could experience an overload,
thus making the WAP network slow.
So what can be done about these things? In the
next section we will look at how some of these problems are handled.
1. With the help of WTSL it is possible to
encrypt the data transferred between the WAP client and the WAP Gateway.
Encryption is of course possible also between the gateway and web server. The
data will be decrypted while processed in the gateway, so it will be vulnerable
while it’s there, but it would be pretty hard to eavesdrop the connection.
There should be some kind of guarantee that the gateway is reliable, that is,
it should be managed by someone trustworthy including that the encryption and
decryption keys are managed in a secure way. In any case, security is not as
good as on the internet, and that’s definitely a major setback. If a browser
and origin server desire end-to-end security, they must communicate directly
using the WAP protocols, which is not the case in the problem we’re interested
in.
2. If the WAP Gateway has bugs in its software,
they will probably get revealed by a user and then he can notify the staff
managing the gateway so the bug could be fixed. Problems with hardware might be
harder to solve, but the hardware is probably not as application specific as
the software, and thus should be easier to replace, when one has come to terms
with what the problem is, that is.
3. As seen above the WAP protocols ensure
reliable transfers, and so is also the case with TCP/IP. Therefor the data
received by the WAP Gateway should be considered correct when it arrives. At
the gateway, when a decryption has been made, the data will be unprotected and
a transient error could occur for example while copying the data from a buffer
to another. That’s a problem that is very hard to detect. Data could also be
lost inside the gateway due to something unpredictable. Both these cases would
probably not be a very big problem though, since what will happen at the client
is he will get an error message and just has to reload the document. This will
of course take longer time, and if the data the end-user want is critical, like
in the case with stock market, he could lose money on these problems. Anyway
there doesn’t seem to be any real dangers involved in these problems.
5. A problem with a WAP Gateway is that it
probably provides WAP services to a lot of users. One gateway (this is actually
a specific one, the WAPgate by VirtuaCom) can have more than 2 billion users
online at the same time and over 30 thousand concurrent transactions. These
numbers might seem a bit exaggerated in the near future, but still this means
that a lot of data will be handled at the same time in the gateway, and
congestion seems not unlikely when dealing with these volumes.The congestion
could occur both in the gateway and on the Internet between gateway and web
server when dealing with these numbers.This means that the WAP Gateway will be
a bottleneck in the network, and that you probably will have to wait a while to
get any service.
The problem with WAP is apparently the WAP
Gateway. Since you want to have access to data on the Internet and the fact
that the WAP protocol suite isn’t directly compatible to TCP/IP, HTML and so
on, you have to convert it somewhere. That’s where the data security is low,
and that’s where it could be altered due to errors in hard and software. In
many WAP services, getting the latest information is essential. That means that
caching data on the gateway might be good for speed, but really not in the case
where the data has been updated and the old data that is cached is sent anyway.
Another problem that probably will grow in the nearest future is congestion in
the gateway because of all the data processed (encryption, decryption and so
on). These are some effects on the end-to-end behaviour of a WAP network. Thinking
about this and facing the fact that the computers of today are quickly getting
smaller, faster and less energy consuming, it’s not far away to think that with
the new IPv6, the next generation of mobile network, and the small handheld
computers, like for instance the Cassiopeia 105 by Casio, WAP should pretty
soon grow obsolete. Right now WAP works pretty well compared to browsing the
internet with a Windows CE computer, since the bandwidth on the GSM net is so
small, but the difference is really not that impressive, the services and
applications not that many, and the clientele not that big. WAP is still to
slow to stream any media, let alone present it in a meaningful way. Hopefully
in the next few years we will see if WAP is strong enough to survive alongside
handheld computers supporting HTTP and HTML, and a faster mobile net.
* *
* * *
WAP
Architecture, Version 30-Apr-1998, WAP Forum, http://www1.wapforum.org/tech/documents/SPEC-WAPArch-19980430.pdf
WAP White
Paper, WAP Forum, http://www.wapforum.org/what/WAP_white_pages.pdf
WAP FAQ,
Combra, http://www.combra.se/datakomm/wapfaq.html
What
is WAP and WAP Forum, WAP Forum, http://www.wapforum.org/what/index.htm
WAP White
Paper, AU System, http://www.ausys.se
End-to-end
arguments in system design,J.H. Saltzer, D.P. Reed and
D.D. Clark, M.I.T. Laboratory for Computer Science
WAP
Solutions, The Wireless Edge, www.thewirelessedge.com/products_wapgate.htm
Products, The Wireless Edge, www.thewirelessedge.com/products.htm