Wireless Application Environment

The main idea behind the wireless application environment (WAE) is to create a general-purpose application environment based mainly on existing technologies and philosophies of the world wide web. This environment should allow service providers, software manufacturers, or hardware vendors to integrate their applications so they can reach a wide variety of different wireless platforms in an efficient way. However, WAE does not dictate or assume any specific man-machine-interface model, but allows for a variety of devices, each with its own capabilities and probably vendor-specific extras (i.e., each vendor can have its own look and feel). WAE has already integrated the following technologies and adapted them for use in a wireless environment with low power handheld devices.

HTML, JavaScript, and the handheld device markup language HDML form the basis of the wireless markup language (WML) and the scripting language WML script. The exchange formats for business cards and phone books vCard and for calendars vCalendar have been included. URLs from the web can be used. A wide range of mobile telecommunication technologies have been adopted and integrated into the wireless telephony application (WTA).

Besides relying on mature and established technology, WAE focuses on devices with very limited capabilities, narrow-band environments, and special security and access control features. The first phase of the WAE specification developed a whole application suite, especially for wireless clients as presented in the following sections. Future developments for the WAE will include extensions for more content formats, integration of further existing or emerging technologies, more server-side aspects, and the integration of intelligent telephone networks.

One global goal of the WAE is to minimize over-the-air traffic and resource consumption on the handheld device. This goal is also reflected in the logical model underlying WAE (Figure 10.29) showing some more detail than the general overview in Figure 10.10. WAE adopts a model that closely follows the www model, but assumes additional gateways that can enhance transmission efficiency.

A client issues an encoded request for an operation on a remote server. Encoding is necessary to minimize data sent over the air and to save resources on the handheld device as explained together with the languages WML and WMLscript. Decoders in a gateway now translate this encoded request into a standard request as understood by the origin servers. This could be a request to get a web page to set up a call. The gateway transfers this request to the appropriate origin server as if it came from a standard client. Origin servers could be standard web servers running HTTP and generating content using scripts, providing pages using a database, or applying any other (proprietary) technology. WAE does not specify any standard content generator or server, but assumes that the majority will follow the standard technology used in today‘s www.

The origin servers will respond to the request. The gateway now encodes the response and its content (if there is any) and transfers the encoded response with the content to the client. The WAE logical model not only includes this standard request/response scheme, but it also includes push services. Then an origin server pushes content to the gateway. The gateway encodes the pushed content and transmits the encoded push content to the client.

Several user agents can reside within a client. User agents include such items as: browsers, phonebooks, message editors etc. WAE does not specify the number of user agents or their functionality, but assumes a basic WML user agent that supports WML, WML script, or both (i.e., a ‗WML browser‘). Further domain specific user agents with varying architectures can be implemented. Again, this is left to vendors. However, one more user agent has been specified with its fundamental services, the WTA user agent. This user agent handles access to, and interaction with, mobile telephone features (such as call control). As over time many vendor dependent user agents may develop, the standard defines a user agent profile (UAProf), which describes the capabilities of a user agent. Capabilities may be related to hardware or software.

Examples are: display size, operating system, browser version, processor, memory size, audio/video codec, or supported network types. The basic languages WML and WML Script , and the WTA will be described in the following three sections.

Wireless session protocol (WSP)

The wireless session protocol (WSP) has been designed to operate on top of the datagram service WDP or the transaction service WTP (WAP Forum, 2000e). For both types, security can be inserted using the WTLS security layer if required. WSP provides a shared state between a client and a server to optimize content transfer. HTTP, a protocol WSP tries to replace within the wireless domain, is stateless, which already causes many problems in fixed networks. Many web content providers therefore use cookies to store some state on a client machine, which is not an elegant solution. State is needed in web browsing, for example, to resume browsing in exactly the same context in which browsing has been suspended. This is an important feature for clients and servers. Client users can continue to work where they left the browser or when the network was interrupted, or users can get their customized environment every time they start the browser. Content providers can customize their pages to clients‘ needs and do not have to retransmit the same pages over and over again. WSP offers the following general features needed for content exchange between cooperating clients and servers:

● Session management: WSP introduces sessions that can be established from a client to a server and may be long lived. Sessions can also be released in an orderly manner. The capabilities of suspending and resuming a session are important to mobile applications. Assume a mobile device is being switched off – it would be useful for a user to be able to continue operation at exactly the point where the device was switched off. Session lifetime is independent of transport connection lifetime or continuous operation of a bearer network.

· Capability negotiation: Clients and servers can agree upon a common level of protocol functionality during session establishment. Example parameters to negotiate are maximum client SDU size, maximum outstanding requests, protocol options, and server SDU size.

c) Content encoding: WSP also defines the efficient binary encoding for the content it transfers. WSP offers content typing and composite objects, as explained for web browsing. While WSP is a general-purpose session protocol, WAP has specified the wireless session protocol/browsing (WSP/B) which comprises protocols and services most suited for browsing-type applications. In addition to the general features of WSP, WSP/B offers the following features adapted to web browsing:

d) HTTP/1.1 functionality: WSP/B supports the functions HTTP/1.1 offers, such as extensible request/reply methods, composite objects, and content type negotiation. WSP/B is a binary form of HTTP/1.1. HTTP/1.1 content headers are used to define content type, character set encoding, languages etc., but binary encodings are defined for well-known headers to reduce protocol overheads.

e) Exchange of session headers: Client and server can exchange request/reply headers that remain constant over the lifetime of the session. These headers may include content types, character sets, languages, device capabilities, and other static parameters. WSP/B will not interpret header information

but passes all headers directly to service users.

f)  Push and pull data transfer: Pulling data from a server is the traditional mechanism of the web. This is also supported by WSP/B using the request/response mechanism from HTTP/1.1. Additionally, WSP/B supports three push mechanisms for data transfer: a confirmed data push within an existing session context, a non-confirmed data push within an existing session context, and a non-confirmed data push without an existing session context.

g)                 Asynchronous requests: Optionally, WSP/B supports a client that can send multiple requests to a server simultaneously. This improves efficiency for the requests and replies can now be coalesced into fewer messages. Latency is also improved, as each result can be sent to the client as soon as it is available.

As already mentioned, WSP/B can run over the transaction service WTP or the datagram service WDP. The following shows several protocol sequences typical for session management, method invocation, and push services.

Wireless transaction protocol (WTP)

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.