Data Flow Through the Wap

8/13/2019 Data Flow Through the Wap

1/19

Flow Of Data Through WAP and TCP/IP Protocol Stacks

The protocols used in WAP are based on internet protocols such as Hypertext Transfer

Protocol (HTTP), and Transfer Control Protocol (TCP). The protocol stack defined in

WAP optimizes these protocols for use under the low bandwidth, high latency conditionsfound in the wireless network environment. A number of enhancements to the session,

transaction, security and transport layers of HTTP make it better suited for the wireless.

DATA FLOW THROUH TH! WAP " TCP/IP STAC#S

The nternet model makes it possible for a client to reach services on a largenumber of origin servers! each addressed by a uni"ue #niform $esource %ocator $%'.

The content stored on the servers is of various formats, but HT(% is the predominant

one. WAP makes use of the nternet paradigm to provide a fle)ible service platform. norder to accommodate wireless access to the information space offered by the WWW,

WAP is based on well*known nternet technology that has been optimized to meet the

constraints of a wireless environment.

LA$!RS OF TH! I%T!R%!T &OD!L'

T+PP stands for Transmission +ontrol Protocol nternet Protocol. t is a -*layer suite of protocols. ach layer builds upon the layer below it, adding new

functionality. The benefit that the layered protocol stack gives is that, if a new network

application or a new type of hardware is invented, the only need will be to create aprotocol for that application or that hardware, there is no need to re*write the whole

stack.The suite is actually composed of several protocols. These include P which handles

the movement of data between host computers, T+P which manages the movement of

data between applications, #/P which also manages the movement of data betweenapplications but is less comple) and less reliable than T+P, and +(P which transmits

error messages and network traffic statistics.The T+PP protocol breaks the 0ob of a full network protocol into a number of

tasks. ach layer in the protocol corresponds to a different facet of communication. The

four of the protocol are as follows1

() Datal*nk la+,r

The /ata %ink layer, is responsible for communicating with the actual network

hardware &e.g., the thernet card'. While receiving data from the network, it takes

packets from the network wire, strips away any %ink layer header information, and

hands it off to the 2etwork layer. While transmitting data onto the network, it takes


2/19

packets from the 2etwork layer, sticks a %ink layer header on them, and sends themout over the wire.

-) %,twork la+,r

The 2etwork layer is where the nternet Protocol &P' and the nternet +ontrol(essage Protocol &+(P', among others, reside. +(P is used both to provide

network reliability information. P is the central, unifying protocol in the T+PP

suite. t provides the basic delivery mechanism for packets of data or datagrams, sentbetween all systems on the nternet. P is able to get packets to their destinations

because every network interface on the nternet has a uni"ue, numeric address.

.) Transort la+,r

The Transport layer consists of two protocols the Transmission +ontrol Protocol

&T+P' and the #ser /atagram Protocol /P'. Transmission +ontrol Protocol

provides a reliable byte*stream transfer service between two endpoints on the

nternet. T+P depends on P to move packets around the network on its behalf. P isinherently unreliable, so T+P protects against data loss, data corruption, packet

reordering and data duplication by adding checksums and se"uence numbers to

transmitted data and, on the receiving side, sending back packets that acknowledgethe receipt of data. T+P establishes or destroys a connection with the destination via

an e)change of management packets.0) Al*cat*on la+,r

The Application %ayer is where the user interacts with the network. All network

programs like telnet, ftp, mail, news, and WWW clients are at the application layer.

They use either T+P or #/P to communicate with other machines.

LA$!RS OF TH! WAP &OD!L

The protocols used in WAP are based on internet protocols such as Hyperte)t

Transfer Protocol &HTTP', and Transfer +ontrol Protocol &T+P'. The protocol stack

defined in WAP optimizes these protocols for use under the low bandwidth, high latencyconditions found in the wireless network environment. A number of enhancements to the

session, transaction, security and transport layers of HTTP make it better suited for the

wireless.

() W*r,l,ss Al*cat*on !n1*ron2,nt

The Wireless Application nvironment is a general*purpose application environmentbased on a combination of World Wide Web &WWW' and (obile Telephony

technologies. WA establishes 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.

-) W*r,l,ss S,ss*on ProtocolThe Wireless 3ession Protocol provides the application layer of WAP with a

consistent interface for the session services. W3P provides the HTTP4.4functionality and semantics in a compact over*the*air encoding. 5ther features such

as long*lived sessions, header caching etc. have optimized W3P to meet the

constraints of the wireless environment..) W*r,l,ss Transact*on Protocol

The Wireless Transaction Protocol is responsible for control of transmitted and

received messages. t provides a reliable communication where messages areuni"uely identified so as not to be accepted twice and may be retransmitted to the


3/19

peer if lost in transmission. WTP is also adapted to the constraints of wireless bearersin that it minimizes the protocol overhead by introducing functionalities like message

concatenation, acknowledgement of received data re"uests and selective

retransmission of lost segments.0) W*r,l,ss Transort La+,r S,cur*t+

The Wireless Transport %ayer 3ecurity is a security protocol based upon the industry*

standard T%3 &Transport %ayer 3ecurity' protocol. WT%3 is intended for use with theWAP transport protocols and has been optimized for use over narrow*band

communication channels. WT%3 provides the following features such as data

integrity, authentication and non*repudiation of client and server etc. Applications canselectively enable or disable WT%3 features depending on their security re"uirements

and the characteristics of the underlying network.3) W*r,l,ss Datagra2 Protocol

The Wireless /atagram Protocol layer operates above the data capable bearerservices supported by the various network types. The W/P protocols provide a

common interface to the upper layer protocols and hence the 3ecurity, 3ession and

Application layers are able to function independently of the underlying wirelessnetwork. This is accomplished by adapting the transport layer to specific features of

the underlying bearer. 6y keeping the transport layer interface and the basic featuresconsistent, global interoperability can be achieved using mediating gateways.

W*r,l,ss Al*cat*on !n1*ron2,nt

The Wireless Application nvironment is a general*purpose application environment

based on a combination of World Wide Web &WWW' and (obile Telephony

technologies. WA establishes an interoperable environment that will allow operatorsand service providers to build applications and services that can reach a wide variety of

different wireless platforms in an efficient and useful manner.

Al*cat*ons'

W*r,l,ss T,l,hon+ Al*cat*ons

The WTA framework supports Wireless Telephony Applications that interfacewith the in*device telephony related functions and the network telephony infrastructure.

The WTA framework e)tends the WA framework. t adds an interface from WTA*

W(% and W(%3cript to a specific set of local, telephony related, functions in the client.

This interface is called the 7Wireless Telephony Application nterface7 &WTA'.

Push Arch*t,ctur,

A push operation in WAP occurs when a Push nitiator transmits content to a

client using either the Push 5ver*The*Air protocol or the Push Access Protocol. The Pushnitiator contacts the WAP +lient with an intermediary, the Push Pro)y 8ateway &PP8'.

The PP8 does what is necessary to forward the pushed content to the WAP domain, andthe content is then transmitted over*the*air in the mobile network to the destination client.

WIR!L!SS T!L!PHO%$ APPLICATIO%S

The Wireless Telephony Application &WTA' environment provides a means to create

telephony services using the Wireless Application Protocol &WAP'.


4/19

() Us,r4ag,nts

The WTA user*agent is an e)tension to the standard W(% user*agent with the

addition of capabilities for interfacing with mobile network services available to a

mobile telephony device, e.g. setting up and receiving phone calls. The ability tosupport simple telephony functions from within a WA user*agent is very important.

-) WTA Us,r4ag,nt

The WTA user*agent, the repository &persistent storage' and WTA &telephonyapplication interface' interact with each other and other entities in a WTA*capable

mobile client device. The WTA user*agent is able to retrieve content from the

repository and WTA ensures that the WTA user*agent can interact with mobilenetwork functions &e.g. setting up calls' and device specific features &e.g.

manipulating the phonebook'. The WTA user*agent receives network events that can

be bound to content, thus enabling dynamic telephony applications. 2etwork events

that will be available to the WTA user*agent are those that are the result of actionstaken by services running in the WTA user*agent itself. Telephony events initiated

from outside the device are also passed to the WTA user*agent, as are network te)t

message events that are not e)plicitly directed towards another user*agent &e.g. eventsintended for a 3('. This means, for instance, that network events caused by the

W(% user*agent will not affect the WTA user*agent..) WA! Us,r4ag,nt

The WA user*agent and WTA &Telephony Application nterface' Public %ibrary

interact with each other and other entities in a WTA*capable mobile client. The WA

user*agent only retrieves its content via the WAP gateway and only has access to the

WTA Public %ibrary functions. These functions e)pose simple functionality such asthe ability to place a call, but do not allow fully featured telephony control. The WA

user*agent is not able to receive and react to telephony and network te)t events.0) WTA S,r1,r

The WTA server can be thought of as a web server delivering content

re"uested by a client. %ike an nternet web browser, a WTA user*agent uses #$%s to

reference content on the WTA server. 6y referencing applications on a WTA server itis possible to create services that use #$%s to interact with the mobile network and

other entities &e.g. a voice mail system'. Thus, the concept of referencing applications

on a WTA server provides a simple but yet powerful model for how to seamlessly

integrate services in the mobile network with services e)ecuting locally in the WAPclient.

3) WTA S,r1*c,s

WTA services are what the end*user ultimately e)periences from using the WTAframework. A WTA service appears to the client in the form of various content

formats, e.g. WTA*W(%, W(%3cript etc. The WTA user*agent e)ecutes content

that is persistently stored in the client9s repository or content retrieved from a WTA

server. The framework also allows the WTA user*agent to act on events from themobile network &e.g. an incoming call'.

5) R,os*tor+

The repository is a persistent storage module within the mobile terminal that may be

used to eliminate the need for network access when loading and e)ecuting fre"uently

used WTA services. The repository also addresses the issue of how a WTA service

developer ensures that time*critical WTA events are handled in a timely manner. Therepository allows the WTA service developer to pre*program the device with content

and also improves the response time for a WTA service. 5nly WTA applications may

access the repository.


5/19

PUSH &!CHA%IS&

The WAP Push framework introduces a means within the WAP effort to transmitinformation to a device without a previous user action. n the normal clientserver model,

a client re"uests a service or information from a server, which then responds in

transmitting information to the client. This is known as pull technology 1the client pullsinformation from the server. The World Wide Web is a typical e)ample of pull

technology, where a user enters a #$% &the re"uest' which is sent to a server, and the

server answers by sending a Web page &the response' to the user. n contrast to this, thereis also push technology, which is also based on the clientserver model, but where there is

no e)plicit re"uest from the client before the server transmits its content.

Pull transactions of information are always initiated from the client, Push transactions areserver*initiated.

Th, Push Fra2,work

A push operation in WAP occurs when a Push nitiator transmits content to a

client using either the Push 5ver*The*Air protocol or the Push Access Protocol. The Pushnitiator shares no protocol with the WAP +lient1 the Push nitiator is on the nternet, andthe WAP +lient is in the WAP domain. Therefore, the Push nitiator cannot contact the

WAP +lient without an intermediary, so we need to insert a translating gateway.

Thus, the Push nitiator contacts the Push Pro)y 8ateway &PP8' from the nternet

side, delivering content for the destination client using nternet protocols. The PP8 doeswhat 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. n addition to

providing simple pro)y gateway services, the PP8 is capable of notifying the Pushnitiator about the final outcome of the push operation. t may also provide the Push

nitiator with client capability lookup services, letting a Push nitiator select the optimal

flavour of this particular content for this particular client.The nternet*side PP8 access protocol is called the Push Access Protocol &PAP'.

The WAP*side protocol is called the Push 5ver*The*Air &5TA' Protocol. The Push

Access Protocol uses :(% messages that may be tunnelled through various well*known

nternet protocols, for e)ample HTTP. The 5TA protocol is based on W3P services.

Th, S,r1*c, Ind*cat*on

The 3ervice ndication &3' content type provides the ability to send notificationsto end*users in an asynchronous manner. 3uch notifications may, for e)ample, be about

new e*mails, changes in stock price, news headlines, advertising, reminders of e.g. low

prepaid balance, etc. n its most basic form, an 3 contains a short message and a #$

indicating a service. The message is presented to the end*user upon reception, and theuser is given the choice to either start the service indicated by the #$ immediately, or

postpone the 3 for later handling. f the 3 is postponed, the client stores it and the end*user is given the possibility to act upon it at a later point of time.


6/19

4. The Push nitiator, in this case the e*mail provider, instructs the Push

Pro)y8ateway to push an 3 to the mobile client using the Push Access Protocol;PushPAP


7/19

4. The Push nitiator, in this case the mobile network operator, instructs the Push

Pro)y8ateway to push an 3% to the mobile client using the Push Access Protocol

;PAP


8/19

b' agree on a common level of protocol functionality using capability negotiation!c' e)change content between client and server using compact encoding

d' suspend and resume the session.

The currently defined services and protocols &W3P' are most suited for browsing*type

applications. W3P defines actually two protocols1 one provides connection*mode session

services over a transaction service, and another provides non*confirmed, connectionlessservices 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. t can be used without actually having to establish a session.

n addition to the general features, W3P offers means to1 provide HTTP4.4 functionality1

such as e)tensible re"uest*reply methods, composite ob0ects C content type negotiation.

W3P provides the application means to4. e)change client and server session headers

=. interrupt transactions in process

>. push content from server to client in an unsynchronised manner-. negotiate support for multiple, simultaneous asynchronous transactions.

6as*c Funct*onal*t+

The core of the W3P design is a binary form of HTTP. +onse"uently the re"uests

sent to a server and responses going to a client may include both headers &meta*

information' and data. All the methods defined by HTTP4.4 are supported. n addition,

capability negotiation can be used to agree on a set of e)tended re"uest methods, so thatfull compatibility to HTTP4.4 applications can be retained. The HTTP4.4 content

headers are used to define content type, character set encoding, languages, etc, in an

e)tensible manner. However, compact binary encodings are defined for the well*knownheaders to reduce protocol overhead. W3P also specifies a compact composite data

format that provides content headers for each component within the composite data

ob0ect.W3P itself does not interpret the header information in re"uests and replies. As

part of the session creation process, re"uest and reply headers that remain constant over

the life of the session can be e)changed between service users in the client and the server.

W3P will pass through client and server session headers as well as re"uest and responseheaders without additions or removals. The lifecycle of a W3P 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 allowsthe session to be resumed without the overhead of full*blown session establishment. A

session may be resumed over a different bearer network.

!7t,nd,d Funct*onal*t+W3P allows e)tended capabilities to be negotiated between the peers. This allows

for both high performance, feature*full implementation as well as simple, basic and smallimplementations. W3P 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.

+ommunications between layers and between entities within the session layer areaccomplished by means of service primitives. 3ervice primitives represent, in an abstract

way, the logical e)change of information and control between the session layer and

ad0acent layers. While peer to peer communication for a particular layer is carried out


9/19

using the Protocol /ata #nits &P/#'. ach P/# serves a particular function in theprotocol and contains type*specific information.

+%2T 3$D$

S!SSIO% SUSP!%D A%D R!SU&!

A session can be suspended temporarily in case of some error at the client or the serverside or even otherwise. To resume the session, client has to send the $esume P/# which

will contain the re"uired identities necessary to resume the previous session. Thefollowing P/#s are essential1

4. 3#3P2/ 3uspend P/# is sent to suspend a session.

=. $3#( The $esume P/# is sent to resume an e)isting session after a change

in the underlying transport protocol.

>. $P%E $eply is the generic response P/# used to return information from theserver in response to a re"uest. $eply is used in the 3*+onnect primitive to

indicate an error during session creation.

PUSH &!CHA%IS&

W3P provides both push and pull data transfer. Pull is done using the re"uestresponsemechanism from HTTP4.4. n addition, W3P provides three push mechanisms for data

transfer1

+onnect P/# sent. +onnect$eply P/# sent.

3ession established.

3ession is being suspended

3uspend P/# field

3essiond

3ending 3uspend

P/#

3ession suspended

+%2T 3$D$

3ession is being resumed

$esume P/# field

3essiond+apabilities%en+apabilities

Headers

3ending $esume

P/#

3ession resumed

nitiating the 3ession

+ontacting the 3erver

+onnect P/# fieldsDersion

+apabilities%en

Headers%en+apabilities Headers

3ending the +onnect

P/#$eceived the +onnect

P/#

3ession stablished. 3ending the

+onnect$eply P/#

+onnect$eply P/#

fields

3erver3essiond

+apabilities%enHeaders%en

+apabilities Headers


10/19

() Conf*r2,d data ush w*th*n an ,7*st*ng s,ss*on cont,7t

This push mechanism allows the server to push data to the client at any time

during a session. The server receives confirmation that the push was delivered.-) %on4conf*r2,d data ush w*th*n an ,7*st*ng s,ss*on cont,7t

This provides a similar function as reliable data push, but without confirmation.

.) %on4conf*r2,d data ush w*thout an ,7*st*ng s,ss*on

The non*confirmed out*of*session data push can be used to send one*waymessages over an unreliable transport. n this case, a default session conte)t is

assumed.

AS$%CHRO%OUS HA%DLI% OF R!8U!STS

W3P optionally supports asynchronous re"uests, so that a client can submit

multiple re"uests to the server simultaneously. This improves utilisation of airtime in that

multiple re"uests and replies can be coalesced into fewer messages. This also improveslatency as the result of each re"uest can be sent to the client when it becomes available.


11/19

WIR!L!SS TRA%SACTIO% PROTOCOL

The Wireless Transaction protocol (WTP)is responsible for control of transmitted andreceived messages. t provides a reliable communication where messages are uni"uely

identified so as not to be accepted twice and may be retransmitted to the peer if lost in

transmission. There is no connection between communications as every communicationse"uence is only alive during the e)change of an individual message set.

The Wireless Transaction Protocol &WTP' runs on top of a datagram service and provides

a light*weight transaction*oriented protocol that is suitable for implementation in thin

clients &mobile stations'. A transaction protocol is defined to provide the servicesnecessary for interactive browsing &re"uestresponse' applications. The re"uest and the

response between the client and the server is called a transaction. The ob0ective of the

protocol is to reliably deliver the transaction while balancing the amount of reliabilitywith the cost of delivering the reliability. WTP operates efficiently over secure or non*

secure wireless datagram networks.

Transact*on class,s

The WTP provider initiating a transaction is referred to as the nitiator. The WTP

provider responding to a transaction is referred to as the $esponder. The transaction class

is set by the nitiator and indicated in the invoke message sent to the $esponder.Transaction classes cannot be negotiated. There are > transaction classes supported by

WTP1

Class 9' Unr,l*a:l, *n1ok, 2,ssag, w*th no r,sult 2,ssag,)

+lass F transactions provide an unreliable datagram service. t can be used by

applications that re"uire an unreliable push service. The P/#9s used in this class of

operation is the nvoke P/#. +lass F transaction is initiated by the WTP user by issuingthe T$*nvoke re"uest primitive with the Transaction +lass parameter set to +lass F. The

initiator must increment the T/ counter between each transaction, but the respondermust not update its cached T/. The nitiator does not wait for or e)pect a response. f

the invoke message is received by the $esponder it is accepted immediately. There is no

duplicate removal or verification procedure performed. The transaction is stateless andcannot be aborted.


12/19

Class (' R,l*a:l, *n1ok, 2,ssag, w*th no r,sult 2,ssag,)

+lass 4 transactions provide a reliable datagram service. t can be used by applications

that re"uire a reliable push service. The P/#s used in this class of transaction are the

nvoke P/#, the Ack P/# and the Abort P/#. A +lass 4 transaction is initiated by theWTP user by issuing the T$*nvoke re"uest primitive with the Transaction +lass

parameter set to +lass 4. The $esponder checks the Transaction dentifier and determines

whether a verification has to be initiated. f not, it delivers the message to the user and

returns the last acknowledgement to the nitiator.

Class -' R,l*a:l, *n1ok, 2,ssag, w*th on, r,l*a:l, r,sult 2,ssag,)

+lass = transactions provide the basic invokeresponse transaction service. 5ne W3P

session may consist of several transactions of this type. The P/#s used here are the

nvoke P/#, the $esult P/#, the Ack P/# and the Abort P/#. A +lass = transaction is

initiated by the WTP user by issuing the T$*nvoke re"uest primitive with theTransaction +lass parameter set to +lass =. The $esponder checks the Transaction

dentifier and determines whether a verification has to be initiated. f not, it delivers the

message to the WTP user and waits for the result.

The $esponder may send a hold on acknowledgement after a specified time if the WTP

user re"uires more time to respond to the re"uest initiated by the nitiator. The WTP usersends the result message by issuing the T$*$esult re"uest primitive. When the nitiator

has received the result message it returns the last acknowledgement to the $esponder.

The nitiator must keep state information in order to re*transmit the lastacknowledgement if it gets lost. f the $esponder does not support this transaction class it

returns an Abort P/# as a response to the invoke message.


13/19

TRA%SACTIO% ID!%TIFI!R ;!RIFICATIO%

The transaction identifier verification procedure is a three*way handshake. The T/

verification procedure is necessary to guarantee that the same invoke message is not

accepted and delivered to the WTP user more the once, due to old duplicate packets. Theinvoke message must not be delivered to the user before the T/ verification procedure is

completed successfully. n the event that the $esponder has received an nvoke P/#

from an nitiator and has decided, using the rules for the Transaction dentifier procedure,to verify the T/, the following process is used1

4. The $esponder sends an Ack P/# with Tve flag set indicating that it has received

an invoke message with this T/.=. When the nitiator receives the Ack P/# from the $esponder it checks whether it

has a corresponding outstanding transaction with this T/.>. f it has a transaction with the particular T/ pending then the nitiator sends back

an Ack P/# with T/ok flag set indicating that the T/ is valid. This completesthe three way handshake.

-. f the nitiator does not have a corresponding outstanding transaction, it mustabort the transaction by sending an Abort P/# with the Abort reason2DA%/T/.

3uccessful T/ verification T/ verification failure.

S!L!CTI;! R!4TRA%S&ISSIO%

n the event that a particular packet if data is lost then the WTP has thefunctionality by which it can retransmit only that packet thus saving considerable

overhead due to retransmission of the same data packets all over again. f one of the

packets of a group send by the nitiator is lost then the following series of events takes

place.

4. The $esponder receives the packet with the 8T$ flag set, it attempts to re*

assemble the packet group but fails due to the one missing packet.


14/19

=. The $esponder returns a 2A+G to re"uest the missing packet. Then nitiator re*transmits the missing packet. The re*transmitted packet has the $/ flag set.

>. 5nce the missing packet has been received by the $esponder the message is

acknowledged and the transaction is finished.-. f the lost packet is the last one of the group and therefore the responder does not

receive the packet with the 8T$ or TT$ flag set, it can9t determine whether the

whole packet group has been transmitted or not.B. After a certain time without receiving any acknowledgement for this group, the

initiator re*transmits the last packet of the group.. The re*transmitted packet has the $/ flag set.I. 5nce the responder has received the missing packet, the message is acknowledged

and the transaction is finished.

Structur, and !ncod*ng of Protocol Data Un*ts

3ending the 3egmented

nvoke P/#

3ending the 4st packet.nvoke P/#

3ending the =nd packet. .

3egmented nvoke P/#

3ending the =nd packet.

3egmented nvoke P/#

nvoke P/# fields

+ontinue Jlag

P/# type

8roup TrailerTransmission Trailer

$e*transmission

ndicatorTransaction dentifier

Dersion

T/new

#P JlagTransaction +lass

$eceived the 4st packet

$eceived the >rd packet.

Packet = missing.$eassembly fails.

3egmented nvoke P/#

fields+ontinue Jlag

P/# type

8roup TrailerTransmission Trailer

$e*transmission

ndicator

Transaction dentifierPacket 3e"uence

2umber

3ending the 2egative

Acknowledgement P/#

2egative Ack P/# fields

+ontinue JlagP/# type

$e*transmission

ndicator

Transactiondentifier

2umber of (issing

Packets

P32 of (issingPacket&s'

$etransmitting the =ndpacket. 3egmented

nvoke P/#

$eceived the =nd packet

3ending the

Acknowledgement P/#

Ack P/# fields

+ontinue JlagP/# type

T/ DerifyT/ 5G$e*transmission

ndicator

Transaction

dentifier

Transaction completed

R!SPO%D!RI%ITIATOR


15/19

A Protocol /ata #nit, P/#, contains an integer number of octets and consists of1a' the header, comprising1

4. the fi)ed part

=. the variable partb' the data, if present

The fi)ed part of the headers contains fre"uently used parameters and the P/# code.The variable part is used to define less fre"uently used parameters. Dariable parameters

are carried in Transport nformation

tems, TP.

In1ok, PDU

CO% cont*nu, flag


16/19

segmentation, if the TT$ flag is set in the last segment, then the 8T$ flag must beignored.

RID R,4trans2*ss*on Ind*cator


17/19

T1,/Tok Flag

n the direction from the responder to the initiator the Tve &T/ Derify' means1 *7/o youhave an outstanding transaction with this T/L7. n the opposite direction the Tok &T/

5G' flag means1 *7 have an outstanding transaction with this T/M7

A:ort PDU

S,g2,nt,d In1ok, PDU

S,g2,nt,d R,sult PDU

%u2:,r of &*ss*ng Pack,ts

ndicates the re"uested number of missing packets. f F)FF, this means that the entirepacket group shall be re*transmitted.

Pack,t S,>u,nc, %u2:,r


18/19

WIR!L!SS TRA%SPORT LA$!R S!CURIT$

The 3ecurity layer protocol in the WAP architecture is called the WirelessTransport %ayer 3ecurity, WT%3. The WT%3 layer operates above the transport protocol

layer. The WT%3 layer is modular and it depends on the re"uired security level of the

given application whether it is used or not. WT%3 provides the upper*level layer of WAP

with a secure transport service interface that preserves the transport service interfacebelow it. n addition, WT%3 provides an interface for managing secure connections.

The primary goal of the WT%3 layer is to provide privacy, data integrity and

authentication between two communicating applications. WT%3 incorporates newfeatures such as datagram support, optimised handshake and dynamic key refreshing. The

WT%3 protocol is optimised for low*bandwidth bearer networks with relatively long

latency.WT%3 is designed to function on connection*oriented andor datagram transport

protocols. 3ecurity is assumed to be an optional layer above the transport layer. The

security layer preserves the transport service interfaces. The session or applicationmanagement entities are assumed to provide additional support re"uired to manage

secure connections.

S,cur, s,ss*on ,sta:l*sh2,nt

WT%3 +onnection 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. Thenegotiation may include the security parameters, key e)change and authentication. ither

the server or client service user can also terminate the connection at any time.

When a WT%3 client and server first start communicating, they agree on aprotocol version, select cryptographic algorithms, optionally authenticate each other, and

use public*key encryption techni"ues to generate a shared secret.

The WT%3 Handshake Protocol involves the following steps1 )change hello messages to agree on algorithms, e)change random values. )change the necessary cryptographic parameters to allow the client and server to

agree on a pre*master secret.

)change certificates and cryptographic information to allow the client and serverto authenticate themselves.

8enerate a master secret from the pre*master secret and e)changed random

values. Provide security parameters to the record layer.

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.

These goals are achieved by the handshake protocol, which can be summarised as

follows1The client sends a client hello message to which the server must respond with a

server hello message, or else a fatal error will occur and the secure connection will fail.

The client hello and server hello are used to establish security enhancement capabilitiesbetween client and server.The client hello and server hello establish the following

attributes1 Protocol Dersion, Gey )change 3uite, +ipher 3uite, +ompression (ethod,


19/19

Gey $efresh, and 3e"uence 2umber (ode. Additionally, two random values aregenerated and e)changed1 +lientHello.random and 3erverHello.random.

Jollowing the hello messages, the server will send its certificate, if it is to be

authenticated. Additionally, a server key e)change message may be sent, if it is re"uired.The server may re"uest a certificate from the client , if that is appropriate to the key

e)change suite selected. 2ow the server will send the server hello done message,

indicating that the hello*message phase of the handshake is complete.The server will then wait for a client response. f the server has sent a certificate

re"uest message, the client must send the certificate message. The client key e)change

message is now sent if the client certificate does not contain enough data for keye)change or if it is not sent at all. The content of that message will depend on the public

key algorithm selected between the client hello and the server hello. f the client is to be

authenticated using a certificate with a signing capability &eg, $3A', a digitally*signed

certificate verify message is sent to e)plicitly verify the certificate. After both theconcerned parties are satisfied with each other9s identity and the parameters e)changed,

the handshake is complete and the client and server may begin to e)change application

layer data.

WIR!L!SS DATARA& PROTOCOL

The Wireless /atagram Protocol layer basically packages the data so that it canbe sent onto the wireless network. The W/P along with the WTP form the Transport

layer protocol in the WAP architecture. The W/P layer operates above the data capable

bearer services supported by the various bearer types.

There are many underlying bearers such as 83( 3(3, 83( #33/, 83( +3/,+/P/, 83( 8P$3, A23*4> 8#T3, A23*4> 8H53T, +3/, and Packet /ata etc.

n order to optimise the protocol with respect to memory usage and radio transmission

efficiency, the protocol performance over each bearer may vary. W/P adapts to thespecific features of the underlying wireless network. Hence they are able to function

independently irrespective of the bearer services used.

S!&!%TATIO% A%D R!ASS!&6L$

The segmentation and reassembly mechanism uses a se"uence number and a ma)size

number to define the order and the completeness of the message. The header of a packetcontains the segmentation information like the reference number for W/P packet, total

number of segments in datagram and the segment number. The se"uence number may be

used to resolve problems with duplicate, dropped and out of order packet delivery. These"uence number can be regarded as a counter that is incremented for each packet.

$eassembly *sperformed using a list of received packets. As packets arrive, they are

inserted in order into the list, and then the list is checked for a complete datagram. f anentire datagram e)ists, then it can be delivered to the upper layer.

Date post:	04-Jun-2018
Category:	Documents
Upload:	surajsupekar
View:	217 times
Download:	0 times

Data Flow Through the Wap

Documents