 |
|
|
WAP is the hottest thing in wireless data right now. A browser on a wireless phone seems like such a cool idea. But, what is substance behind the demos? Does WAP have what it takes to be successful, and will it displace the many wireless data initiatives of the past?
WAP is more than just browser software for a phone, it is a complete suite of protocols that tries to provide its capabilities on a multitude of data-enabled wireless protocols. WAP is adaptable to paging protocols, dedicated data protocols or digital cellular/PCS protocols that include support for wireless data. WAP will not supplant existing wireless data protocols. It needs to use them in order to transmit information between the mobile device and the WAP server.
The concept of WAP is to build on the advances that the internet made in using computers for communications. These are:
One of the most important advances of HTML was that it was designed to adapt to a wide variety of input and output devices. From a character-oriented, black-and-white terminal to a high-end, full-color, large-screen computer controlled by voice commands, the same HTML code can produce useful results (or not, depending on the competence of the designers). HTML does not demand very much, it simply requests a lot. An HTML program may request that text be displayed in a Garamond font or, if that is not available, then Palatino. And, if neither are available, then the browser is at liberty to use whatever font it likes. The screens might not look as nice, but it is much, much better than the user getting a message like “font not available” instead of the information they requested. Similarly, with input devices, HTML does not demand that input be entered in any particular way. If HTML specifies that a list of choices are to be presented to the users, it makes no difference whether a choice is selected by voice commands, mouse clicks, keystrokes or by eyeball tracking.
These lessons from the success of HTML have been learned by the designers of WAP. They will be dealing with today’s pagers and cellular phones that might allow only a few lines of text to be displayed in monochrome using data links in the range of 8kbps to 13kbps. But, future systems are planned with higher bandwidths, which will likely result in wireless devices with larger screens (or, another way to look at it is that devices with larger screens, like PDA’s, will increasingly become wireless-enabled). Color and more advanced input devices will also become more common. WAP appears able to adapt to a wide variety of end-user devices, and should avoid the trap of falling victim to its own success.
WAP is based on a network model, illustrated in Figure 1, that is similar to Internet Hypertext (HTTP/HTML), but with a number of significant enhancements and restrictions based on the capabilities of mobile devices and radio interfaces. Content may originate from the same place as the information displayed in HTML pages. In fact, that is one of the goals of WAP. Assuming that the content is currently available as HTML, a conversion process must be undertaken. This process is at best only partly automatic. The most straightforward approach for simple web pages is to simply re-code them in WML (Wireless Markup Language), however that immediately doubles the maintenance effort for the content provider. A more sophisticated approach consists of manually reorganizing existing web pages to adapt to the needs of wireless devices, and to provide hints to the conversion process. Following these more stringent rules allows an automatic HTML to WML conversion to be performed in real-time, perhaps based on consideration of the type of device (e.g. bandwidth available and screen size). Since an increasing number of web pages are now generated dynamically, it may become possible to simply implement software that can automatically generate WML or HTML, depending on the type of request. A search engine for example, could have one front-end to generate HTML pages (perhaps 20 responses per page) and another for WML (with perhaps only 3 responses per card).
|
WAP content from the server can now travel through the internet in the same fashion as HTML and other forms of internet traffic, such as email and FTP. Once the WML reaches the radio communications system serving the mobile, there are a number of new steps that are required. A WAE Gateway can perform the binary encoding/decoding of WML and can adapt the WML to the needs of the particular wireless device, perhaps even choosing the transmission method (e.g. circuit switched data, short message or packet data). The compressed and optimized WML is then transmitted, picked up by the mobile and travels up the protocol stack until it reaches the browser. Then the information is presented to the user or the information may be acted on by the wireless device, transparently to the user.
WAP is made up of a number of protocol building blocks stacked in layers, as illustrated in Figure 2. Those that are part of the WAP specification are shown in red, while mobile-specific functionality is shown in blue, and a selection of the radio interfaces that can support WAP are shown in green. Each of the WAP protocol modules adds specific functionality to the system, and developers can, for most of them, choose which ones they need, based on the type of mobile they are designing.
|
The design of a WAP browser is outside the scope of WAP – intentionally. Wireless device designers can take the various WAP protocols as building blocks to design a WAP browser that uses the special capabilities of their device in the optimal way. On the other hand, content providers can design applications in WML, for example, that do not rely on specific capabilities of the wireless device.
WML is a page description language in the mould of HTML. It is based on an ASCII readable format that contains many of the elements of HTML, but that also includes many new elements. The use of WML is an essential part of any WAP browser. Some of the enhancements of WML beyond HTML are:
WML Script is similar to the Java Script that is used to jazz up many websites. Quite complex programs can be defined, that can be executed on the user’s device. WML Script eliminates some aspects of Java Script, but adds several more that are related to telephony applications, such as the ability to make calls. This also can reduce communications with the server, assuming that the script is executed often enough to exceed the overhead of transmitting the script.
WAP does not just specify interactions between a WAP browser and a WAP server using WML and WML Script, it also allows a browser, using WTA, to access the telephony services of the mobile device. By incorporating this in the WAP browser (or a separate browser that gets activated when calls are being made), WAP users can initiate or receive calls from within their browser. This concept could easily make the standard telephone keypad obsolete, in favour of merely pointing to a name in the device’s phone directory, or pointing at the digits on the screen. WTA also communicates with content providers to control voice mail, for example.
Since WTA is independent of the particular wireless device being used, an adaptation layer is required. This is WTAI – the Wireless Telephony Application Interface. It provides a list of functions, such as “makeCall” or “sendDTMF” that provide a standard interface to the call processing capabilities of a particular device.
WML/WML Script may make many requests for information, and WSP provides a way for the phone to manage them. It can negotiate the capabilities of the phone with the WAE gateway, and ensure that information is transmitted reliably and in an orderly fashion. WSP can also provide a conversion between the binary encoding of WML and the ASCII format used by the browser.
If a wireless device is operating in a connection- or session-oriented mode, the WSP layer needs to invoke a transaction protocol that can keep track of requests that are outstanding, and can associate responses with them. This is very important when a browser sends out multiple requests, with the responses coming back in a random order. This concept can be seen in an HTML browser (that uses the similar TCP protocol) where those with slow modems have the privilege of watching multiple graphics slowly fill in on their screen. Each request for a graphic is a separate TCP transaction, and it is obviously important that, as each piece of a request is received, it gets placed on the correct position on the screen.
Many of the applications being considered for WAP will require secure transmission of data, particularly those involving financial transactions. WTLS provides an optional layer to provide security, just as “https:” provides secure browser connections. WAP unfortunately does not provide a single suite of security algorithms, but leaves the choice to be negotiated by the phone and the network. Until this is narrowed down to a choice of one or two methods, it is unlikely to be widely adopted.
WDP is a ‘glue’ layer, that allows WAP protocol elements above it to communicate with different radio interfaces employed to carry the data below it. WDP allows packets to be transmitted and received, but does not guarantee end-to-end deliverability. That is the role of higher level protocols, such as WTP. The internet parallel is with the IP layer that provides basic connectivity and routing over a variety of underlying physical layer protocols, but not capabilities such as reliable transport and session management.
Radio interface protocols are generally structured into multiple layers. Although the lower layer protocols are most well known (particularly TIA/EIA-136 TDMA, TIA/EIA-95 CDMA and GSM in Canada), all the major digital wireless protocols have data capabilities, that often exist as distinct “bearer” protocol layers above them. For cellular and PCS, WAP is first being implemented on circuit-switched bearers. The next step may be to add Short Message Service as a way to “push” content, even during a call. A further step will be to employ packet data protocols, as these will allow data transmission at all times, with higher throughput than SMS allows. Some wireless data protocols, notably CDPD, only support packet data, so this would obviously be the only operating mode. Paging systems can support limited WAP functionality, and do not have the rich suite of bearers provided by digital cellular and PCS.
WAP has more support than any previous wireless data initiative, and is the first to get global, rather than regional, support. It is not a new data transmission protocol, but rather it is a generic application that may become the raison d’etre for the many wireless data protocols that exist, yet that today are still the poor cousins next to the enormously successful wireless voice services.
© – Copyright