WAP Overview

Why Do We Need Another Protocol?

Most people would agree that there are more protocols associated with computing than you could shake a stick at, and it can be challenging trying to keep up with them all. So why do we need another protocol? The answer is very simple - because phones are not PCs.

 

To be specific: most of the protocols in use today make a set of assumptions about the environment, such as the type of network that will be available (particularly from the point of view of bandwidth and reliability), the types of devices that will be accessing the services, and the types of services that will be accessed. These assumptions do not necessarily hold true in the wireless world.

 

There are a number of differences in terms of the device itself:

 

Ø       Form Factor - A mobile device needs to be small enough to move around, and ideally to be able to fit in the palm of your hand or carry in a shirt pocket.

Ø       CPU - In a mobile device, the CPU is not nearly as powerful as a desktop PC, and is almost certainly of a different architecture.

Ø       Memory and storage - This is a lot more constrained than on a PC, because handset manufacturers are cost-sensitive, and thus reluctant to add any additional components unless it is really necessary. Also some mobile devices do not have a persistent storage of their own.

Ø       Battery - Mobile devices are battery powered, and the need to have the device available for long periods of time means that the processing CPU cannot make significant demands on the battery.

Ø       Display - This is typically limited in size and resolution, and often cannot cope with color.

Ø       Input - Mobile devices typically do not have keyboards, or if they do they are limited in size. Therefore, input is more challenging than on a typical PC.

A wireless network is considerably different to a fixed-wire network. The bandwidth of the network is typically much smaller, at least at this point in time. Reliability profiles are considerably different, particularly where users move in and out of coverage areas, disappear into tunnels, and so on. Latency may also be an issue in wireless networks. An additional factor is that there are a number of mobile network standards in place across the world, and they do not interoperate seamlessly. Some countries even have incompatible standards in different regions.

 

Finally, it is important to realize that the market is different where wireless applications are concerned. The types of applications that are suitable for use on mobile devices are not the same as those that are popular on fixed-wire environments. Typical users of mobile applications are likely to be a broader subset of the population than PC users. Even the context in which the applications are going to be used will be different. This highlights the most important aspect of mobile application design, which is to make the application easy to use in the context, and on the device that it will be accessed from.

How Does WAP Address These Issues?

WAP was designed specifically to address these issues, and has implications in each of the above areas.

 

On the device, the WAP standard defines a Wireless Application Environment (WAE), which is suited to the constraints of mobile devices. The WAE includes a microbrowser, which is a markup language browser. This browser is less stringent than existing browsers on PCs in terms of specifying exactly how a User Interface (UI) element is to be rendered, and concentrates instead on the functionality that is made available through the element (although the markup language itself has to be well formed). Hints can be provided to the microbrowser, but it is up to the microbrowser to select an appropriate representation for the device. WAP also defines a micro Virtual Machine (VM) for the microbrowser's scripting language to execute in, which is suited to the memory and CPU constraints of mobile devices. There is also an optimized protocol stack for accessing the network.

 

The network issues are addressed largely through the protocol stack that was designed to take into account bandwidth limitations and reliability issues. To maintain compatibility and use existing standards where possible, it operates over IP networks, and uses User Datagram Protocol (UDP) over IP wherever possible. However, because the existing mobile networks are not packet switched, it is capable of operating over non-IP networks as well. To help address the bandwidth issue, the content that is transmitted is encoded and compressed to reduce the overall volume of data.

 

A markup language, Wireless Markup Language (WML), has been defined that is better adapted to the constraints that we previously discussed of mobile devices and wireless networks than HTML. HTML is fairly strongly oriented towards the visual aspects of document rendering and what the specific user interface elements should be and should look like. While this is fine on devices that are capable of sophisticated rendering and have the capability to both render and allow the user to interact with elements, such as push buttons and framesets, it is not appropriate for most mobile devices, and phones in particular. A smaller, tighter markup language was required that is more appropriate to the wireless environment.

 

WML has been derived from XML and contains elements that more conveniently map to mobile devices than HTML elements. For example, WML defines an <option> element, which the microbrowser can render in any appropriate way that is semantically equivalent to the HTML <button> element. There is also a scripting language WMLScript, which is derived from the standard ECMAScript. Again, compatibility has been maintained wherever possible, and much of the semantics uses existing HTTP 1.1.