An Overview of Wireless Application Protocol

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 standardised way that a mobile
phone talks to a server installed in the mobile phone network.
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.
The WAP information is broken down under a number of headins as listed below. We hope
that you find this information useful.
WAP is hot for several reasons:
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 standardi!ed way that a mobile
phone talks to a server installed in the mobile phone network. "t is ama!in how in #ust si$
months, it has become imperative for all "nformation Technoloy companies in %ordic
countries and beyond to have a WAP division. &any many advertisin aencies and
'dot.coms' have announced WAP services.
"t provides a standardised way of linkin the "nternet to mobile phones, thereby
linkin two of the fastest rowin industries anywhere
"ts founder members include the ma#or wireless vendors of %okia, (ricsson and
&otorola, plus a newcomer Phone.com
The WAP )orum has over *+, member companies
&obile information services, a key application for WAP, have not been as successful
as many network operators e$pected. WAP is seen as a way to rectify this situation.
WAP also has its detractors and controversies-
"t is very difficult to confiure WAP phones for new WAP services, with +, or so
different parameters needin to be entered to ain access to a WAP service. This is
described in details for the %okia .**, and &otorola / series in this new edition of
'0ata on WAP'.
There are few mobile phones that support WAP and widespread WAP support in
handsets is unlikely for a lon time. 1ommercial 2uantities of WAP phones are not
e$pected until towards the end of 3uarter * +,,,.
WAP is a protocol that runs on top of an underlyin bearer. %one of the e$istin 45&
bearers for WAP- the 5hort &essae 5ervice (5&5), 6nstructured 5upplementary
5ervices 0ata (6550) and 1ircuit 5witched 0ata (150) are optimi!ed for WAP.
The WAP standard is incomplete, with key elements such as Push (proactive sendin
of information to mobile devices) and wireless telephony (updatin address reports
and the like) not yet standardi!ed (they will be standardi!ed in WAP *.+, due for
standardi!ation in late *777 and first implementation in 5prin +,,,).
There are many WAP 4ateway vendors out there competin aainst each other with
larely the same standardi!ed product. This has led to consolidation such as the
pendin ac2uisition of APi8% by Phone.com.
8ther protocols such as 5"& Application Toolkit and &obile 5tation Application
($ecution (nvironment (&e$() are respectively already widely supported or desined
to supercede WAP.
WAP services are e$pected to be e$pensive to use since the tendency is to be on-line
for a lon 1ircuit 5witched 0ata (150) call as features such as interactivity and
selection of more information are used by the end user. Without specific tariff
initiatives, there are likely to be some surprised WAP users when they see their
mobile phone bill for the first time after startin usin WAP.
WAP Formation and Philosophy
Formation
&otorola, %okia, (ricsson and the 65 software company Phone.com (formerly 6nwired
Planet) were the initial partners that teamed up over two years ao in mid *77. to develop
and deploy the Wireless Application Protocol (WAP). WAP is an attempt to define the
standard for how content from the "nternet is filtered for mobile communications. 1ontent is
now readily available on the "nternet and WAP was desined as the (rather than one) way of
makin it easily available on mobile terminals.
The WAP )orum was formed after a 65 network operator 8mnipoint issued a tender for the
supply of mobile information services in early *77.. "t received several responses from
different suppliers usin proprietary techni2ues for deliverin the information such as 5mart
&essain from %okia and 90&/ from Phone.com (then called 6nwired Planet). 8mnipoint
informed the tender responders that it would not accept a proprietary approach and
recommended that that various vendors et toether to e$plore definin a common standard.
After all, there was not a reat deal of difference between the different approaches, which
could be combined and e$tended to form a powerful standard. These events were the initial
stimulus behind the development of the Wireless Application Protocol, with (ricsson and
&otorola #oinin %okia and 6nwired Planet as the founder members of the WAP )orum.
Philosophy
The Wireless Application Protocol takes a client server approach. "t incorporates a relatively
simple microbrowser into the mobile phone, re2uirin only limited resources on the mobile
phone. This makes WAP suitable for thin clients and early smart phones. WAP puts the
intellience in the WAP 4ateways whilst addin #ust a microbrowser to the mobile phones
themselves. &icrobrowser-based services and applications reside temporarily on servers, not
permanently in phones. The Wireless Application Protocol is aimed at turnin a mass-market
mobile phone into a 'network-based smartphone'. As a representative from Phone.com
(formerly 6nwired Planet) on the board of the WAP )orum commented 'The philosophy
behind Wireless Application Protocol:s approach is to utilise as few resources as possible on
the handheld device and compensate for the constraints of the device by enrichin the
functionality of the network'.
The Wireless Application Protocol is envisaed as a comprehensive and scaleable protocol
desined for use with-
any mobile phone from those with a one line display to a smart phone,
any e$istin or planned wireless service such as the 5hort &essae 5ervice, 1ircuit
5witched 0ata, 6nstructured 5upplementary 5ervices 0ata (6550) and 4eneral
Packet ;adio 5ervice (4P;5).
"ndeed, 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 desin of
the WAP standard separates the application elements from the bearer bein used.
This helps in the miration of some applications from 5&5 or 1ircuit 5witched 0ata to
4P;5 for e$ample.
any mobile network standard such as 1ode 0ivision &ultiple Access (10&A), 4lobal
5ystem for &obiles (45&), or 6niversal &obile Telephone 5ystem (6&T5). WAP has
been desined to work with all cellular standards and is supported by ma#or
worldwide wireless leaders such as AT<T Wireless and %TT 0o1o&o,
multiple input terminals such as keypads, keyboards, touch-screens and styluses.
Technical Introduction
Please note that it is the purpose of this section to supplement the content of the WAP
standards with conte$t that allows readers to understand WAP:s importance and related
issues. As such, we will not be spendin much time reproducin the published WAP
standards that can be freely downloaded from the WAP )orum web site
http-==www.WAPforum.or= by readers.
The Wireless Application Protocol embraces and e$tends the previously conceived and
developed wireless data protocols. Phone.com created a version of the standard 9T&/
(9yperTe$t &arkup /anuae) "nternet protocols desined specifically for effective and cost-
effective information transfer across mobile networks. Wireless terminals incorporated a
90&/ (9andheld 0evice &arkup /anuae) microbrowser, and Phone.com:s 9andheld
0evice Transport Protocol (90TP) then linked the terminal to the 6P./ink 5erver 5uite which
connected to the "nternet or intranet where the information bein re2uested resides. The
"nternet site content was taed with 90&/.
This technoloy was incorporated into WAP - and renamed usin some of the many WAP-
related acronyms such as W&/5, WTP and W5P. 5omeone with a WAP-compliant phone
uses the in-built microbrowser to-
*. &ake a re2uest in W&/ (Wireless &arkup /anuae), a lanuae derived from
9T&/ especially for wireless network characteristics.
+. This re2uest is passed to a WAP 4ateway that then retrieves the information from an
"nternet server either in standard 9T&/ format or preferably directly prepared for
wireless terminals usin W&/. "f the content bein retrieved is in 9T&/ format, a filter
in the WAP 4ateway may try to translate it into W&/. A W&/ scriptin lanuae is
available to format data such as calendar entries and electronic business cards for
direct incorporation into the client device.
>. The re2uested information is then sent from the WAP 4ateway to the WAP client,
usin whatever mobile network bearer service is available and most appropriate.
WAP Protocol Stack
WAP has a layered architecture as shown in the diaram below-
Wireless Application (nvironment (WA()
Wireless 5ession Protocol (W5P)
Wireless Transaction Protocol (WTP)
Wireless Transport /ayer 5ecurity (WT/5)
Wireless 0ataram Protocol (W0P)
?earers e.. 0ata, 5&5, 6550
Wireless Application (nvironment
Wireless 5ession Protocol
Wireless Transaction Protocol
Wireless Transport /ayer 5ecurity
Wireless 0ataram Protocol
/et us take a look at each layer in the WAP protocol stack-
Wireless Application Environment
The WA( defines the user interface on the phone. The application development
environment to facilitate the development of services that support multiple bearers. To
achieve this, the WA( contains the Wireless &arkup /anuae (W&/), W&/5cript -
a scriptin micro-lanuae similar to @ava5cript - 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 WA( to two session services - one connection
oriented operatin above the Wireless Transaction Protocol and a connectionless
service operatin above the Wireless 0ataram Protocol
Wireless Transaction Protocol
;uns on top of a dataram service such as 6ser 0ataram Protocol (60P)A part of
the standard suite of T1P="P protocols, to provide a simplified protocol suitable for low
bandwidth mobile stations. WTP offers three classes of transaction service- unreliable
one way re2uest, reliable one way re2uest and reliable two way re2uest respond.
"nterestinly, WTP supports Protocol 0ata 6nit concatenation and delayed
acknowledement to help reduce the number of messaes sent. This protocol
therefore tries to optimise the user e$perience by providin the information that is
needed when it is needed - it can be confusin to received confirmation of delivery
messaes when you are e$pectin the information itself. ?y strinin several
messaes toether, the end user may well be able to et a better feel more 2uickly
for what information is bein communicated.
Wireless Transport ayer Security
WT/5 incorporates security features that are based upon the established Transport
/ayer 5ecurity (T/5) protocol standard. "ncludes data interity checks, privacy on the
WAP 4ateway to client le and authentication.
Wireless !ata"ram Protocol
Allows WAP to be bearer independent by adaptin the transport layer of the
underlyin bearer. W0P presents a consistent data format to the hiher layers of the
WAP protocol stack thereby conferrin the advantae of bearer independence to
application developers.
Optimal WAP #earer
5hort &essae 5ervice
1ircuit 5witched 0ata
6nstructured 5upplementary 5ervices 0ata
4eneral Packet ;adio 5ervice
Short $essa"e Service
5ee http-==www.mobile5&5.com=
4iven its limited lenth of *B, characters per short messae, 5&5 may not be an
ade2uate bearer for WAP because of the weiht protocol of the protocol. The
overhead of the WAP protocol that would be re2uired to be transmitted in an 5&5
messae would mean that even for the simplest of transactions several 5&5
messaes may in fact have to be sent. This means that usin 5&5 as a bearer can
be a time consumin and e$pensive e$ercise. 8nly one network operator - 5?1 of
the 65 - is known to be developin WAP services based on 5&5.
%ircuit Switched !ata
&ost of the trial WAP based services use 150 as the underlyin bearer. 5ince 150
has relatively few users currently, WAP could kickstart usae of and traffic enerated
by this bearer.
9owever, 150 lacks immediacy- a dial up connection takin about *, seconds is
re2uired to connect the WAP client to the WAP 4ateway, and this is the best case
scenario when there is an complete end to end diital call- in the case of the need for
analo modem handshakin (because the WAP phone does not support C.**, the
diital protocol, or the WAP 4ateway does not have a diital direct connection such
as "50% into the mobile network), the connect time is increased to about >, seconds.
&nstructured Supplementary Services !ata
5ee http-==www.mobile6550.com=
6nstructured 5upplementary 5ervices 0ata (6550) is a means of transmittin
information or instructions over a 45& network. 6550 has some similarities with
5&5 since both use the 45& network:s sinallin path. 6nlike 5&5, 6550 is not a
store and forward service and is session-oriented such that when a user accesses a
6550 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 1ircuit
5witched 0ata than 5&5. 6550 te$t messaes can be up to *D+ characters in
lenth.
6550 has some advantaes and disadvantaes as a tool for deployin services on
mobile networks-
Turnaround response times for interactive applications are shorter for 6550
than 5&5 because of the session-based feature of 6550, and because it is
%8T a store and forward service. Accordin to %okia, 6550 can be up to
seven times faster than 5&5 to carry out the same two-way transaction.
6sers do not need to access any particular phone menu to access services
with 6550- they can enter the 6nstructured 5upplementary 5ervices 0ata
(6550) command direct from the initial mobile phone screen.
?ecause 6550 commands are routed back to the home mobile network:s
9ome /ocation ;eister (9/;), services based on 6550 work #ust as well
and in e$actly the same way when users are roamin.
6nstructured 5upplementary 5ervices 0ata (6550) works on all e$istin
45& mobile phones.
?oth 5"& Application Toolkit and the Wireless Application Protocol support
6550.
6550 5tae + has been incorporated into the 45& standard. Whereas
6550 was previously a one way bearer useful for administrative purposes
such as service access, 5tae + is more advanced and interactive. ?y
sendin in a 6550+ command, the user can receive an information services
menu. As such, 6550 5tae + provides WAP-like features on (E"5T"%4
phones.
6550 strins are typically complicated for the user to remember, involvin
the use of the 'F' and 'G' characters to denote the start and finish of the
6550 strin. 9owever, 6550) strins for reularly used services can be
stored in the phonebook, reducin the need to remember and re-enter them.
As such, 6550 could be an ideal bearer for WAP on 45& networks.
'eneral Packet (adio Service
5ee http-==www.mobile4P;5.com=
The 4eneral Packet ;adio 5ervice (4P;5) is a new packet-based bearer that is
bein introduced on many 45& and T0&A mobile networks from the year +,,,
onwards. "t is an e$citin new bearer because it is immediate (there is no dial up
connection), relatively fast (up to *...+ kbps in the very best theoretical e$treme) and
supports virtual connectivity, allowin relevant information to be sent from the network
as and when it is enerated.
At the time of writin in early Auust *777, there has been no confirmation from any
handset vendors that mobile terminated 4P;5 traffic (i.e. direct receipt of 4P;5
packets on the mobile phone) will be supported by the initial 4P;5 terminals.
Availability or not of 4P;5 &T is a central 2uestion with critical impact on the 4P;5
business case such as application miration from other nonvoice bearers.
There are two efficient means of deliverin proactively sendin ('pushin') content to
a mobile phone- by the 5hort &essae 5ervice which is of course one of WAP
bearers or by the user maintainin more or less a permanent 4P;5 (mobile
oriinated) session with the content server. 9owever, mobile terminated "P traffic
miht allow unsolicited information to reach the terminal. "nternet sources oriinatin
such unsolicited content may not be chareable. A possible worse case scenario
would be that mobile users would have to pay for receivin unsolicited #unk content.
This is a potential reason for a mobile vendor %8T to support 4P;5 &obile
Terminate in their 4P;5 terminals. 9owever, by oriinatin the session themselves
from their handset, users confirm their areement to pay for the delivery of content
from that service. 6sers could make their re2uests 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 4P;5 users can receive information
onto their mobile terminals.
5ince all but the early WAP enabled phones will also support the 4eneral Packet
;adio 5ervice, WAP and 4P;5 could well be syneristic and be used widely
toether. )or the kinds of interactive, menu based information e$chanes that WAP
anticipates, 1ircuit 5witched 0ata is not immediate enouh because of the need to
set up a call. (arly prototypes of WAP services based on 1ircuit 5witched 0ata were
therefore close to unusable. 5&5 on the other hand is immediate but is A/WAH5
store and forward, such that even when a subscriber has #ust re2uested information
from their microbrowser, the 5&5 1entre resources are used in the information
transfer. As such, 4P;5 and WAP are ideal bearers for each other.
Additionally, WAP incorporates two different connection modes - W5P connection
mode or W5P connectionless protocol. This is very similar to the two 4P;5 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 4P;5 terminals. "f WAP terminals
are delayed until the year +,,,, most WAP terminals will support 4P;5 as well. "f the
first WAP terminals support 5&5 and 1ircuit 5witched 0ata, but not 4P;5, then
5&5 could become the predominant initial WAP bearer.
WAP certainly will be important for the development of 4P;5-based applications.
?ecause the bearer level is separated from the application layer in the WAP protocol
stack, WAP provides the ideal and defined and standardised means to port the same
application to different bearers. As such, many application developers will use WAP to
facilitate the miration of their applications across bearers once 4P;5 based WAP
protocols are supported.
WAP !evelopment Issues
There are several non-standardised or unresolved issues relatin to WAP that application
developers should be aware of-
Push %ot 5upported
Wireless Telephony Application %ot 0efined
/ack of 1ookies for 5ession &anaement
Premature (ncryption (ndpoint
5mall 0ownloadable 6nit 5i!e
W0P 0ataram Protocol
WAP Cersion *.+
Push )ot Supported
The WAP W5P specification defines the W5P push operation and a W5P push P06
(Protocol 0ata 6nit). A push operation is not specified for the 9TTP protocol, used by
the WAP 4ateway server to communicate with content hosts. To support pushes, the
server has to provide an application interface to allow server based applications to
enerate 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 %okia 8TA
confiuration proposal to the WAP )orum describes the use of a connectionless push
over the 5&5 bearer, to transfer the confiuration data to the handset.
Wireless Telephony Application )ot !efined
The so-called Wireless Telephony Application (WTA) has been discussed by the WAP
)orum but not yet defined or likely to be defined anytime soon. The WTA ives WAP
some of the features that 5"& Application Toolkit incorporates such as access to
phone report and call handlin.
ack of %ookies for Session $ana"ement
There are no 'cookies' for session manaement, i.e. to hold the session toether.
1ookies are used on the fi$ed "nternet to identify the web browser and thereby assist
in providin customised and streamlined services. "nstead, some WAP applications
use inde$es in the 6;/ as an alternative.
The cookie information is transmitted via 9TTP headers. ?ecause WAP W5P is
based on 9TTP 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
handlin of cookie 9TTP header information or to save this information to a persistent
storae in the mobile phone.
Premature Encryption Endpoint
The Wireless Transport /ayer 5ecurity defines encryption between the &obile 5tation
and the WAP 4ateway. The 'endpoint' of the encrypted WT/5 data is the WAP
4ateway pro$y server. To have a secure connection to a content host (e.. bankin
server) the ateway pro$y server has to establish secure (https) connections to this
hosts. "n this case the pro$y server has access to the decrypted data received via
WT/5 from the mobile station or from the content host via https.
Small !ownloada*le &nit Si+e
WAP incorporates no compression techni2ues for the te$tual content, althouh the
W&/ markup commands are compressed. Additionally, the 'deck' - the smallest unit
of downloadable information in Wireless &ark6p /anuae - is limited to a ma$imum
of *I,, bytes. This means that applications need to be specifically desined to be
very code efficient by usin templates and variables and keepin information on the
server and usin the cache on the phone.
W&/ byte code convertin defines a (maybe inefficient) compression techni2ue by
strin tables. With this techni2ue duplicate strins in the W&/1 bytecode are
avoided. This reduces the si!e of the data to transfer to the mobile client. The W5P
506 si!e of *I,, bytes is a default value. An increased si!e may be neotiated by a
mobile client within the W5P capabilities. The WAP transport layer (WTP) is able to
handle reater 506 si!es than *I,, bytes too, by usin 5A; (5ementation and ;e-
assembly).
W!P !ata"ram Protocol
The 5eptember *777 /ondon meetin of the WAP )orum included a decision from
the 5&5 ($perts 4roup that the sinle common standardi!ed interface between the
5&5 1enter and the WAP 4ateway would be a subset of 5&PP (5hort &essae
Peer to Peer Protocol). A P06 (Protocol 0ata 6nit) set has been added to 5&PP
version >.I for this purpose. There will be no 5&PP specific leacy- in other words,
5&5 1enter manufacturers that do not support 5&PP can evolve their 5&5 1enter
e$ternal interface to support the new 5&PP commands for connectin to WAP
4ateways.
?asically, this is a victory for /oica, the creators of 5&PP, who spun control of the
protocol off in *777 to an 'independent' 5&PP )orum (see www.smpp.or). The
wordin of this resolution was careful to avoid mention of the political battle between
the pro-5&PP companies such as /oica and those opposed to it such as 1&4.
?asically, the 65 carriers insisted upon 5&PP and swun the vote.
WAP ,ersion -./
WAP version *.+ is e$pected to be finali!ed as a specification in late *777 and first
available in sprin +,,,. "t will support Push services (proactive delivery of
information from a WAP 4ateway to a WAP terminal), 6ser Profiles, W0P Tunnelin,
W&/script, 1rypto/ibrary, Wireless Telephony Application, Wireless Application
(nvironment enhancements and other features.
As such, WAP version *.+ may be the first version of the protocol that is actually
workable in terms of deliverin easy to use and innovative non-voice mobile services.
1learly, as the WAP specifications evolve, some of these issues will be resolved.
9owever, prorammers need to be aware of them when they commence WAP
application desin.
WAP !eveloper0s Toolkits
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 0ynamical 5ystems
;esearch (05;), (ricsson, %okia, Phone.com and &otorola.
0ynamical 5ystems ;esearch (05;)
(ricsson
%okia
Phone.1om
&otorola
!ynamical Systems (esearch 1!S(2
&arcel van der 9eyden, WAP Product &anaer
Tel- JII *.* D,* ,*7*
5ee http-==www.wap.net=devkit= or email developerKwap.net or marcelKairmail.nl
Ericsson
(ricsson has a WAP-"0( ("nterated 0eveloper:s (nvironment) offerin for WAP 0evelopers
that can be downloaded free of chare from http-==mobileinternet.ericsson.se=
)okia
The WAP Toolkit for developin applications can be downloaded from
http-==www.forum.nokia.com=
Phone.%om
9ave an 6P.50L for application developers that can be downloaded from
http-==updev.phone.com= Also features a white paper statin why developers should use
Phone.com:s software development kit in preference to any others.
An independent survey of these four 50Ls found them to be very similar. This survey was
featured in the e$cellent Wireless 0ata %ews 5urveillance ;eport (W0%5;) (&obile
/ifestreams is a reseller of this publication. 5ee http-==www.finnevo.fi=77,.+>*7.htm for
sample copies and a subscription form).
$otorola
The &obile Application 0evelopment Lit (&obile A0L) enables third-party developers to
create their own add-on voice and data solutions. 0ownload from
http-==www.motorola.com=mobileadk
WAP Forum $em*ers ist
The initial Wireless Application Protocol partner companies - %okia, (ricsson, &otorola and
Phone.com (formerly 6nwired Planet) - formed a limited company called WAP )orum /imited
to administer the lobal Wireless Application Protocol specification process and et new
companies involved in developin the protocol.
?y Auust *777, the WAP )orum had over *+, members comprisin ma#or phone
manufacturers, network operators, 5&5 1entre suppliers and 5&5 software suppliers.
Announced WAP )orum members include-
Telecommunications 9ardware
Telecommunications 5oftware
&obile Telephone %etwork 8perators
5mart 1ards and 5ecurity
Telecommunications 3ardware
Alcatel, (ricsson, &atsushita 1ommunication "ndustrial, &otorola, %okia, %ortel,
Philips 1onsumer 1ommunications, 3ualcomm, 5amsun (lectronics, 6niden
1orporation, ?osch Telecom, "ntel, %(1, 5iemens.
Telecommunications Software
APi8%, )u#itsu 5oftware 1orporation, 4eoworks, "?&, &0-1o, Psion 5oftware, 5ema
4roup Telecom, 5endit, 5candinavian 5oftline Technoloy, 5pylass, 5tarfish,
Phone.com (formerly 6nwired Planet), CTT "nformation Technoloy, 11", 1&4,
1omverse %etwork 5ystems, 1T1, /oica Aldiscon, Puma Technoloy, Teic, TW5.
$o*ile Telephone )etwork Operators
AT<T Wireless 5ervices, ?ell5outh 1ellular 1orporation, 00" 1orporation, 9onkon
Telecom, 5?1 1ommunications, 5);, 5onera 1orporation, Telecom "talia &obile,
Telenor, Telstra, T-&obil, Codafone, ?T 1ellnet, 0olphin, "08, %TT 0o1o&o, ;oers
1antel, 5print P15, 5wisscom, Telia &obile.
Smart %ards and Security
1erticom, ;5A 0ata 5ecurity, 0e /a ;ue 1ard 5ystems, 4emplus, 5chlumberer.
A full list can be viewed at http-==www.wapforum.or=who=members.htm
"n &ay *777, &icrosoft rapidly e$tended its support of WAP by #oinin the WAP
)orum and ac2uirin 5endit, a stron backer of WAP.
WAP %lients and 'ateways
WAP is a client server philosophy, re2uirin a microbrowser in the mobile phone and a WAP
4ateway connected to the mobile network. ?y the middle of *777, WAP clients such as the
%okia .**, were becomin available in 2uantity and other phone vendors such as Alcatel and
&otorola have announced that they are introducin support for the Wireless Application
Protocol across their entire product rane. 9owever, since WAP re2uires a larer screen si!e
and more memory to handle the WAP stack, it costs more to produce a WAP handset and will
therefore mean more e$pensive mobile phone prices. WAP phones will therefore be
distinuishable from their non WAP counterparts to the informed observer- and will have the
'WWW-&&&' brandin anyway - which the WAP )orum founders have areed on to depict
WAP terminals. 5upport by mobile phones for WAP will be the simple larest determinant of
when WAP is a success.
5"& Application Toolkit is another wireless protocol that enables a similar functionality set to
WAP. 5"& Application Toolkit has been around for loner than WAP and is at a later stae of
development and deployment than WAP but is a 45& only technoloy that has not been
widely adopted by leadin mobile phone vendors such as %okia and (ricsson. 5"&
Application Toolkit is supported by perhaps a 2uarter of the installed base of 45& phones. "t
may be that application developers need to support ?8T9 WAP and 5"& Application Toolkit
A%0 standard 5&5 in their 4ateways so that the applications and services can be offered to
A// mobile phone users, rather than #ust a subset. Widespread reach is of course essential in
ma$imisin use of the services and helpin build a wireless "nternet portal that is popular with
all mobile phone users.
0espite today:s lack of an installed base of WAP capable mobile phones, there are several
vendors of WAP 4ateways that network operators, content providers and application
developers can work with to develop WAP-based services. WAP 4ateways are installed into
the mobile phone network to provide a ateway between the "nternet and different mobile
nonvoice services such as the 5hort &essae 5ervice, 1ircuit 5witched 0ata and 4eneral
Packet ;adio 5ervice. The WAP 4ateway is essentially a piece of middleware, takin
information from a web server, processin it, and sendin it out over the mobile network to a
WAP client.
8f the WAP )orum members, there are about a do!en suppliers of WAP 4ateways. These
WAP 4ateway suppliers are all tryin to sin up mobile network operators who are lookin to
trial WAP services and ain some market feedback. WAP trials will commence in the summer
of *777.
WAP 4ateway suppliers include 1&4, %okia, (ricsson, Phone.com (formerly 6nwired
Planet), 55T, 0r. &aterna, APi8%, &0-1o, Akumiitti and 8racle. 5&5 5erver platform
suppliers such as 5endit and Tecnomen have %8T developed their own WAP 4ateway.
Phone.com announced its ac2uisition of APi8% in 5eptember *777.
1lick here to see a comparison between these WAP 4ateway suppliers and their offerins.
%omparison of WAP 'ateways
0eployment
1ost
WAP ?earer 5upport
%8%-WAP ?earer 5upport
WAP 5tandards 1ompliance
9ardware
?illin
The vendors APi8%, 1&4, 0r. &aterna, (ricsson, %okia and
Phone.com are ranked accordin to the followin comparison criteria-
,E)!O( %&ST %OST WAP
#EA(
)O)4
WAP
#EA(
WAP
STA)!
%O$P
3A(! #I
APi8% &ed 9ih 9ih /ow &ed 9ih &ed
1&4 /ow 9ih &ed 9ih 9ih 9ih 9ih
0r. &aterna &ed &ed /ow /ow 9ih 9ih 9in
(ricsson &ed %=A 9ih &ed 9ih /ow &ed
%okia 9ih 9ih &ed /ow 9ih /ow 9ih
Phone.com Cery
9ih
&ed 9ih &ed /ow &ed &ed
Source: &obile /ifestreams /imited.
)ote: A ratin of '9ih' is better than '&ed' and '&ed' is a hiher
score than '/ow'.
%ow that we have reviewed each of these ateway vendors, we will
compare the key features-
!eployment
(165T). 0enotes the e$tent to which the WAP 4ateway has been
widely deployed. 1&4 has announced five customers for its Wireless
1ontent ?roker. APi8% has announced *, 45& operators. 0r.
&aterna is in the process of announcin its WAP customers. 0+ is also
usin the Phone.com and (ricsson Web8nAir platform). ?oth %okia
and (ricsson are bein used by a do!en or more network operators.
Phone.com has about >M network operators sined to use its
6P.5erver platform (e$cludin its pendin ac2uisition of APi8%).
%ost
(185T). 0enotes the cost of the platform. APi8% offers pay as WAP traffic rows
pricin options. 1&4 chare between a 2uarter and half a million 65 dollars for an
entry level WAP 4ateway. This is considered a low entry cost by other WAP 4ateway
vendors. ?etween >,th @une *777 and >,th 5eptember *777, %okia will be offerin a
free download of its WAP 4ateway *., beta product from
http-==www.forum.nokia.com=. "t offers essentially the same WAP product under two
different product names to two different customer roups at two different prices. 0r.
&aterna e$pect their WAP 4ateway to be priced above that of 1&4, but pricin is still
to be determined.
WAP #earer Support
(WAP ?(A;). 0enotes the bearers that are supported by the WAP 4ateway. The
ma#ority of the WAP 4ateways have been desined as standalone WAP only
ateways, even by vendors that support other non-WAP protocols and platforms. 0r.
&aterna only supports 1ircuit 5witched 0ata as a bearer, althouh 5&5 is planned.
APi8% supports both 1ircuit 5witched 0ata and 5&5, and also 6550 if 5&PP is
used as the protocol to the 6550 server (as in the case of, for e$ample, /oica
Aldiscon:s 6550 server). %okia and 1&4 both support both 5&5 and 1ircuit
5witched 0ata. Phone.com:s 6P.5erver supports by far the widest rane of bearers -
from 45& bearers to many other airlink standards. (ricsson:s WAP 4ateway
supports 1ircuit 5witched 0ata, 5&5 and 6550.
)O)4WAP #earer Support
(%8% WAP ?(A;). 0enotes the bearers such as 5"& Application Toolkit, standard
5&5 and so on that the WAP 4ateway supports in addition to the WAP bearers it
supports. APi8% is a company that focuses on WAP only. 0r. &aterna supports other
bearers such as 1ell ?roadcast and 5&5 in its other platforms, but not its WAP
4ateway. %okia:s WAP 4ateway also supports %okia 5mart &essain, a proprietary
and little used wireless protocol. 1&4 also supports standard 5&5, which is
important since most all of the current installed base of mobile phones supports this
nonvoice service, as will all new phones. (ricsson:s WAP 4ateway does not support
5"& Toolkit, althouh its Web8nAir platform does.
WAP Standards %ompliance
(5TA%0 18&P). 0enotes the e$tent to which the WAP 4ateway complies with the
standards set down by the WAP )orum. Phone.com:s 6P.5erver offers enhanced
features and functionality that are %8T currently incorporated into the WAP )orum
specifications. As a result, end users must have a 6P.?rowser enabled phone in
order to fully utilise Phone.com:s offerin. %okia support the WAP standards to a hih
deree - the only non-WAP feature that is incorporated into the %okia .**, handset is
the '6se %umbers' feature common to 5&5. This would be part of the non-
standardised Wireless Telephony Application (WTA). APi8% too closely complies with
the WAP *.* standards, althouh it has e$tended this to include content push
capability that is not currently incorporated into the WAP standards. (ricsson
supports WAP *.* and will implement other standardi!ed features such as push and
Wireless Telephony Application as they are incorporated into the WAP standard.
3ardware
(9A;0). 0enotes the type of hardware platform the WAP 4ateway runs on. &ost
network operators would prefer a 6ni$ platform that is considered more mature and
stable than operatin systems such as Windows %T. %okia:s WAP platform is based
on a Windows %T platform, althouh 6ni$ variants are bein developed. (ricsson:s
WAP 4ateway is based on Windows %T. APi8%, 0r. &aterna and 1&4 all supply
their WAP 4ateways on a 6ni$ platform.
#illin"
(?"//). 0enotes the e$tent to which the WAP 4ateway incorporates a billin enine. A
billin enine is important since WAP is bein positioned as a means throuh which
companies with "nternet content or non-mobile services can mobilise those offerins.
The plan is to e$tend the mobile market into vertical market sements such as travel,
finance, hotels, retail and entertainment. A billin enine allows these players to make
money from their WAP-based offerins. ;econisin the importance of bein able to
bill for content, 1&4, 0r. &aterna and %okia have all included a billin enine with
the WAP 4ateway itself. %okia:s WAP 4ateway also includes a 5erver ($tension AP"
for developin an interface to incumbent billin systems.
As such, we can see that each of the WAP 4ateways have strenths and
weaknesses. 5election will depend on intended use for the platform.
Applications
WAP is bein used to develop enhanced forms of e$istin applications and new versions of
today:s applications. ($istin mobile data software and hardware supplies are addin WAP
support to their offerin, either by developin their own WAP interface or more usually
partnerin with one of the WAP 4ateway suppliers profiled above. WAP is also iven a
sinificant impetus for new players to add mobile as a new distribution channel for their
e$istin products and services - for e$ample, 1%% and %okia teamed up to offer 1%% &obile
and ;euters and (ricsson teamed up to provide ;euters Wireless 5ervices. The Wireless
Application Protocol will allow customers to easily reply to incomin information on the phone
by allowin new menus to access mobile services. This is part of the business case for
network operators - by makin the value-added services more easily to reply to and re2uest
(usin menus instead of keywords, for e$ample), WAP can help enerate additional traffic on
the network and therefore revenue.
Previously, application developers wrote proprietary software applications and had to port that
application to different network types and bearers within the same platform. ?y separatin the
bearer from the application, WAP facilitates easy miration of applications between networks
and bearers. As such, WAP is similar to @ava in that it simplifies application development. This
reduces the cost of wireless application development and therefore encouraes entry to the
mobile industry by software developers.
1orporate Applications
1onsumer Applications
%orporate Applications
1orporate applications that are bein enhanced and enabled with a WAP interface
include-
@ob 0ispatch
;emote Point 8f 5ale
1ustomer 5ervice
;emote &onitorin 5uch As &eter ;eadin
Cehicle Positionin
1orporate (mail
;emote /A% Access
)ile Transfer
Web ?rowsin
0ocument 5harin=1ollaborative Workin
Audio
5till "maes
&ovin "maes
9ome Automation
%onsumer Applications
1onsumer applications that are bein enhanced and enabled with a WAP interface
include-
5imple Person to Person &essain
Coice and )a$ &ail %otifications
6nified &essain
"nternet (mail
Prepayment
;intones
&obile 1ommerce
Affinity Prorams
&obile ?ankin
1hat
"nformation 5ervices
These applications are described in the '0ata on 4P;5' book from &obile
/ifestreams (http-==www.dataon4P;5.com=).