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

DATA FLOW THROU H TH! WAP " TCP/IP STAC#S The nternet model makes it possible for a client to reach services on a large number 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. n order 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+P, P 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 a protocol 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 between applications but is less comple) and less reliable than T+P, and +(P which transmits error messages and network traffic statistics. The T+P, P 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

packets from the 2etwork layer, sticks a %ink layer header on them, and sends them out 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+P, P suite. t provides the basic delivery mechanism for packets of data or datagrams, sent between 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. .) Trans/ort 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 is inherently 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 acknowledge the receipt of data. T+P establishes or destroys a connection with the destination via an e)change of management packets. 0) A//l*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 latency conditions 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 A//l*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 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 Protocol The Wireless 3ession Protocol provides the application layer of WAP with a consistent interface for the session services. W3P provides the HTTP,4.4 functionality 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 are uni"uely identified so as not to be accepted twice and may be retransmitted to the

0)

3)

peer if lost in transmission. WTP is also adapted to the constraints of wireless bearers in that it minimizes the protocol overhead by introducing functionalities like message concatenation, acknowledgement of received data re"uests and selective retransmission of lost segments. W*r,l,ss Trans/ort 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 the WAP 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 can selectively enable or disable WT%3 features depending on their security re"uirements and the characteristics of the underlying network. W*r,l,ss Datagra2 Protocol The Wireless /atagram Protocol layer operates above the data capable bearer services 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 wireless network. This is accomplished by adapting the transport layer to specific features of the underlying bearer. 6y keeping the transport layer interface and the basic features consistent, global interoperability can be achieved using mediating gateways.

W*r,l,ss A//l*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 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. A//l*cat*ons' W*r,l,ss T,l,/hon+ A//l*cat*ons The WTA framework supports Wireless Telephony Applications that interface with 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 Push nitiator 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, and the 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'.

()

-)

.)

0)

3)

5)

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 to support 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 &telephony application 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 mobile network 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 actions taken 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. events intended 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 as the 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. 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 it is 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 WAP client. WTA S,r1*c,s WTA services are what the end*user ultimately e)periences from using the WTA framework. 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 the mobile network &e.g. an incoming call'. 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. The repository 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.

PUSH &!CHA%IS& The WAP Push framework introduces a means within the WAP effort to transmit information to a device without a previous user action. n the normal client,server 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 pulls information 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, there is also push technology, which is also based on the client,server 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 are server*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 Push nitiator shares no protocol with the WAP +lient1 the Push nitiator is on the nternet, and the 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 does what 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 Push nitiator 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 notifications to 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 the user 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.

4.

=. >.

-.

B.

The Push nitiator, in this case the e*mail provider, instructs the Push Pro)y,8ateway to push an 3 to the mobile client using the Push Access Protocol ;PushPAP<. The Push nitiator provides the 3 with an appropriate message and a #$ to the e*mail service. The Push Pro)y,8ateway sends the 3 to the mobile client using the Push 5TA Protocol ;5TA<. The mobile client receives the push containing the 3 , and the message is presented to the end*user. The clientprovides the end*user with a means to choose whether the e*mail service should be started immediately, or if the 3 should be postponed. n this e)ample, the end*user chooses to start the e*mail service immediately. The e*mail service indicated by the 3 ?s #$ is retrieved &@pulledA' from the origin server via the (ethod Pro)y, 8ateway or optionally from the client?s cache memory. The e*mail service starts e)ecuting on the mobile client.

S,r1*c, Load*ng The 3ervice %oading &3%' content type provides the ability to cause a user agent on a mobile client to load and e)ecute a service that, for e)ample, can be in the form of a W(% deck. The 3% contains a #$ indicating the service to be loaded by the user agent without user intervention when appropriate. The e)ample illustrates how a mobile network operator chooses to force an end*user with a prepaid subscription to take action on his,her low balance by using 3% to cause the user agent to load and e)ecute the appropriate service &in the form of a W(% deck'. The following steps are involved1

4. The Push nitiator, in this case the mobile network operator, instructs the Push Pro)y,8ateway to push an 3% to the mobile client using the Push Access Protocol ;PAP<. The Push nitiator provides the 3% with the #$ to the W(% deck that should be e)ecuted in the client?s user agent. =. The Push Pro)y,8ateway sends the 3% to the mobile client using the Push 5TA Protocol ;5TA<. >. The mobile client receives the push containing the 3%. The end*user is not made aware of this. -. The service indicated by the 3%?s #$ is retrieved &@pulledA' from the origin server via the (ethod Pro)y, 8ateway or optionally from the client?s cache memory. B. The service starts e)ecuting on the mobile client.

WIR!L!SS S!SSIO% PROTOCOL

The 3ession layer protocol family in the WAP architecture is called the Wireless 3ession Protocol &W3P'. Wireless 3ession Protocol is a session*level protocol family for remote operations between a client and pro)y or server. W3P provides the upper*level application layer of WAP with a consistent interface for two session services. The first is a connection*mode service that operates above a transaction layer protocol WTP, and the second is a connectionless service that operates above a secure or non*secure datagram transport service. W3P is designed to function on the transaction and datagram services. 3ecurity is assumed to be an optional layer above the transport layer. W3P itself does not re"uire a security layer! however, applications that use W3P may re"uire it. W3P provides a means for organised e)change of content between co*operating client,server applications. 3pecifically, it provides the applications means to1 a' establish a reliable session from client to server and release that session in an orderly manner!

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, connectionless services 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 HTTP,4.4 functionality1 such as e)tensible re"uest*reply methods, composite ob0ects C content type negotiation. W3P provides the application means to 4. 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 HTTP,4.4 are supported. n addition, capability negotiation can be used to agree on a set of e)tended re"uest methods, so that full compatibility to HTTP,4.4 applications can be retained. The HTTP,4.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*known headers 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 response headers 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 allows the 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 small implementations. 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 are accomplished 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

using the Protocol /ata #nits &P/#'. .ach P/# serves a particular function in the protocol and contains type*specific information. +% .2T
nitiating the 3ession +ontacting the 3erver +onnect P/# fields Dersion +apabilities%en Headers%en +apabilities Headers 3ession .stablished. 3ending the +onnect P/#

3.$D.$
$eceived the +onnect P/# +onnect$eply P/# fields 3erver3ession d +apabilities%en Headers%en +apabilities Headers

3ending the +onnect$eply P/#

S!SSIO% SUSP!%D A%D R!SU&! A session can be suspended temporarily in case of some error at the client or the server side 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. The following P/#s are essential1 4. 3#3P.2/ 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 the server in response to a re"uest. $eply is used in the 3*+onnect primitive to indicate an error during session creation.
+% .2T +onnect P/# sent. 3ession established. 3ession is being suspended 3uspend P/# field 3ession d 3ending 3uspend P/# 3ession suspended 3.$D.$ +onnect$eply P/# sent.

3ession is being resumed $esume P/# field 3ession d +apabilities%en +apabilities Headers

3ending P/#

$esume

3ession resumed

PUSH &!CHA%IS& W3P provides both push and pull data transfer. Pull is done using the re"uest,response mechanism from HTTP,4.4. n addition, W3P provides three push mechanisms for data transfer1

()

-) .)

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*way messages 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 improves latency as the result of each re"uest can be sent to the client when it becomes available.

WIR!L!SS TRA%SACTIO% PROTOCOL

The Wireless Transaction protocol (WTP) is responsible for control of transmitted and received 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 communication se"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 services necessary for interactive browsing &re"uest,response' 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 reliability with 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 issuing the 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 responder must 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 and cannot be aborted.

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 the WTP 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 invoke,response 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 the Transaction +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 user sends 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 last acknowledgement 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.

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. The invoke 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 completes the three way handshake. -. f the nitiator does not have a corresponding outstanding transaction, it must abort the transaction by sending an Abort P/# with the Abort reason 2DA% /T /.

3uccessful T / verification S!L!CTI;! R!4TRA%S&ISSIO%

T / verification failure.

n the event that a particular packet if data is lost then the WTP has the functionality 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.

=. >. -.

B. H. I.

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. 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. 5nce the responder has received the missing packet, the message is acknowledged and the transaction is finished. I%ITIATOR
3ending the 3egmented nvoke P/# nvoke P/# fields +ontinue Jlag P/# type 8roup Trailer Transmission Trailer $e*transmission ndicator Transaction dentifier Dersion T /new #,P Jlag Transaction +lass 3egmented nvoke P/# fields +ontinue Jlag P/# type 8roup Trailer Transmission Trailer $e*transmission ndicator Transaction dentifier Packet 3e"uence 2umber 3ending the 4st packet. nvoke P/# 3ending the =nd packet. . 3egmented nvoke P/# 3ending the =nd packet. 3egmented nvoke P/# 2egative Ack P/# fields +ontinue Jlag P/# type $e*transmission ndicator Transaction dentifier 2umber of (issing Packets P32 of (issing Packet&s'

R!SPO%D!R
$eceived the 4st packet $eceived the >rd packet. Packet = missing. $eassembly fails.

3ending the 2egative Acknowledgement P/#

$etransmitting the =nd packet. 3egmented nvoke P/#

$eceived the =nd packet

Transaction completed

3ending the Acknowledgement P/#

Ack P/# fields +ontinue Jlag P/# type T / Derify,T / 5G $e*transmission ndicator Transaction dentifier

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

A Protocol /ata #nit, P/#, contains an integer number of octets and consists of1 a' the header, comprising1 4. the fi)ed part =. the variable part b' 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 <( :*t=' The continue flag indicates the presence of any TP s in the variable part. f the flag is set, there are one or more TP s in the variable portion of the header. f the flag is clear, the variable part of the header is empty. This flag is also used as the first bit of a TP , and indicates whether the TP is the last of the variable header. f the flag is set, another TP follows this TP . f the flag is clear, the octet after this TP is the first octet of the user data.

PDU t+/,: The P/# type determines the length and structure of the header and dictates what type of WTP P/# the P/# is & nvoke, Ack, etc'. This provides information to the receiving WTP provider as to how the P/# data should be interpreted and what action is re"uired. The following P/# types are defined1 PDU Cod, PDU T+/, F)F4 nvoke F)F= $esult F)F> Ack F)FAbort F)FB 3egmented nvoke F)FH 3egmented $esult F)FI 2egative Ack rou/ tra*l,r < TR= and Trans2*ss*on tra*l,r <TTR= flag <- :*t=' When segmentation and re*assembly is implemented the TT$ flag is used to indicate the last packet of the segmented message, the 8T$ flag is used to indicate the last packet of a packet group. The default setting 3H5#%/ be 8T$K4 and TT$K4, that is, WTP segmentation and re*assembly not supported. n the case where a message uses

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

RID R,4trans2*ss*on Ind*cator <( :*t=' .nables the receiver to differentiate between packets duplicated by the network and packets re*transmitted by the sender. n the original message the $ / is clear. When the message gets re*transmitted the $ / is set. TID Transact*on *d,nt*f*,r <(5 :*t=' The T / is used to associate a packet with a particular transaction. ;,rs*on The current version is F:FF TIDn,w flag This bit is set when the nitiator has wrapped the T / value, i.e. set it to be lower than the previous T / value. U/P When this flag is set it indicates that the nitiator re"uires a #ser acknowledgement from the server WTP user. The WTP user confirms every received message. R!S This is a reserved bit and its value should be set to F. TCL The transaction class shows the desired transaction class in te invoke message.

Pack,t s,>u,nc, nu2:,r <? :*t=' This is used by the P/#s belonging to the segmentation and re assembly.

R,sult PDU

AC# PDU

T1,/Tok Flag n the direction from the responder to the initiator the Tve &T / Derify' means1 *7/o you have 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 entire packet group shall be re*transmitted. Pack,t S,>u,nc, %u2:,r<s= of &*ss*ng Pack,ts %ist of packet se"uence number for the re"uest packets.

S,g2,ntat*on and R,ass,2:l+

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

The 3ecurity layer protocol in the WAP architecture is called the Wireless Transport %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 interface below 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 new features 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 and,or 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 application management 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. The negotiation 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 a protocol 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 server to 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 follows1 The 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 capabilities between client and server.The client hello and server hello establish the following attributes1 Protocol Dersion, Gey .)change 3uite, +ipher 3uite, +ompression (ethod,

Gey $efresh, and 3e"uence 2umber (ode. Additionally, two random values are generated 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 key e)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 the concerned 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 DATA RA& PROTOCOL The Wireless /atagram Protocol layer basically packages the data so that it can be 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>H 8#T3, A23 *4>H 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 the specific 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 packet contains 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. The se"uence number can be regarded as a counter that is incremented for each packet. $eassembly *s performed 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 an entire datagram e)ists, then it can be delivered to the upper layer.