UNIT IV

Mobile TCP– WAP – Architecture – WDP – WTLS – WTP –WSP – WAE – WTA
Architecture – WML

Wireless application protocol WAP

Wireless application protocol (WAP) is a communications protocol that is used for wireless
data access through most mobile wireless networks. WAP enhances wireless specification
interoperability and facilitates instant connectivity between interactive wireless devices (such
as mobile phones) and the Internet. Empowers mobile users with wireless devices to easily
access and interact with information and services.
A “standard” created by wireless and Internet companies to enable Internet access from a
cellular phone.

WAP Goals :
•To deliver Internet services to mobile devices
•Enable applications to scale across a variety of transport options and device types
•Independence from wireless network standards
•GSM, CDMA IS-95, TDMA IS-136, 3G systems (UMTS, W-CDMA)

WAP: Main Features

• Browser : “Micro browser”, similar to existing web browsers
• Markup language : Similar to HTML, adapted to mobile devices
• Script language : Similar to Javascript, adapted to mobile devices
• Gateway : Transition from wireless to wired world
• Server : “Wap/Origin server”, similar to existing web servers
• Protocol layers : Transport layer, security layer, session layer etc.
• Telephony application interface : Access to telephony functions

How WAP Model Works?

When it comes to actual use, WAP works as follows :

1. The user selects an option on their mobile device that has a URL with Wireless Markup language
(WML) content assigned to it.
2. The phone sends the URL request via the phone network to a WAP gateway using the binary
encoded WAP protocol.
3. The gateway translates this WAP request into a conventional HTTP request for the specified URL
and sends it on to the Internet.
4. The appropriate Web server picks up the HTTP request.
5. The server processes the request just as it would any other request. If the URL refers to a static
WML file, the server delivers it. If a CGI script is requested, it is processed and the content
returned as usual.
6. The Web server adds the HTTP header to the WML content and returns it to the gateway.
7. The WAP gateway compiles the WML into binary form.
8. The gateway then sends the WML response back to the phone.
9. The phone receives the WML via the WAP protocol.
10. The micro-browser processes the WML and displays the content on the screen.
WAP Architecture Model:
The user opens the mini-browser in a mobile device. He selects a website that he wants to view.
The mobile device sends the URL encoded request via network to a WAP gateway using WAP protocol.
This figure below shows the WAP programming model. Note, the similarities with the Internet model.
Without the WAP Gateway/Proxy, the two models would have been practically identical.

WAP Architecture

The WAP Gateway/Proxy is the entity that connects the wireless domain with the Internet.
You should make a note that the WAp gateway translate this WAP request that is sent from the
wireless client to the WAP Gateway/Proxy uses the Wireless Session Protocol (WSP). In its essence,
WSP is a binary version of HTTP.
The request reaches to a specified Web server and it processes the request just as it
would have processed any other request and sends the response back to the mobile device
through WAP gateway in WML file which can be seen in the micro-browser.
A markup language − the Wireless Markup Language (WML) has been adapted to develop
optimized WAP applications. In order to save valuable bandwidth in the wireless network, WML can
be encoded into a compact binary format. Encoding WML is one of the tasks performed by the WAP
Gateway/Proxy.

Configure Web Server for WAP:

In the WAP architecture, the web server communicates with the WAP gateway, accepting
HTTP requests and returning WML code to the gateway. The HTTP protocol mandates that each reply
must include something called a Multi-Purpose Internet Mail Extensions (MIME) type.

In normal web applications, MIME type is set to text/html, designating normal HTML code. Images on
the other hand could be specified as image/gif or image/jpeg for instance. With this content type
specification, the web browser knows the data type that the web server returns.
In WAP applications a new set of MIME types must be used, as shown in the following table :
S.No. File type MIME type
1 WML (.wml) text/vnd.wap.wml
2 WMLScript (.wmls) text/vmd.wap.wmlscript
3 WBMP (.wbmp) image/vnd.wap.wbmp

In dynamic applications, the MIME type must be set on the fly, whereas in static WAP applications,
the web server must be configured appropriately.

WAP Protocol stack:

Layers of WAP Protocol :

1. Application Layer
Wireless Application Environment (WAE). This layer is of most interest to content developers because
it contains among other things, device specifications, and the content development programming
languages, WML, and WMLScript.

2. Session Layer
Wireless Session Protocol (WSP). Unlike HTTP, WSP has been designed by the WAP Forum to provide
fast connection suspension and reconnection.

3. Transaction Layer
Wireless Transaction Protocol (WTP). The WTP runs on top of a datagram service, such as User
Datagram Protocol (UDP) and is part of the standard suite of TCP/IP protocols used to provide a
simplified protocol suitable for low bandwidth wireless stations.

4. Security Layer
Wireless Transport Layer Security (WTLS). WTLS incorporates security features that are based upon
the established Transport Layer Security (TLS) protocol standard. It includes data integrity checks,
privacy, service denial, and authentication services.

5. Transport Layer
Wireless Datagram Protocol (WDP). The WDP allows WAP to be bearer-independent by adapting the
transport layer of the underlying bearer. The WDP presents a consistent data format to the higher layers
of the WAP protocol stack, thereby offering the advantage of bearer independence to application
developers.

Each of these layers provides a well-defined interface to the layer above it. This means that the internal
workings of any layer are transparent or invisible to the layers above it. The layered architecture allows
other applications and services to utilise the features provided by the WAP-stack as well. This makes it
possible to use the WAP-stack for services and applications that currently are not specified by WAP.

Wireless Datagram Protocol WDP

Wireless Datagram Protocol defines the movement of information from receiver to the sender and
resembles the User Datagram Protocol in the Internet protocol suite. This is Transport layer protocol
within the WAP architecture
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.

–uses the Service Primitive

•T-UnitData.req .ind
–offers a common interface for higher layer protocols
–allows for transparent communication despite different technologies
–addressing uses port numbers
–WDP over IP is UDP/IP

Goals
–create a worldwide interoperable transport system by adapting WDP to the different underlying
technologies
–transmission services, such as SMS in GSM might change, new services can replace the old ones

WDP 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 illustrates the difference in
functions provided by the bearers and 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 optimise 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.

General WDP Architecture of WDP

General WDP Architecture

The Figure Shows the shaded areas are the layers of protocol which the WDP Specification is
specifically applicable. At the Mobile the WDP protocol consists of the common WDP elements shown
by the layer labelled 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 ANSI-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 Tunnelling 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 t he wireless WTP protocol
suites and the wired Internet.
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: -
1. The mobile is within a coverage area applicable to the bearer service being invoked;
2. The mobile having sufficient power and the power being on;
3. Sufficient resources (processing and memory) within the mobile are available to WDP;
4. The WDP protocol is correctly configured.
5. 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.

Processing Errors of WDP

Datagrams Processing errors can happen when WDP datagrams are sent from a WDP provider to
another.
For example, a Wireless Data Gateway may not be able to send the datagram to the WAP
Gateway, or there is no application listening to the destination port, or the receiver might not have
enough buffer space to receive a large message.
The Wireless Control Message Protocol (WCMP) provides an efficient error handling
mechanism for WDP, resulting in improved performance for WAP protocols and applications.
Therefore the WCMP protocol SHOULD be implemented. See the [WCMP] specification. WDP is
expected not to pass up corrupted messages. If a particular bearer does not provide this service, then the
WDP bearer adaptation MUST provide payload protection.

Wireless Transport Layer Security (WTLS)

WTLS is to provide privacy, data integrity and authentication between applications
communicating using WAP. If requested by an application, a security service, the wireless transport
layer security (WTLS), can be integrated into the WAP architecture on top of WDP as specified in
(WAP Forum, 2000c). WTLS is designed by www.wapforum.org to provide security for WAP
protocol. WTLS's design is based on TLS architecture and wireless computing environment
requirements. WTLS takes into account the low processing power and very limited memory capacity
of the mobile devices for cryptographic algorithms. WTLS supports datagram and connection-oriented
transport layer protocols.

WTLS originates from TLS(Transportation Layer Security), which is the IETF standard for Internet
transaction security. WTLS is based on and provides similar functionality to the Transport Layer
Security (TLS) protocol but is optimized for low bandwidth mobile devices. The three major differences
between TLS and WTLS are:

• Compressed Data Structures – Packet size was reduced by using bit-fields, discarding
redundancy and truncating cryptographic elements when ever possible

• Compressed Certificate Format – The format follows the X.509v3 certificate structure but
uses smaller data structures

• Packet Based Instead of Stream Based – TLS is designed to be used over a data stream and
a significant part of the design of WTLS was to allow it to be used in a data packet
environment so that protocols such as Short Message Service (SMS) could be used as data
transport.
Features of WTLS:

The following are some of the major features added to WTLS:

• Support for other cryptographic algorithms. SSL and TLS primarily use RSA encryption.
WTLS supports RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC).
• Definition of a new compact public key certificate, WTLS certificates. These are a more
efficient version of X.509 certificates.
• UDP datagram support. This impacts many areas of the protocol, from how data is encrypted
to extra support for message handling, to ensure messages do not get lost, duplicated, or
delivered out of order.
• A key refresh option. This is renegotiated periodically, based on the number of messages sent.
• An expanded set of alerts. This adds clarity for error handling.
• Optimized handshakes. This reduces the number of round-trips required in high-latency
networks.
WTLS also introduced three levels of authentication between the client and the gateway. They are listed
in ascending order:
• Class I WTLS. Anonymous interactions between the client and WAP gateway; no
authentication takes place.
• Class II WTLS. The server authenticates itself to the client using WTLS certificates.
• Class III WTLS. Both the client and the WAP gateway authenticate to each other. This is the
form of authentication used with smartcards. GSM Subscriber Identity Modules (SIM), for
example, can store authentication details on the device for two-way authentication.

WTLS Elements for Layer-to-Layer Communication

Notations Used:
1. Definition of Service Primitives and Parameters
Communication between layers is accomplished by means of service primitives. Service
primitives represent, in an abstract way, the logical exchange of information and control between the
security layer and adjacent layers.
Service primitives consist of commands and their respective responses associated with the services
requested of another layer. The general syntax of a primitive is:
X-Service.type (Parameters)
where X designates the layer provid ing the service. For this specification X is “SEC” for the
Security layer.
Service primitives are not the same as an application programming interface (API) and are not
meant to imply any specific method of implementing an API.
WTLS Primitives Types
The primitives types defined in this specification are:

WTLS has seven service Primitives listed below with their description:
• Unit data – Primitive for exchanging data between peers when there is an existing secure
connection between the peers transport addresses
 • Create – Primitive for initiation of the establishment of the secure connection
• Exchange – Primitive for public-key authentication or key exchange with the client in the
creation of a secure connection
• Commit – Primitive for switching to the newly negotiated secure connection once the
handshake is complete
• Terminate – Primitive for terminating the connection
• Exception – Primitive for information about warning level alerts
• Create-Request – Primitive for the server to request the client to initiate a new handshake

The service Primitives can be one of four different types listed below with their description:
• Request – used when a higher layer is requesting a service from a lower layer
• Indication – used by the service providing layer to notify the next higher layer of activities
related to the request type of the peer or to the provider of the service
• Response – used to acknowledge receipt of the indication type from the next lower layer
• Confirm – used by the service providing layer to report that activity has been completed
successfully

2. Time Sequence Charts :

The behaviour of service primitives is illustrated using time sequence charts, which are described in

A Non-confirmed Service

The above Figure Shows 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.

3. Service Parameter :
The service primitives are defined using tables indicating which parameters are possible and how they
are used with the different primitive types. For example, a simple confirmed primitive might be
defined using the following:

If some primitive type is not possible, the column for it will be omitted. The entries used in the primitive type
columns are
defined in the following table:
The higher layers simply use SEC-Unit data instead of T-D Unit data. The parameters are the same
here: source address (SA), source port (SP), destination address (DA), destination port (DP), and user
data (UD).