The Wireless Application Protocol (WAP) is a hot topic that has been widely hyped in the mobile industry and 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 in just six months, 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.
WAP is hot for several reasons:
Mobile information services, a key application for WAP, have not been as successful as many network operators expected. WAP is seen as a way to rectify this situation.
WAP also has its detractors and controversies:
Motorola, Nokia, Ericsson and the US software company Phone.com (formerly Unwired Planet) were the initial partners that teamed up over two years ago in mid 1997 to develop and deploy the Wireless Application Protocol (WAP). WAP is an attempt to define the standard for how content from the Internet is filtered for mobile communications. Content is now readily available on the Internet and WAP was designed as the (rather than one) way of making it easily available on mobile terminals.
The WAP Forum was formed after a US network operator Omnipoint issued a tender for the supply of mobile information services in early 1997. 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 initial stimulus behind the development of the Wireless Application Protocol, with Ericsson and Motorola joining Nokia and Unwired Planet as the founder members of the WAP Forum.
The Wireless Application Protocol takes a client server approach. It incorporates a relatively simple microbrowser into the mobile phone, requiring only limited resources on the mobile phone. This makes WAP suitable for thin clients and early smart phones. WAP puts the intelligence in the WAP Gateways whilst adding just a microbrowser to the mobile phones themselves. Microbrowser-based services and applications reside temporarily on servers, not permanently in phones. The Wireless Application Protocol is aimed at turning a mass-market mobile phone into a "network-based smartphone". As a representative from Phone.com (formerly Unwired Planet) on the board of the WAP Forum commented "The philosophy behind Wireless Application Protocol's approach is to utilize as few resources as possible on the handheld device and compensate for the constraints of the device by enriching the functionality of the network".
The Wireless Application Protocol is envisaged as a comprehensive and scaleable protocol designed for use with:
Indeed, the importance of WAP can be found in the fact that it provides an evolutionary path for application developers and network operators to offer their services on different network types, bearers and terminal capabilities.
The design of the WAP standard separates the application elements from the bearer being used. This helps in the migration of some applications from SMS or Circuit Switched Data to GPRS for example.
Please note that it is the purpose of this report to supplement the content of the WAP standards with context that allows readers to understand WAP's importance and related issues. As such, we will not be spending much time reproducing the published WAP standards that can be freely downloaded from the WAP Forum web site www.WAPforum.org by readers.
The Wireless Application Protocol embraces and extends the previously conceived and developed wireless data protocols. Phone.com created a version of the standard HTML (HyperText Markup Language) Internet protocols designed specifically for effective and cost-effective information transfer across mobile networks. Wireless terminals incorporated a HDML (Handheld Device Markup Language) 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. Someone with a
WAP-compliant phone uses the in-built microbrowser to:
1. Make a request in WML (Wireless Markup Language), a language derived from HTML especially for wireless network characteristics.
2. This request is passed to a WAP Gateway that then retrieves the information from an Internet server either in standard HTML format or preferably directly prepared for wireless terminals using WML. If the content being retrieved 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 has a layered architecture as shown in the diagram below:
Next we'll take a look at each layer in the WAP protocol stack:
A sandwich layer that links the WAE to two session services- one connection oriented operating above the Wireless Transaction Protocol and a connectionless service operating above the Wireless Datagram Protocol.
Runs on top of a datagram service such as User Datagram Protocol (UDP); 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.
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.
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.
See www.mobileSMS.com from Mobile Lifestreams for more information.
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 in fact have to be sent. This means that using SMS as a bearer can be a time consuming and expensive exercise. Only one network operator- SBC of the US- is known to be developing WAP services based on SMS.
Most of the trial WAP based services use CSD as the underlying bearer. Since CSD has relatively few users currently, WAP could kickstart usage of and traffic generated by this bearer.
However, CSD lacks immediacy- a dial up connection taking about 10 seconds is required to connect the WAP client to the WAP Gateway, and this is the best case scenario when there is an complete end to end digital call- in the case of the need for analog modem handshaking (because the WAP phone does not support V.110 the digital protocol, or the WAP Gateway does not have a digital direct connection such as ISDN into the mobile network), the connect time is increased to about 30 seconds.
See www.mobileUSSD.com from Mobile Lifestreams for more information. Unstructured Supplementary Services Data (USSD) is a means of transmitting information or instructions over a GSM network. USSD has some similarities with SMS since 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 up to 182 characters in length.
USSD has some advantages and disadvantages as a tool for deploying services on mobile networks:
Home Location Register (HLR), services based on USSD work just as well and in exactly the same way when users are roaming.
As such, USSD could be am ideal bearer for WAP on GSM networks.
See www.mobileGPRS.com from Mobile Lifestreams for more information.
The General Packet Radio Service (GPRS) is a new packet-based bearer that is being introduced on many GSM and TDMA mobile networks from the year 2000 onwards. It is an exciting new bearer because it is immediate (there is no dial up connection), relatively fast (up to 177.2 kbps in the very best theoretical extreme) and supports virtual connectivity, allowing relevant information to be sent from the network as and when it is generated.
At the time of writing , there has been no confirmation from any handset vendors that mobile terminated GPRS traffic (i.e. direct receipt of GPRS packets on the mobile phone) will be supported by the initial GPRS terminals. Availability or not of GPRS MT is a central question with critical impact on the GPRS business case such as application migration from other nonvoice bearers.
There are two efficient means of delivering proactively sending ("pushing") content to a mobile phone: by the Short Message Service which is of course one of WAP bearers or by the user maintaining more or less 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 worse 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 their 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 therefore 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.
Since 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 Circuit Switched Data were therefore close to unusable. SMS on the other hand is immediate but is ALWAYS store and forward, such that even when a subscriber has just requested information from their microbrowser, the SMS Center resources are used in the information transfer. As such, GPRS and WAP are ideal bearers for each other.
Additionally, WAP incorporates two different connection modes- WSP connection mode or WSP connectionless protocol. This is very similar to the two GPRS Point to Point services- connection oriented and connection less.
The predominant bearer for WAP-based services will depend on delays in availability of WAP handsets and delays in the availability of GPRS terminals. If WAP terminals are delayed until the year 2000, most WAP terminals will support GPRS as well. If the first WAP terminals support SMS and Circuit Switched Data, but not GPRS, then SMS could become the predominant initial WAP bearer.
WAP certainly will be important for the development of GPRS-based applications. Because the bearer level is separated from the application layer in the WAP protocol stack, WAP provides the ideal and defined and standardized means to port the same application to different bearers. As such, many application developers will use WAP to facilitate the migration of their applications across bearers once GPRS based WAP protocols are supported.
WAP version 1.2 may be the first version of the protocol that is actually workable in terms of delivering easy to use and innovative non-voice mobile services.
WAP version 1.2 is expected to be finalized as a specification in late 1999 and first available in spring 2000. It will support Push services (proactive delivery of information from a WAP Gateway to a WAP terminal), User Profiles, WDP Tunneling, WMLscript, CryptoLibrary, Wireless Telephony Application, Wireless Application Environment enhancements and other features. There are several non-standardized or unresolved issues relating to WAP that application developers should be aware of:
The WAP WSP specification defines the WSP push operation and a WSP push PDU (Protocol Data Unit). A push operation is not specified for the HTTP protocol, used by the WAP Gateway server to communicate with content hosts.
To support pushes, the server has to provide an application interface to allow server based applications to generate a push to a mobile client. The support of pushes on the client side depends on the capabilities of the handsets to handle pushed content. The Nokia OTA configuration proposal to the WAP Forum describes the use of a connectionless push over the SMS bearer, to transfer the configuration data to the handset.
The so-called Wireless Telephony Application (WTA) was only defined by the WAP Forum in June 1999. The WTA gives WAP some of the features that SIM Application Toolkit incorporates such as access to phone report and call handling.
There are no "cookies" for session management, i.e. to hold the session together. Cookies are used on the fixed Internet to identify the web browser and thereby assist in providing customized and streamlined services. Instead, some WAP applications use indexes in the URL as an alternative.
The cookie information is transmitted via HTTP headers. Because WAP WSP is based on HTTP headers, it should be possible to transmit cookie information to the clients. The problem may be the clients itself, which may currently not support the handling of cookie HTTP header information or to save this information to a persistent storage in the mobile phone.
The Wireless Transport Layer Security defines encryption between the Mobile Station and the WAP Gateway. The "endpoint" of the encrypted WTLS data is the WAP Gateway proxy server. To have a secure connection to a content host (e.g. banking server) the Gateway proxy server has to establish secure (https) connections to this hosts. In this case the proxy server has access to the decrypted data received via WTLS from the mobile station or from the content host via https.
WAP incorporates no compression techniques for the textual content, although the WML markup commands are compressed. Additionally, the "deck"- the smallest unit of downloadable information in Wireless MarkUp Language- is limited to a maximum of 1400 bytes. This means that applications need to be specifically designed to be very code efficient by using templates and variables and keeping information on the server and using the cache on the phone.
WML byte code converting defines a (maybe inefficient) compression technique by string tables. With this technique duplicate strings in the WMLC bytecode are avoided. This reduces the size of the data to transfer to the mobile client. The WSP SDU size of 1400 bytes is a default value. An increased size may be negotiated by a mobile client within the WSP capabilities. The WAP transport layer (WTP) is able to handle greater SDU sizes than 1400 too, by using SAR (Segmentation and Re-assembly).
The September 1999 London meeting of the WAP Forum included a decision from the SMS Experts Group that the single common standardized interface between the SMS Center and the WAP Gateway would be a subset of SMPP (Short Message Peer to Peer Protocol). A PDU (Protocol Data Unit) set has been added to SMPP version 3.4 for this purpose. There will be no SMPP specific legacy- in other words, SMS Center manufacturers that do not support SMPP can evolve their SMS Center external interface to support the new SMPP commands for connecting to WAP Gateways.
Basically, this is a victory for Logica, the creators of SMPP, who spun control of the protocol off in 1999 to an "independent" SMPP Forum
The wording of this resolution was careful to avoid mention of the political battle between the pro-SMPP companies such as Logica and those opposed to it such as CMG. Basically, the US carriers insisted upon SMPP and swung the vote.
Clearly, as the WAP specifications evolve, some of these issues will be resolved.
However, programmers need to be aware of them when they commence WAP application design.
There are at least four WAP toolkits available for software developers to use to assist in the speedy development of WAP-based services. These are supplied by Dynamical Systems Research (DSR), Ericsson, Nokia and Phone.com.
Marcel van der Heyden, WAP Product Manager
Tel +44 171 801 0191
Ericsson has a WAP-IDE (Integrated Developer's Environment) offering for WAP Developers that can be downloaded free of charge from http://mobileinternet.ericsson.se
The WAP Toolkit for developing applications can be downloaded from www.forum.nokia.com
Have an UP.SDK for application developers that can be downloaded fromwww.phone.com/products/upsdk.shtml Also features a white paper stating why developers should use Phone.com's software development kit in preference to any others.
An independent survey of these four SDKs found them to be very similar. This survey was featured in the excellent Wireless Data News Surveillance Report (WDNSR) (Mobile Lifestreams is a reseller of this publication- see www.finnevo.fi/99072319.htm for sample copies and a subscription form).
The initial Wireless Application Protocol partner companies- Nokia, Ericsson, Motorola and Phone.com (formerly Unwired Planet)- formed a limited company called WAP Forum Limited to administer the global Wireless Application Protocol specification process and get new companies involved in developing the protocol. By April 2000, the WAP Forum had over 250 member companies comprising of phone manufacturers, network operators, SMS Center suppliers and SMS software suppliers, amongst others.
Announced WAP Forum members include:
Alcatel, Ericsson, Matsushita Communication Industrial, Motorola, Nokia, Nortel, Philips Consumer Communications, Qualcomm, Samsung Electronics, Uniden Corporation, Bosch Telecom, Intel, NEC, Siemens.
APiON, Fujitsu Software Corporation, Geoworks, IBM, MD-Co, Psion Software, Sema Group Telecom, Sendit, Scandinavian Softline Technology, Spyglass, Starfish, Phone.com (formerly Unwired Planet), VTT Information Technology, CCI, CMG, Comverse Network Systems, CTC, Logica Aldiscon, Puma Technology, Tegic, TWS.
AT&T Wireless Services, BellSouth Cellular Corporation, DDI Corporation, Hongkong Telecom, SBC Communications, SFR, Sonera Corporation, Telecom Italia Mobile, Telenor, Telstra, T-Mobil, Vodafone, BT Cellnet, Dolphin, IDO, NTT DoCoMo, Rogers Cantel, Sprint PCS, Swisscom, Telia Mobile.
Certicom, RSA Data Security, De La Rue Card Systems, Gemplus, Schlumberger.
A full list can be viewed at www.wapforum.org/who/members.htm
WAP is a client server philosophy, requiring a microbrowser in the mobile phone and a WAP Gateway connected to the mobile network. By early 2000, WAP clients such as the Nokia 7110 were becoming available in quantity and other phone vendors such as Alcatel and Motorola have announced that they are introducing support for the Wireless Application Protocol across their entire product range. However, since WAP requires a larger screen size and more memory to handle the WAP stack, it costs more to produce a WAP handset and will therefore mean more expensive mobile phone prices. WAP phones will therefore be distinguishable from their non WAP counterparts to the informed observer- and will have the "WWW:MMM" branding anyway- which the WAP Forum founders have agreed on to depict WAP terminals. Support by mobile phones for WAP will be the simple largest determinant of when WAP is a success.
SIM Application Toolkit is another wireless protocol that enables a similar functionality set to WAP. SIM Application Toolkit has been around for longer than WAP and is at a later stage of development and deployment than WAP but is a GSM only technology that has not been widely adopted by leading mobile phone vendors such as Nokia and Ericsson. SIM Application Toolkit is supported by perhaps a quarter of the installed base of GSM phones. It may be that application developers need to support BOTH WAP and SIM Application Toolkit AND standard SMS in their Gateways so that the applications and services can be offered to ALL mobile phone users, rather than just a subset. Widespread reach is of course essential in maximizing use of the services and helping build a wireless Internet portal that is popular with all mobile phone users.
Despite today's lack of an installed base of WAP capable mobile phones, there are several vendors of WAP Gateways that network operators, content providers and application developers can work with to develop WAP-based services. WAP Gateways are installed into the mobile phone network to provide a gateway between the Internet and different mobile nonvoice services such as the Short Message Service, Circuit Switched Data and General Packet Radio Service. The WAP Gateway is essentially a piece of middleware, taking information from a web server, processing it, and sending it out over the mobile network to a WAP client.
Of the WAP Forum members, there are about a dozen suppliers of WAP Gateways. WAP Gateway suppliers include CMG, Nokia, Ericsson, Phone.com (formerly Unwired Planet), Materna and Motorola. SMS Server platform suppliers such as Sendit and Tecnomen have NOT developed their own WAP Gateway.
Phone.com announced its acquisition of APiON in September 1999.
(CUST). Denotes the extent to which the WAP Gateway has been widely deployed. Phone.com has by far the most installations globally, and is particularly strong in the North American market. Nokia follows on with strength in continental Europe in particular, and is competing with Phone.com in many of those markets. Ericsson follows on in third place. Materna and CMG have half a dozen installations each.
(COST). Denotes the cost of the platform.
CMG charges between a quarter and half a million US dollars for an entry
level WAP Gateway. This is considered a low entry cost by other WAP
Gateway vendors. Between 30 th June 1999 and 30th September 1999, Nokia
offered a free download of its WAP Gateway beta product from www.forum.nokia.com.
(WAP BEAR). Denotes the bearers that are supported by the WAP Gateway.
The majority of the WAP Gateways have been
designed as standalone WAP only Gateways, even by vendors that support
other non-WAP protocols and platforms. Materna supports Circuit Switched
Data (CSD) and the Short Message Service (SMS).
(NON WAP BEAR). Denotes the bearers such as
SIM Application Toolkit, standard SMS and so on that the WAP Gateway
supports in addition to the WAP bearers it supports. Nokia's WAP Gateway
also supports Nokia Smart Messaging, a proprietary and little used
(STAND COMP). Denotes the extent to which
the WAP Gateway complies with the standards set down by the WAP Forum.
Phone.com's UP.Server offers enhanced features and functionality that are
NOT currently incorporated into the WAP Forum specifications. As a result,
end users must have a UP.Browser enabled phone in order to fully utilize
Phone.com's offering. Nokia support the WAP standards to a high degree-
the only non-WAP feature that is incorporated into the Nokia 7110 handset
is the "Use Numbers" feature common to SMS.
(HARD). Denotes the type of hardware
platform the WAP Gateway runs on. Most network operators would prefer a
Unix platform that is considered more mature and stable than operating
systems such as Windows NT.
(BILL). Denotes the extent to which the WAP
Gateway incorporates a billing engine. A billing engine is important since
WAP is being positioned as a means through which companies with Internet
content or non-mobile services can mobilize those offerings. The plan is
to extend the mobile market into vertical market segments such as travel,
finance, hotels, retail and entertainment.
As such, we can see that each of the WAP Gateways have strengths and weaknesses. Selection will depend on intended use for the platform.
WAP is being used to develop enhanced forms of existing applications and new versions of today's applications.
Existing mobile data software and hardware
supplies are adding WAP support to their offering, either by developing
their own WAP interface or more usually partnering with one of the WAP
Gateway suppliers profiled above. WAP is 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
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:
Consumer Applications that are being enhanced and enabled with a WAP interface include:
These applications are described in the "Data on GPRS" book from Mobile Lifestreams (www.dataonGPRS.com).
The Wireless Application Protocol (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.
This white paper is a cut down
version of a 250 page report "YES
2 WAP", published by Mobile Lifestreams in April 2000, cost 250
US dollars. The full report contains detailed profiles of the WAP Gateway
vendors, other wireless protocols, plus case studies from around the
world. To order this or "YES 2 SMS" or "Data on GPRS",
contact Mobile Lifestreams by any of the methods listed below:
Copyright © 2000 Mobile Lifestreams Ltd
|Copyright©1999-2003 LibanPhone.com , Samir Saadi KHAYAT. All rights reserved|