The Wireless Application
Protocol (WAP) is a topic that has been widely hyped in the
mobile networks industry and outside of it. WAP is simply a
standardised way that a mobile phone talks to a server installed
in the mobile phone network.
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. WAP information is broken down under a number of
headings as listed below.
WAP Formation and Philosophy
Formation
Motorola, Nokia, Ericsson and
the US software company Phone.com (formerly Unwired Planet) were
the initial partners that teamed up over three years ago in mid
1997 to develop and deploy the Wireless Application Protocol. 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 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.
Philosophy
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 on the board
of the WAP Forum 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 enriching the functionality of the
network".
The Wireless Application
Protocol is envisaged as a comprehensive and scaleable protocol
designed for use with:
Any mobile phone
from those with a one line display to a smart
phone,
Any existing or
planned wireless service such as the Short
Message Service, Circuit Switched Data,
Unstructured Supplementary Services Data (USSD)
and General Packet Radio Service (GPRS). 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.
Any mobile network
standard such as Code Division Multiple Access
(CDMA), Global System for Mobiles (GSM), or
Universal Mobile Telephone System (UMTS). WAP has
been designed to work with all cellular standards
and is supported by major worldwide wireless
leaders such as AT&T Wireless and NTT DoCoMo,
Multiple input
terminals such as keypads, keyboards,
touch-screens and styluses
Technical Introduction
Published WAP standards can be
freely downloaded from the WAP Forum web site http://www.WAPforum.org/.
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 nd 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:
Make a request in WML
(Wireless Markup Language), a language derived from HTML
especially for wireless network characteristics.
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.
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
WAP has a layered architecture
and this section discusses the the WAP protocol stack :
Wireless Application
Environment
The WAE 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 WAE contains
the Wireless Markup Language (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
operating above the Wireless Transaction Protocol and a
connectionless service operating above the Wireless Datagram
Protocol.
Wireless Transaction
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
optimise 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
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.
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.
Circuit Switched Data
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.
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
signalling 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:
Turnaround
response times for interactive applications are
shorter for USSD than SMS because of the
session-based feature of USSD, and because it is
NOT a store and forward service. According to
Nokia, USSD can be up to seven times faster than
SMS to carry out the same two-way transaction.
Users do not need
to access any particular phone menu to access
services with USSD- they can enter the
Unstructured Supplementary Services Data (USSD)
command direct from the initial mobile phone
screen.
Because USSD
commands are routed back to the home mobile
network's Home Location Register (HLR), services
based on USSD work just as well and in exactly
the same way when users are roaming.
Unstructured
Supplementary Services Data (USSD) works on all
existing GSM mobile phones.
Both SIM
Application Toolkit and the Wireless Application
Protocol support USSD.
USSD Stage 2 has
been incorporated into the GSM standard. Whereas
USSD was previously a one way bearer useful for
administrative purposes such as service access,
Stage 2 is more advanced and interactive. By
sending in a USSD2 command, the user can receive
an information services menu. As such, USSD Stage
2 provides WAP-like features on EXISTING phones.
USSD strings are
typically complicated for the user to remember,
involving the use of the "*" and
"#" characters to denote the start and
finish of the USSD string. However, USSD) strings
for regularly used services can be stored in the
phonebook, reducing the need to remember and
re-enter them.
As such, USSD could be an
ideal bearer for WAP on GSM networks.
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 in
early August 1999, 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 Centre 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 standardised 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 Development Issues
There are several
non-standardised or unresolved issues relating to WAP that
application developers should be aware of:
Push Not Supported
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.
Wireless Telephony
Application Not Defined
The so-called Wireless
Telephony Application (WTA) has been discussed by the WAP
Forum but not yet defined or likely to be defined anytime
soon. The WTA gives WAP some of the features that SIM
Application Toolkit incorporates such as access to phone
report and call handling.
Lack of Cookies for
Session Management
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
customised 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.
Premature Encryption
Endpoint
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.
Small Downloadable Unit
Size
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
bytes too, by using SAR (Segmentation and Re-assembly).
WDP Datagram Protocol
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 (see
www.smpp.org).
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.
WAP Version 1.2
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.
As such, 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. 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.
WAP Forum Members List
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 August 1999, the WAP Forum
had over 120 members comprising major phone manufacturers,
network operators, SMS Centre suppliers and SMS software
suppliers.
In May 1999, Microsoft
rapidly extended its support of WAP by joining the WAP Forum
and acquiring Sendit, a strong backer of WAP.
WAP Clients and Gateways
WAP is a client server
philosophy, requiring a microbrowser in the mobile phone and a
WAP Gateway connected to the mobile network. By the middle of
1999, 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 maximising 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. These WAP Gateway
suppliers are all trying to sign up mobile network operators who
are looking to trial WAP services and gain some market feedback.
WAP trials will commence in the summer of 1999.
WAP Gateway suppliers include
CMG, Nokia, Ericsson, Phone.com (formerly Unwired Planet), SST,
Dr. Materna, APiON, MD-Co, Akumiitti and Oracle. 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.
Comparison of WAP Gateways
Deployment
(CUST). Denotes the extent to which the WAP Gateway has been
widely deployed. CMG has announced five customers for its
Wireless Content Broker. APiON has announced 10 GSM
operators. Dr. Materna is in the process of announcing its
WAP customers. D2 is also using the Phone.com and Ericsson
WebOnAir platform). Both Nokia and Ericsson are being used by
a dozen or more network operators. Phone.com has about 35
network operators signed to use its UP.Server platform
(excluding its pending acquisition of APiON).
Cost (COST). Denotes the cost of the platform. APiON offers
pay as WAP traffic grows pricing options. CMG charge 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 30th June 1999 and 30th September
1999, Nokia will be offering a free download of its WAP
Gateway 1.0 beta product from http://www.forum.nokia.com/.
It offers essentially the same WAP product under two
different product names to two different customer groups at
two different prices. Dr. Materna expect their WAP Gateway to
be priced above that of CMG, but pricing is still to be
determined.
WAP Bearer Support (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. Dr.
Materna only supports Circuit Switched Data as a bearer,
although SMS is planned. APiON supports both Circuit Switched
Data and SMS, and also USSD if SMPP is used as the protocol
to the USSD server (as in the case of, for example, Logica's
USSD server). Nokia and CMG both support both SMS and Circuit
Switched Data. Phone.com's UP.Server supports by far the
widest range of bearers - from GSM bearers to many other
airlink standards. Ericsson's WAP Gateway supports Circuit
Switched Data, SMS and USSD.
NON-WAP Bearer Support (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.
APiON is a company that focuses on WAP only. Dr. Materna
supports other bearers such as Cell Broadcast and SMS in its
other platforms, but not its WAP Gateway. Nokia's WAP Gateway
also supports Nokia Smart Messaging, a proprietary and little
used wireless protocol. CMG also supports standard SMS, which
is important since most all of the current installed base of
mobile phones supports this nonvoice service, as will all new
phones. Ericsson's WAP Gateway does not support SIM Toolkit,
although its WebOnAir platform does.
WAP Standards Compliance (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 utilise
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. This would be part of the
non-standardised Wireless Telephony Application (WTA). APiON
too closely complies with the WAP 1.1 standards, although it
has extended this to include content push capability that is
not currently incorporated into the WAP standards. Ericsson
supports WAP 1.1 and will implement other standardized
features such as push and Wireless Telephony Application as
they are incorporated into the WAP standard.
Hardware (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. Nokia's WAP platform is
based on a Windows NT platform, although Unix variants are
being developed. Ericsson's WAP Gateway is based on Windows
NT. APiON, Dr. Materna and CMG all supply their WAP Gateways
on a Unix platform.
Billing (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
mobilise those offerings. The plan is to extend the mobile
market into vertical market segments such as travel, finance,
hotels, retail and entertainment. A billing engine allows
these players to make money from their WAP-based offerings.
Recognising the importance of being able to bill for content,
CMG, Dr. Materna and Nokia have all included a billing engine
with the WAP Gateway itself. Nokia's WAP Gateway also
includes a Server Extension API for developing an interface
to incumbent billing systems.
Applications
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 Wireless
Services. The Wireless Application Protocol will allow customers
to easily 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
more easily to reply to and request (using menus instead of
keywords, for example), WAP can help generate 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. 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.
