Back to WAP Basics: A Technical Review

WAP is an important development in the wireless industry because of its attempt to develop an open standard for wireless protocols, independent of vendor and airlink.

Adapted from a white paper by Mobile Lifestreams Ltd.

The Wireless Application Protocol (WAP) is a hot topic that has been widely hyped in the mobile industry, as well as outside of it. WAP is simply a protocol—a standardized way that a mobile phone talks to a server installed in the mobile phone network. It is amazing how it has become imperative for all Information Technology companies in Nordic countries and beyond to have a WAP division. Many advertising agencies and "dot.coms" have announced WAP services.

History
Philosophy
Technical Details
WAP Protocol Stack
Optimal WAP Bearer
Content Delivery
Applications

History (Back to Top)
The WAP Forum was formed after U.S. carrier Omnipoint issued a tender in early 1997for the supply of mobile information services. It received several responses from different suppliers using proprietary techniques for delivering the information such as Smart Messaging from Nokia and HDML from Phone.com (then called Unwired Planet).

Omnipoint informed the tender responders that it would not accept a proprietary approach and recommended that that various vendors get together to explore defining a common standard. After all, there was not a great deal of difference between the different approaches, which could be combined and extended to form a powerful standard. These events were the stimulus behind the Wireless Application Protocol development. Ericsson and Motorola joined Nokia and Unwired Planet as the founding members of the WAP Forum.

Philosophy (Back to Top)
WAP takes a client-server approach. It incorporates a relatively simple microbrowser into the mobile phone, requiring only limited resources on the phone. This makes WAP suitable for thin clients and early smart phones. WAP puts the intelligence in the WAP Gateways while adding just a microbrowser to the phones themselves. Microbrowser-based services and applications reside temporarily on servers, not permanently in phones. WAP is aimed at turning a mass-market mobile phone into a network-based smart phone.

Technical Details (Back to Top)
The Wireless Application Protocol embraces and extends the previously conceived and developed wireless data protocols. Phone.com created a version of the standard Hypertext Markup Language (HTML) Internet protocols designed specifically for efficient and cost-effective information transfer across mobile networks. Wireless terminals incorporated a Handheld Device Markup Language (HDML) microbrowser and Phone.com's Handheld Device Transport Protocol (HDTP), then linked the terminal to the UP.Link Server Suite, which connected to the Internet or intranet where the information being requested resides. The Internet site content was tagged with HDML.

This technology was incorporated into WAP and renamed using some of the many WAP-related acronyms such as WMLS, WTP, and WSP. A person with a WAP-compliant phone uses the in-built microbrowser to:

1. Make a request in wireless markup language (WML), a language derived from HTML especially for wireless network characteristics.

2. This request is passed to a WAP Gateway, which then retrieves the information from an Internet server either in standard HTML format or WML. WML is preferable because it is prepared directly for wireless terminals. If the content is in HTML format, a filter in the WAP Gateway may try to translate it into WML. A WML scripting language is available to format data such as calendar entries and electronic business cards for direct incorporation into the client device.

3. The requested information is then sent from the WAP Gateway to the WAP client, using whatever mobile network bearer service is available and most appropriate.

WAP Protocol Stack (Back to Top)
WAP has a layered architecture. (See Figure)

Wap's protocol stack

Wireless Application Environment—The WAE defines the user interface on the phone. The application development environment facilitates the development of services that support multiple bearers. To achieve this, the WAE contains the WML, WMLScript (a scripting micro-language similar to JavaScript), and the Wireless Telephony Application (WTA). These are the tools that allow WAP-based applications to be developed.

Wireless Session Protocol—A sandwich layer that links the WAE to two session services—one connection-oriented service operating above the Wireless Transaction Protocol and a connectionless service operating above the Wireless Datagram Protocol.

Wireless Transaction Protocol—This runs on top of a datagram service, such as User Datagram Protocol (UDP, which is part of the standard suite of TCP/IP protocols) to provide a simplified protocol suitable for low-bandwidth mobile stations. WTP offers three classes of transaction service: unreliable one-way request, reliable one-way request, and reliable two-way request respond. Interestingly, WTP supports Protocol Data Unit concatenation and delayed acknowledgement to help reduce the number of messages sent. This protocol, therefore, tries to optimize the user experience by providing the information that is needed when it is needed—it can be confusing to received confirmation of delivery messages when you are expecting the information itself. By stringing several messages together, the end user may well be able to get a better feel more quickly for what information is being communicated.

Wireless Transport Layer Security—WTLS incorporates security features that are based upon the established Transport Layer Security (TLS) protocol standard. Includes data integrity checks, privacy on the WAP Gateway to client leg and authentication.

Wireless Datagram Protocol—This allows WAP to be bearer-independent by adapting the transport layer of the underlying bearer. WDP presents a consistent data format to the higher layers of the WAP protocol stack, thereby conferring the advantage of bearer independence to application developers.

Optimal WAP Bearer (Back to Top)

Short Message Service—Given its limited length of 160 characters per short message, SMS may not be an adequate bearer for WAP because of the weight protocol of the protocol. The overhead of the WAP protocol that would be required to be transmitted in an SMS message would mean that even for the simplest of transactions, several SMS messages may have to be sent. This means that using SMS as a bearer can be time consuming and expensive. Only one network operator—SBC in the United States—is known to be developing WAP services based on SMS.

Circuit-switched data—Most of the trial WAP-based services use CSD as the underlying bearer. Because CSD has relatively few users currently, WAP could kick-start usage of and traffic generated by this bearer.

However, CSD lacks immediacy because it requires a dial-up connection to link the WAP client to the WAP Gateway. In a best-case scenario (when there is a complete end-to-end digital call), that takes about 10 seconds. When there is need for analog modem handshaking (because the WAP phone does not support the V.110 digital protocol or the WAP Gateway does not have a digital direct connection, such as ISDN, into the mobile network), the connection time increases to about 30 seconds.

Unstructured Supplementary Services Data (USSD)—USSD is a means of transmitting information or instructions over a GSM network. USSD has some similarities with SMS because both use the GSM network's signaling path. Unlike SMS, USSD is not a store-and-forward service and is session-oriented such that when a user accesses a USSD service, a session is established and the radio connection stays open until the user, application, or time out releases it. This has more in common with circuit-switched data than SMS. USSD text messages can be as long as 182 characters.

General Packet Radio Service (GPRS)—GPRS is a new packet-based bearer that is being introduced on many GSM and TDMA mobile networks from 2000 onward. It is an exciting bearer because it is immediate (there is no dial-up connection), relatively fast (up to 177.2 kb/s in the best theoretical extreme) and supports virtual connectivity, allowing relevant information to be sent from the network as it is generated.

Content Delivery (Back to Top)
There are two efficient means of proactively sending (pushing) content to a mobile phone: by SMS, which is one of the WAP bearers, or by the user maintaining a "permanent" GPRS (mobile originated) session with the content server. However, mobile-terminated IP traffic might allow unsolicited information to reach the terminal. Internet sources originating such unsolicited content may not be chargeable. A possible worst-case scenario would be that mobile users would have to pay for receiving unsolicited junk content. This is a potential reason for a mobile vendor not to support GPRS Mobile Terminate in its GPRS terminals.

However, by originating the session themselves from their handset, users confirm their agreement to pay for the delivery of content from that service. Users could make their requests via a WAP session, which would not need to be blocked. As such, a WAP session initiated from the WAP microbrowser could well be the only way that GPRS users can receive information onto their mobile terminals.

Because all but the early WAP-enabled phones will also support the general packet radio service, WAP and GPRS could well be synergistic and be used widely together. For the kinds of interactive, menu-based information exchanges that WAP anticipates, circuit-switched data is not immediate enough because of the need to set up a call. Early prototypes of WAP services based on CSD were therefore close to unusable. SMS, on the other hand, is immediate but is always store and forward. Even when a subscriber has just requested information from his microbrowser, the SMS Center resources are used in the information transfer. As such, GPRS and WAP are ideal bearers for each other.

Applications (Back to Top)
WAP is being used to develop enhanced forms of existing applications and new versions of today's applications. Existing mobile data software and hardware suppliers are adding WAP support to their offerings, either by developing their own WAP interface or more usually partnering with one of the WAP Gateway suppliers. WAP has also given a significant impetus for new players to add mobile as a new distribution channel for their existing products and services. For example, CNN and Nokia teamed up to offer CNN Mobile, and Reuters and Ericsson teamed up to provide Reuters Wireless Services.

The Wireless Application Protocol will allow customers to reply to incoming information on the phone by allowing new menus to access mobile services. This is part of the business case for network operators. By making the value-added services easier to request (using menus instead of keywords, for example), WAP can help generate additional traffic on the network and, therefore, bring in more revenue.

Previously, application developers wrote proprietary software applications and had to port that application to different network types and bearers within the same platform. By separating the bearer from the application, WAP facilitates easy migration of applications between networks and bearers. As such, WAP is similar to Java in that it simplifies application development. This reduces the cost of wireless application development and therefore encourages entry to the mobile industry by software developers.

Corporate applications that are being enhanced and enabled with a WAP interface include:

• Job Dispatch
  
• Remote Point Of Sale
  
• Customer Service
  
• Remote Monitoring Such As Meter Reading
  
• Vehicle Positioning
  
• Corporate Email
  
• Remote LAN Access
  
• File Transfer
  
• Web Browsing
  
• Document Sharing/Collaborative Working
  
• Audio
  
• Still Images
  
• Moving Images
  
• Home Automation

Consumer Applications that are being enhanced and enabled with a WAP interface include:

• Simple Person to Person Messaging
  
• Voice and Fax Mail Notifications
  
• Unified Messaging
  
• Internet Email
  
• Prepayment
  
• Ringtones
  
• Mobile Commerce
  
• Affinity Programs
  
• Mobile Banking
  
• Chat
  
• Information Services

About the author
Mobile Lifestreams Ltd. was formed following the success of it first publication "Data on SMS," published in October 1998. The company's staff and operations rapidly expanded from there, encompassing a team of several writers, a consulting division, the roll out of more than 75 Internet sites related to mobile communications, as well as several staff responsible for customer services, accounts and database marketing. For more information, contact founding director Simon Buckingham at 9 The Broadway; Newbury, Berkshire RG14 1AS UK; email: simonb@mobilelifestreams.com; Tel:+44 7000 366366; Fax: +44 7000 366367.