The wireless transaction protocol (WTP) is on top of either WDP or, if security is required, WTLS (WAP Forum, 2000d). WTP has been designed to run on very thin clients, such as mobile phones. WTP offers several advantages to higher layers, including an improved reliability over datagram services, improved efficiency over connection-oriented services, and support for transaction-oriented services such as web browsing. In this context, a transaction is defined as a request with its response, e.g. for a web page. WTP offers many features to the higher layers. The basis is formed from three classes of transaction service as explained in the following paragraphs. Class 0 provides unreliable message transfer without any result message. Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with, exactly one reliable result message (the typical request/response case).

WTP achieves reliability using duplicate removal, retransmission, acknowledgements and unique transaction identifiers. No WTP-class requires any connection set-up or tear-down phase. This avoids unnecessary overhead on the communication link. WTP allows for asynchronous transactions, abort of transactions, concatenation of messages, and can report success or failure of reliable messages (e.g., a server cannot handle the request). To be consistent with the specification, in the following the term initiator is used for a WTP entity initiating a transaction (aka client), and the term responder for the WTP entity responding to a transaction (aka server). The three service primitives offered by WTP are TR-Invoke to initiate a new transaction, TR-Result to send back the result of a previously initiated transaction, and TR-Abort to abort an existing transaction. The PDUs exchanged between two WTP entities for normal transactions are the invoke PDU, ack PDU, and result PDU.

A special feature of WTP is its ability to provide a user acknowledgement or, alternatively, an automatic acknowledgement by the WTP entity. If user acknowledgement is required, a WTP user has to confirm every message received by a WTP entity. A user acknowledgement provides a stronger version of a confirmed service because it guarantees that the response comes from the user of the WTP and not the WTP entity itself. WTP class 0 Class 0 offers an unreliable transaction service without a result message. The transaction is stateless and cannot be aborted. The service is requested with the TR-Invoke.req primitive as shown in Figure 10.14. Parameters are the source address (SA), source port (SP), destination address (DA), destination port (DP) as already explained in section 10.3.2. Additionally, with the A flag the user of this service can determine, if the responder WTP entity should generate an acknowledgement or if a user acknowledgement should be used. The WTP layer will transmit the user data (UD) transparently to its destination. The class type C indicates here class 0. Finally, the transaction handle H provides a simple index to uniquely identify the transaction and is an alias for the tuple (SA, SP, DA, DP), i.e., a socket pair, with only local significance.

The WTP entity at the initiator sends an invoke PDU which the responder receives. The WTP entity at the responder then generates a TR-Invoke.ind primitive with the same parameters as on the initiators side, except for which is now the local handle for the transaction on the responders side. In this class, the responder does not acknowledge the message and the initiator does not perform any retransmission. Although this resembles a simple datagram service, it is recommended to use WDP if only a datagram service is required. WTP class 0 augments the transaction service with a simple datagram like service for occasional use by higher layers.

WTP class 1 Class 1 offers a reliable transaction service but without a result message. Again, the initiator sends an invoke PDU after a TR-Invoke.req from a higher layer.

This time, class equals „1, and no user acknowledgement has been selected as shown in Figure 10.15. The responder signals the incoming invoke PDU via the TR-Invoke.ind primitive to the higher layer and acknowledges automatically without user intervention. The specification also allows the user on the responders side to acknowledge, but this acknowledgement is not required. For the initiator the transaction ends with the reception of the acknowledgement. The responder keeps the transaction state for some time to be able to retransmit the acknowledgement if it receives the same invoke PDU again indicating a loss of the acknowledgement.

If a user of the WTP class 1 service on the initiators side requests a user acknowledgement on the responders side, the sequence diagram looks like Figure. Now the WTP entity on the responders side does not send an acknowledgement automatically, but waits for the TR-Invoke.res service primitive from the user. This service primitive must have the appropriate local handle H for identification of the right transaction. The WTP entity can now send the ack PDU. Typical uses for this transaction class are reliable push services.

WTP class 2 Finally, class 2 transaction service provides the classic reliable request/response transaction known from many client/server scenarios. Depending on user requirements, many different scenarios are possible for initiator/responder interaction. Three examples are presented below. Figure shows the basic transaction of class 2 without-user acknowledgement. Here, a user on the initiators side requests the service and the WTP entity sends the invoke PDU to the responder. The WTP entity on the responders side indicates the request with the TR-Invoke.ind primitive to a user. The responder now waits for the processing of the request, the user on the responders side can finally give the result UD* to the WTP entity on the responder side using TR-Result.req. The result PDU can now be sent back to the initiator, which implicitly acknowledges the invoke PDU. The initiator can indicate the successful transmission of the invoke message and the result with the two service primitives TR-Invoke.cnf and TR-Result.ind. A user may respond to this result with TR-Result.res. An acknowledgement PDU is then generated which finally triggers the TR-Result.cnf primitive on the responder‟s side. This example clearly shows the combination of two reliable services (TR-Invoke and TR-Result) with an efficient data transmission/acknowledgement.

An even more reliable service can be provided by user acknowledgement as explained above. The time-sequence diagram looks different (see Figure 10.18). The user on the responder‘s side now explicitly responds to the Invoke PDU using the TR-Invoke.res primitive, which triggers the TR-Invoke.cnf on the initiator‘s side via an ack PDU. The transmission of the result is also a confirmed service, as indicated by the next four service primitives. This service will likely be the most common in standard request/response scenarios as, e.g., distributed computing.

If the calculation of the result takes some time, the responder can put the initiator on ―hold on‖ to prevent a retransmission of the invoke PDU as the initiator might assume packet loss if no result is sent back within a certain timeframe. This is shown in the Figure.

After a time-out, the responder automatically generates an acknowledgement for the Invoke PDU. This shows the initiator that the responder is still alive and currently busy processing the request. WTP provides many more features not explained here, such as concatenation and separation of messages, asynchronous transactions with up to 215 transactions outstanding, i.e., requested but without result up to now, and segmentation/ reassembly of messages.