Chapter 29

Mobile IP and Wireless Application Protocol (WAP)

29.1 Mobile IP Introduction 29.1.1 Operation of Mobile IP 29.1.12 Co-located address, 29.1.2 3 Registration, Tunnelling 29.1.4 Tunnelling 29.2 Wireless Application Protocol (WAP): Introduction and Architecture overview 29.2.1 WML scripts 29.2.2 WAP service 29.2.3 WAP session protocol 29.2.4 Wireless transaction 29.2.5 Wireless datagram protocol. 29.2.6 Connections 29.3 Application Layer 9 29.3.1 WAP Model 29.3.2 Mobile Location based services 29.3.2.1 WAP Gateway 29.3.2.2 WAP protocols 29.3.2.4 WAP user agent profile 29. 4 caching model-wireless bearers for WAP 29.5 WML WML Scripts 29.6 WTA 29.6.1 IMode 29.6.2 SyncML.

Chapter 29

Mobile IP and Wireless Application Protocol (WAP) 29.1 Mobile IP Introduction

Mobile IP is an open standard, defined by the Internet Engineering Task Force (IETF), which allows users to keep the same IP address, stay connected, and to maintain ongoing applications while roaming between IP networks. Mobile IP is scalable for the Internet because it is based on IP any media that can support IP can support Mobile IP. The number of wireless devices for voice or data is projected to surpass the number of fixed devices. Mobile data communication will likely emerge as the technology supporting most communication including voice and video. Mobile data communication will be persistent in cellular systems such as 3G and in wireless LAN, and will extend into satellite communication. Though mobility may be enabled by link-layer technologies, data crossing networks or different link layers is still a problem. The solution to this problem is a standards-based protocol, Mobile IP. In IP networks, routing is based on stationary IP addresses, similar to how a postal letter is delivered to the fixed address on the envelope. A device on a network is reachable through normal IP routing by the IP address it is assigned on the network. The problem occurs when a device roams away from its home network and is no longer reachable using normal IP routing. This results in the active sessions of the device being terminated. Mobile IP was created to enable users to keep the same IP address while traveling to a different network (which may even be on a different wireless operator), thus ensuring that a roaming individual could continue communication without sessions or connections being dropped.

29.1.1

Operation of Mobile IP

Mobile IP having the following functional entities:

o o

Mobile Node: This is the mobile device, the one moving around the internetwork. Home Agent(HA): This is a router on the home network that is responsible for catching datagrams intended for the mobile node and forwarding them to it when it is traveling. It also implements other support functions necessary to run the protocol.

Foreign Agent(FA): This is a router on the network to which the mobile node is currently attached. It serves as a home away from home for the mobile node, normally acting as its default router as well as implementing Mobile IP functions. Depending on the mode of operation, it may receive forwarded datagrams from the home agent and forward them to the mobile node. It also supports the sharing of mobility information to make Mobile IP operate. The foreign agent may not be required in some Mobile IP implementations but is usually considered part of how the protocol operates.

The topology of a Mobile IP system is shown in figure 29.1.

Fig. 29.1 Mobile IP topology In Mobile IP the following scenario shows how a datagram moves from one point to another point within the Mobile IP framework: 1. The Internet host sends a datagram to the mobile node by using the mobile node's home address (normal IP routing process). 2. If the mobile node is on its home network, the datagram is delivered through the normal IP process to the mobile node. Otherwise, the home agent receives the datagram. 3. If the mobile node is on a foreign network, the home agent forwards the datagram to the foreign agent. The home agent must encapsulate the datagram in an outer datagram so that the foreign agent's IP address appears in the outer IP header. 4. The foreign agent delivers the datagram to the mobile node. 5. Datagram from the mobile node to the Internet host are sent by using normal IP routing procedures. If the mobile node is on a foreign network, the packets are delivered to the foreign agent. The foreign agent forwards the datagram to the Internet host. 6. In situations with ingress filtering present, the source address must be topologically correct for the subnet that the datagram is coming from, or a router cannot forward the datagram. If this scenario exists on links between the mobile node and the correspondent node, the foreign agent needs to provide reverse tunneling support. Then, the foreign agent can deliver every datagram that the mobile node sends to its home agent. The home agent then forwards the datagram through the path that the datagram would have taken had the mobile node resided on the home network. This process guarantees that the source address is correct for all links that the datagram must traverse. 29.1.2 Mobile IP address types Co - located address

As most of us have only a single address used for our mail, most IP devices have only a single address. Our traveling consultant, however, needs to have two addresses; a normal one and one that is used while he is away. Mobile-IP-equipped notebook our consultant carries needs to have two addresses as well:
o

Home Address: The normal, permanent IP address assigned to the mobile node. This is the address used by the device on its home network, and the one to which datagrams intended for the mobile node are always sent. Care-Of Address: A secondary, temporary address used by a mobile node while it is 'traveling away from its home network. It is a normal 32-bit IP address in most respects, but is used only by Mobile IP for forwarding IP datagrams and for administrative functions. Higher layers never use it, nor do regular IP devices when creating datagrams.

Mobile IP Care-Of Address Types The care-of address is a slightly tricky concept. There are two different types, which correspond to two distinctly different methods of forwarding datagrams from the home agent router. Foreign Agent Care-Of Address This is a care-of address provided by a foreign agent in its Agent Advertisement message. It is, in fact, the IP address of the foreign agent itself. When this type of care-of address is used, all datagrams captured by the home agent are not relayed directly to the mobile node, but indirectly to the foreign agent, which is responsible for final delivery. Since in this arrangement the mobile node has no distinct IP address valid on the foreign network, this is typically done using a layer two technology. Co-Located Care-Of Address This is a care-of address assigned directly to the mobile node using some means external to Mobile IP. For example, it may be assigned on the foreign network manually, or automatically using DHCP. In this situation, the care-of address is used to forward traffic from the home agent directly to the mobile node. Mobile IP Functions An important difference between Mobile IP and our mail forwarding example is one that represents the classic distinction between people and computers: people are smart and computers are not. To this end, Mobile IP includes a host of special functions that are used to set up and manage datagram forwarding. To see how these support functions work, we can describe the general operation of Mobile IP as a simplified series of steps:
1. Agent Communication: The mobile node finds an agent on its local network by

engaging in the Agent Discovery process. It listens for Agent Advertisement messages sent out by agents and from this can determine where it is located. If it doesn't hear these messages it can ask for one using an Agent Solicitation message.

2. Network Location Determination: The mobile node determines whether it is on its

home network or a foreign one by looking at the information in the Agent Advertisement message. If it is on its home network it functions using regular IP. To show how the rest of the process works, let's say the device sees that it just moved to a foreign network. The remaining steps are:
3. Care-Of Address Acquisition: The device obtains a temporary address called a care-

of address. This either comes from the Agent Advertisement message from the foreign agent, or through some other means. This address is used only as the destination point for forwarding datagrams, and for no other purpose.
4. Agent Registration: The mobile node informs the home agent on its home network

of its presence on the foreign network and enables datagram forwarding, by registering with the home agent. This may be done either directly between the node and the home agent, or indirectly using the foreign agent as a conduit.
5. Datagram Forwarding: The home agent captures datagrams intended for the mobile

node and forwards them. It may send them either directly to the node or indirectly to the foreign agent for delivery, depending on the type of care-of address in use. Datagram forwarding continues until the current agent registration expires. The device can then renew it. If it moves again, it repeats the process to get a new care-of address and then registers its new location with the home agent. When the mobile node returns back to its home network, it deregisters to cancel datagram forwarding and resumes normal IP operation. Mobile IP Agent Discovery When a mobile node is first turned on, it cannot assume that it is still at home the way normal IP devices do. It must first determine where it is, and if it is not at home, begin the process of setting up datagram forwarding from its home network. This process is accomplished by communicating with a local router serving as an agent, through the process called agent discovery. Agent Discovery Process Agent discovery encompasses the first three steps in the simplified five-step Mobile IP operational summary I gave in the topic on general operation. The main goals of agent discovery include the following:
o

Agent/Node Communication: Agent discovery is the method by which a mobile node first establishes contact with an agent on the local network to which it is attached. Messages are sent from the agent to the node containing important information about the agent; a message can also be sent from the node to the agent asking for this information to be sent. Orientation: The node uses the agent discovery process to determine where it is. Specifically, it learns whether it is on its home network or a foreign network by identifying the agent that sends it messages.

Care-Of Address Assignment: The agent discovery process is the method used to tell a mobile node the care-of address it should use, when foreign agent care-of addressing is used.

Mobile IP agents are routers that have been given additional programming to make them Mobile IP aware. The communication between a mobile node and the agent on its local network is basically the same as the normal communication required between a device on an IP network and its local router, except more information needs to be sent when the router is an agent. 29.1.3 Mobile IP Home Agent Registration and Registration Messages Once a mobile node has completed agent discovery, it knows whether it is on its home network or a foreign network. If on its home network it communicates as a regular IP device, but if on a foreign network it must activate Mobile IP. This requires that it communicate with its home agent so information and instructions can be exchanged between the two. This process is called home agent registration, or more simply, just registration. The main purpose of registration is to actually start Mobile IP working. The mobile node must contact the home agent and tell it that it is on a foreign network and request that datagram forwarding be turned on. It also must let the home agent know its care-of address so the home agent knows where to send the forwarded datagrams. The home agent in turn needs to communicate various types of information back to the mobile node when registration is performed. Note that the foreign agent is not really involved in registration, except perhaps to relay messages, as we will see.

Figure 29.2 Mobile IP home agent registration Mobile Node Registration Events Successful registration establishes what is called in the standard a mobility binding between a home agent and a mobile node. For the duration of the registration, the mobile node's regular home address is tied to its current care-of address and the home agent will encapsulate and

forward datagrams addressed to the home address over to the care-of address. The mobile node is supposed to manage its registration and handle various events using several actions:
o

Registration: The mobile node initiates a registration when it first detects it has moved from its home network to a foreign network. Deregistration: When the mobile node returns home, it should tell the home agent to cancel forwarding, a process called deregistration. Reregistration: If the mobile node moves from one foreign network to another, or if its care-of address changes, it must update its registration with the home agent. It also must do so if its current registration is about to expire, even if it remains stationary on one foreign network.

Each registration is established only for a specific length of time, which is why regular reregistration is required whether the device moves or not. Registrations are time-limited to ensure that they do not become stale. If, for example, a node forgets to de-register when it returns home, the datagram forwarding will eventually stop when the registration expires. New Registration Request and Registration Reply Messages To perform registration, two new message types have been defined in Mobile IP: the Registration Request and the Registration Reply. Each of these does what you would expect from its name. Interestingly, these are not ICMP messages like the ones used in agent discovery; they are User Datagram Protocol (UDP) messages. Thus, technically speaking, registration is performed at a higher layer than the rest of Mobile IP communication. Agents listen for Registration Requests on well-known UDP port #434, and respond back to mobile nodes using whatever ephemeral port the node used to send the message. Registration Procedures There are two different procedures defined for registration, depending on the type of care-of address used by the mobile node and other specifics we will get into shortly. The first is the direct registration method, which has just two steps:
1. Mobile node sends Registration Request to home agent. 2. Home agent sends Registration Reply back to mobile node.

In some cases, however, a slightly more complex process is required, where the foreign agent conveys messages between the home agent and the mobile node. In this situation, the process has four steps : and is shown in fig 29.3
1. Mobile node sends Registration Request to foreign agent. 2. Foreign agent processes Registration Request and forwards to home agent. 3. Home agent sends Registration Reply to foreign agent. 4. Foreign agent processes Registration Reply and sends back to mobile node.

Figure 29.3 Mobile IP registration process The first, simpler method is normally used when a mobile node is using a co-located care-of address. In that situation, the node can easily communicate directly with the home agent, and the mobile node is also set up to directly receive information and datagrams from the home agent. When there is no foreign agent, this is obviously the method that must be used. It is also obviously the method used when a mobile node is de-registering with its home agent after it arrives back on the home network. The second method is required when a mobile node is using a foreign care-of address. Recall that in this situation, the mobile node doesn't have its own unique IP address at all; it is using a shared address given it by the foreign agent, which precludes direct communication between the node and the home agent. Also, if a mobile node receives an Agent Advertisement with the R flag set, it also should go through the foreign agent, even if it has a co-located care-of address. Note that the foreign agent really is just a middleman; the exchange is still really between the home agent and the mobile node. However, the foreign agent can deny registrations if the request violates whatever rules are in place for using the foreign network. It is for this reason that some foreign agents may require that they be the conduit for registrations even if the mobile node has a co-located care-of address. Of course, if the foreign agent can't contact the home agent the registration will not be able to proceed. The description above is really a highly simplified explanation of the basics of registration. The Mobile IP standard specifies many more details on exactly how agents and nodes perform registration, including particulars on when requests and replies are sent, how to handle various special conditions such as invalid requests, rules for how home agents maintain a table of mobility bindings, and much more. The standard covers the definition of extensions to the regular registration messages to support authentication, which is required for secure communications (see the topic on security issues for more details). It also includes the ability to have a mobile node maintain more than one concurrent binding, when needed.

29.2.5 Mobile

IP

Data

Encapsulation

Once a mobile node on a foreign network has completed a successful registration with its home agent, the Mobile IP datagram forwarding process described in the general operation topic will be fully activated. The home agent will intercept datagrams intended for the mobile node as they are routed to its home network, and forward them to the mobile node. This is done by encapsulating the datagrams and then sending them to the node's care-of address. Mobile IP Data Encapsulation Techniques Encapsulation is required because each datagram we intercept and forward needs to be resent over the network to the device's care-of address. In theory, the designers might conceivably have done this by just having the home agent change the destination address and stick it back out on the network, but there are various complications that make this unwise. It makes more sense to take the entire datagram and wrap it in a new set of headers before retransmitting. In our mail analogy, this is comparable to taking a letter received for our traveling consultant and putting it into a fresh envelope for forwarding, as opposed to just crossing off the original address and putting a new one on. The default encapsulation process used in Mobile IP is called IP Encapsulation Within IP, defined in RFC 2003 and commonly abbreviated IP-in-IP. It is a relatively simple method that describes how to take an IP datagram and make it the payload of another IP datagram. In Mobile IP, the new headers specify how to send the encapsulated datagram to the mobile node's care-of address. In addition to IP-in-IP, two other encapsulation methods may be optionally used: Minimal Encapsulation Within IP, defined in RFC 2004, and Generic Routing Encapsulation (GRE), defined in RFC 1701. To use either of these, the mobile node must request the appropriate method in its Registration Request and the home agent must agree to use it. If foreign agent care-of addressing is used, the foreign agent also must support the method desired. 29.2.6 The Mobile IP Data Tunnelling The encapsulation process creates a logical construct called a tunnel between the device that encapsulates and the one that decapsulates. This is the same idea of a tunnel used in discussions of virtual private networks (VPNs), IPSec tunnel mode, or the various other tunneling protocols used for security. The tunnel represents a medium over which datagrams are forwarded across an arbitrary internetwork, with the details of the encapsulated datagram (meaning the original IP headers) temporarily hidden.

Figure 29.4 Mobile IP tunneling In Mobile IP, the start of the tunnel is the home agent, which does the encapsulation. The end of the tunnel depends on what sort of care-of address is being used:
o

Foreign Agent Care-Of Address: The foreign agent is the end of the tunnel. It receives encapsulated messages from the home agent, strips off the outer IP header and then delivers the datagram to the mobile node. This is generally done using layer two, because the mobile node and foreign agent are on the same local network, and of course, the mobile node does not have its own IP address on that network (it is using that of the foreign agent.) Co-Located Care-Of Address: The mobile node itself is the end of the tunnel and strips off the outer header.

29.2.6.1 Mobile IP Conventional Tunneling Normally, the tunnel described above is used only for datagrams that have been sent to the mobile node and captured by the home agent. When the mobile nodes wants to send a datagram, it doesn't tunnel it back to the home agent; this would be needlessly inefficient. Instead it just sends out the datagram directly using whatever router it can find on its current network, which may or may not be a foreign agent. When it does this, it uses its own home address as the source address for any requests it sends. As a result, any response to those requests will go back to the home network. This sets up a triangle of sorts for these kinds of transactions: 1. The mobile node sends a request from the foreign network to some third party device somewhere on the internetwork. 2. The third party device responds back to the mobile node. However, this sends the reply back to the mobile node's home address on its home network. 3. The home agent intercepts the response on the home network and tunnels it back to the mobile node.

This process is illustrated in Figure 134. The reverse transaction would be pretty much the same, just in the reverse order. In that case the third party (Internet) device would send a request to mobile node, which would be received and forwarded by the home agent. The mobile node would reply back directly to the Internet host. .29.2.6.2 Mobile IP Reverse Tunneling There may be situations where it is not feasible or desired to have the mobile node send datagrams directly to the internetwork using a router on the foreign network as we just saw. In this case, an optional feature called reverse tunneling may be deployed, if it is supported by the mobile node, the home agent and if relevant, the foreign agent. When this is done, a reverse tunnel to complement the normal one is set up between the mobile node and the home agent, or between the foreign agent and the home agent, depending on care-of address type. All transmissions from the mobile node are tunneled back to the home network where the home agent transmits them over the internetwork, resulting in a more symmetric operation rather than the triangle just described. This is basically what I described earlier as being needlessly inefficient, because it means each communication requires four steps. Thus, it is used only when necessary. One situation where reverse tunneling may be required is if the network where the mobile node is located has implemented certain security measures that prohibit the node from sending datagrams using its normal IP address. In particular, a network may be set up to disallow outgoing datagrams with a source address that doesnt match its network prefix. This is often done to prevent spoofing (impersonating anothers IP address.) 29.2.7 Mobile IP Security Considerations In many situations, mobile computers use wireless links to connect to the network. Wireless links are particularly vulnerable to passive eavesdropping, active replay attacks, and other active attacks. Because Mobile IP recognizes its inability to reduce or eliminate this vulnerability, Mobile IP uses a form of authentication to protect Mobile IP registration messages from these types of attack. The default algorithm that is used is MD5, with a key size of 128 bits. The default operational mode requires that this 128-bit key precede and succeed the data to be hashed. The foreign agent uses MD5 to support authentication. The foreign agent also uses key sizes of 128 bits or greater, with manual key distribution. Mobile IP can support more authentication algorithms, algorithm modes, key distribution methods, and key sizes. These methods do prevent Mobile IP registration messages from being altered. However, Mobile IP also uses a form of replay protection to alert Mobile IP entities when they receive duplicates of previous Mobile IP registration messages. If this protection method were not used, the mobile node and its home agent might become unsynchronized when either of them receives a registration message. Hence, Mobile IP updates its state. For example, a home agent receives a duplicate deregistration message while the mobile node is registered through a foreign agent. Replay protection is ensured either by a method known as nonces, or timestamps. Nonces and timestamps are exchanged by home agents and mobile nodes within the Mobile IP registration messages. Nonces and timestamps are protected from change by an authentication mechanism. Consequently, if a home agent or mobile node receives a duplicate message, the duplicate message can be thrown away.

The use of tunnels can be a significant vulnerability, especially if registration is not authenticated. Also, the Address Resolution Protocol (ARP) is not authenticated, and can potentially be used to steal another host's traffic. 29.3 Wireless Application Protocol overview Architecture and overview

Another open standard providing mobile users of wireless terminals access to telephony and information services is Wireless Application Protocol (WAP). The name "Wireless Application Protocol" (WAP) is misleading. WAP is not actually a protocol at all, in the sense that HTTP and IP are protocols. In fact, WAP involves multiple protocols and complete network architecture for delivery of wireless content. WAP specifies architecture based on layers that follow the OSI model fairly closely. Designed to work with all wireless network technologies such as GSM, CDMA, and TDMA. The wireless industry hopes that WAP devices will become popular for ecommerce applications like online banking. In the short term, it is more likely that useful WAP applications will simply extend the functions of telephone and allow us to answer a phone message with an email, for example. The early WAP applications have featured news feeds, stock quotes, and weather forecasts. Significant backlash against the hype and optimism surrounding WAP has certainly occurred as a result of the uncertainly about its future. In this chapter first we discuss the main components of a Mobile IP, co-located address and the concept of tunnelling. Then we focus the WAP architecture, the basic WAP model and different cache models for WAP.

The Wireless Application Protocol (WAP) is a universal, open standard developed by the WAP Forum to provide mobile users of wireless phones and other wireless terminals such as pagers and personal digital assistants (PDAs) access to telephony and information services, including the Internet and the Web. WAP is designed to work with all wireless network technologies (e.g., GSM, CDMA, andTDMA).WAP is based on existing Internet standards, such as IP, XML, HTML, and HTTPp, as much as possible. It also includes security facilities. Ericsson, Motorola, Nokia, and Phone.com established the WAP Forum in 1997, which now has several hundred members. At the time of this writing, the current release of the WAP specification is version 2.0. Strongly affecting tThe use of mobile phones and terminals for data services are the significant limitations of the devices and the networks that connect them. The devices have limited processors, memory, and battery life. The user interface is also limited, and the displays small. The wireless networks are characterized by relatively low bandwidth, high latency, and unpredictable availability and stability compared to wired connections. Moreover, all these features vary widely from terminal device to terminal device and from network to network. Finally, mobile, wireless users have different expectations and needs from other information systems users. For instance, mobile terminals must be extremely easy to use, much easier than workstations and personal computers. WAP is designed to deal with these challenges. The WAP specification includes

A programming model based on the WWW Programming Model A markup language, the Wireless Markup Language, adhering to XML A specification of a small browser suitable for a mobile, wireless terminal A lightweight communications protocol stack A framework for wireless telephony applications (WTAs)

29.3.1 WAP protocol stack architecture WAP is designed in a layered fashion so that it can be extensible, flexible, and scalable. As a result, tThe WAP protocol stack is divided into five layers.: The WAP protocol architecture is shown in figure 29.5 alongside a typical Internet Protocol stack. Application Layer Wireless Application Environment (WAE). This layer is of most interest to content developers because it contains, among other things, device specifications and the content development programming languages, WML and WML Script. Session Layer Wireless Session Protocol (WSP). Unlike HTTP, WSP has been designed by the WAP Forum to provide fast connection suspension and reconnection. Transaction Layer Wireless Transaction Protocol (WTP). The WTP runs on top of a datagram service such as User Datagram Protocol (UDP) and is part of the standard suite of TCP/IP protocols used to provide a simplified protocol suitable for low bandwidth wireless stations. Security Layer Wireless Transport Layer Security (WTLS). WTLS incorporates security features that are based upon the established Transport Layer Security (TLS) protocol standard. It includes data integrity checks, privacy, service denial, and authentication services. Transport Layer Wireless Datagram Protocol (WDP). The WDP allows WAP to be bearer-independent by adapting the transport layer of the underlying bearer. The WDP presents a consistent data format to the higher layers of the WAP protocol stack, thereby offering the advantage of bearer independence to application developers.

Each of these layers provides a well-defined interface to the layer above it. This means that the internal workings of any layer are transparent or invisible to the layers above it. The layered architecture allows other applications and services to utilize the features provided by the WAP-stack as well. This makes it possible to use the WAP-stack for services and applications that currently are not specified by WAP. The WAP protocol architecture is shown in figure alongside a typical Internet Protocol stack.

Figure 29.5 WAP protocol architecture 29.3.2 Wireless Application Environment (WAE) The uppermost layer in the WAP stack, the Wireless Application Environment (WAE) provides an environment that enables a wide range of applications to be used on wireless devices.

Addressing model: Syntax suitable for naming resources stored on servers. WAP use the same addressing model as the one used on the Internet, that is, Uniform Resource Locators (URL). Wireless Markup Language (WML): A lightweight markup language designed to meet the constraints of a wireless environment with low bandwidth and small handheld devices. The Wireless Markup Language is WAP.s analogy to HTML used on the WWW. WML is based on the Extensible Markup Language (XML). WML Script: A lightweight scripting language. WML Script is based on ECMA Script, the same scripting language that JavaScript is based on. It can be used for enhancing services written in WML in the way that it to some extent adds intelligence to the services, for example procedural logic, loops, conditional expressions, and computational functions. Wireless Telephony Application (WTA, WTAI): A framework and programming interface for telephony services. The Wireless Telephony Application (WTA) environment provides a means to create telephony services using WAP.

WML Scripts WML Script (Wireless Markup Language Script) is the client-side scripting language of WML (Wireless Markup Language). A scripting language is similar to a programming language, but is of lighter weight. With WML Script, the wireless device can do some of the

processing and computation. This reduces the number of requests and responses to/from the server. WML Script Components: WML Script is very similar to Java Script. Almost WML Script components have similar meaning as they have in Java Script. WML Script program components are summarized as follows: WML Script Operators: WML Script supports following type of operators. Arithmetic Operators Comparison Operators Logical (or Relational) Operators Assignment Operators Conditional (or ternary) Operators WML Script Control Statements: Control statements are used for controlling the sequence and iterations in a program. Statement Description if-else for while break continue Conditional branching Making self-incremented fixed iteration loop Making variable iteration loop Terminates a loop Quit the current iteration of a loop

WML Script Functions: The user-defined functions are declared in a separate file having the extension .wmls. Functions are declared as follows: function name (parameters) { control statements; return var; } The functions used are stored in a separate file with the extension .wmls. The functions are called as the filename followed by a hash, followed by the function name. Example: maths.wmls#squar() In the example, maths.wmls is the file name and squar() is the function name.

29.3.2.1 WML Scripts Standard Libraries: There are six standard libraries totally. Here is an overview of them: Lang: The Lang library provides functions related to the WMLScript language core. Example Function: abs(),abort(), characterSet(),float(), isFloat(), isInt(), max(), isMax(), min(), minInt(), maxInt(), parseFloat(), parseInt(), random(), seed() Float: The Float library contains functions that help us perform floating-point arithmeticoperations. Example Function: sqrt(), round(), pow(), ceil(), floor(), int(), maxFloat(), minFloat() String: The String library provides a number of functions that help us manipulate strings. Example Function: length(), charAt(), find(), replace(), trim(), compare(), format(), isEmpty(), squeeze(), toString(), elementAt(), elements(), insertAt(), removeAt(), replaceAt() URL: The URL library contains functions that help us manipulate URLs. Example Function: getPath(), getReferer(), getHost(), getBase(), escapeString(), isValid(), loadString(), resolve(), unescapeString(), getFragment() WMLBrowser: The WMLBrowser library provides a group of functions to control the WML browser or to get information from it. Example Function: go(), prev(), next(), getCurrentCard(), refresh(), getVar(), setVar() Dialogs: The Dialogs library contains the user interface functions. Example Function: prompt(), confirm(), alert() 29.3.3 Wireless Session Protocol The Wireless Session Protocol (WSP), a protocol in the Wireless Application Protocol (WAP) suite, provides the Wireless Application Environment a consistent interface with two services: 1. Connection-mode session services over a transaction service, to operate above the Transaction Layer Protocol .This mode will be used for long-lived connections. A session state is maintained. There is reliability for data sent over a connection-mode session. 2. Non-confirmed, connection-less services over a datagram transport service, which operates above secure or non secure datagram service. This service is suitable when applications do not need reliable delivery of data and do not are about confirmation. It can be used without actually having established a session. connection-oriented service to operate above the Transaction Layer Protocol (WTP) and a connectionless service that operates above either secure or non-secure datagram service (WDP). Basic functionality Currently the protocols of the WSP family provide HTTP/1.1 functionality and semantics in a compact encoding, long lived session state with session suspend and resume capabilities, a common facility for reliable and unreliable data push as well as a protocol feature negotiation. These protocols are optimized to be used in low-bandwidth bearer networks with relative long latency in order to connect a WAP client to a HTTP server.

WSP is part of a system offering web capabilities to cell phones. The protocol offers connection-oriented services that are lacking in the Transport Layer of the WAP protocol stack. Each session is given an ID so that several sessions can be maintained between the same client and server without data being muddled between sessions. Unlike most session management protocols, WSP allows a session to be suspended and resumed in the same place. This functionality requires the server to mark a save point in the session activities. WSP has a long timeout delay to account for typical long waits in establishing connections over low-bandwidth networks. WSP communications are carried out over Hypertext Transfer Protocol (HTTP). Messaging is text-based and negotiates allowable HTTP extensions for the session at the point of session establishment. 29.3.4 Wireless Transaction Protocol The Wireless Transaction Protocol (WTP), a protocol in the Wireless Application Protocol (WAP) suite, operates efficiently over either secure or non-secure wireless datagram networks. It provides three different kinds of transaction services, namely, unreliable oneway, reliable one-way and reliable two-way transactions. This layer also includes optional user-to-user reliability by triggering the confirmation of each received message. To reduce the number of messages sent, the feature of delaying acknowledgements can be used. WTP manages transactions by conveying requests and responses between a user agent (such as a WAP browser) and an application server for such activities as browsing and e-commerce transactions. WTP provides a reliable transport service but dispenses with much of the overhead of TCP, resulting in a lightweight protocol that is suitable for implementation in "thin" clients (e.g., mobile nodes) and suitable for use over low-bandwidth wireless links. WTP includes the following features: Three classes of transaction service. Optional user-to-user reliability: WTP user triggers the confirmation of each received message. Optional out-of-band data on acknowledgments. PDU concatenation and delayed acknowledgment to reduce the number of messages sent. Asynchronous transactions. WTP is transaction oriented rather than connection oriented. With WTP, there is no explicit connection setup or teardown but rather a reliable connectionless service. WTP Transaction Classes WTP provides three transaction classes that may be invoked by WSP or another higher layer protocol: Class 0: Unreliable invoke message with no result message Class 1: Reliable invoke message with no result message Class 2: Unreliable invoke message with one reliable result message

Class 0 provides an unreliable datagram service, which can be used for an unreliable push operation. Data from a WTP user are encapsulated by WTP (the initiator, or client) in an Invoke PDU and transmitted to the target WTP (the responder, or server), with no acknowledgment. The responder WTP delivers the data to the target WTP user. Class 1 provides a reliable datagram service, which can be used for a reliable push operation. Data from an initiator are encapsulated in an Invoke PDU and transmitted to the responder. The responder delivers the data to the target WTP user and acknowledges receipt of the data by sending back an ACK PDU to the WTP entity on the initiator side, which confirms the transaction to the source WTP user. The responder WTP maintains state information for some time after the ACK has been sent to handle possible retransmission of the ACK if it gets lost and/or the initiator retransmits the Invoke PDU. Class 2 provides a request/response transaction service and supports the execution of multiple transactions during one WSP session. Data from an initiator are encapsulated in an Invoke PDU and transmitted to the responder, which delivers the data to the target WTP user. The target WTP user prepares response data, which are handed down to the local WTP entity. The responder WTP entity sends these data back in a result PDU If there is a delay in generating the response data beyond a timer threshold, the responder may send an ACK PDU before sending the result PDU. This prevents the initiator from unnecessarily retransmitting the Invoke message. 29.3.5 Wireless Transport Layer Security (WTLS) Many applications on the Web today require a secure connection between a client and the application server. WTLS is the security protocol to ensure secure transactions on WAP terminal. WTLS is based upon the industry standard Transport Layer Security (TLS) protocol, formerly known as Secure Socket Layer (SSL). WTLS has been optimized for use over narrow-band communication channels. It ensures data integrity, privacy, authentication, and denial-of-service protection. For Web applications, that employ standard Internet security techniques with TLS, the WAP gateway automatically and transparently manages wireless security with minimal overhead. It provides end-to-end security and application-level security. This includes security facilities for en-/decrypting, strong authentication, integrity, and key management. WTLS complies with regulations on the use of cryptographic algorithms and key lengths in different countries. The primary goal is to provide security between client and server in terms of: Privacy Data sent is not presented in clear text to make it difficult for another network user to look at the data. This is done through encrypting the data stream. Data integrity If a network user where able to change the sent data, it should be detected by the client or server that sent the data. This is done through message digests. Authentication A network partner can be sure that he or she is connected with the true desired partner and not with someone else who pretends to be it. This is done through digital certificates. Denial of service Rejecting and detecting data that is not successfully verified. This is done through a WTLS function.

Figure 207 the location of WTLS in the WAP architecture model and the internal WTLS architecture with its different WTLS protocols

Figure 29.6 WTLS architecture Record protocol The record protocol is the interface to the upper layer (transaction or session layer) and to the lower layer (transport layer). The record protocol receives messages from the upper layer to be transmitted. It optionally compresses the data, applies a message authentication code (MAC), and encrypts and transmits the message. Received data is decrypted, verified, decompressed, and delivered to a higher layer of the client. Four protocols are defined that cooperate very closely with the record protocol in a client implementation environment: Handshake protocol This protocol consists of three sub-protocols that allow peers to agree to security parameters for the record layer. The handshake protocol is responsible for the negotiation process between the client and server. Change cipher spec protocol The change cipher spec is sent by the client or server to notify the other partner that subsequent records will be sent under the newly negotiated cipher spec and keys. This message is sent during the handshake after the security parameters have been agreed upon, but before the verifying finished message is sent. Alert protocol Alert messages contain information about the severity of the message and a description of the alert. Messages of a fatal level may terminate the secure connection. User data protocol Consist of the payload which the WAP client intends to send.

29.3.6 Wireless Datagram Protocol

The Wireless Datagram Protocol (WDP), a protocol in WAP architecture, covers the Transmission Layer Protocols in an Internet model. As a general transport service, WDP offers to the upper layers an invisible interface independent of the underlying network technology used. In consequence of the interface common to transport protocols, the upper layer protocols of the WAP architecture can operate independent of the underlying wireless network. By letting only the transport layer deal with physical network-

dependent issues, global interoperability can be acquired using mediating gateways. WDP architecture is shown in figure.29.7

Figure 29.7 Wireless Datagram Protocol WDP offers a consistent service at the Transport Service Access Point to the upper layer protocol of WAP. This consistency of service allows for applications to operate transparently over different available bearer services. The varying heights of each of the bearer services shown in Figure 4-2 illustrates the difference in functions provided by the bearers and thus the difference in WDP protocol necessary to operate over those bearers to maintain the same service offering at the Transport Service Access Point is accomplished by a bearer adaptation. WDP can be mapped onto different bearers, with different characteristics. In order to optimise optimize the protocol with respect to memory usage and radio transmission efficiency, the protocol performance over each bearer may vary. However, the WDP service and service primitives will remain the same, providing a consistent interface to the higher layers. The WDP layer operates above the data capable bearer services supported by the various network types. As a general datagram service, WDP offers a consistent service to the upper layer protocol (Security, Transaction and Session) of WAP and communicate transparently over one of the available bearer services. WDP supports several simultaneous communication instances from a higher layer over a single underlying WDP bearer service. The port number identifies the higher layer entity above WDP. This may be another protocol layer such as the Wireless Transaction Protocol (WTP) or the Wireless Session Protocol (WSP) or an application such as electronic mail. By reusing the elements of the underlying bearers, WDP can be implemented to support multiple bearers and yet be optimized for efficient operation within the limited resources of a mobile device. 29.3.7 Overview of the WAP programming model The WAP programming model illustrated in Figure 29.8 describes: The WAP client (the handheld device or WAP terminal) The WAP gateway The Web server

Figure 29.8 WAP programming model

29.3.7.1 WAP client The client, also known as wireless application environment (WAE) user agent is a component of the WAP terminal. It consists of a micro browser and the WAP protocol stack in order to handle the execution of all requests and responses going through the WAP layered structure. For example this includes: Session establishment Data transport connection-less or connection-oriented Setting up a secure environment including: - Applying encryption and authentication - Encoding of outgoing requests Decoding of incoming responses to minimize bandwidth 29.3.7.2 WAP Gateway The gateway works as a WAP proxy. It receives requests from the client, transforms an HTTP message, and sends it (based on the Uniform Resource Locator (URL)) to the addressed Web server. When the Web server returns the response, the gateway transforms it again into a bit-coded output. It then sends it to the mobile network, which directs it to the WAP client. This method allows the data content and applications to be hosted in standard Web servers using traditional Web technology. The WAP gateway is also able to work as a WAP application server (see Figure 193 on page 486). This solution does not need a Web server. It can be used to support end-to-end security configurations. This could be for applications which require higher access control or a guarantee of service, like those used for Wireless Telephony Application (WTA) (see 14.5.2, Wireless Telephony Application (WTA) on page 498). The WAP gateway decreases the response time to the WAP terminal by aggregating data from different Web servers and caching frequently used information. It also divides large HTTP responses into smaller transmission units before sending the responses to the client. The WAP gateway can also interface with subscriber databases and use information to dynamically customize WML pages for a certain group of users. The WAP gateway provides transition between the Internet and different non-voice mobile services. These might be services such as Short Message Services (SMS), Circuit Switched Data (CSD), or General Packet Radio Services (GPRS).

Usage of a WAP gateway This type of configuration, illustrated in Figure 192, consists of two connections: The first connection is between the client and a WAP gateway. The second connection is between the WAP gateway and the Web server. While the first connection uses the Wireless Session Protocol (WSP) and the Wireless Transaction Protocol (WTP), the second connection uses the traditional Hypertext Transfer Protocol (HTTP), which runs above TCP. The proxy gateway maintains the two connections as one logical connection between the client and the Web server.

29.9 usage of a WAP gateway Client-server flow The client-server flow is as follows:
1. A client asking for a particular service from an origin server submits a request to this

server using the WML user agent (refer to Figure 198 on page 497).
2. The WML user agent uses the URL addressing scheme operation to find the origin

server. URLs are used to address applications on a Web server, for example, a Common Gateway Interface (CGI).1
3. The clients request is transmitted to the gateway using WSP/WTP. 4. The gateway does the bit-encoding, transforms the request into an HTTP message,

and sends it to the Web server (addressed by the URL).

5. The origin server replies to the request by returning a single deck (refer to 14.3.1,

WML on page 486), if it is stored in textual format in the origin server. 6. The deck is transmitted to the gateway.
7. On its way through the gateway, the textual format of each deck has to be onverted

into a format that is better suited for over-the-air transmission to WAP terminals. This conversion is done by the gateway using the WML encoder to convert the textual format into a binary format.
8. The gateway sends the encoded content to the client via the WAP protocol stack

layers (refer to Figure 197 on page 496) over the wireless network.
9. At the clients WAP terminal, the data is received and can be displayed and

interpreted, for example, by a microbrowser. 29.3.7.3 Origin server The client's microbrowser requests Wireless Markup Language (WML) pages. These WML pages are stored on the origin server, which might be a Web server, connected via the Internet or intranet. WML pages may also be stored in an application server installed in the gateway itself. A WML page consists of a WML deck. One WML deck is divided into one or more WML cards. A WML card can be regarded as a unit of interaction. Services let the user navigate back and forth between cards from one or several WML pages. WML, especially designed for WAP terminals, provides a smaller set of markup tags than HTML. It is based on HTTP 1.1. WML decks may also contain WMLScripts, another way of coding Web pages. 29.3.8 WAP user agent profile Existing mark-up languages and content written in those mark-up languages presume that devices have similar display sizes, memory capacities, and software capabilities. Content is also largely oblivious to the available network bandwidth and perceived network latency. Moreover, users may have content presentation preferences that also cannot be transferred to the server for consideration. Recently, work has begun within the World-Wide Web Consortium (W3C) to define mechanisms for describing and transmitting information about the capabilities of Web clients and the display preferences of Web users. The Composite Capabilities/Preferences Profile (CC/PP) note defines a high-level structured framework for describing this information using the Resource Description Framework (RDF). CC/PP profiles are structured into named components, each containing a collection of attribute-value pairs, or properties. Each component may optionally provide a default description block containing either a set of default values for attributes of that component or a URI that refers to a document containing those default values. End-to-End Architecture of User Agent Profile

This specification provides for the end-to-end specification, delivery, and processing of composite capability information from the device. The information is collected on the client device, encoded into an efficient binary form, transmitted and cached within a WSP session, optionally enhanced with information provided with a particular request, optionally combined with other information available over the network, and made available to the origin server. Over the Internet, this specification assumes the use of the CC/PP, CC/PP Exchange Protocol over HTTP, and HTTP with the HTTP Extension Framework.

Figure 29.10 User Agent Profile End-to-End System The end-to-end system consists of five logical components: A client device capable of requesting and rendering WAP content. A wireless network employing WAP 1.1 or later protocols. A WAP-capable gateway capable of translating WAP protocol requests into corresponding requests over the Internet and translating responses from the Internet into corresponding responses over the WAP protocols. The Internet or an intranet using TCP/IP-based protocols and possibly having one or more protocol gateways and Web/HTTP proxies. An origin (Web) server that can generate requested content. Though this specification refers to five end-to-end system components, actual configurations may physically deploy those components in many forms. For example, the latter three components (WAP gateway, Internet/intranet, and origin server) might easily be merged into a single server-side system connected to the WAP network. Moreover, the WAP gateway may itself be distributed, with different hosts serving as endpoints for different layers of the WAP protocol stack. 29.3.9 Wireless Telephony Application (WTA) The WAP WTAI features provide the means to create Telephony Applications, using a WTA user-agent with the appropriate WTAI function libraries. A typical example is to set-up a

mobile originated call using the WTAI functions accessible from either a WML deck/card or WML Script. The application model for WTA is based on a WTA User-agent, executing WML and WML Script. The WTA user-agent uses the WTAI function libraries to make function calls related to network services. The WTA user-agent is able to receive WTA events from the mobile network and pushed content, like WML decks and WTA events, from the WTA server. WTA events and WTAI functions make it possible to interact and handle resources, for call control etc., in the mobile network. The WTA server can invoke applications dynamically using content push with WML and WML Script. WTA provides tools for building telephony applications. It is primarily designed for network operators, carriers, and equipment vendors. Network security and reliability is a major consideration. Extensions are added to the standard WML/WML Script browser to support an additional WTA Application Programming Interface (WTAI). WTAI includes the following functions: call control, network text messaging, phone book interface, indicator control, and event processing.

29.11 WTA Architecture Location Based Service (LBS) In this age of significant telecommunications competition, mobile network operators continuously seek new and innovative ways to create differentiation and increase profits. One of the best ways to do accomplish this is through the delivery of highly personalized services. One of the most powerful ways to personalize mobile services is based on location. One of the most obvious technologies behind LBS is positioning, with the most widely recognized system being the Global Positioning System (GPS). There are however, other means of positioning in addition to GPS. These other technologies are network based positioning and typically rely on various means of triangulation of the signal from cell sites serving a mobile phone. In addition, the serving cell site can be used as a fix for location of the user. Geographic data is an important aspect of any location system. Geographic Information Systems (GIS) provide the tools to provision and administer base map data such as man made structures (streets, buildings) and terrain (mountains, rivers). GIS is also used to manage point-of-interest data such as location of gas stations, restaurants, nightclubs, etc. Finally, GIS information also includes information about the radio frequency characteristics of the mobile network. This allows the system to determine the serving cell site of the user. It is not

enough to be able to position the mobile user and know the map data around that position. There must be a location management function to process positioning and GIS data on behalf of LBS applications. The location management function acts as a gateway and mediator between positioning equipment and LBS infrastructure. LBS Services

Location based information Many people are familiar with wireless Internet, but many don't realize the value and potential to make information services highly personalized. One of the best ways to personalize information services is to enable them to be location based. An example would be someone using their Wireless Application Protocol (WAP) based phone to search for a restaurant. The LBS application would interact with other location technology components to determine the user's location and provide a list of restaurants within a certain proximity to the mobile user. Location based billing The ability to have preferential billing is provided by this type of application. Through location based billing, the user can establish personal zones such as a home zone or work zone. Through arrangements with the serving wireless carrier, the user could perhaps enjoy flat-rate calling while in the home area and special rates while in other defined zones. This type of application can be especially useful when use in conjunction with other mobile applications such as prepaid wireless. Tracking This is a rather large category that contains everything from the difficult fleet applications to enabling mobile commerce. Fleet applications typically entail tracking vehicles for purposes of the owning company knowing the whereabouts of the vehicle and/or operator. Tracking is also an enable of mobile commerce services. A mobile user could be tracking and provided information that he has predetermined he desires, such as notification of a sale on men's suits at a store close to the user's current proximity. i-Mode

WAP uses a special language called Wireless Markup Language (WML) for communication between a special protocol conversion device called a WAP Gateway (GW) and content on the Internet. The WAP GW converts between WML and HTML, allowing delivery of WAP based content to a WAP capable mobile device. In most networks today, the connection between the MSC and the GW is circuit switched as indicated in the illustration above in which the MSC must utilize the Public Switched Telecommunications Network (PSTN) to connect to the GW. As mobile network operators deploy next generation packet-data technologies such as General Packet Radio Service (GPRS), the connection between the MSC and the WAP GW will be upgraded to leverage the faster packet connection facilitated by the GPRS network. In contrast to WAP, iMode utilizes an overlay packet network for direct communications (no gateway needed) to the content providers on the Internet. i-Mode is the packet-based service for mobile phones offered by Japan's leader in wireless technology, NTT DoCoMo. i-mode is built on a firm foundation of advanced technology. The use of packet transmissions offers continuous access, while the use of a subset of HTML makes content creation easy and provides simple conversion of existing websites. NTT DOCOMO's packet-switched technology was specifically designed to provide users with "always-on" network access, eliminating the need to log on or off. In turn, i-mode the service developed for this packet-switched technology provides the most efficient wireless access possible as no dedicated radio channel is required. The result is lower costs for customers as they are billed according to volume of data sent and received, rather than by time spent connected. i-mode offers one more significant benefit i.e., mobile voice and data service in a single convenient package. This voice/data flexibility is unprecedented. People can download information about events, restaurants, etc., and then make reservations, or place calls to numbers searched in the i-mode directory. SyncML SyncML is the leading open industry standard for universal synchronization of remote data and personal information across multiple networks, platforms and devices. The SyncML initiative recently consolidated into the Open Mobile Alliance (OMA), contributing their technical work to the OMA technical Working Groups: Device Management Working Group and Data Synchronization Working Group. SyncML's goal is to have networked data that support synchronization with any mobile device, and mobile devices that support synchronization with any networked data. SyncML is intended to work on transport protocols as diverse as HTTP, WSP (part of WAP) and OBEX and with data formats ranging from personal data (e.g. vCard & vCalendar) to relational data and XML documents. The ability of applications running on handheld devices, on desktop computers, and in networks to update a single body of information, and to coordinate the updates intelligently, is key to the popularity of the paradigm of ubiquitous computing. The process of making two or more sets of data identical is called data synchronization. To synchronize personal information on your handheld device and your PC you probably use the proprietary technology that comes with the device and use a different technology to

synchronize data on your phone with data on your laptop. Each technology can synchronize one or a few applications, and is limited to a particular type of device or network connectivity. Users waste huge amounts of time and money configuring and installing all these different applications. Given the large and growing diversity of applications and devices we use today, we need a standard synchronization technology. The SyncML initiative is such a standard, which promises to enable users to buy devices that synchronize with a wide range of data and devices, and to reduce the effort and costs expended by device manufacturers, service providers, and application developers as well. SyncML is an open standard that drives data mobility by establishing a common language for communications among devices, applications, and networks. The goal is to enable smooth, efficient synchronization of remote data and personal information across devices, platforms, and multiple networks, both fixed and mobile. This universal language enables devices and applications to synchronize data like email, contact information, calendar, and to-do lists over the network, so that information is consistent, up to date, and accessible, no matter where it's stored: on a mobile phone, a PDA, a laptop, a PC, or a server. Benefits of SyncML SyncML represents a common synchronization standard that benefits all kinds of users in the mobility industry: Device manufacturers: Because storage on mobile devices is limited, manufacturers can support only one synchronization standard. Adopting a common standard enables the device to interoperate with a wide range of applications, services, and network transmission technologies.
Service

providers: If multiple synchronization technologies are widely used, service providers must install and configure multiple server infrastructures, one for each synchronization technology, and must update and maintain each to preserve compatibility and performance. Using a common synchronization standard reduces maintenance effort and operating costs.
Application

developers: Developers who adopt SyncML can create applications that connect to broad varieties of devices and networked data. Applications that don't need to support multiple synchronization technologies are less complex and less costly to maintain. Deployment is easier, too a feature likely to appeal to service providers deciding which of similar applications to offer.
End

users: If platforms and applications use a standard synchronization technology, users will be able to synchronize a wide range of data and devices without spending all those hours configuring multiple, incompatible connections.