wireless application protocol

Wireless Application Protocol

Dr. Smriti AgrawalAssociate Professor

CBIT, Hyderabad, INDIA

Mobile Applications - 1• Vehicles

– transmission of news, road condition etc– ad-hoc network with near vehicles to prevent

accidents

• Emergencies– early transmission of patient data to the hospital– ad-hoc network in case of earthquakes, cyclones– military ...

• Traveling salesmen– direct access to central customer files– consistent databases for all agents– mobile office

Mobile Applications - 2• Web access

– outdoor Internet access – intelligent travel guide with up-to-date location

dependent information

• Information services– push: stock quotes; pull: nearest cash ATM

• Disconnected operations– file-system caching for off-line work– mobile agents, e.g., shopping

• Entertainment– games, etc

Wireless Application Protocol (WAP)

• 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

• wapforum.org: – co-founded by Ericsson, Motorola, Nokia, Phone.com– 450 members in 2000, comprise of Handset manufacturers, Wireless

service providers, ISPs, Software companies in the wireless industry– Goals• Interoperable: allowing terminals with different h/w and s/w to

communicate with the network from different providers.• Scalable: protocols and services should scale with customer needs

and number of customers• Efficient: provision of QoS suited to the characteristics of the

wireless and mobile network.• Reliable: consistent and predictable platform for deploying services.• Secure: preservation of the integrity of user data, protection of

devices and services from security problems.

WAP ArchitectureMicroBrowser (WML, WMLScript, WTA, WTAI)

Runs on top of WDPProvided lightweight X-oriented service• Unreliable 1-way request• Reliable 1-way/2-way req./response

Lightweight SSLUses WIM/PKI-Cards

Datagram service on different bearersConvergence between bearer services

Different Wireless Tech.

Source: WAP Forum

WAP Architecture• Bearer Services: WAP does not specify bearer services, but use existing

data services and will integrate further services. • No special interface is specified between the bearer service and the next

higher layer,• Transport layer (WDP): offers bearer independent, consistent datagram

(WDP) oriented service to the higher layer of the WAP Architecture.• Communication is done over one of the available bearer service.• Transport layer service access point: is the common interface used by the

higher layers independent of the underlying network. • Wireless Transport layer security (WTLS) : offers its services at the

security SAP (SEC-SAP) based on the transport layer security (TLS, formerly SSL) for www. It is optimized for use in wireless networks with narrow band channels. WTLS offer data integrity, privacy, authentication, denial of service protection.

WAP Architecture• Wireless Transaction Protocol (WTP): offers lightweight transaction

services. It provides reliable message transfer mechanisms, based on ideas from TCP/RPC.

• WSP (Wireless Session Protocol): offers connection oriented and connection-less if used directly on top of WDP. Special service for browsing the web that offers HTTP/1.1 functionality, manages sessions.

• WAE (Wireless Application Environment): offers framework for integration of different WWW and mobile telephony applications.

• WAP transport layer together with the bearers can be compared to the services offered by TCP and UDP over IP.

• WAP does not force all the applications to use the entire protocol architecture.

WAP: Componentswireless networkfixed network

WAPproxy

WTAserver

filter/WAPproxyweb

server

filter

PSTN

Internet

Binary WML: binary file format for clients

Binary WML

Binary WML

Binary WML

HTML

HTML

HTML WML

WMLHTML

Source: Schiller

• WML: Wireless Markup Language for WAP

• Special filters within the fixed network translate HTML into WML.

• Still better into binary WML

• WTA Wireless telephony Application server translates e.g., signaling of the telephone network into WML events

WDP: Wireless Datagram Protocol• 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– Transport layer protocol within the WAP architecture– uses the Service Primitive

• T-DUnitdata.req– uses transport mechanisms of different bearer technologies– 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

WDP: Wireless Datagram Protocol• T-DUnitdata.req contains

• DA: Destination Address• DP: Destination Port• SA: Source Address• SP: Source Port• UD: User Data• DA: Destination Address and SA: Source Address are unique could be

MSISDN’s or IP address.• T-DUnitdata.ind indicates• Reception of data • T-DError.ind is used • If higher layer request a service the WDP cannot fulfil (such as user data

too large), but does not indicate problem in the bearer services • An error code is returned

WDP: Service PrimitivesT-SAP T-SAP

T-DUnitdata.req(DA, DP, SA, SP, UD) T-DUnitdata.ind

(SA, SP, UD)

T-DUnitdata.req(DA, DP, SA, SP, UD)

T-DError.ind(EC)

SAP: Service Access Point

DA: Destination Address

DP: Destination Port

SA: Source Address

SP: Source Port

UD: User Data

EC: Error Code

Source: Schiller

WDP: Wireless Datagram Protocol• Wireless control message protocol (WCMP) provides error handling

• If an error from one WDP to another such as destination is unreachable, no application is listening to the specified destination port, etc.

• Contains control message such as that in ICMP (Internet control message protocol)

• Can be used for diagnostic and information purpose.• Can be used by WDP nodes and gateways to report errors.• Typical WCMP msg are:

• Destination unreachable (route, port, address unreachable)• Parameter problem (errors in the packet header)• Message too big• Reassembly failure,• Echo request/reply.

WDP: Wireless Datagram Protocol• Wireless management entity

• Supports WDP and information about changes in environment.• Such as Current configuration of the devices, currently available bearer

services

• It is vendor specific.

WTLS: Wireless Transport Layer Security• Goals

– Provide mechanisms for secure transfer of content, for applications needing privacy, identification, message integrity and non-repudiation

– Provide support for protection against denial-of-service attacks

• WTLS – is based on the TLS/SSL (Transport Layer Security) protocol– optimized for low-bandwidth communication channels and high delay

bearer network– provides

• privacy (encryption)• data integrity (MACs)• authentication (public-key and symmetric)

– Takes into account• Low processing power and • limited memory capacity for cryptographic algo.

WTLS: Wireless Transport Layer Security• Before data exchange starts a secure session has to be established• Full handshake• Both originator and the peer can interrupt the session at any time.• First step SEC-Create.req

• SA: Source Address• SP: Source Port• DA: Destination Address• DP: Destination Port• KES: Key Exchange Suite (e.g. RSA, Diffie, ECC)• CS: Cipher Suite (e.g. DES, IDEA)• CM: Compression Method

• Peer answers with • SNM: Sequence Number Mode• KR: Key Refresh Cycle (how often the keys are refreshed within this

secure session)• SID: Session Identifier (unique for each peer)• KES’: Key Exchange Suite (e.g. RSA, Diffie, ECC)• CS’: Cipher Suite (e.g. DES, IDEA)• CM’: Compression Mode

WTLS: Wireless Transport Layer Security• Peer also issues SEC-Exchange.req

• Indicate that peer wishes to perform public key authentication, i.e., peer requests a certificate from the originator.

• SEC-Commit.req• Originator answers with a certificate• Indicates that the handshake is complete.

• SEC-Commit.ind • Indicates that the certificate is delivered.• Concludes the full handshake.

• User data can be exchanged now using SEC-Unitdata• same as T-Dunitdata• Data transmission is not secure

• Users can put stronger encryption over the protocol stack if required

WTLS: Secure session, Full handshake

SEC-Create.req(SA, SP, DA, DP, KES, CS, CM) SEC-Create.ind

(SA, SP, DA, DP, KES, CS, CM)

originatorSEC-SAP

peerSEC-SAP

SEC-Create.cnf(SNM, KR, SID, KES‘, CS‘, CM‘)

SEC-Create.res(SNM, KR, SID, KES‘, CS‘, CM‘)

SEC-Exchange.req

SEC-Exchange.ind

SEC-Exchange.res(CC)SEC-Commit.req SEC-Exchange.cnf

(CC)SEC-Commit.ind

SEC-Commit.cnf

Source: Schiller

KES: Key Exchange Suite

CS: Cipher Suite

CM: Compression Method

SNM: Sequence Number Mode

KR: Key Refresh Cycle

SID: Session Identifier

CC: Client Certificate

WTP: Wireless Transaction Protocol• Designed to support thin clients.• Provides reliability over datagram services,• Improve efficiency over connection oriented services.• Support transaction oriented services.• support for different communication scenarios

• class 0: unreliable message transfer– unconfirmed Invoke message with no Result message– a datagram that can be sent within the context of an existing Session• class 1: reliable message transfer without result message– confirmed Invoke message with no Result message– used for data push, where no response from the destination is expected• class 2: reliable message transfer with exactly one reliable result message– confirmed Invoke message with one confirmed Result message– a single request produces a single reply

WTP: Wireless Transaction Protocol• Achieves reliability using

• Retransmission• Acknowledgements• Unique Transaction identifiers

• No class requires connection setup or tear down• Allows

• Asynchronous transactions• Abort of transactions• Concatenation of messages• Report success or failure

WTP: Wireless Transaction Protocol• TR-Invoke.req

• To initiate a new transaction• TR-Result.req

• Result of the previously initiated transaction• TR-Abort.req

• To abort an existing transaction.

WTP: Wireless Transaction Protocol• WTP class 0: unreliable message transfer

• These transactions are stateless and cannot be aborted• TR-Invoke.req (SA, SP, DA, DP, A, UD, C=0, H)• Where

– A is ack flag, if the the responder WTP should be generate an ACK or if USER ACK is used.

– C is Class type which is 0 for this class– H Handle simple index to uniquely identify the transaction.

• In this class the responder does not ACK and initiator does not perform any retransmission.

• This occasionally used

WTP Class 0 Transaction

TR-Invoke.req(SA, SP, DA, DP, A, UD, C=0, H)

Invoke PDUTR-Invoke.ind(SA, SP, DA, DP, A, UD, C=0, H‘)

initiatorTR-SAP

responderTR-SAP

Source: Schiller

A: Acknowledgement Type (WTP/User)

C: Class (0,1,2)

H: Handle (socket alias)

WTP: Wireless Transaction Protocol• WTP class 1: reliable message transfer without result message

• Sender send a TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H)• Responder signals the incoming by TR-Invoke.ind and ACK automatically• Where

– C is Class type which is 1 for this class

• Sender on receipt of ACK will close the connection• Responder maintains the connection for sometime incase it receives the

duplicate TR-Invoke.req indicating loss of its ACK.

WTP Class 1 Transaction, no user ack & user ack



initiatorTR-SAP

responderTR-SAP

Ack PDU

TR-Invoke.res(H‘)

TR-Invoke.cnf(H)



initiatorTR-SAP

responderTR-SAP

Ack PDUTR-Invoke.cnf(H)

Source: Schiller

user ACK is required

WTP: Wireless Transaction Protocol• WTP class 2: reliable message transfer with exactly one reliable result

message• Reliable request/respond transaction

• Sender send a TR-Invoke.req (SA, SP, DA, DP, A, UD, C=1, H)• Responder signals the incoming by TR-Invoke.ind and ACK automatically• Where

– C is Class type which is 1 for this class

• Sender on receipt of ACK will close the connection• Responder maintains the connection for sometime incase it receives the

duplicate TR-Invoke.req indicating loss of its ACK.

WTP Class 2 Transaction, no user ack, no hold on



initiatorTR-SAP

responderTR-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‘)

Source: Schiller

WTP Class 2 Transaction, user ack



initiatorTR-SAP

responderTR-SAP

Result PDUTR-Result.ind(UD*, H)

Ack PDU

TR-Invoke.res(H‘)

TR-Invoke.cnf(H) Ack PDU


TR-Result.res(H)

TR-Result.cnf(H‘)

Source: Schiller

WTP Class 2 Transaction, hold on, no user ack



initiatorTR-SAP

responderTR-SAP

Result PDU


TR-Result.ind(UD*, H)

Ack PDU

Ack PDUTR-Invoke.cnf(H)

TR-Result.res(H)

TR-Result.cnf(H‘)

Source: Schiller

WSP - Wireless Session Protocol• Goals

– HTTP 1.1 functionality• Request/reply, content type negotiation, ...

– support of client/server transactions, push technology– key management, authentication, Internet security services

• WSP Services– provides shared state between client and server, optimizes content

transfer– session management (establish, release, suspend, resume)– efficient capability negotiation– content encoding

• WSP/B (Browsing)– HTTP/1.1 functionality - but binary encoded– exchange of session headers– push and pull data transfer– asynchronous requests

WSP/B session establishment

S-Connect.req(SA, CA, CH, RC) Connect PDU

S-Connect.ind(SA, CA, CH, RC)

clientS-SAP

serverS-SAP

ConnReply PDU

S-Connect.res(SH, NC)

S-Connect.cnf(SH, NC)

WTP Class 2transaction

Source: Schiller

CH: Client Header (optional)

RC: Requested Capabilities

SH: Server Header (optional)

NC: Negotiated Capabilities

WSP - Wireless Session Protocol

• S-Connect.cnf confirms the session establishment and includes the server header and the negotiated capabilities from the server.

• WSP/B (Browsing) include several procedures to refuse a session or to abort session establishment.

WSP - Wireless Session Protocol• Session may be suspended due to

– the bearer network may not be available due to roaming.– User switches off the device– Client suspend the session.

• On resuming– If server Address (SA) and Client Address (CA) are not the same

(before suspension and on resuming) then it is the responsibility of the service user to map the addresses.

WSP/B session suspend/resume

S-Suspend.req Suspend PDUS-Suspend.ind(R)

clientS-SAP

serverS-SAP

Reply PDUS-Resume.res


S-Suspend.ind(R)

~ ~S-Resume.req(SA, CA) S-Resume.ind

(SA, CA)

Resume PDU

S-Resume.cnf


Source: Schiller

R: Reason for disconnection

WSP/B session termination

Disconnect PDUS-Disconnect.ind(R)

clientS-SAP

serverS-SAP

S-Disconnect.ind(R) WTP Class 0

transaction

S-Disconnect.req(R)

Source: Schiller

R: Reason for disconnection

WSP - Wireless Session Protocol• S-MethodInvoke.req

– Used to request an operation to be executed by the server– CTID : client transaction ID to distinguish between pending

transactions.– Method M: requested operations at the server– Request URI: Uniform Resource Identifier i.e., URL’s

• S-MethodResult.ind– Result is sent back

• The methodPDU can be– Get PDU

• HTTP/1.1 GET, OPTIONS, HEAD, DELETE and TRACE– Post PDU

• POST and PUT

WSP - Wireless Session Protocol• At sever side responses with S-MethodInvoke.res

– Server confirms the request so that WSP/B does not generate a new PDU

– STID: server transaction ID to distinguish between pending transactions.

• S-MethodResult.ind– Result is sent back– Parameters are

• S: Response Status– Is the HTTP/1.1 status code such as

» 404 (indicating server could not be found)» 200 (indicating everything is ok)

• RH: Response Header• RB: Response Body

WSP/B method invoke

S-MethodInvoke.req(CTID, M, RU) Method PDU

S-MethodInvoke.ind(STID, M, RU)

clientS-SAP

serverS-SAP

Reply PDU

S-MethodInvoke.res(STID)

S-MethodInvoke.cnf(CTID)


S-MethodResult.req(STID, S, RH, RB)

S-MethodResult.ind(CTID, S, RH, RB)

S-MethodResult.res(CTID) S-MethodResult.cnf

(STID)

CTID: Client Transaction ID M: Method Invoked RU: Request UR

STID: Server Transaction ID S: Response Status RH: Response Header

RB: Response Body Source: Schiller

WSP/B over WTP - method invocation

S-MethodInvoke.req

S-MethodInvoke.ind

clientS-SAP

serverS-SAP

S-MethodInvoke.res

S-MethodInvoke.cnfS-MethodResult.req

S-MethodResult.ind

S-MethodResult.res

S-MethodResult.cnf

TR-Invoke.req

initiatorTR-SAP

TR-Result.ind

TR-Invoke.cnf

TR-Result.res

TR-Invoke.ind

responderTR-SAP

TR-Invoke.res

TR-Result.req

TR-Result.cnf

Invoke(Method)

Result(Reply)

Ack PDU

Ack PDU

Source: Schiller

WSP - Wireless Session Protocol

• It does not provide any sequencing between different requests or responses.

• Some requests may need more time to be responded

WSP/B over WTP - asynchronous, unordered requests

S-MethodInvoke_1.req

S-MethodInvoke_1.ind

clientS-SAP

serverS-SAP



S-MethodResult_1.ind







S-MethodResult_1.req





Source: Schiller

WSP - Wireless Session Protocol• Push data from the server to the client using S-Push.req• Class 0 transaction service• Another variation is class 1.

WSP/B - confirmed/non-confirmed push

S-Push.req(PH, PB)

clientS-SAP

serverS-SAP

ConfPush PDU


S-Push.ind(PH, PB)

S-ConfirmedPush.res(CPID)

S-ConfirmedPush.ind(CPID, PH, PB)


Push PDU

S-ConfirmedPush.req(SPID, PH, PB)

clientS-SAP

serverS-SAP

S-ConfirmedPush.cnf(SPID)

Source: Schiller

PH: Push Header

PB: Push Body

SPID: Server Push ID

CPID: Client Push ID

WSP - Wireless Session Protocol• WSP/B connectionless session service

– The connection establishment and release require overhead, confirm method invocation require overheads

– Which may not be required.

• S-Unit-MethodInvoke.req– To request an operation on the server.– TID: Transaction Identifier to distinguish between different users.

• S-Unit-MethodResult.req– To return the result

• S-Unit-Push.req– To push the data onto a client.

WSP/B over WDPS-Unit-MethodInvoke.req(SA, CA, TID, M, RU)

clientS-SAP

serverS-SAP

S-Unit-MethodResult.ind(CA, SA, TID, S, RH, RB)

S-Unit-Push.ind(CA, SA, PID, PH, PB)

S-Unit-MethodInvoke.ind(SA, CA, TID, M, RU)

S-Unit-MethodResult.req(CA, SA, TID, S, RH, RB)

S-Unit-Push.req(CA, SA, PID, PH, PB)

Method PDU

Reply PDU

Push PDU

WDP Unitdataservice

Source: Schiller

TID: Transaction Identifier

PH: Push Header

PB: Push Body

Wireless Application Environment (WAE)• Goals

– device and network independent application environment– for low-bandwidth, wireless devices– considerations of slow links, limited memory, low computing power,

small display, simple user interface (compared to desktops)– integrated Internet/WWW programming model – high interoperability– Minimize the over the air traffic and resource consumption on the

handheld devices

Web Server

Content

CGIScripts

etc.

WM

L D

ecks

with

WM

L-Sc

ript

WAP Gateway

WML Encoder

WMLScriptCompiler

Protocol Adapters

Client

WML

WML-Script

WTAI

Etc.

HTTPWSP/WTP

WAP Architecture

Source: WAP Forum

Origin Servers

WAE: Logical Model

webserver

other contentserver

Gateway Client

otherWAE

user agents

WMLuser agent

WTAuser agent

Push proxy

encodedrequest

request

encodedresponsewithcontent

responsewithcontent

pushcontent

encodedpushcontent

Method proxy

encoders&

decoders

Wireless Application Environment (WAE)• Model is close to www model but assumes an additional gateway• A client issues an encoded request for an operation • Encoding minimizes the data sent over the air.• Gateway

– Decodes the encoded request into standard request understood by the origin servers.

– Transfer the request to the appropriate server.• The origin server will respond to the request.• Gateway

– Encodes the response – Transfer to the client• Incase the server PUSH content to the gateway then too the gateway

encodes it and PUSHes it to the client.

Wireless Application Environment (WAE)• Within the client various user agents can reside

– Browser– Phonebook– Message editor etc.

• WAE does not specify the number of user agents that can reside.• WTA user agent handles the access and interaction with mobile telephone

features (call control etc)

WML: Wireless Markup Language• WML is based on the HTML• XML-based language

– describes only intent of interaction in an abstract manner

– presentation depends upon device capabilities

• Takes into account – Small display, – Limited navigation

capabilities of devices– Limited memory– Low performance

computational resources.

Content (XML)

XSL Processor

HTTP Browser

HTML StyleSheet

WML Browsers

WML Stylesheet

WML: Wireless Markup Language• Basic unit of navigation in HTML is a page, while that in WML is a card• Only one card will be shown on the screen of the wireless device each

time• Cards and Decks

– document consists of many cards– Cards are grouped to form decks– User interactions are split into cards– Explicit navigation between cards– deck is similar to HTML page, unit of content transmission

• If the user goes to another card of the same deck, the mobile browser does not have to send any requests to the server since the file that contains the deck is already stored in the wireless device.

WML: Wireless Markup Language<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//EN" "http://www.wapforum.org/DTD/wml12.dtd">

<wml> <card id="one" title="First Card"> <p> This is the first card in the deck </p> </card>

<card id="two" title="Second Card"> <p> Ths is the second card in the deck </p> </card> </wml>

WML: Wireless Markup LanguageOutput : on Nokia Mobile Browser 4.0. This mobile supports horizontal scrolling. You can see the text off the screen by pressing the "Left" or "Right" button.

When you press right button, then second card will be visible as follows:

WML Script• Complement to WML, provides capabilities not available in the WML• It is based on JAVAScript.• Adapted for

– Small memory– Efficient over the air transport.

• WMLScript compiler is used to generate the WMLScript bytecodes• This complier may reside in the gateway or the origin server may store

precompiled WMLScript bytecodes.• WMLScript is event based.

WML Script• WMLScript supports WML as follows

– Validity check of user input: • Before sending to the server• WMLScript checks validity and saves bandwidth

– Access to devices facilities:• WMLScript offers functions to access hardware components and

software functions– Local user interaction:

• WMLScript can locally interact with the user, show messages or prompt for input.

• Result of several transactions can be sent to the server.– Extensions to device software:

• A device can be configured or new functionality can be added using WMLScript.

WML Script• Provided features such as

– While, for– If– Return etc

• It weakly typed, i.e., any variable can contain any type of data• Parameters are always passed by value to functions.

WML Script• WMLScript has following libraries :

– Lang: contains functions such as • isInt

– Float: typical arithmetic floating point operations• sqrt

– String: string manipulation functions• Length• subString: • Find : to find a substring within a string• Sqeeze: replace several whitespcaes with only one

– URL: handling URL’s – Dialogs: interaction with user

• prompt– WMLBrowser: functions typical to Browsers such as

• Prev• Refresh• go

Wireless Telephony Application (WTA)• Along with WML Browser the user still wants to access the telephone

network as usual (primary task)• WTA is collection of telephony specific extensions for call and feature

control mechanism• Extends the basic WAE application model as

– Content Push: A WTA origin server

• Example– calling a number (WML)wtai://wp/mc;07216086415

– calling a number (WMLScript)WTAPublic.makeCall("07216086415");

• Implementation– Extension of basic WAE application model– Extensions added to standard WML/WMLScript browser– Exposes additional API (WTAI)

Technology

wireless application protocol