Site Map

Solution & Product Guide


Business Cases

Hardware/Software Components

Mobile Computing

Application Development

Systems Design Issues & Tools


Other Resources

Education, Seminars, CBTs, Books

Vendor Links






























































































































Wireless Application Protocol - WAP

WAP Communication Protocol & its Components

The WAP Protocols cover both the application (WAE), and the underlying transport layers (WSP and WTP, WTLS, and WDP). WML and WMLScript are collectively known as WAE, the Wireless Application Environment. As described earlier the 'bearer' level of WAP depends on the type of mobile network. It could be CSD, SMS, CDMA, or any of a large number of possible data carriers. Whichever bearer your target client is using, the development above remains the same.

Although it’s not absolutely essential for a developer to know the details of the WAP communication protocols, a brief understanding of the various protocols involved, their significance and the capabilities can help a lot while looking for specific solutions. In this section I’ll briefly describe the protocol components you say in the figures above.

WML and WMLScript are collectively known as WAE, the Wireless Application Environment

WML is the WAP equivalent to HTML (HyperText Markup Language). It is a markup language based on XML (eXtensible Markup Language). The WAE specification defines the syntax, variables, and elements used in a valid WML file. WML 1.1 Document Type Definition (DTD)  is available at http://www.wapforum.org/DTD/wml_1.1.xml. Note that XML is a meta-language defined by the W3C. This means that it is a series of rules for how to create other languages for specific applications. Content is not directly encoded in XML, but in a specific markup language defined, using XML. WML is an example of a specific language for wireless applications that is fully compliant with XML's rules. WML is thus an XML application.

For those who know HTML, WML should be quite easy to learn since many tags and attributes in WML are almost the same as in HTML, but there are fewer tags. Unlike HTML, you can play around with variables in WML, making it more dynamic. In WML it is also possible to have many sub-pages (cards) in one WML page (deck). Each WML card works like a web page and it's content is displayed to the user.

WML introduces the concept of decks and cards. A WML deck consists of one or several cards, and each card functions like an independent page, with it’s own title and preferences. This approach helps conserve valuable bandwidth because so the HTTP header information is not occupying bandwidth for each single little page.

WML is an application of XML. So WML is more XML than HTML, but the syntax of WML is a lot like HTML. Where as in HTML one can take some liberties of skipping some end tags and omit quotation marks, the rules in WML are much stricter. In WML documents, the DOCTYPE definition must always be written in the beginning of each deck, after the XML declaration, while this is optional in HTML documents. The head tag in WML is not used very often. Instead, http header information is sent using some server-side script language. In WML the  <card> tag replaces the <head> tag in HTML. There is no body tag in WML.

In WML, it is possible to use variables, which opens for slight dynamic functionality.

My aim is not to teach you how to code in WML and WML script, I’ll briefly talk about the WML syntax to give a better feel of WML.

All decks must start with the following XML header:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

The first line gives the version number of the XML version used. The second line shows the URL to the Document Type Definition provided by W3C

The body of a WML file starts with <wml>.
Between this and the end tag </wml> comes the cards.

A card is defined like this:

<card id="card1" title="WML example">

The 'id' must be unique inside each deck. Whereas the id is used to navigate between different cards in a deck the title is not that significant. It actually specifies the text that is presented on top of the window in WAP browsers but not all browsers display it.

In order to display text inside a card, you must write a paragraph start and end tag and apply the text inside them:

This is card1 text!

align= ”center” or “left” or “right” and line break <br/>  tags do the normal formatting. (tags that do not delimit content must have a '/' at the end)

The image tag is similar as in HTML.

<img src="image.wbmp" alt="description"/>

Note that there is no closing tag for the <img> tag, but as you can see, the tag ends with a / (slash) unlike the tags that need a closing tag

Links can either be written like this:

<a href="http://domain.com/wmlfile.wml">Linktext</a>
or like this:

<anchor><go href="http://domain.com/wmlfile.wml"/> Linktext</anchor>

<a href="#cardID">Linktext</a> provides a link to another card in a deck

You can use a timer to automatically load a card (same or other)

In the example below, the second card automatically loads after 4 seconds.

<card id="card1" title="" ontimer="#card2">
<timer value="40"/> à (Note the / at the end of timer tag)
This is card one!

<card id="card2" title="Card two">
This is card two!

Some editors you can use for creating WAP pages:

  • WAPPage: http://www.wapmine.com

  • WAPtor is a WYSIWYG (What You See Is what You Get) editor for writing WML and testing how it looks. http://www.wapdrive.com

  • For those developing WML with ASP,  ASPEdit, Frontpage or Visual InterDev can be used.

  • Other possible editors are: Notepad, TextPad, Emacs, SynEdit (for Java, Perl & PHP).

Note that there is a limitation on the maximum compiled deck code size. The size limitation varies from phone to phone. Maximum size for a compiled deck or image on Nokia 7110 is 1397 bytes. Maximum deck size on Ericsson R320 is 3000 bytes (excluding images).  Therefore it makes sense to limit the size of your deck to less than 1300 bytes.

Just as javascript allows client side processing for use with HTML, WMLScript (Wireless Markup Language Script) is a client side script language for use with WML. JavaScript can be used to make the pages more dynamic, and to perform advanced mathematical calculations in HTML pages. WMLScript is very similar to JavaScript and therefore easy to learn for those who have used that before. WMLScript is actually based on ECMAScript (which is based on Netscape’s JavaScript language), however it has been modified in places to support low bandwidth communications and thin clients. WMLScript makes minimal demands on memory and CPU usage, while omitting a number of functions that are not required from other scripting languages. WMLScript is integrated with WML in a particularly flexible way for developers.

Server based computation means that several round trips to and from mobile to server have to made in case of any interaction or computation. This is not very desirable in case of low bandwidth systems. WMLScript allows code to be built into files transferred to mobile client so that many of these round-trips can be eliminated. WML script also allows developer to provide interactivity in WAP pages without taxing the very valuable air interface.

You can get lots of examples on WML script at www.wmlscript.com/library/

A big difference with javascript though, is that WMLScript must be kept in a separate file, and can not be used with inline tags like JavaScript. WMLScript can perform mathematical calculations, manipulate strings of text, make redirections etc.

A listing the entire syntax of WMLScript can be obtained from specification at WAPForum. A good WMLScript tutorial available at Wireless Developer Network

WBMP stands for Wireless BitMaP. It is the default picture format for WAP. The current version of WBMP is called type 0. WBMPs are uncompressed, monochrome black/white bitmaps intended for use in devices with small screens and narrow bandwidth connection.  The constraints when using WBMP are the small screen size, limited graphics capabilities and the limited bandwidths available. As a thumb rule, a WBMP should not be wider than 96 pixels and higher than 48 pixels (at 72 dots per inch).  Nokia’s toolkit have a nice WBMP editor where you can draw and edit. Other WBMP tools create the WBMPs from BMPs, GIFs or JPGs. There are also plug-ins available for Paintshop, Photoshop and Gimp, which let you save WBMP files with these programs.

You can also use online services like

to convert your existing pictures to WBMP

A look at the following pictures will give you a clear idea about graphics and graphics support in WAP. Remember that WAP is designed to enable Internet access in low bandwidth systems. Therefore the idea is providing content fit for low bandwidth and low resolution devices rather than providing high resolution content. If you are confused as to which picture is in WDMP format, feel free to mail me!



The Security layer protocol in the WAP architecture is called the Wireless Transport Layer Security, WTLS. The WTLS layer operates above the transport protocol layer. The WTLS layer is modular and it depends on the required security level of the given application whether it is used or not. WTLS provides the upper-level layer of WAP with a secure transport service interface that preserves the transport service interface below it. In addition, WTLS provides an interface for managing (e.g., creating and terminating) secure connections.

WTLS is fast becoming the de facto standard for providing privacy, data integrity, and authentication for applications in cellular phones and other small wireless terminals. WTLS bears a close resemblance to the SSL and TLS protocols. Already WTLS has found place in a large number of mobile devices.

WTLS, though similar to SSL and TLS has some differences basically because of the nature of mobile data communications. The differences arise due to specific requirements of the WTLS protocol because of the constraints presented by the mobile data systems.

  • Long round-trip times.
  • Memory limitations of mobile devices
  • The low bandwidth (most of the bearers)
  • The limited processing power of mobile devices
  • The restrictions on exporting and using cryptography

In other words, design of WTLS is based on the requirements to provide datagram support, optimize the packet size, have an optimized handshake mechanism, provide dynamic key refreshing and select fast algorithms into the algorithm suite. The primary goal of the WTLS layer is to provide privacy, data integrity and authentication between two communicating applications.

WTLS is designed to function on connection-oriented and/or datagram transport protocols. Security is assumed to be an optional layer above the transport layer. The security layer preserves the transport service interfaces. The session or application management entities are assumed to provide additional support required to manage (e.g., initiate and terminate) secure connections. Using WTLS the client and server agree on protocol options to use. The negotiation may include the security parameters (e.g., cryptographic algorithms and key lengths), key exchange and authentication. Since this exchange of parameters involve several steps it is possible for either client or server to terminate the negotiation process at will (if e.g. some parameters are not supported.

For more details you can refer to the WTLS specification at WAP forum


The Transport layer protocol in the WAP architecture consists of the Wireless Transaction Protocol (WTP) and the Wireless Datagram Protocol (WDP). The WDP protocol operates above the data capable bearer services supported by multiple network types. As a general datagram service, WDP offers a consistent service to the upper layer protocol (Security, Transaction and Session) of WAP and communicate transparently over one of the available bearer services.

The protocols in the WAP family are designed for use over narrow band bearers in wireless telecommunications networks. Since the WDP protocols provide a common interface to the upper layer protocols (Security, Transaction and Session layers), they are able to function independently of the underlying wireless network. This is accomplished by adapting the transport layer to specific features of the underlying bearer. WDP services include application addressing by port numbers, segmentation and reassembly of messages and error detection (optional).

Source: WAP- WDP Specifications  

As I mentioned above WDP can be mapped onto different bearers, with different characteristics. In order to optimize the protocol with respect to memory usage and radio transmission efficiency, the protocol performance over each bearer may vary. However, the WDP service and service primitives will remain the same, providing a consistent interface to the higher layers. This is visible in the figure above. WDP supports several simultaneous communication instances from a higher layer over a single underlying WDP bearer service. The port number identifies the higher layer entity above WDP. This may be another protocol layer such as the Wireless Transaction Protocol (WTP) or the Wireless Session Protocol (WSP) or an application such as electronic mail. By reusing the elements of the underlying bearers, WDP can be implemented to support multiple bearers and yet be optimized for efficient operation within the limited resources of a mobile device. The figure below describes the WDP architecture.

Source: WAP- WDP Specifications

bottommenu.jpg (5946 bytes)

(Dedicated to providing comprehensive information to mobile computing community of IT professionals, user organizations, and vendors)