How does a WAP device connect to the internet?

The normal implementation of a WAP 1.x scenario looks pretty much like this:

In the figure above, starting from the left, you’ll find the mobile WAP device attached to the mobile network (GSM, CDDA, etc) which dials the modem attached to a dial-in server (RAS, or Remote Access Service). This server gives the WAP device access to the protocols it needs. These are the same lower level protocols as a normal Internet Service Provider will give you. This is known as PPP or Point-to-Point Protocol.

These protocols are used to access the next step in the chain, the WAP gateway, in this figure hosted by the mobile operator. The WAP gateway is the link between the wireless and the “web” world, basically giving the WAP device access to the common internet.

Another way of explaining it, and in a bit more detail would be to say that when you type in the URL for a site on your WAP device, for instance http://t.wurfl.com/ the WAP device first checks if it already has an open connection, if not it dials up the PPP provider as described above. After the PPP provider has given the WAP device the required protocols and assigned it an IP address, the request for the URL is sent to the gateway. The WAP gateway, now under “control” of the WAP device requests the URL with a normal HTTP request, such as GET HTTP://WAP.COLORLINE.NO/.

On the internet, there is a normal “web” server which in this case holds both WAP and “web” contents, which now receives the request to send out the contents located at the HTTP://WAP.COLORLINE.NO/ URL. Also note the normal “web” browser at the lower part of the figure. The web server, depending on which type of browser it is talking to (WAP or “web”), sends out WAP, represented by the blue line, or “web” content represented by the green line.

Following the requested content back to the WAP device, the contents, if they are in so called textual WML code (the human readable type), the WAP gateway compiles the textual WML into so called tokenized WML, or WMLC, where basically the code is “compressed” down into binary data (the machine readable type). This tokenized WML is then passed back to the WAP device. If the contents from the web server is already in tokenized WML format, the WAP gateway skips this operation. The reason for the conversion from textual WML to tokenized WML is to reduce bandwidth usage. A WAP device’s WML browser can only read tokenized WML.

Finally, back at the WAP device that requested the URL, the WML browser, when receiving the tokenized WML code renders the contents on the WAP device’s display to present a card for the user.

This is how the majority of WAP devices is connected to the Internet, and if you’re completely new to WAP, you might want to get back to the more complex configurations below a bit later.

When the WAP device is configured to use a public WAP gateway, and not one that is hosted by the mobile operator, we basically move the WAP gateway out on to the Internet. I repeat that this is not the normal way WAP devices are configured, but during development you might come across this. The figure then looks something like this:

The WAP device now requests another WAP gateway, located on the Internet. There’s really not much more to say about this configuration other than that this is the typical configuration for developer who want to test a specific WAP gateway.

All the communication between the WAP device and the gateway is UDP and not TCP. Between the gateway and the HTTP server, the standard TCP connection is used.

If the content provider wants pretty much total control over the stream of data sent back and forth between the web server and the WAP device, they would install something called a WAP server. This device is merely a web server and a WAP gateway in one, and it is usually located inside a firewall on the content provider’s networks.

The configuration would look something like this:

(The firewall is of course optional, but highly recommended)

The WAP device gets Internet access the same way as before, but from there it now connects to the firewall which accepts or rejects the connection depending on the firewall configuration. The firewall then passes the connection on to the WAP gateway inside the WAP server. In this configuration, the chain between the content server and the WAP device is point-to-point secured with the WTLS encryption protocol.

In WAP 2 the TCP stack and HTTP protocol were added in the implementation. The WAP gateway may still be used and this is the default configuration for many browsers and preferred by many mobile operators.
The browser, anyway, is able to manage the entire communication with the remote server, so the WAP gateway is not required anymore.

If the browser allows it, users may change their settings and avoid going through the WAP gateway.
Many operators enforce the use of the WAP gateway providing special rates when using it, for example, accessing the operator portal for free, but only while using their WAP gateway.