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 Mobile Node: This is the mobile device, the one moving around the internetwork.

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

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

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

o Deregistration: When the mobile node returns home, it should tell the home agent to
cancel forwarding, a process called deregistration.

o 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.)

o 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 doesn’t match its network prefix.
This is often done to prevent “spoofing” (impersonating another’s 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 Conditional branching
for Making self-incremented fixed iteration loop
while Making variable iteration loop
break Terminates a loop
continue 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 one-
way, 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 client’s 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 client’s 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.