WTA Architecture

Browsing the web using the WML browser is only one application for a handheld device user. Say a user still wants to make phone calls and access all the features of the mobile phone network as with a traditional mobile phone. This is where the wireless telephony application (WTA), the WTA user agent (as shown in Figure), and the wireless telephony application interface WTAI come in. WTA is a collection of telephony specific extensions for call and feature control mechanisms, merging data networks and voice networks.

The WTA framework integrates advanced telephony services using a consistent user interface (e.g., the WML browser) and allows network operators to increase accessibility for various special services in their network. A network operator can reach more end-devices using WTA because this is integrated in the wireless application environment (WAE) which handles device-specific characteristics and environments. WTA should enable third-party developers as well as network operators to create network-independent content that accesses the basic features of the bearer network. However, most of the WTA functionality is reserved for the network operators for security and stability reasons.

WTA extends the basic WAE application model in several ways:

● Content push: A WTA origin server can push content, i.e., WML decks or WMLScript, to the client. A push can take place without prior client request. The content can enable, e.g., the client to handle new network events that were unknown before. Access to telephony functions: The wireless telephony application interface (WTAI, WAP Forum, 2000m) provides many functions to handle telephony events (call accept, call setup, change of phone book entries etc.).

● Repository for event handlers: The repository represents a persistent storage on the client for content required to offer WTA services. Content are either channels or resources. Examples for resources are WML decks, WMLScript objects, or WBMP pictures. Resources are loaded using WSP or are pre-installed. A channel comprises references to resources and is associated with a lifetime. Within this lifetime, it is guaranteed that all resources the channel points to are locally available in the repository. The motivation behind the repository is the necessity to react very quickly for time-critical events (e.g., call accept). It would take too long to load content from a server for this purpose.

●  Security model: Mandatory for WTA is a security model as many frauds happen with wrong phone numbers or faked services. WTA allows the client to only connect to trustworthy gateways, which then have to check if the servers providing content are authorized to send this content to the client. Obviously, it is not easy to define trustworthy in this context. In the beginning, the network operator‟s gateway may be the only trusted gateway and the network operator may decide which servers are allowed to provide content. Figure 10.30 gives an overview of the WTA logical architecture.

The components shown are not all mandatory in this architecture; however, firewalls or other origin servers may be useful. A minimal configuration could be a single server from the network operator serving all clients. The client is connected via a mobile network with a WTA server, other telephone networks (e.g., fixed PSTN), and a WAP gateway. A WML user agent running on the client or on other user agents is not shown here.

The client may have voice and data connections over the mobile network. Other origin servers within the trusted domain may be connected via the WAP gateway. A firewall is useful to connect third-party origin servers outside the trusted domain. One difference between WTA servers and other servers besides security is the tighter control of QoS. A network operator knows (more or less precisely) the latency, reliability, and capacity of its mobile network and can have more control over the behavior of the services. Other servers, probably located in the internet, may not be able to give as good QoS guarantees as the network operator.

Similarly, the WTA user agent has a very rigid and real-time context management for browsing the web compared to the standard WML user agent. Figure shows an exemplary interaction between a WTA client, a WTA gateway, a WTA server, the mobile network (with probably many more servers) and a voice box server. Someone might leave a message on a voice box server as indicated. Without WAP, the network operator then typically generates an SMS indicating the new message on the voice box via a little symbol on the mobile phone. However, it is typically not indicated who left a message, what messages are stored etc. Users have to call the voice box to check and cannot choose a particular message. In a WAP scenario, the voice box can induce the WTA server to generate new content for pushing to the client. An example could be a WML deck containing a list of callers plus length and priority of the calls. The server does not push this deck immediately to the client, but sends a push message containing a single

URL to the client. A short note, e.g., ―5 new calls are stored", could accompany the push message. The WTA gateway translates the push URL into a service indication and codes it into a more compact binary format. The WTA user agent then indicates that new messages are stored. If the user wants to listen to the stored messages, he or she can request a list of the messages.

This is done with the help of the URL. A WSP get requests the content the URL points to. The gateway translates this WSP get into an HTTP get and the server responds with the prepared list of callers.

After displaying the content, the user can select a voice message from the list. Each voice message in this example has an associated URL, which can request a certain WML card from the server. The purpose of this card is to prepare the client for an incoming call. As soon as the client receives the card, it waits for the incoming call. The call is then automatically accepted. The WTA server also signals the voice box system to set up a (traditional) voice connection to play the selected voice message. Setting up the call and accepting the call is shown using dashed lines, as these are standard interactions from the mobile phone network, which are not controlled by WAP.

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.