WAP

VinishA23 213 views 41 slides Jan 11, 2022
Slide 1
Slide 1 of 41
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41

About This Presentation

Wireless Application Protocol


Slide Content

Vinish alikkal Assistant professor Mea engineering college Wireless Application Protocol (WAP)

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

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

WAP ARCHITECTURE

WAP Gateway

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

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.

Components and interface of the WAP architecture

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

Examples for the integration of WAPcomponents

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.

WDP service primitives

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.

WTLS establishing a secure session

Cont… The first step is to initiate the session with the SEC-Create primitive. 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 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 The WTLS layer of the peer sends back a confirmation to the originator. This concludes the full handshake for secure session setup. 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

WTLS datagram transfer

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).

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)

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

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)

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

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

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

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

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

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

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)

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

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

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

WSP/B method invoke S-MethodInvoke.req (CTID, M, RU) Method PDU S-MethodInvoke.ind (STID, M, RU) client S-SAP server S-SAP Reply PDU 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)

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 Invoke(Method) Result(Reply) Ack PDU Ack PDU

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

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

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, ...

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

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

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>

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>