 |
|
|
WAP, the Wireless Application Protocol, is supposed to make consumers hungry for wireless data. Will consumers line up for a browser in every phone, or will they largely spurn it like so many wireless data initiatives of the past? If WAP is the new restaurant in town, then WML is their secret book of recipes. Now that WAP is open for business in Europe, and WAP-enabled phones are the hottest new fun essential executive productivity tool, what is going to happen now that WAP has started to open its doors for business on this side of the pond?
According to Greg Williams, Chairman of the WAP Forum, commercial launches of WAP by the major US carriers are expected throughout the first half of 2000, allowing WAP browsers to be included on cellular and PCS phones that have modestly sophisticated pixel-oriented screens (e.g. the Nokia 6160 so closely associated with AT&T’s flat rate plan). According to Williams, WAP is “air interface agnostic and bearer independent,” which means that it can be used on every major digital cellular and PCS technology that provides data speeds of 8 kbps or higher. This technology independence is what has generated so much international interest. Williams jokes “Join the WAP Forum and see the World!”
WAP can best be viewed as a wireless browser for the internet. It is not separated from the internet, but builds upon it. Currently, the internet, as viewed from a wireless device, is a supremely hostile environment. Most sophisticated web sites are barely tolerable when connecting at 56 kbps, while wireless phones are generally limited in bandwidth to 8 kbps to 13 kbps. Furthermore, the tiny screens, coarse resolution and numeric keyboards provide extremely limited user interface capabilities. Yet, in the early days of the internet, many people surfed quite contentedly on the text-based pages of the day using speeds that were no higher than wireless provides today.
The WAP model for delivering content is shown in Figure 1. It is similar to the HTML/HTTP delivery model, but requires some extra processing to adapt to the limitations of wireless phones. A WAP client does not use HTML, but WML instead. A WML file looks quite similar to HTML, partly because both are based on the Extensible Markup Language (XML), and partly because they both provide similar capabilities. Unlike HTML, however, WML has two different forms, one based on readable ASCII characters, and the other is a compressed binary form, intended for delivery across a radio interface. WAP also provides a scripting language, which provides a subset of the capabilities of Java Script.
|
WAP is based on the Client-Server model, where content is stored on a Server, to be dished out when clients order it up. The client is generally the user’s computing device that provides an interface for ordering content and then displaying it in the way that best fits the user’s preferences and the characteristics of the client device. This is simply a realization that some functions must be centralized (databases, for example) and that others are best controlled by the device that is serving a single person (such as the user interface). The client-server architecture generally arises when user devices became fully fledged computers. The transition from a Server-based architecture to a Client-Server architecture evolved when PCs started replacing dumb terminals on the desks of workers and consumers. The same transition is now occurring with wireless devices now that the digital wireless revolution has transformed phones into powerful computing devices.
Methods to perform the HTML-to-WML conversion are evolving. While manual generation of WML pages is certainly possible, there are also some partially automated approaches. Herb Williams, Director of Mobile Data Solutions for Spyglass, describes their PRISM product that can produce WML from HTML in real-time, but first they have to work with the customer to adapt the website to these new requirements. Website managers can continue to make routine changes, but major structural changes require their consultative involvement again. Williams notes that on a well designed site, in conjunction with sophisticated tools, content can be dished up in different forms to support text based phones, PDAs with simple graphics capabilities, and fully-fledged computing platforms that just happen to have wireless connections. Eventually there may be tools that can generate WML dynamically in response to queries, like sophisticated HTML-based websites, such as web search engines, do today.
WAP is independent of the underlying radio interface, which need only provide the minimum capabilities to support WML and scripting. Figure 2 illustrates how the WML application can utilize some of the major radio interfaces in use in North America. In fact, virtually every radio interface that has data capabilities has a WAP protocol stack defined, although that does not mean that products are yet available. However, independence from the underlying access method is a characteristic that makes the WAP concept virtually unique among wireless data protocols.
According to Williams of the WAP Forum the majority of implementations will be based on Circuit Switched Data (CSD), with future enhancements taking advantage of short message service and packet data, for example. An interactive session might take advantage of the bulk data efficiencies of CSD, while a notification of a change in a stock price might be delivered in a short message, even allowing delivery with a voice call in progress.
|
An important characteristic of markup languages like WML and HTML is that they do not describe pages exactly, but only give guidance to the client. This allows the display of information to be adapted to the display device being used. HTML files can be displayed on small, text-based terminals or large, high-performance, graphics monitors. Similarly, it is intended that WML will be used to display information on wireless devices with screens that show only a few short lines and on those that may be the size of a PDA screen, or even larger. Since WML only gives hints, what is seen on a variety of wireless devices could be quite different. Similarly, the input devices are not specified. When text input is required, typing on a keyboard, tracing letters on a PDA screen or speaking into a device with speech-to-text capabilities are all equivalent.
The basic syntax of WML is also similar to HTML, using the familiar (to geeks at least) angle-bracket notation (e.g. <b>this text is to be shown in bold letters<b/>) with the insertion of a slash indicating the end of a command. Simple commands that do not have a beginning and an end can use a more compact notation, <tag/>, which is equivalent to <tag></tag>. For example, <go href=“glossary.html” /> instead of <go href=“glossary.html”></go>.
WML tries to provide data in smaller, byte-sized pieces, as compared with HTML. While the smallest HTML program is a web-page (usually represented by a single file on a web server), WML is further broken down into decks (roughly equivalent to a web-page) that contain multiple cards. Deciding where to break an existing web-page into cards will be one of the greatest challenges when making an existing HTML site WAP-ready.
WML provides many of the capabilities of HTML, including the concept of URL (Uniform Resource Locator). Just as with HTML browsers, absolute, relative and fragment references are supported. Absolute URLs include the complete address (e.g. www.cnp-wireless.com) while relative URLs include only a partial address – the remainder is included from the most recent absolute URL that was used (e.g. glossary.html would be translated to www.cnp-wireless.com/glossary.html). A fragment URL references a point within an HTML file or, for WML, a card within a deck. It can either be absolute (e.g. www.cnp-wireless.com/glossary.html#WAP) or relative (e.g. glossary.html#WAP or even just #WAP if a reference within the current file or deck is required).
All modern HTML browsers contain a history – a list of URLs that have been recently accessed. Browsers provide user interface commands to navigate the stack, but HTML does not have this capability. WML goes further and has the history file built into the protocol, allowing commands like <prev> that can move the user back one command in the history stack.
Through “event-handling,” WML allows actions to occur without interactions with the server. In an HTML application (without Java), pressing a button causes a command to be sent to the server, where an application determines what action should be taken, possibly loading a new page. With WML, events can be trapped by the application, and cause the browser to take an action such as transferring to a different card or a different URL.
WML also supports telephony applications through the Wireless Telephony Application Interface (WTAI). This allows a browser to communicate, not with a remote server, but with call processing on the phone. An obvious application for this would be to allow calls to be made from an address book in a PDA by clicking on an entry.
Most HTML browser applications work in a ‘get’ environment. When the client wants something, it asks for it, and if it wants an update, it waits a while and asks again. This is both inconvenient and, especially in a wireless environment, a waste of bandwidth. WML supports a ‘Push,’ where the client makes a request that is not fulfilled until certain criteria are met (e.g. a stock reaches a certain price, an accident occurs in a certain stretch of highway, or a weather alert is declared in a certain county). At that time, a message will be sent by the server to alert an application in the WAP client. This could result in, for example, the phone beeping and displaying a flashing message on its screen.
When HTML was first introduced, interactions with clients were very restricted. HTML allowed fairly sophisticated display capabilities – tables, graphics and frames, for example, but forms were the only method of data input. While forms are still heavily used, they have been made somewhat more functional and a lot more glitzy through the use of Java. WAP provides a scripting language that is, according to Alastair Angwin, a member of the WAP Forum board’s technical committee, “equivalent to an optimized subset with extensions for telphony.” Although not a complete programming lanuage, WMLScript does allow for more sophisticated interactions with the user, and for calculations and text processing to be performed on the client. Perl, another common scripting language in world-wide web systems is, by comparison, executed on the server. In many applications, the WMLScript on the client will interact with scripts or other application programs on the server.
If WML was just a customized form of HTML, the radio interface would still be a forbidding barrier, but WAP has one more trick up its sleeve – binary encoding of the messages. HTML is not very efficient in the use of bandwidth. The common HTML code <a href=“URL”> has an overhead (not counting the URL) of only 3 bytes instead of 11. WML provides short binary (numeric) equivalents for many of the text strings that are commonly used. This can reduce the transmission requirements for a WML program by several times, which is equivalent to increasing the transmission speed several times over (which is not so easy to do).
Binary WML is one of the major reasons that a WAE gateway is required. The base station or MSC is a convenient place to convert from the ASCII-formatted WML code to the binary format that will be sent over the radio interface. The WAE gateway can also choose the bearer protocol that will be optimal for transmission based on a profile of the phone and browser capabilities that is provided to it.
The following example (taken from the WAP Specification, Version 1.1) describes a simple WML Deck containing two Cards. The first Card is presented to the user along with a button (or other user input device) labeled “Accept.” When this button is selected, the second Card is displayed and the WML Deck terminates:
|
Readers who are interested in learning more about WML or other aspects of WAP should download the WAP series of specifications from www.wapforum.org.
The many players behind WAP are making a major gamble in the wireless data market, and they think that WML is their strongest card. There are no guarantees in the competitive wireless business, but it looks like WAP may be the wireless data initiative with the odds in its favor. It certainly has breathed new life and confidence into the wireless data marketplace. Expectations are high – Haroon Alvi, Nokia Mobile Phones Director of Business Development for the Americas – predicts that “95% of phones will be WAP-enabled by 2005.”
WAP will not replace existing wireless data technologies because it utilizes them for transport. There will be a synergistic relationship between them, with WAP potentially dramatically increasing the demand for these services, allowing the data services that best support it to flourish. Alvi anticipates that as the demand for data increases, “the market for more sophisticated phones, such as touch-screen phones, will increase dramatically.” WAP may also give the coup de grace to analog cellular, as there will be a much more obvious distinction between the phone-call-only capabilities of analog compared to integrated data-voice capabilities of a WAP-enabled digital phone.
Greg Williams, Chairman of the WAP Forum, notes that wireless data proponents are no longer talking about the details of the radio interface – modulation schemes, and bit rates ” but focusing on building an infrastructure for applications. Manufacturers and carriers appear to have realized that only a single, global, “technology agnostic” protocol stands a chance of success.
WAP is not only introducing new technology, but also new terminology. Here are some of the acronyms that you will come across in places where WAP is discussed:
|
CDPD |
Cellular Digital Packet Data |
|
CSD |
Circuit Switched Data |
|
GPRS |
GSM/ANSI-136 General Packet Radio Service |
|
GUTS |
Generic UDP TeleService for ANSI-136 TDMA |
|
HTML |
HyperText Markup Language |
|
Java Script |
Client scripting language commonly used in conjunction with HTML |
|
PD |
Packet switched Data |
|
R-Data |
Message transmission protocol within ANSI-136 |
|
SMS |
Short Message Service |
|
SMSCB |
Cell Broadcast Short Message Service |
|
USSD |
GSM Unstructured Supplementary Service Data |
|
WAE |
Wireless Application Environment |
|
WAP |
Wireless Application Protocol |
|
WML |
Wireless Markup Language |
|
WTA |
Wireless Telephony Application |
|
XML |
eXtensible Markup Language |
© – Copyright