WAP

Wireless Application Protocol
(WAP)
Affan Ahmed Adeel Abbas

affan7@isd.wol.net.pk exadeelabbas@hotmail.com
Abstract
The initial advent of wireless infrastructures and associated technologies were originally
overlooked by most within the technological community. This was mostly due to the
infantile nature of the technology, as well as its failure to address absolute critical issues
such as security. Other variables such as cost and reliability also played a part in the
shunning of wireless technology. However, the astounding acceptance and ingraining of
the Internet into the everyday operations of life have spawned an overwhelming
requirement and desire for access to unlimited amounts of information under virtually no
restraints. We now find that being able to receive email and access calendar information
among numerous other data only from the confines of ones office or home PC is not only
unacceptable, but also a serious detriment to business and enterprises alike. Once again
the endless possibilities of wireless communications and technology enters the stage, but
this time it is unquestionably here to stay.
At the dawning of the 21st century we see an overwhelming interest in wireless

technologies. This interest is not only for the luxuries and conveniences that they
promise, but also for the sheer magnitude in which they can and probably will change the
way in which enterprises are run and maintained in future generations. One such
technology that has grabbed the communities’, as well as the general public’s attention is
the Wireless Application Protocol (WAP). WAP is an open industry-established world
standard that is based upon successful Internet standards such as, but not limited to the
eXtensible Markup Language (XML) and the Internet Protocol (IP). By being established
using already existing and accepted protocols WAP was destined to gain a tremendous
amount of recognition from the start. However, regardless of the glitz and glamour the
protocol still must meet certain requirements and be capable of certain functionality
before it will be deemed suitable for the enterprise.
This paper aims at expounding what this new technology is, what it holds for us in the
future and also what minimum functionality it must provide in order to be embraced by
the industry as well as the general public. The document will provide an in-depth look at
how this technology is structured and implemented. Upon reviewing this paper the reader
should develop an informed opinion on WAP, its implementation and future.
ii
Wireless Application Protocol EE-419 (Communication System Project Report)
Acknowledgments
The ideas and understanding in this paper have come from many sources. Firstly thanks to everyone on the
internet and especially www.wapforum.com, who have been tremendously helpful in improving the quality
of this text.
A huge thanks to our instructor, Dr. Kamal Athar who gave us invaluable guidance and direction in the
field of Digital Communication.
The supporting cast of friends includes, but is not limited to, Iqbal, Qasim, Bilal, Pasha and of course, Mom
and Dad.
3
Table of Contents
1. An Introduction To WAP..…..…..…..…..…..…..…..…… 1
1.1 History of WAP 1
1.2 Motivation of WAP 2
1.3 Requirements 4
1.4 The WAP philosophy 4
2. WAP Architectural Overview.…..…..…..…..…..…..…… 7

2.1 The World Wide Web Model 7
2.2 The WAP Model 8
2.3 Example WAP Network 10
3. The WAP protocol stack..…..…..…..…..…..…..…..…….. 11

3.1 Wireless Application Environment (WAE) 11
3.2 Wireless Session Protocol (WSP) 12
3.3 Wireless Transaction Protocol (WTP) 12
3.4 Wireless Transport Layer Security (WTLS) 13
3.5 Wireless Datagram Protocol (WDP) 13
3.6 Bearers 14
3.7 Other Services And Applications 14
3.8 Sample Configurations of WAP Technology 14
3.9 WAP Reference Model 16
4. WAE – The Application Layer…..…..…..…..…..…..…… 17

4.1 Background 17
4.2 Goals and Requirements 18
4.3 WAE Architectural Model 18
4.4 Components of WAE 21
4.4.1 WAE User Agents 21
4.4.2 WAE Services and Formats 22
4.4.2.1 WML 22
4.4.2.2 WMLScript 24
4.4.2.3 URLs 25
4.4.2.4 WAE Content Formats 25
4.5 Security and Access Control 26
5. WSP – The Session Layer.…..…..…..…..…..…..…..……. 27

5.1 WSP Features 27
5.1.1 Basic Functionality 27
5.1.2 Extended Functionality 28
5.2 WSP Notations 29
5.2.1 Definition of Service Primitives 29
5.2.2 Time Sequence Charts 29
5.2.3 Services Primitives Types 30
5.3 WSP Elements of Layer-to-Layer Communication 30
5.3.1 Connection Mode Service 30
5.3.1.1 Overview 30
5.3.1.2 Capabilities and Capability Negotiations 32
5.3.2 Protocol Features of Connection-Oriented WSP 34
4
5.3.3 Connectionless Session Service 37

5.3.3.1 Protocol Features of Connectionless WSP 37
6. WTP – The Transaction Layer..…..…..…..…..…..…..…… 39

6.1 WTP Protocol Features 39
6.2 Transaction Classes 40
6.2.1 Class 0: Unreliable invoke message with no result message 40
6.2.2 Class 1: Reliable invoke message with no result message 40
6.2.3 Class 2: Reliable invoke message with one reliable message 40
6.3 WTP Management Entity 41
6.4 Notations Used 42
6.5 Services Provided to Upper Layer 42
6.5.1 TR – Invoke 42
6.5.1.1 Source Address 42
6.5.1.2 Source Port 42
6.5.1.3 Destination Address 42
6.5.1.4 Destination Port 42
6.5.1.5 ACK-Type 42
6.5.1.6 User Data 42
6.5.1.7 Class Type 42
6.5.1.8 Exit Info 43
6.5.1.9 Handle 43
6.5.2 TR – Result 43
6.5.3 TR – Abort 43
6.6 Classes of Operation 43
6.6.1 Class 0 Transaction 43
6.6.1.1 Motivation 43
6.6.1.2 Protocol Data Unit 43
6.6.1.3 Procedure 44
6.6.2.2 Protocol Data Units 44
6.6.2.3 Procedure 44
6.6.3.2 Protocol Data Units 44
7. WTLS and WDP – Security and Transport Layer…………. 47

7.1 Wireless Transport Layer Security (WTLS) 47
7.1.1 WTLS Connection Management 47
7.1.2 WTLS Connection State 49
7.1.3 Handshake Protocol 49
7.1.4 WTLS Cryptography Schemes 50
7.1.4.1 RSA Encryption Scheme 50
7.1.4.2 Diffie-Hellman Algorithm 50
7.1.4.3 Elliptic Curve Diffie-Hellman Algorithm 50
7.1.5 WTLS Internal Architecture 50
7.2 Wireless Datagram Protocol (WDP) 51
7.2.1 WDP Architecture 52
7.2.2 WDP General Description 53
7.2.3 WDP Management Entity 54
7.2.4 WDP Conformance Clause for Bearers 55
7.2.5 WDP Profiles 55
7.2.5.1 WDP Over GSM: SMS Profile 56
7.2.6 WDP Protocol Description 56
5
7.2.6.1 Mapping of WDP for IP 56

7.2.6.2 Mapping of WDP for GSM, SMS and USSD 57
8. WAP Push Architectural Overview..…..…..…..…..…..…. 58

8.1 Introduction 58
8.2 The Push Framework 58
8.3 The Push Proxy Gateway 60
8.3.1 Services Overview 60
8.3.2 Access from the Internet Side 60
8.3.3 Message Handling Service 61
8.3.4 Encoding and Compilation 61
8.3.5 Client Capabilities Query Service 61
8.4 The Push Access Protocol 61
8.4.1 PAP Operations 61
8.4.2 Push Submission 62
8.4.3 Confirmation Notification 62
8.4.4 Push Cancellation 62
8.4.5 Client Capabilities Query 62
8.5 The Push-Over-The-Air Protocol
8.6 Security Considerations 63
8.6.1 Authentication a Push Initiator 63
8.6.1.1 Use of Session-Level Certificates 63
8.6.1.2 Use of Object-Level Certificates 64
8.6.1.3 HTTP Authentication 64
8.6.1.4 A Combination of Technologies 64
8.6.1.5 Trusted Network 64
9. WAP and IMode: A Comparison……………………..…… 65

9.1 Introduction to IMode 65
9.2 Differences between WAP and IMode 65
9.2.1 WML and CHTML 65
9.2.2 IMode: Always-on Connection 65
9.2.3 Billing 65
9.3 The Future 66
10. References………………..…..…..…..…..…..…..…..…… 67
6
List of Figures
Figure 2.1 The WWW Architecture 7

Figure 2.2 The WAP Programming Model 8
Figure 2.3 Example of WAP Network 10
Figure 3.1 The WAP Protocol Stack 11

Figure 3.2 Sample WAP Stack 15
Figure 3.3 WAP Reference Model 16
Figure 4.1 WAE Logical Model 19

Figure 4.2 WAE Push Based Model 20
Figure 4.3 WAE Client Components 21
Figure 5.1 A non-confirmed Service 29

Figure 5.2 Session Establishment 34
Figure 5.3 Method Invocation 35
Figure 5.4 Method Abort 35
Figure 5.5 A non-confirmed Push 36
Figure 5.6 A confirmed Push 36
Figure 5.7 Session Resumption 37
Figure 6.1 Class 0 Transaction 44

Figure 7.1 Abbreviated Handshake 49

Figure 7.2 WTLS Architecture 51
Figure 7.3 WDP Architecture 52
Figure 7.4 General WDP Model 53
Figure 7.5 WDP Over GSM SMS 56
Figure 8.1 Comparison of pull vs. push technology 58

Figure 8.2 The push framework at its simplest 59
Figure 8.3 The push framework with push proxy gateway 59
Figure 8.4 The push framework with protocols 60
7
List of Tables
Table 5.1 The four Service Primitives 30
Table 5.2 Minimum capabilities of user and service provider 33
8
Definitions
Author – an author is a person or program that writes or generates WML, WMLScript or other content.
Client – a device (or application) that initiates a request for a connection with a server.
Content – subject matter (data) stored or generated at an origin server. Content is typically displayed or
interpreted by a user agent in response to a user request.
Content Encoding – when used as a verb, content encoding indicates the act of converting content from
one format to another. Typically the resulting format requires less physical space than the original, is easier
to process or store and/or is encrypted. When used as a noun, content encoding specifies a particular format
or encoding standard or process.
Content Format – actual representation of content.
Device – a network entity that is capable of sending and receiving packets of information and has a unique
device address. A device can act as both a client or a server within a given context or across multiple
contexts. For example, a device can service a number of clients (as a server) while being a client to another
server.
JavaScript – a de facto standard language that can be used to add dynamic behaviour to HTML
documents. JavaScript is one of the originating technologies of ECMAScript.
Man-Machine Interface – a synonym for user interface.
Origin Server – the server on which a given resource resides or is to be created. Often referred to as a web
server or an HTTP server.
Resource – a network data object or service that can be identified by a URI or URL. Resources may be
available in multiple representations (eg, multiple languages, data formats, size and resolutions) or vary in
other ways.
Server – a device (or application) that passively waits for connection requests from one or more clients. A
server may accept or reject a connection request from a client.
Terminal – a device providing the user with user agent capabilities, including the ability to request and
receive information. Also called a mobile terminal or mobile station.
User – a user is a person who interacts with a user agent to view, hear, or otherwise use a resource.
User Agent – a user agent is any software or device that interprets WML, WMLScript, WTAI or other
resources. This may include textual browsers, voice browsers, search engines, etc.
WMLScript – a scripting language used to program the mobile device. WMLScript is an extended subset
of the JavaScrip scripting language.
9
Abbreviations
CGI Common Gateway Interface
CPU Central Processing Unit
DNS Domain Name System
EFI External Functionality Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IP Internet Protocol
MMI Man-Machine Interface
MMS Multimedia Message Service
OTA Over The Air
PDA Personal Digital Assistant
PICS Protocol Implementation Conformance Statement
PKI Public Key Infrastructure
RAM Random Access Memory
RFC Request For Comments
ROM Read Only Memory
SCR Static Conformance Requirement
SSL Secure Sockets Layer
STD Internet Standard
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol [STD0006]
URI Uniform Resource Identifier [RFC2396]
URL Uniform Resource Locator [RFC2396]
W3C World Wide Web Consortium
WAE Wireless Application Environment [WAE]
WAP Wireless Application Protocol
WDP Wireless Datagram Protocol [WDP]
WIM Wireless Identity Module [WIM]
WML Wireless Markup Language [WML]
WPKI Wireless Public Key Infrastructure [WPKI]
WSP Wireless Session Protocol [WSP]
WTA Wireless Telephony Application [WTA]
WTAI Wireless Telephony Application Interface [WTAI]
WTLS Wireless Transport Layer Security [WTLS]
10
1. An introduction to WAP
In this chapter we will compose a description of the WAP concept. We aim to give
an overview of the relevant technology aspects and do not focus on explaining how
to specifically use the different parts of the WAP technology.
Barely a decade ago, when Internet was in its infancy, the mere thought that a
person could access a global database of information right from his/hers room was
thought to be science fiction. In the late nineties when Internet had spawned into a
behemoth that we so greatly depend upon, human race was faced with another such
awe inspiring thought. Could a person chat with his wife, bid at the stock exchange,
keep in touch with the latest in sports and business, catch up on some research, all
while commuting to and from his office? The technology that will make this
feasible is WAP.
WAP bridges the gap between the mobile world and the Internet as well as
corporate intranets and offers the ability to deliver an unlimited range of mobile
value-added services to subscribers—independent of their network, bearer, and
terminal. Mobile subscribers can access the same wealth of information from a
pocket-sized device as they can from the desktop.
1.1 History of WAP

In 1995 Ericsson started a project which main goal was to develop a concept for
value added services on mobile networks. The protocol to handle this was named
Intelligent Terminal Transfer Protocol (ITTP) and the ambition was to make this
protocol a standard for value added services in mobile networks. During 1996 and
1997 Unwired planet and Nokia among others also presented concepts for value
added services on mobile networks (AU-System Radio, 1999).
Unwired Planet introduced the Handheld Device Markup Language (HDML) and
the Handheld Device Transport Protocol (HDTP). HDML was created as a version
of HTML, used on the Internet. HDML was designed and optimized specifically for
effective information transfer across mobile networks with low bandwidth. HTML
is the way to present the data and formatting in a way that any application can
interpret it. In the same manner HDTP was considered to be a wireless equivalent of
HTTP, as a lightweight protocol to perform client/server transactions (Mobile
Lifestream Ltd., 1999, 1). In 1997 Nokia presented the Smart Messaging concept,
an open specification which provides access to value-added services, such as
Internet, directly from any standard GSM phone. The communication between the
phone and the server was based on Short Message Service (SMS) and a mark-up
language called Tagged Text Markup Language (TTML) technology, which like
11
HDML, optimized for narrow-band connection (Techmall, 1997). With all these
concepts being developed and presented there was a substantial risk that the market
of value added services in mobile networks could become fragmented. This would
lead to a situation that neither of the involved companies would benefit from.
In order to avoid this multitude of concepts and guide the development of

translating the fixed world of the Internet access to that of the mobile the leaders of
the wireless telecommunications industry formed the Wireless Application Protocol
(WAP) Forum.
Ericsson, Nokia and Unwired Planet (now known as Phone.com) founded WAP
Forum in June 1997 and since then a lot of new members have entered. WAP
Forum has over 500 members consisting of some of the world’s premier service
developers, handset manufactures, infrastructure providers and software developers.
This forum has developed a de facto world standard for wireless information and
telephony services on digital mobile phones and other wireless terminals called
Wireless Application Protocol – WAP. WAP is an open global specification that
introduces the concept of providing access and interact with information as well as
services to the mobile users with wireless devices. This information may reside on
the Internet or the Intranet of an organization. WAP can be seen as integration and
defragmentation of wireless communication and the Internet towards a completely
new market of information telecommunication. Technically, WAP can roughly be
described as a set of protocols that has inherited its characteristics and functionality
from existing Internet technologies and technologies for wireless communication.
The delivery of a set of specifications in order to enable potential suppliers to
develop WAP enabled products and services for early deployment has been the
initial thrust for the WAP Forum. In April 1998 this goal was achieved as the WAP
version 1.0 specifications were approved and made public. [2]
1.2 Motivation for WAP

WAP is positioned at the convergence of two rapidly evolving network
technologies, wireless data and the Internet. Both the wireless data market and the
Internet are growing very quickly and are continuously reaching new customers.
The explosive growth of the Internet has fuelled the creation of new and exciting
information services. Most of the technology developed for the Internet has been
designed for desktop and larger computers and medium to high bandwidth,
generally reliable data networks. Mass-market, hand-held wireless devices present a
more constrained computing environment compared to desktop computers. Because
of fundamental limitations of power and form-factor, mass-market handheld
devices tend to have:
• Less powerful CPUs,

• Less memory (ROM and RAM),
• Restricted power consumption,
• Smaller displays, and
• Different input devices (e.g. a phone keypad).
12
Wireless devices are, as a rule not equipped with amounts of memory and
computational power comparable to desktop computers. Even though the trend
shows that more powerful hardware will be included in wireless devices, the
relative difference between handheld devices and desktop computer will most
likely be sustained.
Wireless communication of today suffers from the restricted operating time due to
battery power consumption. Even though batteries are being developed to last
longer and the radio interfaces are tuned to consume less power, there is still more
to ask for in this area.
There has been a strive to make wireless hand-held devices as small as possible in
order to make them convenient when the user is on the move and thus provide
large portability. This need for portability set the constraints on the size of the
display used for service interaction on a wireless hand-held device.
Similarly, wireless data networks present a more constrained communication

environment compared to wired networks. Because of fundamental limitations of
power, available spectrum, and mobility, wireless data networks tend to have:
• Less bandwidth,
• More latency,
• Less connection stability, and
• Less predictable availability.
A WAP service must not consume much bandwidth when transmitted in order to be
suitable for wireless access. Compared to wired networks, the wireless networks
have high latency. This restriction is addressed in WAP by minimizing the
roundtrips between the wireless device and the wireless network.
Wired network access provide a connection which can be unstable and
unpredictable for shorter or longer periods due to for example lost radio coverage
and deficient capacity.
Mobile networks are growing in complexity and the cost of all aspects for
provisioning of more value added services is increasing. In order to meet the
requirements of mobile network operators, solutions must be:
• Interoperable – terminals from different manufacturers communicate with

services in the mobile network;
• Scaleable – mobile network operators are able to scale services to customer needs;
• Efficient – provides quality of service suited to the behavior and characteristics of
the mobile network;
• Reliable – provides a consistent and predictable platform for deploying services;
• Secure – enables services to be extended over potentially unprotected mobile
13
networks while still preserving the integrity of user data; protects the devices and
services from security problems such as denial of service.
Many of the current mobile networks include advanced services that can be offered
to end-users. Mobile network operators strive to provide advanced services in a
useable and attractive way in order to promote increased usage of the mobile
network services and to decrease the turnover rate of subscribers. Standard features,
like call control, can be enhanced by using WAP technology to provide customized
user interfaces. For example, services such as call forwarding may provide a user
interface that prompts the user to make a choice between accepting a call,
forwarding to another person, forwarding it to voice mail, etc.
The WAP specifications address mobile network characteristics and operator needs
by adapting existing network technology to the special requirements of mass-
market, hand-held wireless data devices and by introducing new technology where
appropriate. [1]
1.3 Requirements
The requirements of the WAP Forum are to:
• Leverage existing standards where possible.
• Define a layered, scaleable and extensible architecture.
• Support as many wireless networks as possible.
• Optimize for narrow-band bearers with potentially high latency.
• Optimize for efficient use of device resources (low memory/CPU usage/power
consumption).
• Provide support for secure applications and communication.
• Enable the creation of Man Machine Interfaces (MMIs) with maximum
flexibility and vendor control.
• Provide access to local handset functionality, such as logical indication for
incoming call.
• Facilitate network-operator and third party service provisioning.
• Support multi-vendor interoperability by defining the optional and mandatory
components of the specifications.
• Provide a programming model for telephony services and integration. [1]
1.4 The WAP philosophy

The entire philosophy behind the introduction of WAP was to establish a viable
protocol structure, which instead of reinventing the wheel, made maximum leverage
of existing industry proven architectures. As a result the WAP architecture greatly
resembles that of the World Wide Web (see 2.1 & 2.2).
In short, WAP provides a method to communicate across wireless networks

quickly, securely and efficiently. Communication can take place using, but is not
14
limited to, devices such as cell-phones, pagers, two-way radios and personal data
assistants. This communication is not limited to static, boring pages like the web
once was; Rather, WAP offers the opportunity to integrate databases, dynamic
content, e-commerce, and secure information trafficking via a WAP-enabled
device. Although the name itself refers to a single protocol, WAP can actually be
thought of a compilation of protocols brought together to cover many aspect of
wireless communications.
WAP offers the solution to all those problems that wireless devices tend to face,
which have been enumerated in section 1.2. The solution are provided as follows:
• Model closely intertwined with that of the Internet

Rather than re-inventing the wheel, WAP developers based design upon
currently existing ideas and standards. This attempt to produce a cohesive
environment with that of the existing infrastructure not only on the level of
data transfer, but also in the way that developers can communicate this
information through a common language. This provides for a much more fast
development phase for the new technology since people already in the Internet
industry can quickly adapt to WAP development. This leads to efficient,
scaleable and reliable platform for development.
• Handheld Device Markup Language and Wireless Markup Language

HDML is the language that provides a programmer with the tools to produce
content for a handheld WAP device. WML is also a markup language used to
interface with the WAP browser, but it allows a programmer to
simultaneously develop web-based applications that can be viewed both
within the traditional web browser and within a handheld device.
Wireless Markup Language (WML) has a limited set of functionality
compared to HTML. WML makes it possible to implement user agents (also
called micro-browsers) that make small claims on computational power and
memory resources. Further, memory resources can also be kept rather small,
as WML can be binary encoded.
WAP solves the portability problem by structuring the WML documents in decks
and cards and provide limited functionality in WML. This structure provides
for a much more convenient user interface on small displays typical of hand
held wireless devices.
• Optimization of data transfer.

Wireless communication suffers from a major drawback, bandwidth limitation
(typically 14.4 kbps). For this reason, the WAP developers concentrated upon
optimizing existing protocols such as HTTP (HyperText Transport Protocol)
and TCP (Transmission Control Protocol) to maximize data transfer while
taking low bandwidth into account. WAP addresses the issue of limited
bandwidth by binary encoding WML into a compact form when sent over the
air in order to minimize the traffic over the air interface. The WSP is also
15
binary, for the same reason. Moreover it provides for long-lived sessions that
can be suspended and resumed (more on this in chapter describing WSP).
• Operating system independent

WAP can be used on any operating system, including such popular handheld
platforms like Palm OS, Windows CE, and JavaOS. It can also compatible
with Windows 95/98/NT, Linux, Solaris. This is because the protocol is
dependent upon communications standards rather than the platform itself. Any
platform capable of adhering to the communications standards is WAP
compatible.
16
2. WAP Architectural Overview

This chapter gives an overview of what the WAP architectural model is and how
closely it’s related to the World Wide Web model. For this purpose a comparison of
the two models is presented. An example of a WAP network is provided.
2.1 The World Wide Web model
Figure 2.1 The WWW architecture
The Internet World Wide Web (WWW) architecture provides a very flexible and
powerful programming model (Figure 2.1). Applications and content are presented
in standard data formats, and are browsed by applications known as web browsers.
The web browser is a networked application, i.e. it sends requests for named data
objects to a network server and the network server responds with the data encoded
using the standard formats.
The WWW standards specify many of the mechanisms necessary to build a general-
purpose application environment, including:
• Standard naming model – All servers and content on the WWW are named with an
Internet-standard Uniform Resource Locator (URL).
• Content typing – All content on the WWW is given a specific type thereby
allowing web browsers to correctly process the content based on its type.
• Standard content formats – All web browsers support a set of standard content
formats. These include the HyperText Markup Language (HTML), the JavaScript
scripting language, and a large number of other formats.
17
• Standard Protocols – Standard networking protocols allow any web browser to

communicate with any web server. The most commonly used protocol on the WWW
is the HyperText Transport Protocol (HTTP).
This infrastructure allows users to easily reach a large number of third-party

applications and content services. It also allows application developers to easily
create applications and content services for a large community of clients.
The WWW protocols define three classes of servers:
• Origin server – The server on which a given resource (content) resides or is to be

created.
• Proxy – An intermediary program that acts as both a server and a client for the
purpose of making requests on behalf of other clients. The proxy typically resides
between clients and servers that have no means of direct communication, e.g. across
a firewall. Requests are either serviced by the proxy program or passed on, with
possible translation, to other servers. A proxy must implement both the client and
server requirements of the WWW specifications.
• Gateway – A server, which acts as an intermediary for some other server. Unlike a
proxy, a gateway receives requests as if it were the origin server for the requested
resource. The requesting client may not be aware that it is communicating with a
gateway.
2.2 The WAP Model
Figure 2.2 WAP programming model
The WAP programming model (Figure 2.2) is similar to the WWW programming
model. This provides several benefits to the application developer community,
including a familiar programming model, a proven architecture, and the ability to
leverage existing tools (e.g., Web servers, XML tools, etc.). Optimizations and
18
extensions have been made in order to match the characteristics of the wireless
environment. Wherever possible, existing standards have been adopted or have been
used as the starting point for the WAP technology.
WAP content and applications are specified in a set of well-known content formats
based on the familiar WWW content formats. Content is transported using a set of
standard communication protocols based on the WWW communication protocols. A
micro browser in the wireless terminal co-ordinates the user interface and is
analogous to a standard web browser. WAP defines a set of standard components
that enable communication between mobile terminals and network servers,
including:
• Standard naming model – WWW-standard URLs are used to identify WAP
content on origin servers. WWW-standard URLs are used to identify local resources
in a device, e.g. call control functions.
• Content typing – All WAP content is given a specific type consistent with WWW
typing. This allows WAP user agents to correctly process the content based on its
type.
• Standard content formats – WAP content formats are based on WWW technology
and include display markup, calendar information, electronic business card objects,
images and scripting language.
• Standard communication protocols – WAP communication protocols enable the
communication of browser requests from the mobile terminal to the network web
server.
The WAP content types and protocols have been optimized for mass market, hand-
held wireless devices. WAP utilizes proxy technology to connect between the
wireless domain and the WWW. The WAP proxy typically is comprised of the
following functionality:
• Protocol Gateway – The protocol gateway translates requests from the WAP
protocol stack (WSP, WTP, WTLS, and WDP) to the WWW protocol stack (HTTP
and TCP/IP).
• Content Encoders and Decoders – The content encoders translate WAP content
into compact encoded formats to reduce the size of data over the network.
This infrastructure ensures that mobile terminal users can browse a wide variety of
WAP content and applications, and that the application author is able to build
content services and applications that run on a large base of mobile terminals. The
WAP proxy allows content and applications to be hosted on standard WWW servers
and to be developed using proven WWW technologies such as CGI scripting. While
the nominal use of WAP will include a web server, WAP proxy and WAP client, the
WAP architecture can quite easily support other configurations. It is possible to
create an origin server that includes the WAP proxy functionality. Such a server
might be used to facilitate end-to-end security solutions, or applications that require
better access control or a guarantee of responsiveness, e.g. WTA.
19
2.3 Example WAP Network

The following example illustrates a theoretical WAP network as shown in figure 2.3
Figure 2.3 Example WAP network
In the example, the WAP client communicates with two servers in the wireless
network. The WAP proxy translates WAP requests to WWW requests thereby
allowing the WAP client to submit requests to the web server. The proxy also
encodes the responses from the web server into the compact binary format
understood by the client.
If the web server provides WAP content (e.g., WML), the WAP proxy retrieves it
directly from the web server. However, if the web server provides WWW content
(such as HTML), a filter is used to translate the WWW content into WAP content.
For example, the HTML filter would translate HTML into WML.
The Wireless Telephony Application (WTA) server is an example origin or
gateway server that responds to requests from the WAP client directly. The WTA
server is used to provide WAP access to features of the wireless network provider’s
telecommunications infrastructure.
20
3. The WAP Protocol Stack

This chapter introduces the components of WAP architecture. The WAP architecture
provides a generic protocol stack, which ensures that all the requirements of the
WAP forum are fulfilled.
The WAP architecture provides a scaleable and extensible environment for

application development for mobile communication devices. This is achieved
through a layered design of the entire protocol stack (Figure 3.1). Each of the layers
of the architecture is accessible by the layers above, as well as by other services and
applications.
Figure 3.1 WAP protocol Stack
The WAP layered architecture enables other services and applications to utilize the
features of the WAP stack through a set of well-defined interfaces. External
applications may access the session, transaction, security and transport layers
directly. The following sections provide a description of the various elements of the
protocol stack architecture.
3.1 Wireless Application Environment (WAE)
21
The Wireless Application Environment (WAE) is a general-purpose application

environment based on a combination of World Wide Web (WWW) and Mobile
Telephony technologies. The primary objective of the WAE effort is to establish an
interoperable environment that will allow operators and service providers to build
applications and services that can reach a wide variety of different wireless platforms
in an efficient and useful manner. WAE includes a micro-browser environment
containing the following functionality:
• Wireless Markup Language (WML) – a lightweight markup language, similar to

HTML, but optimized for use in hand-held mobile terminals.
• WMLScript – a lightweight scripting language, similar to JavaScript™.
• Wireless Telephony Application (WTA, WTAI) – telephony services and
programming interfaces.
• Content Formats – a set of well-defined data formats, including images, phone
book records and calendar information.
3.2 Wireless Session Protocol (WSP)
The Wireless Session Protocol (WSP) provides the application layer of WAP with a
consistent interface for two session services. The first is a connection-oriented
service that operates above the transaction layer protocol WTP. The second is a
connectionless service that operates above a secure or non-secure datagram service
(WDP). The Wireless Session Protocols currently consist of services suited for
browsing applications (WSP/B). WSP/B provides the following functionality:
• HTTP/1.1 functionality and semantics in a compact over-the-air encoding,

• Long-lived session state,
• Session suspend and resume with session migration,
• A common facility for reliable and unreliable data push, and
• Protocol feature negotiation.
The protocols in the WSP family are optimized for low-bandwidth bearer networks
with relatively long latency. WSP/B is designed to allow a WAP proxy to connect a
WSP/B client to a standard HTTP server.
3.3 Wireless Transaction Protocol (WTP)
The Wireless Transaction Protocol (WTP) runs on top of a datagram service and
provides as a lightweight transaction-oriented protocol that is suitable for
implementation in “thin” clients (mobile stations). WTP operates efficiently over
secure or non-secure wireless datagram networks and provides the following
features:
• Three classes of transaction service:
• Unreliable one-way requests.
• Reliable one-way requests.
22
• Reliable two-way request-reply transactions.

• Optional user-to-user reliability - WTP user triggers the confirmation of each
received message.
• Optional out-of-band data on acknowledgements.
• PDU concatenation and delayed acknowledgement to reduce the number of
messages sent.
• Asynchronous transactions.
3.4 Wireless Transport Layer Security (WTLS)
WTLS is a security protocol based upon the industry-standard Transport Layer

Security (TLS) protocol, formerly known as Secure Sockets Layer (SSL). WTLS is
intended for use with the WAP transport protocols and has been optimized for use
over narrow-band communication channels. WTLS provides the following features:
• Data integrity – WTLS contains facilities to ensure that data sent between the
terminal and an application server is unchanged and uncorrupted.
• Privacy – WTLS contains facilities to ensures that data transmitted between the
terminal and an application server is private and cannot be understood by any
intermediate parties that may have intercepted the data stream.
• Authentication – WTLS contains facilities to establish the authenticity of the
terminal and application server.
• Denial-of-service protection – WTLS contains facilities for detecting and rejecting
data that is replayed or not successfully verified. WTLS makes many typical denial-
of-service attacks harder to accomplish and protects the upper protocol layers.
WTLS may also be used for secure communication between terminals, e.g., for
authentication of electronic business card exchange. Applications are able to
selectively enable or disable WTLS features depending on their security
requirements and the characteristics of the underlying network (e.g., privacy may be
disabled on networks already providing this service at a lower layer)
3.5 Wireless Datagram Protocol (WDP)
The Transport layer protocol in the WAP architecture is referred to as the Wireless
Datagram Protocol (WDP). The WDP layer operates above the data capable bearer
services supported by the various network types. As a general transport service,
WDP offers a consistent service to the upper layer protocols of WAP and
communicate transparently over one of the available bearer services.
Since the WDP protocols provide a common interface to the upper layer protocols
the Security, Session and Application layers are able to function independently of
the underlying wireless network. This is accomplished by adapting the transport
layer to specific features of the underlying bearer. By keeping the transport layer
23
interface and the basic features consistent, global interoperability can be achieved
using mediating gateways.
3.6 Bearers
The WAP protocols are designed to operate over a variety of different bearer
services, including short message, circuit-switched data, and packet data. The
bearers offer differing levels of quality of service with respect to throughput, error
rate, and delays. The WAP protocols are designed to compensate for or tolerate this
varying level of service.
Since the WDP layer provides the convergence between the bearer service and the
rest of the WAP stack, the WDP specification lists the bearers that are supported and
the techniques used to allow WAP protocols to run over each bearer. The list of
supported bearers will change over time with new bearers being added as the
wireless market evolves.
3.7 Other Services and Applications
The WAP layered architecture enables other services and applications to utilize the
features of the WAP stack through a set of well-defined interfaces. External
applications may access the session, transaction, security and transport layers
directly. This allows the WAP stack to be used for applications and services not
currently specified by WAP, but deemed to be valuable for the wireless market. For
example, applications, such as electronic mail, calendar, phone book, notepad, and
electronic commerce, or services, such as white and yellow pages, may be developed
to use the WAP protocols.
3.8 Sample Configurations of WAP Technology

WAP technology is expected to be useful for applications and services beyond those
specified by the WAP Forum. Figure 3.2 depicts several possible protocol stacks
using WAP technology. These are for illustrative purposes only and do not constitute
a statement of conformance or interoperability.
24
Figure 3.2 Sample WAP Stacks
The leftmost stack represents a typical example of a WAP application, i.e., WAE
user agent, running over the complete portfolio of WAP technology. The middle
stack is intended for applications and services that require transaction services with
or without security. The rightmost stack is intended for applications and services that
only require datagram transport with or without security. [1]
In the next few chapters each of this protocol stack components, briefly touched
upon above will, be explained in detail.
25
3.9 WAP Reference Model

A model of the way layering is done between protocols in WAP is illustrated in
Figure 3.3.
Figure 3.3 WAP Reference Model
Layer Management Entities handle protocol initialization, configuration and error

conditions (such as loss of connectivity due to the mobile station roaming out of
coverage) that are not handled by the protocol itself.
In all of the following chapters wherein the Protocol layers are being explained
individually, consistent references to this figure will be made.
26
4. WAE: The Application layer

The top layer in the WAP stack is the Wireless Application Environment (WAE)
which is a general-purpose environment based on a combination of World Wide
Web and Mobile telephony technologies. WAE is the result of efforts to introduce a
set of specifications common to development of all applications that operate over the
wireless network. In keeping with the WAP tradition of promoting interoperability,
WAP is fundamentally based on WWW technologies. This chapter gives a
comprehensive review of WAE background, direction, model and its components.
4.1 Background
WAE specifies an application framework for wireless devices such as PDAs, mobile
phones etc. The framework is built upon existing WAP technologies like WTP and
WSP, both part of the protocol stack. WAE being the top most layer has access to
each and every layer beneath it, as dictated by the WAP protocol stack architecture
(refer to chapter 3).
The output of the WAE effort is a collection of technical specifications that are
either new or based on existing and proven technologies. Among the existing
technologies leveraged by the WAE efforts are:
• Phone.com (formerly Unwired Planet)’s Hand Held Mark-up Language

(HDML).
• World Wide Web’s Consortium’s (W3C) Hypertext Mark-up Language
(HTML).
• ECMA-262 Standard “ECMAScript Language Specification” that is based on
JavaScript™.
• IMC’s calendar data exchange format (vCalendar) and phonebook data exchange
format (vCard).
• A wide range of WWW technologies such as URLs and HTTP.
• A wide range of Mobile Network technologies such as GSM call control services
and generic IS-136 services such as send flash.
The resulting WAE technologies are not fully compliant to all of the motivating
technologies. Where necessary, modifications were made to better integrate the
elements into a cohesive environment and better optimize the interaction and user
interface for small screen limited capability terminals that communicate over
wireless networks.
27
4.2 Goals and Requirements

The following list summarizes the requirements of the Wireless Application
Environment (WAE):
• WAE must enable simple yet efficient, meaningful and powerful application
development and execution environments.
• WAE must provide a general framework. WAE cannot assume that a browser is
the controlling agent in the device, nor can it assume that a browser is running at all
times. Other applications may exist in the device. In which case, WAE must not
prevent such applications from coexisting or even integrating with a browser. In
addition, those other applications should be able to access and leverage common
WAE services on the device where appropriate.
• WAE must not dictate or assume any particular Man-Machine-Interface (MMI)

model. WAE implementations must be able to introduce new MMI models or use
existing MMI models. Implementers must be able to present end users with a
consistent and meaningful MMI suitable to the targeted device.
• WAE must be suited for a wide variety of limited capability devices. WAE must
have a small memory footprint and limited computational power requirement. WAE
must be suitable for the current generation of wireless devices without jeopardizing
its ability to evolve and support future generations of those devices.
• WAE must promote as well as incorporate efficient means to reduce the amount
and frequency of over-the-air data exchanges with origin servers. WAE must provide
the means to communicate device capabilities to origin servers, which would enable
origin server-side optimizations and further minimize over-the-air resource
consumption. In addition, WAE network services must be based on WAP’s network
protocol stack.
• WAE must support internationalization and localization using standard or well-
accepted practices and methods.
• WAE must not compromise WAP’s security model. WAE must include
meaningful access control mechanisms that ensure secure processing of network
accessed content.
• WAE must promote and enable interoperable implementation between various
manufacturers and content or service providers.
• WAE must include extensions to allow means for call control and messaging, as
well as enabling a standard set of value-added call and feature control capabilities.
• WAE must allow network operators to introduce new operator-specific features to
their implementations. [3]
4.3 WAE Architectural Model

WAE follows a model dictated by that of the WWW (refer to section 2.1). All
content is specified in formats that are similar to the standard Internet formats.
28
Content is transported using standard protocols in the WWW domain and an

optimized HTTP-like protocol in the wireless domain. WAE has borrowed from
WWW standards including authoring and publishing methods wherever possible.
The WAE architecture allows all content and services to be hosted on standard Web
origin servers that can be incorporate proven technologies (e.g., CGI). All content is
located using WWW standard URLs.
WAE enhances some of the WWW standards in ways that reflect the device and
network characteristics. WAE extensions are added to support Mobile Network
Services such as Call Control and Messaging. Careful attention is paid to the
memory and CPU processing constraints that are found in mobile terminals. Support
for low bandwidth and high latency networks is included in the architecture as well.
WAE assumes the existence of gateway functionality responsible for encoding and
decoding data transferred from and to the mobile client. The purpose of encoding
content delivered to the client is to minimize the size of data sent to the client over-
the-air as well as to minimize the computational energy required by the client to
process that data. The gateway functionality can be added to origin servers or placed
in dedicated gateways as illustrated in Figure 4.1.
Figure 4.1 WAE logical Model
The major elements of the WAE model include:

• WAE User Agents:
Client-side in-device software that provides specific functionality (e.g., display
content) to the end-user. User agents (such as browsers) are integrated into the
WAP architecture. They interpret network content referenced by a URL. WAE
includes user agents for the two primary standard contents: encoded Wireless
Markup language (WML) and compiled Wireless Markup Language Script
(WMLScript.)
• Content Generators:
Applications (or services) on origin servers (e.g., CGI scripts) that produce
standard content formats in response to requests from user agents in the mobile
29
terminal. WAE does not specify any standard content generators but expects that
there will be a great variety available running on typical HTTP origin servers
commonly used in WWW today.
• Standard Content Encoding:

A set of well-defined content encoding, allowing a WAE user agent (e.g., a
browser) to conveniently navigate web content. Standard content encoding
includes compressed encoding for WML, byte code encoding for WMLScript,
standard image formats, a multi-part container format and adopted business and
calendar data formats.
• Wireless Telephony Applications (WTA):

A collection of telephony specific extensions for call and feature control
mechanisms that provide authors (and ultimately end-users) advanced Mobile
Network Services. [3]
Typically, a user agent on the terminal initiates a request for content. However, not
all content delivered to the terminal will result from a terminal-side request. For
example, WTA includes mechanisms that allow origin servers to deliver generated
content to the terminal without a terminal’s request as illustrated in Figure 4.2
Figure 4.2 WAE Push-Based Model
The push based WAP model would be explained in more detail later on in this
report.
In some cases, what the origin server delivers to the device may depend on the
characteristics of the device. The user agent characteristics are communicated to the
server via standard capability negotiation mechanisms that allows applications on
the origin server to determine characteristics of the mobile terminal device. WAE
defines a set of user agent capabilities that will be exchanged using WSP
30
mechanisms. These capabilities include such global device characteristics as WML

version supported, WMLScript version supported, floating-point support, image
formats supported and so on.
4.4 Components of WAE
The figure 4.3 shows the client components of WAE, whereby the WAE is divide
into two logical layers:
• User agents such as browsers, phonebooks, message editors, etc.
• Services and Formats, which include common elements and formats accessible to
user agents such as WML, WMLScript, image formats, vCard and vCalendar
formats, etc.
Figure 4.3 WAE Client Components
The thing to note is that this segregation is logical and not an explicit
requirement for the implementers. The structure of a WAE depends upon the
design decisions of its implementers.
4.4.1 WAE User Agents

The WML user agent is a fundamental user agent of the WAE. However, WAE is
not limited to a WML user agent. WAE allows the integration of domain-specific
31
user agents with varying architectures and environments. In particular, a Wireless

Telephony Application (WTA) user agent has been specified as an extension to the
WAE specification for the mobile telephony environments. The WTA extensions
allow authors to access and interact with mobile telephone features (e.g., call
control) as well as other applications assumed on the telephones, such as
phonebooks and calendar applications.
WAE does not formally specify any user agent. Features and capabilities of a user
agent are left to the implementers. Instead, WAE only defines fundamental services
and formats that are needed to ensure interoperability among implementations. An
overview of those services and formats is included in subsequent sections.
4.4.2 WAE Services and Formats

The WAE Services and Formats layer includes the bulk of technical contribution of
the WAE effort. The following section provides an overview of the major
components of WAE including the Wireless Markup Language (WML), the
Wireless Markup Scripting language (WMLScript), WAE applications and WAE
supported content formats.
4.4.2.1 WML
WML is a tag-based document language. In particular, it is an application of a
generalized mark-up language. WML shares a heritage with the WWW’s HTML
and Handheld Device Markup Language. WML is specified as an XML [XML]
document type. It is optimized for specifying presentation and user interaction on
limited capability devices such as telephones and other wireless mobile terminals.
WML and its supporting environment were designed with certain small narrow-
band device constraints in mind including small displays, limited user-input
facilities, narrow band network connections, limited memory resources and limited
computational resources. Given the wide and varying range of terminals targeted by
WAP, considerable effort was put into the proper distribution of presentation
responsibility between the author and the browser implementation.
WML is based on a subset of HDML version 2.0. WML changes some elements
adopted from HDML and introduces new elements, some of which have been
modeled on similar elements in HTML. The resulting WML implements a card and
deck metaphor. It contains constructs allowing the application to specify documents
made up of multiple cards. An interaction with the user is described in a set of
cards, which can be grouped together into a document (commonly referred to as a
deck). Logically, a user navigates through a set of WML cards. The user navigates
to a card, reviews its contents, may enter requested information, may make choices,
and then moves on to another card. Instructions imbedded within cards may invoke
services on origin servers as needed by the particular interaction. Decks are fetched
from origin servers as needed. WML decks can be stored in ‘static’ files on an
origin server, or they can be dynamically generated by a content generator running
on an origin server. Each card, in a deck, contains a specification for a particular
user interaction. [3]
32
WML has a wide variety of features, including:
• Support for Text and Images

WML provides the authors with means to specify text and images to be presented to
the user. As with other mark-up languages, WML requires the author to specify the
presentation in very general terms and gives the user agent a great deal of freedom
to determine exactly how the information is presented to the end user. WML
provides a set of text mark-up elements including various emphasis elements (e.g.,
bold, italic, big, etc.); various line breaks models (e.g., line wrapping, line wrapping
suppression, etc.); and tab columns that supports simple tabbing alignment.
• Support for User Input

WML supports several elements to solicit user input. The elements can be
combined into one or more cards.. WML includes a small set of input controls. For
example, WML includes a text entry control that supports text and password entry.
Text entry fields can be masked preventing the end user from entering incorrect
character types. WML includes an option selection control that allows the author to
present the user with a list of options that can set data, navigate among cards, or
invoke scripts. WML supports both single and multiple option selections. WML
also includes task invocation controls. When activated, these controls initiate a
navigation or a history management task such as traversing a link to another card
(or script) or popping the current card off of the history stack. The user agent is free
to choose how to present these controls.
• Navigation and History Stack

WML allows several navigation mechanisms using URLs. It also exposes a first-
class history mechanism. Navigation includes HTML-style hyperlinks, inter-card
navigation elements, as well as history navigation elements.
• International Support
The document character set for WML is the Universal Character Set of ISO/IEC-
10646. Currently, this character set is identical to Unicode 2.0. There is no
requirement that WML decks be encoded using the full Unicode encoding (e.g.,
UCS-4). Any character encoding ("charset") that contains a proper subset of
the logical characters in Unicode may be used (e.g., US-ASCII, ISO-8859-1, UTF-
8, Shift_JIS, etc.)
• MMI Independence
WML’s abstract specification of layout and presentation enables terminal and
device vendors to control the MMI design for their particular products.
• Narrow-band Optimization
WML includes a variety of technologies to optimize communication on a narrow-
band device. This includes the ability to specify multiple user interactions (cards) in
one network transfer (a deck). It also includes a variety of state management
33
facilities that minimize the need for origin server requests. WML includes other
mechanisms to help improve response time and minimize the amount of data
exchanged over-the-air. For example, WML allows the author to parameterize (or
pass variables to) a subsequent context. It supports variable substitution and
provides out-of-band mechanisms for client-side variable passing without having to
alter URLs. The out-of-band passing of variables without changing the way URLs
appear attempts to improve client-side cache hits.
• State and Context Management

WML exposes a flat context (i.e., a linear non-nested context) to the author. Each
WML input control can introduce variables. The state of the variables can be used
to modify the contents of a parameterized card without having to communicate with
the server. Furthermore, the lifetime of a variable state can last longer than a single
deck and can be shared across multiple decks without having to use a server to save
intermediate state between deck invocations.
4.4.2.2 WMLScript
WMLScript is a lightweight procedural scripting language. It enhances the standard
browsing and presentation facilities of WML with behavioral capabilities, supports
more advanced UI behavior, adds intelligence to the client, provides a convenient
mechanism to access the device and its peripherals, and reduces the need for round-
trips to the origin server.
WMLScript is loosely based on a subset of the JavaScript™ WWW scripting

language. It is an extended subset of JavaScript™ and forms a standard means for
adding procedural logic to WML decks. WMLScript refines JavaScript™ for the
narrow-band device, integrates it with WML, and provides hooks for integrating
future services and in-device applications.
WMLScript provides the application programmer with a variety of interesting
capabilities:
• The ability to check the validity of user input before it is sent to the content server.
• The ability to access device facilities and peripherals.
• The ability to interact with the user without introducing round-trips to the origin
server (e.g., display an error message).
Key WMLScript features include:
• JavaScript™-based scripting language:

WMLScript starts with an industry standard solution and adapts it to the narrow-
band environment. This makes WMLScript very easy for a developer to learn and
use.
• Procedural Logic:
WMLScript adds the power of procedural logic to WAE.
• Event-based:
34
WMLScript may be invoked in response to certain user or environmental events.
• Compiled implementation:
WMLScript can be compiled down to a more space efficient byte code that is
transported to the client.
• Integrated into WAE:

WMLScript is fully integrated with the WML browser. This allows the author to
construct their services using both technologies, using the most appropriate solution
for the task at hand. WMLScript has access to the WML state model and can set
and get WML variables. This enables a variety of functionality (e.g., validation of
user input collected by a WML card).
• International Support
WMLScript source text is represented as a sequence of characters representable
using the Universal Character set of ISO/IEC-10646. Currently, this character set is
identical to Unicode 2.0. There is no requirement that WMLScript documents be
encoded using the full Unicode encoding (e.g. UCS-4). Any character encoding
("charset") that contains an inclusive subset of the characters in Unicode may be
used (e.g. US-ASCII, ISO-8859-1, Shift_JIS, etc.).
• Efficient extensible library support:

WMLScript can be used to expose and extend device functionality without changes
to the device software. [3]
WMLScript supports several categories of operations such as assignment

operations, arithmetic operations, logical operations and comparison operations.
WMLScript supports several categories of functions including Local script
functions (i.e., script functions defined inside the same script that the calling
expression is in), External script functions (i.e., script functions defined in another
script not containing the calling expression) and Standard library functions (i.e.,
functions defined in a library that is part of the WAE specification.) WMLScript
defines several standard libraries including a language library, a string library, a
browser library, a floating point library and a dialog library.
4.4.2.3 URLs
WAE assumes a rich set of URL services that user agents can use. In particular,
WAE relies heavily on HTTP and HTML URL semantics. In some cases, WAE
components extend the URL semantics, such as in WML, where URL fragments
has been extended to allow linking to particular WMLScript functions.
4.4.2.4 WAE Content Formats

WAE includes a set of agreed upon content formats that facilitate interoperable data
exchange. The method of exchange depends on the data and the targeted WAE user
agents. The two most important formats defined in WAE are the encoded WML and
35
the WMLScript byte code formats. WAE defines WML and WMLScript encoding
formats that make transmission of WML and WMLScript more efficient as well as
minimizes the computational efforts needed on the client. In addition, WAE defines
and adopts other formats for data types including:
• Images:
WAE assumes visual environments that support images will support several image
formats. The selection of formats was an attempt to meet several competing
requirements including: support of multiple choices of pixel depth, support of
colorspace tables, small encoding, very low CPU and RAM decoding and
presentation demands and availability of common tools and other developer
support.
• Multipart Messages:
WAE leverages a multipart-encoding scheme optimized for exchanging multiple
typed content over WSP.
• User Agent-Specific Formats:

WAE adopts two additional content formats specific to exchanging data among user
agents suitable for both client-server communication and peer-to-peer
communication: electronic business cards (vCard.2.1) and electronic calendaring
and scheduling exchange format (vCalendar 1.0) specified by the IMC.
4.5 Security and Access Control

For the purpose of effecting secure communications over the wireless network
WAE leverages the WTLS (Wireless Transport Layer Security). In addition, both
WML and WMLScript include access control constructs that communicate to the
client URL based access restrictions. WAE also supports HTTP 1.1 basic
authentication. More on security issues will be discussed in the chapter regarding
WTLS.
36
5. WSP : The Session layer

The session layer in the WAP protocol stack is named the Wireless Session Protocol
(WSP). WSP provides an interface between the WAE and the rest of the protocol
stack. This interface is used to accommodate organized exchange of content between
client and server applications. WSP is designed on the transaction and datagram
services. This chapter illustrates how WSP, through modularity of the WAP protocol
stack, handles the issue of transaction and security.
5.1 WSP Features
WSP provides a means for organized exchange of content between co-operating

client/server applications. Specifically, it provides the applications means to:
a) establish a reliable session from client to server and release that session in an
orderly manner;
b) agree on a common level of protocol functionality using capability negotiation;
c) exchange content between client and server using compact encoding;
d) suspend and resume the session.
The currently defined services and protocols (WSP) are most suited for browsing-
type applications. WSP defines actually two protocols: one provides connection-
mode session services over a transaction service, and another provides non-
confirmed, connectionless services over a datagram transport service. The
connectionless service is most suitable, when applications do not need reliable
delivery of data and do not care about confirmation. It can be used without actually
having to establish a session.
In addition to the general features, WSP offers means to:
a) provide HTTP/1.1 functionality:

1) extensible request-reply methods,
2) composite objects,
3) content type negotiation;
b) exchange client and server session headers;
c) interrupt transactions in process;
d) push content from server to client in an unsynchronized manner;
e) negotiate support for multiple, simultaneous asynchronous transactions.[4]
5.1.1 Basic Functionality

The core of the WSP design is a binary form of HTTP. Consequently the requests
sent to a server and responses going to a client may include both headers (meta-
information) and data. All the methods defined by HTTP/1.1 are supported. In
37
addition, capability negotiation can be used to agree on a set of extended request

methods, so that full compatibility to HTTP/1.1 applications can be retained.
WSP itself does not interpret the header information in requests and replies. As part
of the session creation process, request and reply headers that remain constant over
the life of the session can be exchanged between service users in the client and the
server. These may include acceptable content types, character sets, languages,
device capabilities and other static parameters. WSP will pass through client and
server session headers as well as request and response headers without additions or
removals.
The lifecycle of a WSP session is not tied to the underlying transport. A session can
be suspended while the session is idle to free up network resources or save battery.
A lightweight session re-establishment protocol allows the session to be resumed
without the overhead of full-blown session establishment. A session may be
resumed over a different bearer network.
5.1.2 Extended Functionality

WSP allows extended capabilities to be negotiated between the peers. This allows
for both high-performance, feature-full implementation as well as simple, basic and
small implementations.
WSP provides an optional mechanism for attaching header information (meta-data)

to the acknowledgement of a transaction. This allows the client application to
communicate specific information about the completed transaction back to the
server.
WSP provides both push and pull data transfer. Pull is done using the
request/response mechanism from HTTP/1.1. In addition, WSP provides three push
mechanisms for data transfer:
• Confirmed data push within an existing session context

• Non-confirmed data push within an existing session context
• Non-confirmed data push without an existing session
The Push mechanism will be explained in greater detail in chapter 7. For the
moment just think of Push as being a mechanism to provide the end user with
unsolicited information by the origin server.
WSP optionally supports asynchronous requests, so that a client can submit

multiple requests to the server simultaneously. This improves utilization of airtime
in that multiple requests and replies can be coalesced into fewer messages. This also
improves latency as the results of each request can be sent to the client when it
becomes available.
38
WSP partitions the space of well-known header field names into header code pages.
Each code page can define only a fairly limited number of encodings for well-
known field names, which permits them to be represented more compactly.
Running out of identities for well-known field names on a certain code page is still
not a problem, since WSP specifies a mechanism for shifting from one header code
page to another.
5.2 WSP Notations
In the following sections some definitions will be made which will be referred to
through out for the better explanation of both WSP and WTP (chapter 6).
5.2.1 Definition of Service Primitives

Communications between layers and between entities within the session layer are
accomplished by means of service primitives. Service primitives represent, in an
abstract way, the logical exchange of information and control between the session
layer and adjacent layers.
Service primitives consist of commands and their respective responses associated

with the particular service provided.
The general syntax of a primitive is:
X-Service.type (Parameters)
where X designates the layer providing the service. For this specification X is “S”
for the Session Layer, “T” for the transport layer and so on.
5.2.2 Time Sequence Charts

Time Sequence charts are used to illustrate the behavior of service primitives. These
are very much like the UML sequence charts used to describe behavior of any
system.
Figure 5.1 a non-confirmed Service
39
Figure 5.1 illustrates a simple non-confirmed service, which is invoked using a

request primitive and results in an indication primitive in the peer. The dashed line
represents propagation through the provider over a period of time indicated by the
vertical difference between the two arrows representing the primitives. If the labels
Client and Server are included in the diagram, this indicates that both peers cannot
originate a primitive; if the labels are omitted, either peer can originate the
primitive.
5.2.3 Service Primitives Types

To keep matters simple only four possible service primitive types are defined. The
types, with their abbreviation and description are given in Table 5.1.[4]
Table 5.1 The Four Service Primitives
5.2 WSP Elements of Layer-to-Layer Communication

The session layer in WAP provides both connection-mode and connectionless
services. They are defined using an abstract description technique based on service
primitives. This service definition specifies the minimum functionality that the
WAP session must be able to provide to support its users. Since this definition is
abstract, it does not specify or constrain programming interfaces or
implementations. In fact the same service could be delivered by different protocols
5.3.1 Connection Mode Service

5.3.1.1 Overview
The connection-mode session service is divided into facilities, some of which are
optional. Most of the facilities are asymmetric so that the operations available for
the client and the server connected by the session are different. The provided
facilities are
• Session Management facility
• Method Invocation facility
• Exception Reporting facility
• Push facility
40
• Confirmed Push facility

• Session Resume facility
The Session Management and Exception reporting facilities are always available.
The others are controlled by capability negotiation during session establishment.
Session Management allows a client to connect with a server and to agree on the
facilities and protocol options to be used. A server can refuse the connection
attempt, optionally redirecting the client to another server. During session
establishment the client and server can also exchange attribute information, which
is expected to remain valid for the duration of the session. Both the server and the
client service user can also terminate the session, so that the peer is eventually
notified about the termination. The user is also notified if session termination occurs
due to the action of the service provider or a management entity.
Method Invocation permits the client to ask the server to execute an operation and
return the result. The available operations are the HTTP methods or user-defined
extension operations, which fit into the same request-reply or transaction pattern.
The service users both in the client and the server are always notified about the
completion of the transaction, whether it succeeded or failed. Failure can be caused
by an abort initiated either by the service user or the service provider.
The Exception Reporting facility allows the service provider to notify the user about
events that are related to no particular transaction and do not cause a change in the
state of the session.
The Push facility permits the server to send unsolicited information to the client
taking advantage of the session information shared by the client and the server. This
facility is a non-confirmed one, so delivery of the information MAY be unreliable.
The Confirmed Push facility is similar to the Push facility, but the client confirms
the receipt of the information. The client may also choose to abort the push, so that
the server is notified.
The Session Resume facility includes means to suspend a session so that the state of
the session is preserved, but both peers know that further communication is not
possible until the client resumes the session. This mechanism is also used to handle
the situations in which the service provider detects that further communication is no
longer possible, until some corrective action is taken by the service user or
management entities. It can also be used to switch the session to use an alternate
bearer network, which has more appropriate properties than the one being used.
This facility SHOULD be implemented to ensure reasonable behavior in certain
bearer network environment. [4]
41
5.3.1.2 Capabilities and Capability Negotiations

Information that is related to the operation of the session service provider is handled
using capabilities. Capabilities are used for a wide variety of purposes, ranging
from representing the selected set of service facilities and settings of particular
protocol parameters, to establishing the code page and extension method names
used by both peers.
Capability negotiation is used between service peers to agree on a mutually

acceptable level of service, and to optimize the operation of the service provider
according to the actual requirements of the service user. Capability negotiation is to
be applied only to negotiable capabilities; informational capabilities are to be
communicated to the peer service user without modifications.
The peer which starts the capability negotiation process is called the initiator, and
the other peer is called the responder. Only a one-way capability negotiation is
defined, in which the initiator proposes a set of capabilities, and the responder
replies to these. The capability negotiation process is under the control of the
initiator, so that the responder MUST NOT ever reply with any capability setting,
which implies a higher level of functionality than the one proposed by the initiator
and supported by the service provider peers. Capability negotiation applies always
to all the known capabilities. If a particular capability is omitted from the set of
capabilities carried by a service primitive, this must be interpreted to mean that the
originator of the primitive wants to use the current capability setting, either the
default or the value agreed upon during capability negotiation process. However,
the responder may still reply with a different capability value, as long as this does
not imply a higher level of functionality. The one-way capability negotiation
proceeds as follows:
1. Service user in initiator proposes a set of capability values.
2. The service provider in the initiator modifies the capabilities, so that they do not
imply a higher level of functionality than the provider actually can support.
3. The service provider in the responder further modifies the capabilities, so that
they do not imply a higher level of functionality than the provider in the
responder actually can support.
4. The service user in the responder receives this modified set of capabilities, and
responds with a set of capabilities, which reflect the level of functionality it
actually wishes to use. If a particular capability is omitted, this is interpreted to
mean that the responding service user wants to use the proposed capability
setting.
42
5. The capabilities selected by the service user in the responder are indicated to the
service user in the initiator. They will become the default settings, which will be
applicable in the next capability negotiation during the session.
If the operation implied by the service primitive that is used to convey the
capability information fails, the capability settings that were in effect before the
operation shall remain in effect.
If a negotiable capability value is a positive integer, the final capability setting shall
be the minimum of the values, which the service users have proposed to use and
which the service provider peers are capable of supporting.
If a negotiable capability value is a set, the final capability setting shall contain only
those elements, which are all included in the subsets that the service users have
proposed to use and which the service provider peers are capable of supporting.[4]
Table 5.2 [4] describes the minimum capabilities that must be recognized by the
service user and service provider.
Table 5.2 Minimum capabilities of user and service provider
43
5.3.2 Protocol Features of Connection-Oriented WSP

The connect-oriented WSP supports,
• session establishment
• method invocation
• push messages
• suspend
• resume
• session termination
each of these possibilities are explained through examples and Time sequence
diagrams (see 5.2.2).
Session establishment example
Figure 5.2 Session Establishment
The capability negotiation is done at the session establishment. Only a one-way

capability negotiation is defined in which the initiator proposes a set of capabilities,
and the responder replies. Since WAP server is much heavier weighted than the
WAP handset, so we can expect WAP server can handle all the possible handset's
capabilities.
44
Method invocation example
Figure 5.3 Method Invocation
The method invocation is similar to that of HTTP/1.1.
Aborting a method invocation example
Figure 5.4 Method Abort
45
Unconfirmed Push example
Figure 5.5 Non-confirmed Push
Confirmed Push example
Figure 5.6 Confirmed Push
46
Normal Session Resume
Figure 5.7 Session Resumption
5.3.3 Connectionless Session Service
In the connectionless mode, WSP provides only the bare bones of the services.
Since it does not utilize the WTP layer, no confirmation can be expected for the
invocation of any method. All communication thus takes place blindly, with the
server sending information with the basic assumption that it is being accepted by
the client. Following are some of the features of connectionless WSP service:
1. only basic request-reply and push, no session management

2. does not rely upon WTP
3. provides Smart Messaging-like session services
5.3.2.1 Protocol Features of Connectionless WSP

Only three service primitives are supported:
1. MethodInvoke send a request

2. MethodResult reply to a request
3. UnitPush send a push message
47
Every push or Invoke/Result pair is identified by a TID (Transaction Identifier).

There is no intrinsic protocol logic. Communication is possible at any point in time,
provided network is available. Security services (WTLS) can be used. Since, it does
not use WTP; connectionless WSP may be unreliable!
48
6. WTP : The Transaction Layer

A transaction protocol is defined to provide the services necessary for interactive
“browsing” (request/response) applications. During a browsing session the client
generally requests information from a server & the server responds. This
request/response pair is referred to as a “transaction”. The objective of WTP is to
reliably deliver the transaction. WTP runs on top a datagram and optional security
layer. This chapter exploits the scope of WTP and its interaction with other layers.
6.1 WTP Protocol Features
The following list summarizes the features of WTP.
• Three classes of transaction service:

Class 0: Unreliable invoke message with no result message
Class 1: Reliable invoke message with no result message
Class 2: Reliable invoke message with exactly one reliable result message
• Reliability is achieved through the use of unique transaction identifiers,

acknowledgements, duplicate removal and re-transmissions.
• No explicit connection set up or tear down phases. Explicit connection open
and/or close imposes excessive overhead on the communication link.
• Optionally user-to-user reliability: the WTP user confirms every received
message.
• Optionally, the last acknowledgement of the transaction MAY contain out of
band information related to the transaction. For example, performance
measurements.
• Concatenation MAY be used, where applicable, to convey multiple Protocol
Data Units in one Service Data Unit of the datagram transport.
• Message orientation. The basic unit of interchange is an entire message and not a
stream of bytes.
• The protocol provides mechanisms to minimize the number of transactions being
replayed as the result of duplicate packets.
• Abort of outstanding transaction, including flushing of unsent data both in client
and server. The user canceling a requested service can trigger the abort.
• For reliable invoke messages, both success and failure is reported. If an invoke
can not be handled by the Responder, an abort message will be returned to the
Initiator instead of the result.
• The protocol allows for asynchronous transactions. The Responder sends back
the result, as the data becomes available.
49
6.2 Transaction Classes
The following subsections describes the transaction classes of WTP. The WTP
provider initiating a transaction is referred to as the Initiator. The WTP provider
responding to a transaction is referred to as the Responder. The transaction class is
set by the Initiator and indicated in the ‘invoke’ message sent to the Responder.
Transaction classes can not be negotiated. ‘Invoke’ is a service primitive assumed to
be present for WTP user. (for service primitives refer to chapter 5)
6.2.1 Class 0: Unreliable invoke message with no result message

Class 0 transactions provide an unreliable datagram service. It can be used by
applications that require an "unreliable push" service.
The basic behavior for class 0 transactions is as follows:

One invoke message is sent from the Initiator to the Responder. The Responder does
not acknowledge the invoke message and the Initiator does not perform re-
transmissions. At the Initiator, the transaction ends when the invoke message has
been sent. At the Responder, the transaction ends when the invoke has been
received. The transaction is stateless and can not be aborted.
6.2.2 Class 1: Reliable invoke message with no result message

Class 1 transactions provide a reliable datagram service. It can be used by
applications that require a "reliable push" service.
One invoke message is sent from the Initiator to the Responder. The invoke message
is acknowledged by the Responder. The Responder maintains state information for
some time after the acknowledgement has been sent to handle possible re-
transmissions of the acknowledgement if it gets lost and/or the Initiator re-transmits
the invoke message. At the Initiator, the transaction ends when the
acknowledgement has been received. The transaction can be aborted at any time.
If the User acknowledgement function is enabled, the WTP user at the Responder
confirms the invoke message before the acknowledgement is sent to the Initiator.
6.2.3 Class 2: Reliable invoke message with one reliable result message
Class 2 transactions provide the basic invoke/response transaction service. One WSP
session MAY consist of several transactions of this type.

One invoke message is sent from the Initiator to the Responder. The Responder
replies with exactly one result message that implicitly acknowledges the invoke
message. If the Responder takes longer to service the invoke than the Responder's
acknowledgement timer interval, the Responder MAY reply with a "hold on"
acknowledgement before sending the result message. This prevents the Initiator from
unnecessarily re-transmitting the invoke message. The Responder sends the result
50
message back to the Initiator. The result message is acknowledged by the Initiator.
The Initiator maintains state information for some time after the acknowledgement
has been sent. This is done in order to handle possible re-transmissions of the
acknowledgement if it gets lost and/or the Responder re-transmits the result
message. At the Responder the transaction ends when the acknowledgement has
been received. The transaction can at any time be aborted.
If the User acknowledgement function is enabled, the WTP user at the Responder
confirms the invoke message before the result is generated. The WTP user at the
Initiator confirms the result message before the acknowledgement is sent to the
Responder.
6.3 WTP Management Entity

The WTP Management Entity is used as an interface between the WTP layer and the
environment of the device. The WTP Management Entity provides information to
the WTP layer about changes in the devices environment, which MAY impact
the correct operation of WTP.
The WTP protocol is designed around an assumption that the environment in which
it is operating is capable of transmitting and receiving data. For example, this
assumption includes the following basic capabilities that must be provided by the
mobile device:
• The mobile is within a coverage area applicable to the bearer service being
invoked;
• The mobile having sufficient power and the power being on;
• Sufficient resources (processing and memory) within the mobile are available to
WTP;
• The WTP protocol is correctly configured, and ;
• The user is willing to receive/transmit data.
The WTP Management Entity monitors the state of the above services/capabilities of
the mobile’s environment and would notify the WTP layer if one or more of the
assumed services were not available. For example if the mobile roamed out of
coverage for a bearer service, the Bearer Management Entity should report to the
WTP Management Entity that transmission/reception over that bearer is no longer
possible. In turn, the WTP Management Entity would indicate to the WTP layer to
close all active connections over that bearer.
In addition to monitoring the state of the mobile environment the WTP Management
Entity MAY be used as the interface to the user for setting various configuration
parameters used by WTP, such as device address. It could also be used to
implement functions available to the user such as a drop all data connections feature.
In general the WTP Management Entity will deal with all issues related to
initialization, configuration, dynamic re-configuration, and resources as they pertain
to the WTP layer.
51
6.4 Notations Used

The notations used for the explanation of some of the WTP transaction services
require prior knowledge of certain notations and definitions. For a quick brush up on
them refer to 5.2 (WSP Notations). The only significant difference is that now X will
be TR for the transaction layer.
6.5 Services Provided to Upper Layer

6.5.1 TR-Invoke
This primitive is used to initiate a new transaction. Following are the parameters of
this primitive and their utilization.
6.5.1.1 Source Address

The source address is the unique address of the device making a request to the WTP
layer. The source address MAY be an MSISDN number, IP address, X.25 address or
other identifier.
6.5.1.2 Source Port

The source port number associated with the source address.
6.5.1.3 Destination Address

The destination address of the user data submitted to the WTP layer. The destination
address MAY be an MSISDN number, IP address, X.25 address or other identifier.
6.5.1.4 Destination Port

The destination port number associated with the destination address for the requested
or existing transaction.
6.5.1.5 Ack-Type
This parameter is used to turn the User acknowledgement function on or off.
6.5.1.6 User Data

The user data carried by the WTP protocol. The unit of data submitted to or received
from the WTP layer is also referred to as the Service Data Unit. This is the complete
unit (message) of data which the higher layer has submitted to the WTP layer for
transmission. The WTP layer will transmit the Service Data Unit and deliver it to its
destination without any manipulation of its content.
6.5.1.7 Class Type

Indicates the WTP transaction class.
6.5.1.8 Exit Info

Additional user data to be sent to the originator on transaction completion.
52
6.5.1.9 Handle
The transaction handle is an index returned to the higher layer so the higher layer
can identify the transaction and associate the data received with an active
transaction. The TR-Handle uniquely identifies a transaction. TR-Handle is an alias
for the source address, source port, destination address, and destination port of the
transaction. The TR-Handle has local significance only.[5]
6.5.2 TR-Result
This primitive is used to send back a result of a previously initiated transaction. It
also utilizes the following parameters :
• User Data
• Exit Info
• Handle
6.5.3 TR-Abort
This primitive is used to abort an existing transaction. Parameters include:
• Abort Code
• Handle
6.6 Classes of Operation
6.6.1 Class 0 Transaction
6.6.1.1 Motivation
Class 0 is an unreliable datagram service. It can be used by WSP [WSP], for
example, to make an unreliable “push” within a session using the same socket
association.
This class is intended to augment the transaction service with the capability for an
application using WTP to occasionally send a datagram within the same context of
an existing session using WTP. It is not intended as a primary means of sending
datagrams.
6.6.1.2 Protocol Data Unit

The following PDU is used:
1. Invoke PDU
53
Figure 6.1 Class 0 Transaction

6.6.1.3 Procedure
A Class 0 transaction is initiated by the WTP user by issuing the TR-Invoke request
primitive with the Transaction Class parameter set to Class 0. The WTP provider
sends the invoke message and becomes the Initiator of the transaction. The remote
WTP provider receives the invoke message and becomes the Responder of the
transaction. The Initiator does not wait for or expect a response. If the invoke
message is received by the Responder it is accepted immediately. There is no
duplicate removal or verification procedure performed. However, the initiator
MUST increment the TID counter between each transaction, but the responder
MUST NOT update its cached TID.
The WTP provider MUST support this transaction class. The WTP provider MUST
be able to act as both Initiator and Responder. Refer to figure 6.1.

6.6.2.1 Motivation
The Class 1 transaction is a reliable invoke message without any result message.
This type of transaction can be used by WSP to realize a reliable "push" service.
6.6.2.2 Protocol Data Units

The following PDUs are used:
1. Invoke PDU
2. Ack PDU
2. Abort PDU
54
6.6.2.3 Procedure
transaction. The Responder checks the Transaction Identifier and determines
whether a verification has to be initiated. If not, it delivers the message to the user
and returns the last acknowledgement to the Initiator. The Responder MUST keep
state information in order to re-transmit the last acknowledgement if it gets lost.
The WTP provider MUST support this transaction class. The WTP provider MUST
also be able to act as both Initiator and Responder. Refer to figure 6.2.
6.6.3.1 Motivation
The Class 2 transaction is the basic request/response transaction service. This is the
most commonly used transaction service. For example, it is used by WSP for method
invocations.
6.6.3.2 Protocol Data Units

The following PDUs are used:
1. Invoke PDU
2. Result PDU
3. Ack PDU
4. Abort PDU
55

6.6.3.3 Procedure
transaction. The Responder checks the Transaction Identifier and determines
whether a verification has to be initiated. If not, it delivers the message to the WTP
user and wait for the result. The Responder MAY send a hold on acknowledgement
after a specified time.
The WTP user sends the result message by issuing the TR-Result request primitive.
When the Initiator has received the result message it returns the last
acknowledgement to the Responder. The Initiator MUST keep state information in
order to re-transmit the last acknowledgement if it gets lost. Refer to figure 6.3.
If the Responder does not support this transaction class it returns an Abort PDU with
the abort reason NOTIMPLEMENTEDCL2 as a response to the invoke message.
7. WTLS and WDP : Security and transport layer

At the security layer the Wireless Transport Layer Security (WTLS) is used to
provide transport security between a WAP client and the WAP Gateway. WTLS is a
security protocol based upon the industry-standard Transport Layer Security (TLS)
protocol, formerly known as Secure Sockets Layer (SSL).
The Transport Layer Protocol in the WAP architecture is referred to as the Wireless
datagram Protocol (WDP). WDP operates above the data capable bearer services
supported by the various network types and offers a consistent interface to the upper
56
layers of the stack and communication transparently over one of the available
bearer services.
This chapter briefly touches upon both of these protocol layers in the WAP protocol
stack.
7.1 Wireless Transport Layer Security (WTLS)
In the WTLS layer operates above the transport protocol layer. The WTLS layer is
modular and it depends on the required security level of the given application
whether it is used or not. WTLS provides the upper-level layer of WAP with a
secure transport service interface that preserves the transport service interface below
it. In addition, WTLS provides an interface for managing (e.g. creating and
terminating) secure connections.
The primary goal of the WTLS layer is to provide privacy, data integrity and
authentication between two communicating applications. WTLS provides
functionality such as datagram support, optimized handshake and dynamic key
refreshing. The WTLS protocol is optimized for low-bandwidth bearer networks
with relatively long latency.
7.1.1 WTLS Connection Management

Before we go into the details of the WTLS Connection and session management, a
brief over view of the more important concepts is given below:
Abbreviated Handshake
A creation of a new connection state based on an existing secure session.
Connection State
The operating environment of the record protocol. The connection state includes all
parameters that are needed for the cryptographic operations (encryption/decryption
and MAC (Message Authentication Code) calculation/verification). Each secure
connection has a connection state
Datagram Transport
A transport service that does not guarantee that the sent transport SDUs are not lost,
duplicated or delivered out of order.
Handshake
The procedure of agreeing on the protocol options to be used between a client and a
server. It includes the negotiation of security parameters (e.g., algorithms and key
lengths), key exchange and authentication. Handshaking occurs in the beginning of
each secure connection.
Full Handshake
57
A creation of a new secure session between two peers. The full handshake includes
the parameter negotiation and the exchange of public-key information between the
client and server.
Optimized Handshake
A creation of a new secure session between two peers. Unlike in the full handshake,
the server looks up the client certificate from its own source without requesting it
over the air from the client.
Record Protocol
The record protocol takes messages to be transmitted, optionally compresses the
data, applies a MAC, encrypts and transmits the result. Received data is decrypted,
verified, decompressed and then delivered to higher level clients. There are four
record protocol clients described in this document: the handshake protocol, the alert
protocol, the change cipher spec protocol and the application data protocol.
Secure Connection
The WTLS connection that has a connection state. Each secure connection is
identified by the transport addresses of the communicating peers.
Secure Session
The secure session that is negotiated on a handshake. The items that are negotiated
(e.g., session identifier, algorithms and master secret) are used for creating secure
connections.
Session Resume
A new secure connection can be established based on a previously negotiated secure
session. So if there is an existing secure session it is not necessary to perform the full
handshake and cryptographic calculations again. For example, a secure connection
may be terminated and resumed later. Many secure connections can be established
using the same secure session through the resumption feature of the WTLS
handshake protocol. [6]
WTLS Connection management allows a client to connect with a server and to agree
on protocol options to be used. The secure connection establishment consists of
several steps and either client or server can interrupt the negotiation at will (e.g., if
the parameters proposed by the peer are not acceptable). The negotiation may
include the security parameters (e.g., cryptographic algorithms and key lengths), key
exchange and authentication. Either the server or client service user can also
terminate the connection at any time.
The primitive sequence for establishing a secure session (abbreviated handshake) is

shown in 7.1.
58
7.1.2 WTLS Connection State

A WTLS connection state is the operating environment of the WTLS Record
Protocol. It specifies a compression algorithm, encryption algorithm and MAC
algorithm.
Logically, there are always two connection states outstanding:

• The current state; and
• The pending state.
All records are processed under the current state. The security parameters for the
pending state are set by the WTLS Handshake Protocol. The Handshake Protocol
must make the pending state current. The pending state is then reinitialized to an
empty state. The initial current state always specifies that no encryption,
compression, or MAC will be used.[6]
7.1.3 Handshake Protocol

The cryptographic parameters of the secure session are produced by the WTLS
Handshake Protocol, which operates on top of the WTLS Record Layer. When a
WTLS client and server first start communicating, they agree on a protocol version,
select cryptographic algorithms, optionally authenticate each other, and use public-
key encryption techniques to generate a shared secret.
The WTLS Handshake Protocol involves the following steps: [6]
1. Exchange hello messages to agree on algorithms, exchange random values.

2. Exchange the necessary cryptographic parameters to allow the client and server
to agree on a pre-master secret.
59
3. Exchange certificates and cryptographic information to allow the client and

server to authenticate themselves.
4. Generate a master secret from the pre-master secret and exchanged random
values.
5. Provide security parameters to the record layer.
6. Allow the client and server to verify that their peer has calculated the same
security parameters and that the handshake occurred without tampering by an
attacker.
7.1.4 WTLS Cryptography Schemes

Following are some of the key agreement schemes utilized in WTLS.
7.1.4.1 RSA Encryption Scheme

When RSA is used for server authentication and key exchange, a 20-byte secret
value is generated by the client, encrypted under the server's public key, and sent to
the server. The server uses its private key to decrypt the secret value.
7.1.4.2 Diffie-Hellman algorithm

Conventional Diffie-Hellman algorithm is used.
7.1.4.3 Elliptic Curve Diffie-Hellman algorithm

The EC Diffie-Hellman algorithm is used.
7.1.5 WTLS Internal Architecture

In order to provide the security environment demanded for secure over the air
transactions, WTLS has four primary protocols
• Handshake Protocol
• Alert Protocol
• Application Protocol
• Change Cipher Spec Protocol
Transaction Protocol (WTP)
Handshake Alert Application Change Cipher

WTLS Protocol Protocol Protocol Spec Protocol
Record Protocol
60
7.2 Wireless Datagram Protocol (WDP)

The Transport layer protocol in the WAP architecture consists of the Wireless
Transaction Protocol (WTP) and the Wireless Datagram Protocol (WDP). The WDP
layer operates above the data capable bearer services supported by the various
network types. As a general datagram service, WDP offers a consistent service to the
upper layer protocol (Security, Transaction and Session) of WAP and communicate
transparently over one of the available bearer services.
Since the WDP protocols provide a common interface to the upper layer protocols
(Security, Transaction and Session layers), they are able to function independently of
the underlying wireless network. This is accomplished by adapting the transport
layer to specific features of the underlying bearer.
The services offered by WDP include application addressing by port numbers,

optional segmentation and optional error detection. The services allow for
applications to operate transparently over different available bearer services.
7.2.1 WDP Architecture
61
Figure 7.3 Wireless Datagram Protocol Architecture
WDP offers a consistent service at the Transport Service Access Point to the
upper layer protocol of WAP. This consistency of service allows for applications
to operate transparently over different available bearer services. The varying
heights of each of the bearer services shown in Figure 7.3 illustrate the difference
in functions provided by the bearers. Thus the difference in WDP protocol
necessary to operate over those bearers to maintain the same service offering at
the Transport Service Access Point is accomplished by a bearer adaptation.
WDP can be mapped onto different bearers, with different characteristics. In order
to optimize the protocol with respect to memory usage and radio transmission
efficiency, the protocol performance over each bearer may vary. However, the
WDP service and service primitives will remain the same, providing a consistent
interface to the higher layers.[7]
7.2.2 WDP General Description
62
The WDP layer operates above the data capable bearer services supported by the
various network types. As a general datagram service, WDP offers a consistent
service to the upper layer protocol (Security, Transaction and Session) of WAP
and communicate transparently over one of the available bearer services.
WDP supports several simultaneous communication instances from a higher layer

over a single underlying WDP bearer service. The port number identifies the
higher layer entity above WDP. This may be another protocol layer such as the
Wireless Transaction Protocol (WTP) or the Wireless Session Protocol (WSP) or
an application such as electronic mail. By reusing the elements of the underlying
bearers, WDP can be implemented to support multiple bearers and yet be
optimized for efficient operation within the limited resources of a mobile device.
Figure 7.4 shows a general model of the WAP protocol architecture and how
WDP fits into that architecture.
Figure 7.4 General WDP Model
In Figure 7.4 the shaded areas are the layers of protocol, which the WDP
Specification is specifically applicable. At the Mobile the WDP protocol consists
63
of the common WDP elements shown by the layer labeled WDP. The Adaptation
Layer is the layer of the WDP protocol that maps the WDP protocol functions
directly onto a specific bearer. The Adaptation Layer is different for each bearer
and deals with the specific capabilities and characteristics of that bearer service.
The Bearer Layer is the bearer service such as GSM SMS, or USSD, or IS-136 R-
Data, or CDMA Packet Data. At the Gateway the Adaptation Layer terminates
and passes the WDP packets on to a WAP Proxy/Server via a Tunneling protocol,
which is the interface between the Gateway that supports the bearer service and
the WAP Proxy/Server. For example if the bearer were GSM SMS, the Gateway
would be a GSM SMSC and would support a specific protocol (the Tunnelling
protocol) to interface the SMSC to other servers. The SubNetwork is any common
networking technology that can be used to connect two communicating devices,
examples are wide-area networks based on TCP/IP or X.25, or LANs operating
TCP/IP over Ethernet. The WAP Proxy/Server may offer application content or
may act as a gateway between the wireless WTP protocol suites and the wired
Internet [7].
7.2.3 WDP Management Entity

The WDP Management Entity is used as an interface between the WDP layer and
the environment of the device. The WDP Management Entity provides
information to the WDP layer about changes in the devices environment, which
may impact the correct operation of WDP.
For example, this assumption includes the following basic capabilities that must
be provided by the mobile:
• the mobile is within a coverage area applicable to the bearer service being
invoked;
• the mobile having sufficient power and the power being on;
• sufficient resources (processing and memory) within the mobile are available
to WDP;
• the WDP protocol is correctly configured, and ;
• the user is willing to receive/transmit data.
The WDP Management Entity would monitor the state of the above
services/capabilities of the mobile’s environment and would notify the WDP layer
if one or more of the assumed services were not available. For example if the
mobile roamed out of coverage for a bearer service, the Bearer Management
Entity should report to the WDP Management Entity that transmission/reception
over that bearer is no longer possible. In turn the WDP Management Entity would
indicate to the WDP layer to close all active connections over that bearer. Other
examples such as low battery power would be handled in a similar way by the
WDP Management Entity.
In addition to monitoring the state of the mobile environment the WDP

Management Entity may be used as the interface to the user for setting various
configuration parameters used by WDP, such as device address. It could also be
64
used to implement functions available to the user such as a “drop all data
connections” feature. In general the WDP Management Entity will deal with all
issues related to initialization, configuration, dynamic re-configuration, and
resources, as they pertain to the WDP layer.[7]
7.2.4 WDP Conformance Clause for Bearers

The WDP defines a minimum set of features that must be supported by the bearer
to ensure interoperability.
The WDP protocol operates over various bearer services. Each bearer service for
which WDP is specified supports a datagram service. It is this datagram service
which WDP uses to support the abstract service primitives defined in this
specification. For bearer services supporting IP the WDP protocol must be UDP.
For bearer services not supporting IP the bearer services must provide some basic
functionalities through their data link layer such as Source and Destination port
address T-DUnitdata Service primitives.
7.2.5 WDP Profiles

Since WDP is supposed to adapt differently to different bearer services in order to
maintain a consistent datagram layer to the other layers, it has a different profile
for different bearers. We will illustrate a typical WDP profile over GSM using the
GSM SMS profile as an example
7.2.5.1 WDP over GSM: SMS Profile
65
Figure 7.5 WDP over GSM SMS
In the figure the shaded portion is the adaptation required by the WDP to SMS, to
provide consistent interface to the upper layers. In between the Mobile and the
WAP proxy the frame is passed through a SMS-IF Tunnel which ensures that the
frame reaches the proxy even through a different subnetwork. If the intervening
network has a TCP/IP subnetwork then a direct link to the server TCP/IP layer
can be provided through UDP (User datagram Protocol).
7.2.6 WDP Protocol Description

In order to implement the WDP datagram protocol the following fields are
necessary:
· Destination Port
· Source Port
· If the underlying bearer does not provide Segmentation and Reassembly the
feature is implemented by the WDP provider in a bearer dependent way.
7.2.6.1 Mapping of WDP for IP

The User Datagram Protocol (UDP) is adopted as the WDP protocol definition for
any wireless bearer network where IP is used as a routing protocol. UDP provides
port based addressing and IP provides the segmentation and reassembly in a
connectionless datagram service. There is no value in defining a new datagram
protocol to operate over IP when the ubiquitous User Datagram Protocol (UDP)
will provide the same mechanisms and functions, and is already very widely
66
implemented. Therefore in all cases where the IP protocol is available over a

bearer service the WDP Datagram service offered for that bearer will be UDP.
7.2.6.2 Mapping of WDP for GSM SMS and USSD

WDP bearers in the Global System for Mobile Communications (GSM) include
GSM Short Message Service (GSM SMS) and GSM Unstructured Supplementary
Service Data (GSM USSD).
WDP for GSM supports mandatory binary and optional text based headers. GSM
USSD Phase 2 supports binary headers, GSM SMS Phase 2 supports both binary
and text based headers and GSM SMS Phase 1 supports text based headers.
Each packet (segment) used in the WDP protocol are identified by a User Data
Header Information Element Identifier defining a port number structure located in
the header of the packet. This Information Element Identifier for GSM SMS or
USSD has a similar function to the Protocol Identifier in a IP based network. The
construct enables the WDP protocol to coexist with other features of the legacy
bearer network.
This brings us to the end of our description of the WAP Protocol stack. We will
now elaborate on a more specialized WAP service, the WAP Push Protocol.
8. WAP Push Architectural Overview
67
The push access protocol is the protocol used for conveying content that should be
pushed to a client (using XML), and push related control information, between a
Push Initiator and a Push Proxy / Gateway.
8.1 Introduction
The WAP Push framework introduces a means within the WAP effort to transmit
information to a device without a previous user action. In the normal client/server
model, a client requests a service or information from a server, which then responds
in transmitting information to the client. This is known as “pull” technology: the
client “pulls” information from the server. The World Wide Web is a typical
example of pull technology, where a user enters a URL (the request) which is sent to
a server, and the server answers by sending a Web page (the response) to the user. In
contrast to this, there is also “push” technology, which is also based on the
client/server model, but where there is no explicit request from the client before the
server transmits its content.
Figure 8.1 Comparison of Pull vs. Push Technology
Another way to say this is that whereas “pull” transactions of information are always
initiated from the client, “push” transactions are server-initiated.
8.2 The Push Framework
A push operation in WAP occurs when a Push Initiator transmits content to a client
using either the Push Over-The-Air protocol or the Push Access Protocol. In its
simplest form, the architecture would look like this:
68
Figure 8.2 The push framework at its simplest
However, the Push Initiator shares no protocol with the WAP Client: the Push
Initiator is on the Internet, and the WAP Client is in the WAP domain. Therefore, the
Push Initiator cannot contact the WAP Client without an intermediary, so we need to
insert a translating gateway:
Figure 8.3 The push framework with push proxy gateway
Thus, the Push Initiator contacts the Push Proxy Gateway (PPG) from the Internet
side, delivering content for the destination client using Internet protocols. The PPG
does what is necessary to forward the pushed content to the WAP domain, and the
content is then transmitted over-the-air in the mobile network to the destination
client. The Push Access Protocol, or PAP, uses XML messages that may be tunneled
through various well-known Internet protocols, for example HTTP.
In addition to providing simple proxy gateway services, the PPG may is capable of
notifying the Push Initiator about the final outcome of the push operation, and it may
wait for the client to accept or reject the content in two-way mobile networks. It may
also provide the Push Initiator with client capability lookup services, letting a Push
Initiator select the optimal flavor of this particular content for this particular client.
69
The Internet-side PPG access protocol is called the Push Access Protocol. The
WAP-side (OTA) protocol is called the Push Over-The-Air Protocol. Thus, a revised
schematic looks something like this:
Figure 8.4 The push framework with protocols
8.3 The Push Proxy Gateway
The Push Proxy Gateway (PPG) is the entity that does most of the work in the Push
architecture. Its responsibilities include acting as an access point for content pushes
from the Internet to the mobile network, and everything associated therewith
(authentication, security, client control, etc). As the PPG is the entry point to a
mobile network, it is the owner of this gateway that decides the policies about who is
able to gain access to the WAP network, who is able to push content and who is not
and under which circumstances and parameters, etc.
8.3.1 Services Overview

The PPG hosts the Push framework with several services. First and foremost, it is
the entry point for pushed content from the Internet destined for the WAP domain;
this means it may be able to perform at least the following:
• Push initiator identification and authentication; access control

• Parsing of and error detection in content control information
• Client discovery services
• Address resolution
• Protocol conversion
8.3.2 Access from the Internet Side

The PPG accepts pushed content from the Internet using the Push Access Protocol.
This content is divided into several sections using a multipart / related content type,
where the first part contains information for the PPG itself. Such information
70
includes recipient information, timeouts, callback requests, and similar pieces of

information. The PPG will acknowledge successful (or report unsuccessful) parsing
of this control information, and may in addition report debug information about the
content itself. It may also do a callback to the pushing server when the final status
of the push submission (delivered, cancelled, expired, etc.) has been reached, if the
push initiator so requests.
8.3.3 Message Handling Service

Once the content has been accepted for delivery, the PPG attempts to find the
correct destination device and deliver the content to that client using the Push Over-
The-Air protocol (see section 9). The PPG will attempt to deliver the content until a
timeout expires. This timeout may be set by the push initiator and/or policies of the
mobile operator.
The net result of this function is asynchronous operation from the Initiator’s point
of view (the Initiator need not wait on-line for the PPG to complete its delivery).
8.3.4 Encoding and Compilation

The PPG may encode WAP content types (e.g. WML and SI) into their binary
counterparts, if feasible. This textual-to-binary translation would take place before
delivery over-the-air. Other content types, which may be application-specific or just
plain arbitrary, may be forwarded as received.
It is also possible for the Push Initiator to pre-compile its content into binary form,
to take workload off the PPG (or for other reasons). When the PPG receives
precompiled WML, WMLScript, or SIs, they are forwarded as received.
8.3.5 Client Capabilities Query Service

A Push Initiator may query the PPG for client capabilities and preferences, to create
better-formatted content for a particular WAP device.
8.4 The Push Access Protocol
The Push Access Protocol (PAP) is the means by which an Internet-based Push
Initiator pushes content to a mobile network, addressing its PPG. Care has been
taken to ensure that this protocol can be tunneled through any other or future
Internet protocol in common use, although HTTP is chosen as the initially supported
carrier.
8.4.1 PAP Operations

The PAP supports the following operations:
• Push Submission (Initiator to PPG)

• Result Notification (PPG to Initiator)
• Push Cancellation (Initiator to PPG)
71
• Status Query (Initiator to PPG)

• Client Capabilities Query (Initiator to PPG)
8.4.2 Push Submission

The Push message contains three entities: a control entity, a content entity, and
optionally a capability entity. These are bundled together in a multipart / related
message, which is sent from the Push Initiator to the PPG.
The control entity is an XML document that contains delivery instructions

destined for the PPG, whereas the content entity is destined for the mobile device.
The PPG may or may not convert this content into a more bandwidth-optimized
form before forwarding it over-the-air: WML could be encoded to WML-C, while
other content types will be completely unknown to the PPG or even encrypted for
use by the mobile device only.
The optional capability entity contains the client capabilities that the message was
formatted for. The Push Initiator may create this entity to indicate what it thinks
the client capabilities are.
8.4.3 Confirmation Notification

If the Push Initiator has requested confirmation of successful delivery, this
message is transmitted from the PPG to the Push Initiator when the content has
been delivered to the mobile device (over a 2-way bearer) or transmitted to the
device (over a 1-way bearer). It contains an XML entity. It is also transmitted in
case of a detected delivery failure, informing the Initiator thereof.
One key feature of the Push Framework is the possibility for a Push Initiator to
rely on the response from the PPG. If it cannot take that responsibility, it must
abort the operation, and the Push Initiator will know that the content never
reached its destination. There are no loopholes within the framework for false
positive delivery confirmations.
8.4.4 Push Cancellation

This is an XML entity transmitted from the Push Initiator to the PPG, requesting
cancellation of previously submitted content. The PPG responds with an XML
entity whether or not the cancellation was successful.
8.4.5 Client Capabilities Query

This is an XML entity transmitted from the Push Initiator to the PPG, requesting
the capabilities of a particular device on the network. The PPG responds with a
multipart / related in two parts, where the multipart root is the result of the
request, and the second part is the capabilities of the device in the format defined
by the User Agent Profiles group.
8.5 The Push Over-The-Air Protocol
72
The Push Over-The-Air (OTA) protocol is a thin protocol layer architecturally on

top of WSP. It is this part of the Push Framework that is responsible for
transporting content from the PPG to the client and its user agents. The OTA
protocol may use WSP sessions to deliver its content.
Connection-oriented pushes require that an active WSP session is available, but

the server cannot create a session. To solve the case where there is no active WSP
session, the Push framework introduces a Session Initiation Application in the
client, that listens to session requests from the OTAservers and responds by
setting up a WSP session for push purposes. The client may verify the identity
information in this request against a list of recognized OTAservers before
attempting to establish any push sessions. Push delivery may also be performed
without the use of sessions, in a connectionless manner. This is needed in one-
way networks.
8.6 Security Considerations
When implementing WAP Push, security and trust models come into
consideration in several areas. These are examples of questions that may arise:
• How can a PI be authenticated?

• What role could the PPG play in the security and trust model?
• What are the access control policies for a Push Initiator and pushed content?
• How can a client authenticate something if it has no certificate?
Regardless of these issues, it should be kept in mind that the Push Framework is
always capable of providing the client with enough information to have a trust
model and security policy of its own.
8.6.1 Authenticating a Push Initiator

It is important that a Push Initiator is authenticated in one form or another,
depending on the security environments in which the Push Initiator and PPG are
operating. This is an attempt to list some of the possible solutions.
8.6.1.1 Use of Session-level Certificates (TLS, SSL).

If the network between the Push Initiator and PPG is not trusted (e.g., the Internet,
a very large Intranet, etc.), TLS/SSL can be used between the Push Initiator and
the PPG.
8.6.1.2 Use of Object-level Certificates (Encrypted Content).

Certificates could be used to sign and/or encrypt the pushed content on an end-to-
end basis. This would not involve the PPG in the authentication process, and
would strengthen confidence in the content authenticity at the client end of the
push submission.
73
8.6.1.3 HTTP Authentication.

Even though the most common form of HTTP authentication is the basic
authentication (i.e., a user/password pair), other forms of HTTP authentication
(e.g., digest based) might be preferable. The major differences between this
approach and the use of certificates are that the latter is stronger in scalability and
confidence, while the former is weak in these aspects.
8.6.1.4 A Combination of Technologies.

Technologies could be combined. For example, the Push Initiator can establish an
anonymous TLS/SSL session with a PPG, whereupon HTTP authentication could
be used to authenticate the Push Initiator. Signed and/or encrypted content could
then be sent over this authenticated session.
8.6.1.5 Trusted Network.

In many real world installations, the network between the Push Initiator and the
PPG is a private network. Therefore, the Push Initiator is implicitly trusted in such
installations.
9. WAP and IMode: A Comparison

9.1 Introduction to IMode
74
I-mode is a wireless technology developed by the Japanese company NTT DoCoMo

that enables users to access Internet services via their wireless phones. I-mode (the I
stands for information) is based on packet data transmission technology. This
means that i-mode is always online, and therefore users are charged only for how
much information they retrieve, not how many minutes they are using it for. i-mode
can be used to exchange e-mail with computers, handhelds and other i-mode
cellular phones.
As the Japanese giant NTT DoCoMo recently expanded their services into the
European market we may witness a convergence of the two global standards in
Mobile Internet technology, Wireless Application Protocol (WAP) and i-mode.
They are essentially similar technologies allowing the user to access web based
information with transactional capabilities from a mobile phone. However there are
some major differences.
9.2 Differences between WAP and IMode
9.2.1 WML and CHTML

The first important difference is the programming language used. WAP uses the
markup language WML (Wireless Markup Language) while i-mode uses CHTML
(Compact HTML). Compact HTML has an advantage over WML in that a large
majority of WML developers come from the "Web" world where they are used to
HTML. However, the future of Internet content serving is XML, and from XML the
step to WML is hardly noticeable. It's much more noticeable with Compact HTML
or HTML.
9.2.2 IMode: Always on Connection

The second important difference between WAP and i-mode is that i-mode is an
always-on connection. This means that you do not have to 'dial up' to access a site
and email is instantly sent to your phone. This uses GPRS (General Packet Radio
Service) technology and will be made available to us some time next year. E-mail
will become as instant as Short Message Service (SMS), and as phone technology
advances, we will be able to send, receive and store large files on our wireless
devices.
9.2.3 Billing
The third major difference is in billing. As i-mode is based on a packet-data
(9600bps) transmission system, subscribers will be charged according to the volume
of data transmitted, not the time spent on line. With the 'always on' connection, this
method is necessary as the time spent is unlimited.
9.3 The Future

One bonus for i-mode is the fact that you do not need to own a credit card to
purchase online, as the cost is added to your mobile phone bill. This is particularly
75
important to companies targeting younger audiences who do not have credit cards. It
also creates a smaller barrier to purchase for consumers as some product lines are
expected to sell higher volumes over the 'wireless' Internet than the 'wired' Internet.
It must be noted that i-mode is NOT the WAP killer the media has been waiting for.
To be honest, both technologies are in their infancy, and would do well to learn from
each other. While WAP and i-mode both have different specifications, WAP
specifications are being modified to to become more like it's Asian counterpart. This
is overseen by the WAP Forum, which is the industry association involving
companies from every sector of the wireless industry value chain.
Also, for now, i-mode is being used mostly in Japan, although NTT DoCoMo (which
has 20 million subscribers) hopes to move i-mode service into Britain and the rest of
Europe in the future. In doing so, NTT DoCoMo has begun to provide English
content on their i-mode cellular phones for foreigners living in Japan. I-Mode
service in the United Kingdom is expected to launch later this month.
Before it's launch, WAP was hailed as the future for mobile communication,
entertainment and commerce. The hype was massive and expectations were high.
We have now seen what it has to offer, and some are disappointed with the present
offerings. WAP has made a jump in mobile technology. We can now email, purchase
and access data on the move. Something we couldn't do a few months ago.
After the hype has died down we will realize that it is an interim technology while
we wait for the real deal. 3G (third generation) mobile Internet will be in our pocket
by 2004 realistically, when we'll be video-conferencing and playing 3D games.
The wireless industry and analysts alike believe - and more probably hope - that
more people will be accessing the Internet from their mobile phone than from their
PCs in the next few years.
They also anticipate that handsets will have the computing power of a sophisticated
laptop within the next five years and that these devices will be used for nearly all our
communication and information needs.
But aside from this wistful dreaming of a bright technological future, it is important
for the industry to realize that above all other considerations, managing the
consumer's expectations is foremost among them.
If the end user fails to see the benefit of WAP they will quickly ditch it in favor of
something more appropriate to their needs and desires.
10. References
[1] Wireless Application Protocol Architecture Specification, URL:
www.wapforum.org
76
[2] WAP – a study of the concept for mobile service provisioning, a thesis by
Mattias Andersson & Kim Bergström.
[3] Wireless Application Protocol, Wireless Application Environment overview, v

1.3, URL : www.wapforum.org
[4] Wireless Application Protocol, Wireless Session Protocol Specification,

URL: www.wapforum.org
[5] Wireless Application Protocol, Wireless transaction Protocol Specification,

URL : www.wapforum.org
[6] Wireless Application Protocol, Wireless Transport Layer Security

Specification, URL : www.wapforum.org
[7] Wireless Application Protocol, Wireless Datagram Protocol Specification,

URL : www.wapforum.org
[8] Wireless Application Protocol, Push Message Specification, URL :

www.wapforum.org
77

WAP

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

WAP

Enviado por

Direitos autorais:

Formatos disponíveis

Wireless Application Protocol

Affan Ahmed Adeel Abbas

At the dawning of the 21st century we see an overwhelming interest in wireless

2. WAP Architectural Overview.…..…..…..…..…..…..…… 7

3. The WAP protocol stack..…..…..…..…..…..…..…..…….. 11

4. WAE – The Application Layer…..…..…..…..…..…..…… 17

5. WSP – The Session Layer.…..…..…..…..…..…..…..……. 27

5.3.3 Connectionless Session Service 37

6. WTP – The Transaction Layer..…..…..…..…..…..…..…… 39

7. WTLS and WDP – Security and Transport Layer…………. 47

7.2.6.1 Mapping of WDP for IP 56

8. WAP Push Architectural Overview..…..…..…..…..…..…. 58

9. WAP and IMode: A Comparison……………………..…… 65

Figure 2.1 The WWW Architecture 7

Figure 3.1 The WAP Protocol Stack 11

Figure 4.1 WAE Logical Model 19

Figure 5.1 A non-confirmed Service 29

Figure 6.1 Class 0 Transaction 44

Figure 7.1 Abbreviated Handshake 49

Figure 8.1 Comparison of pull vs. push technology 58

Content Format – actual representation of content.

Man-Machine Interface – a synonym for user interface.

1.1 History of WAP

In order to avoid this multitude of concepts and guide the development of

1.2 Motivation for WAP

• Less powerful CPUs,

Similarly, wireless data networks present a more constrained communication

• Interoperable – terminals from different manufacturers communicate with

1.4 The WAP philosophy

In short, WAP provides a method to communicate across wireless networks

• Model closely intertwined with that of the Internet

• Handheld Device Markup Language and Wireless Markup Language

• Optimization of data transfer.

• Operating system independent

2. WAP Architectural Overview

2.1 The World Wide Web model

Figure 2.1 The WWW architecture

• Standard Protocols – Standard networking protocols allow any web browser to

This infrastructure allows users to easily reach a large number of third-party

The WWW protocols define three classes of servers:

• Origin server – The server on which a given resource (content) resides or is to be

2.2 The WAP Model

Figure 2.2 WAP programming model

2.3 Example WAP Network

Figure 2.3 Example WAP network

3. The WAP Protocol Stack

The WAP architecture provides a scaleable and extensible environment for

Figure 3.1 WAP protocol Stack

3.1 Wireless Application Environment (WAE)

The Wireless Application Environment (WAE) is a general-purpose application

• Wireless Markup Language (WML) – a lightweight markup language, similar to

3.2 Wireless Session Protocol (WSP)

• HTTP/1.1 functionality and semantics in a compact over-the-air encoding,

3.3 Wireless Transaction Protocol (WTP)

• Reliable two-way request-reply transactions.

3.4 Wireless Transport Layer Security (WTLS)

WTLS is a security protocol based upon the industry-standard Transport Layer

3.5 Wireless Datagram Protocol (WDP)

3.7 Other Services and Applications

3.8 Sample Configurations of WAP Technology

Figure 3.2 Sample WAP Stacks

3.9 WAP Reference Model

Figure 3.3 WAP Reference Model