Wireless IP and WAP

8/4/2019 Wireless IP and WAP

1/29

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.


2/29

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.


3/29

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

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

Fig. 29.1 Mobile IP topology
http://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-2.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-2.htm


4/29

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.
http://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_TCPIPDynamicHostConfigurationProtocolDHCP.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_TCPIPDynamicHostConfigurationProtocolDHCP.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htm


5/29

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 stepsare:

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 IPoperational 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 byidentifying the agent that sends it messages.
http://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation-3.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htm


6/29

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 localnetwork is basically the same as the normal communication required between a device on an

IP networkand its local router, except more information needs to be sent when the router is

an agent.

29.1.3 Mobile IPHome 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 regularIP 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
http://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPAgentDiscoveryandAgentAdvertisementandSoli.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPAddressingHomeandCareOfAddresses.htm


7/29

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 itreturns 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 whateverephemeral 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.
http://www.tcpipguide.com/free/t_TCPIPUserDatagramProtocolUDP.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_TCPIPClientEphemeralPortsandClientServerApplicatio.htmhttp://www.tcpipguide.com/free/t_TCPIPUserDatagramProtocolUDP.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_TCPIPClientEphemeralPortsandClientServerApplicatio.htm


8/29

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 usinga 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.
http://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPSecurityConsiderations.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag-2.htmhttp://www.tcpipguide.com/free/t_MobileIPSecurityConsiderations.htm


9/29

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 themobile 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

ourmail analogy, this is comparable to taking a letter received for our traveling consultantand 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 datagramsare forwarded across an arbitrary internetwork, with the details of the encapsulated datagram

(meaning the original IP headers) temporarily hidden.
http://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_IPSecModesTransportandTunnel.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPHomeAgentRegistrationandRegistrationMessag.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPConceptsandGeneralOperation.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_IPSecModesTransportandTunnel.htm


10/29

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 whateverrouterit can find on its current

network, which may or may not be a foreign agent. When it does this, it uses its own homeaddress 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 tothe mobile node.
http://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htm


11/29

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 routeron 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 networkwhere the home agent transmits them over the internetwork, resulting in

a more symmetric operation rather than the triangle just described. This is basically what Idescribed 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.
http://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htm#Figure_134http://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htm#Figure_134http://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-2.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htmhttp://www.tcpipguide.com/free/t_MobileIPDataEncapsulationandTunneling-3.htm


12/29

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 WAPapplications 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 HTTP p, 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


13/29

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

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.


14/29

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


15/29

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.


16/29

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 ProtocolThe 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 whenapplications 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 withrelative long latency in order to connect a WAP client to a HTTP server.


17/29

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 andresumed 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


18/29

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.


19/29

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 thatcooperate 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. Thismessage 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


20/29

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

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


21/29

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


22/29

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


23/29

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


24/29

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 onvertedinto 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 clientsand 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


25/29

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 WTAuser-agent with the appropriate WTAI function libraries. A typical example is to set-up a


26/29


27/29

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 mobileapplications 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


28/29

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 asindicated 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 downloadinformation 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 usethe proprietary technology that comes with the device and use a different technology to


29/29

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

Documents

Wireless IP and WAP