Wireless Application Protocol

1. V I N I S H A L I K K A L
A S S I S T A N T P R O F E S S O R
M E A E N G I N E E R I N G C O L L E G E
Wireless Application Protocol
(WAP)

2. Introduction
 Wireless Application Protocol commonly known as WAP is used to enable the
access of internet in the mobile phones or PDAs.
 An open, global specification that empowers mobile users with wireless
devices to easily access and interact with internet information and services
instantly.
 WAP is an application communication protocol
 WAP is used to access services and information
 WAP is for handheld devices such as mobile phones
 WAP enables the creating of web applications for mobile devices.
 WAP uses the mark-up language WML (not HTML) WML is defined as
an XML 1.0 application

3. GOALS
 The basic AIM of WAP is to provide a web-likeexperience on
small portable devices - like mobile phones and PDAs

4. WAP ARCHITECTURE

5. WAP Gateway

7. WAP ARCHITECTURE
REQUIREMENTS
 Leverage existing standards whenever possible
 Define a layered and extensible architecture
 Support as many wireless networks as possible
 Provide support for secure applications and communication
 Optimize for efficient use of device resources

8. All solutions must be:
 ● interoperable, i.e., allowing terminals and software from different
vendors to communicate with networks from different providers;
 ● scalable, i.e., protocols and services should scale with customer
needs and number of customers;
 ● efficient, i.e., provision of QoS suited to the characteristics of the
wireless and mobile networks;
 ● reliable, i.e., provision of a consistent and predictable platform for
deploying services; and
 ● secure, i.e., preservation of the integrity of user data, protection of
devices and services from security problems.

9. Components and interface of the WAP
architecture

10. Architecture
 The transport layer service access point (T-SAP) is the common
interface to be used by higher layers independent of the underlying
network
 The security layer with its wireless transport layer security protocol
WTLS offers its service at the security SAP (SEC-SAP).
 The WAP transaction layer with its wireless transaction
protocol (WTP) offers a lightweight transaction service at the
transaction SAP (TR-SAP)
 The session layer with the wireless session protocol (WSP)
currently offers two services at the session-SAP (S-SAP)
 the application layer with the wireless application environment (WAE)
offers a framework for the integration of different www and mobile
telephony applications

11. Examples for the
integration of WAPcomponents

12. Wireless datagram protocol
 The wireless datagram protocol (WDP) operates on top of many
different bearer services capable of carrying data.
 The T-SAP WDP offers a consistent datagram transport service
independent of the underlying bearer (WAP Forum, 2000b). To offer
this consistent service
 WDP offers more or less the same services as UDP.
 WDP offers source and destination port numbers used for multiplexing
and demultiplexing of data respectively
 The service primitive to send a datagram is TDUnitdata. req with the
destination address (DA), destination port (DP), Source address (SA),
source port (SP), and user data (UD) as mandatory parameters
 Destination and source address are unique addresses for the receiver
and sender of the user data.

13. WDP service primitives

14. Wireless Transport layer security
( WTLS)
 WTLS can provide different levels of security
 Data Integrity
Privacy
Authentication
 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.

15. WTLS establishing a secure session

16. Cont…
The first step is to initiate the session with the SEC-Create primitive.
o The first step of the secure session creation, the negotiation of the security
parameters and suites, is indicated on the originator’s side, followed by the
request for a certificate. The originator answers with its certificate and issues a
SEC-Commit.req primitive
o This primitive indicates that the handshake is completed for the originator’s
side and that the originator now wants to switch into the newly negotiated
connection state. The certificate is delivered to the peer side and the SEC-
Commit is indicated
o The WTLS layer of the peer sends back a confirmation to the originator. This
concludes the full handshake for secure session setup.
o After setting up a secure connection between two peers, user data can be
exchanged. This is done using the simple SEC-Unit data primitive as shown in
Figure

17. WTLS datagram transfer

18. WTP - Wireless Transaction Protocol
WTP has been designed to run on very thin clients, such as mobile phones. WTP
offers several advantages to higher layers, including an improved reliability over
datagram services, improved efficiency over connection-oriented services, and
support for transaction-oriented services such as web browsing.
Three classes of transaction service:
 Class 0 provides unreliable message transfer without any result message
 Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with,
exactly one reliable result message (the typical request/response case)
 WTP achieves reliability using duplicate removal, retransmission, acknowledgements
and unique transaction identifiers.
 No WTP-class requires any connection set-up or tear-down phase. This avoids
unnecessary overhead on the communication link
 WTP allows for asynchronous transactions, abort of transactions, concatenation of
messages, and can report success or failure of reliable messages (e.g., a server cannot
handle the request).

19. WTP - Wireless Transaction Protocol
• Goals
– different transaction services, offloads applications
• application can select reliability, efficiency
– support of different communication scenarios
• class 0: unreliable message transfer
• class 1: reliable message transfer without result message
• class 2: reliable message transfer with exactly one reliable result
message
– supports peer-to-peer, client/server and multicast applications
– low memory requirements, suited to simple devices (< 10kbyte )
– efficient for wireless transmission
• segmentation/reassembly
• selective retransmission
• header compression
• optimized connection setup (setup with data transfer)

20. Details of WTP I
• Support of different communication scenarios
– Class 0: unreliable message transfer
• Example: push service
– Class 1: reliable request
• An invoke message is not followed by a result message
• Example: reliable push service
– Class 2: reliable request/response
• An invoke message is followed by exactly one result message
• With and without ACK
• Example: typical web browsing
• No explicit connection setup or release is available
• Services for higher layers are called events

21. Details of WTP II
• Used Mechanisms
– Reliability
• Unique transaction identifiers (TID)
• Acknowledgements
• Selective retransmission
• Duplicate removal
– Optional: concatenation & separation of messages
– Optional: segmentation & reassembly of messages
– Asynchronous transactions
– Transaction abort, error handling
– Optimized connection setup (includes data transmission)

22. WTP Class 0 transaction
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=0, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=0, H‘)
initiator
TR-SAP
responder
TR-SAP

23. WTP Class 1 transaction, no user ack & user ack
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=1, H‘)
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=1, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=1, H‘)
initiator
TR-SAP
responder
TR-SAP
TR-Invoke.res
(H‘)
TR-Invoke.cnf
(H)
TR-Invoke.cnf
(H)

24. WTP Class 2 transaction, no user ack, no hold on
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
initiator
TR-SAP
responder
TR-SAP
TR-Result.req
(UD*, H‘)
TR-Result.ind
(UD*, H)
TR-Invoke.cnf
(H)
TR-Result.res
(H)
TR-Result.cnf
(H‘)

25. WTP Class 2 transaction, user ack
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
initiator
TR-SAP
responder
TR-SAP
TR-Result.ind
(UD*, H)
TR-Invoke.res
(H‘)
TR-Invoke.cnf
(H) TR-Result.req
(UD*, H‘)
TR-Result.res
(H)
TR-Result.cnf
(H‘)

26. WTP Class 2 transaction, hold on, no user ack
TR-Invoke.req
(SA, SP, DA, DP, A, UD, C=2, H) TR-Invoke.ind
(SA, SP, DA, DP, A, UD, C=2, H‘)
initiator
TR-SAP
responder
TR-SAP
TR-Result.req
(UD*, H‘)
TR-Result.ind
(UD*, H)
TR-Invoke.cnf
(H)
TR-Result.res
(H)
TR-Result.cnf
(H‘)

27. WSP - Wireless Session Protocol
• Goals
– HTTP 1.1 functionality (WSP/B supports the functions HTTP/1.1)
• Request/reply, content type negotiation, ...
– support of client/server, transactions, push technology
– key management, authentication, Internet security services
– session management (interruption, resume,...)
• Open topics
– QoS support
– group communication
– isochronous media objects
– management

28. WSP protocols
WSP
Connection mode
(uses WTP)
Connectionless mode
(uses WDP or WTLS)
• Session Management (class 0, 2)
• Method Invocation (Kl. 2)
• Error Report
• Push (class 0)
• Confirmed Push (class 1)
• Session suspend/resume (class 0, 2)
• Method Invocation
• Push
(in general unreliable)

29. WSP/B session establishment
S-Connect.req
(SA, CA, CH, RC) S-Connect.ind
(SA, CA, CH, RC)
client
S-SAP
server
S-SAP
S-Connect.res
(SH, NC)
S-Connect.cnf
(SH, NC)
WTP Class 2
transaction

30. WSP/B session suspend/resume
S-Suspend.req S-Suspend.ind
(R)
client
S-SAP
server
S-SAP
S-Resume.res
WTP Class 2
transaction
S-Suspend.ind
(R)
~ ~
S-Resume.req
(SA, CA) S-Resume.ind
(SA, CA)
S-Resume.cnf
WTP Class 0
transaction

31. WSP/B session termination
S-Disconnect.ind
(R)
client
S-SAP
server
S-SAP
S-Disconnect.ind
(R) WTP Class 0
transaction
S-Disconnect.req
(R)

32. WSP/B method invoke
S-MethodInvoke.req
(CTID, M, RU) S-MethodInvoke.ind
(STID, M, RU)
client
S-SAP
server
S-SAP
S-MethodInvoke.res
(STID)
S-MethodInvoke.cnf
(CTID)
WTP Class 2
transaction
S-MethodResult.req
(STID, S, RH, RB)
S-MethodResult.ind
(CTID, S, RH, RB)
S-MethodResult.res
(CTID) S-MethodResult.cnf
(STID)

33. WSP/B over WTP - method invocation
S-MethodInvoke.req
S-MethodInvoke.ind
client
S-SAP
server
S-SAP
S-MethodInvoke.res
S-MethodInvoke.cnf
S-MethodResult.req
S-MethodResult.ind
S-MethodResult.res
S-MethodResult.cnf
TR-Invoke.req
initiator
TR-SAP
TR-Result.ind
TR-Invoke.cnf
TR-Result.res
TR-Invoke.ind
responder
TR-SAP
TR-Invoke.res
TR-Result.req
TR-Result.cnf

34. WSP/B over WTP - asynchronous, unordered
requests
S-MethodInvoke_1.req
S-MethodInvoke_1.ind
client
S-SAP
server
S-SAP
S-MethodInvoke_2.req
S-MethodInvoke_3.req
S-MethodResult_1.ind
S-MethodInvoke_4.req
S-MethodResult_3.ind
S-MethodResult_4.ind
S-MethodResult_2.ind
S-MethodInvoke_3.ind
S-MethodInvoke_2.ind
S-MethodResult_1.req
S-MethodResult_2.req
S-MethodResult_3.req
S-MethodResult_4.req
S-MethodInvoke_4.ind

35. WSP/B - confirmend/non-confirmed push
S-Push.req
(PH, PB)
client
S-SAP
server
S-SAP
WTP Class 1
transaction
S-Push.ind
(PH, PB)
S-ConfirmedPush.res
(CPID)
S-ConfirmedPush.ind
(CPID, PH, PB)
WTP Class 0
transaction
S-ConfirmedPush.req
(SPID, PH, PB)
client
S-SAP
server
S-SAP
S-ConfirmedPush.cnf
(SPID)

36. WAE - Wireless Application Environment
 Goals
 network independent application environment for low-bandwidth, wireless
devices
 integrated Internet/WWW programming model with high interoperability
 Requirements
 device and network independent, international support
 manufacturers can determine look-and-feel, user interface
 considerations of slow links, limited memory, low computing power, small
display, simple user interface (compared to desktop computers)
 Components
 architecture: application model, browser, gateway, server
 WML: XML-Syntax, based on card stacks, variables, ...
 WMLScript: procedural, loops, conditions, ... (similar to JavaScript)
 WTA: telephone services, such as call control, text messages, phone book, ...
(accessible from WML/WMLScript)
 content formats: vCard, vCalendar, Wireless Bitmap, WML, ...

37. WAE logical model
Origin Servers
web
server
other content
server
Gateway Client
other
WAE
user agents
WML
user agent
WTA
user agent
encoders
&
decoders
encoded
request
request
encoded
response
with
content
response
with
content
push
content
encoded
push
content

38. Wireless Markup Language (WML)
 WML follows deck and card metaphor
 WML document consists of many cards, cards are grouped to decks
 a deck is similar to an HTML page, unit of content transmission
 WML describes only intent of interaction in an abstract manner
 presentation depends on device capabilities
 Features
 text and images
 user interaction
 navigation
 context management

39. WML – example I
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="card_one" title="simple example">
<do type="accept">
<go href="#card_two"/>
</do>
<p>
This is a simple first card!
<br/>
On the next one you can choose ...
</p>
</card>

40. WML – example II
<card id="card_two" title="Pizza selection">
<do type="accept" label="cont">
<go href="#card_three"/>
</do>
<p>
... your favorite pizza!
<select value="Mar" name="PIZZA">
<option value="Mar">Margherita</option>
<option value="Fun">Funghi</option>
<option value="Vul">Vulcano</option>
</select>
</p>
</card>
<card id="card_three" title="Your Pizza!">
<p>
Your personal pizza parameter is <b>$(PIZZA)</b>!
</p>
</card>
</wml>