12.

1 MOBILEIP
In response to the increasing popularity of palm-top and other mobile computers
Mobile IF was developed to enable computers to maintain Internet connectivity
while moving from one Internet attachment point to another. Although Mobile IP
can work with wired connections, in which a computer is unplugged from one phys
ical attachment point and plugged into another, it is particularly suited to wireless
connections
The term mobile in this context implies that a user is connected to one or
more applications acrOss the Internet, that the user's point of attachment changes
dynamically, and that all connections are automatically maintained despite the
change. Ihis 1S in contrast to a user, such as a business traveler, with a portable com
puter of some sort who arrives at a destination and uses the computer's notebook
to dial into an ISP (Internet service provider). In this latter case, the user's Internet
connection is terminated cach time the user moves anda new connection is initiated
when the user dials back in. Each time an Internet connection is established,
software in the point of attachment (typically an ISP) is used to obtain a new,
temporarily assigned P address. This temporary 1IP address is used by the user's
correspondent for each application-level connection (eg. FTP, Web connection).
A
better termfor kind of use is
this nomadic.
We begin with a general overview of Mobile IP and then look at some of
the details

Operation of Mobile IP
As was described in Chapter 4, routers make use of the IP address in an IP datagram
to perform routing. In particular, the nefwork portion of an IP address (Figure 4.1l)
is used by routers to move a datagram from the source computer to the network to
which the target computer is attached. Then the final router on the path, which is
attached to the same network as the target computer, uses the host portion of the IP
address to deliver the IP datagram to the destination. Further, this IP address is
known to the next higher layer in the protocol architecture (Figure 4.1). In particu-
Jar, most applications over the
Internet are supported by TcP connections. When
a C connection is set up, the C P entity on cach side of the connection knows the
P address of the correspondent host. When a TCP segment is handed down to the
IP layer for delivery, TCP provides the IP address, and IP creates an IP datagram
with that P address in the IP header and sends the datagram out for routing and
deivery. Fiowever, with a mobile host, the lP address may change while one or more
TCP connections are
active.
Figure 12.1 shows in general terms how Mobile IP deals with the problem
ot dynamic IP addresses. A mobile node is assigned to a particular network,
known as its home network. Its IP address on that network, known as its home
address, is static. When the mobile node moves its attachment point to another

360 CHAPTER 12 / MOBILE TP AND WIRELESS APPLICATION PROTOCOL

Mobile

- O

etie Detw

Foreig

nrret r other

opoo
ns
---*

e
Figure 12.1 Mobile IP Scenario
Discovery
to the router advertisement
The discovery process in Mobile IP is very similar
Accordingly, agent discovery makes
process defined in ICMP (see Appendix 12A).
one or more extensions specific
use of 1CMP router advertisement messages, with
to Mobile IP

Discover Tunneling
Registration

.
ntermet Control
ser Datagram
Protocol (UDP) Message Protocol
(ICMP)

Tnternet Protocol ( u

Figure 12.2 Protocol Support for Mobile IP

362 CHAPTER 12/MOBILE IP AND WIRELESS APPLICATION PROTOCOOL

Table 12.1 Mobile IP Terminology (RFC 3220)

Mobile node A host or router that changes its point of attachment from one network or subnetwork to
another.A mobile node may change its location without changing 1sidarest tmay
continue to communicate withother Internet nodes at any location usung its (constant)
1Paddres, assuming link-ayer conpectivity to a pointot attachment s availabe
Home address An IP address that is assigned for an extended period of time to a mobile node. If remains
changca regardiess of where the node is attached to the Internet.

Home gent A router on a mobile node s home network which tunnels datagrams for delivery to the
mobile node when it is away from home, and maintains current location information for
the mobile Dode
Home network A network, possibly virtual, having a network prefix matching that of a mobile nodes
bome address Note that standard IP routing mechanisms will deliver datagrams destined
to a mobile nodes Home Address to the mobile nodes Home Network.
Foreign agent Arouter on a mobile node viIted Detwork which provides routing serices to the mobue

mobile node, the foreign agent may serve as a detault router for registered mobile nodes

Foreign Any network other than the mobile node's Home Network,
network
Care-of Ihe termination point of a tunnel toward a mobile node, for datagrams torwarded top
address the mobile node while it is away from home. The protocol can use two different types of

care-of address:atoreign agent care-ot addres5 an address ot a toregn agent witn

aich the mobile node is registered, and a "co-located care-of cddress a n externaluly
obtained local address which the mobile node has associafed with one of its own network
interfaces.
Correspondent Apeer with which a mobile node is communicating A correspondent node may be either
Jode mobile or stationary
Lank A facility or medium over which nodes can communicate at the link layer. A link underlies
the network layer.
Node host or a
routet
Tunnel The path followed by a datagram while it is encapsulated. The model is that, while iti
encapsulated, a datagram is routed to a knowledgeable decapsulating agent, which
decapsulates the datagram and then correctly delivers it to its ultimate destination.

The mobile node is responsible for an ongoing discovery process. It must

determine if it is attached to its home network, in which case IP datagrams may
be received without forwarding, or if it is attached to a foreign network. Because
handoff from one network to another occurs at the physical layer, a transition irom
the home network to a foreign network can occur at any time without notification
to the network layer (ie., the IP layer). Thus, discovery for a mobile node is a con-
tinuous process.
For the purpose of discovery, a router or other network node that can act as an
agent periodically issues a router advertisement 1CMP message (see Figure 12.20d
1 Appendix 12A) with an advertisement extension. The router advertisement
portion of the message includes the IP address of the router. The advertisement
extension includes additional information about the router's role as an agent, as dis-
cussed subsequently. A mobile node listens for these agent advertisement messages.

12.1 / MOBILE P 363

Code Checksum

Num addrs Entry size Time ta Hve

ter a irss.

elereceee

Preference level n

Leng Sequence mumber

Lifetime reserved

Lero or more care-of addreses

Length Prefix length [1]Preñx length [2)

Additional prefis lengths iT neede

Figure 12.3 Mobile IP Agent Advertisement Message

 Because a foreign agent could be on the mobile node's home network (set up to
serve visiting mobile nodes), the arrival of an agent advertisement does not neces
sarily tell the mobile node thatit is on a toreign network. Ihe mobile node must
compare the network portion of the router's IP address with the network portion of
its own home address If these network portions do not match, then the mobile node
is on
a foreign network.
The agent advertisement extension follows the 1CMP router advertisement
fields and consists of the following fields (Figure 12.3):
1ype: 16,indicates that this is an agent advertisement.
Length: Number of bytes in the extension, excluding the Type and Length
fields The value is (6 + 4N), where N is the number of care-of addresses
advertised.
Sequence Number: The count of agent advertisement messages sent since the
agent was initialized.
Lifetime: The longest lifetime, in seconds, that this agent is willing to accept a
registration request from a mobile node.
R: Registration with this foreign agent is required (or another foreign agent on
this network). Even those mobile nodes that have already acquired a care-of
address from this foreign agent must re-register.

364 CHAPTER 12 / MOBILE IP AND WIRELESS APPLICATICON PROTOCOL

B : Busy. The foreign agent will not accept registrations from additional mobile
nodes

H: This agent offers services as a home agent on this network.

EThis agent offers services as a foreign agent on this network.

M: This agent can receive tunneled IP datagrams that use minimal encapsula
tion, explained subsequently.
G: This agent can receive tunneled IP datagrams that use GRE encapsulation,
explained subsequently
reserved.

FForeign agent supports reverse tunneling

Care-Of Address: The care-of address or addresses supported by this agent on
this network. There must be at least one such address if the F bit is set. There
may be multiple addresses

There may also be an optional prefix-length extension following the advertise

ment extension. This extension indicates the number of bits in the router's address
hat define the network number (Figure 4.11). The mobile node uses this informa-
tion to compare the network portion of its own IP address with the network portion
of the router. The fields are as follows:
Type: 19, indicates that this is a prefix-length advertisement.
Length: N, where N is the value of the Num Addrs field in the 1CMP router
advertisement portion of this ICMP message. In other words, this is the num-
ber of router addresses listed in this ICMP message.
Prefix Length: The number of leading bits that define the network number of
the corresponding router addres listed in the ICMP router advertisement
portion of this message. The number of Prefix Length fields matches the num-
ber of router address fields (N).

Agent Solicitation Foreign agents are expected to issue agent advertisement

messages periodically. If a mobile node needs agent information immediately, it can
issue an 1CMP router solicitation message (see Figure 12.20e in Appendix 12A).
Any agent receiving this message will then issue an agent advertisement.

Move Detection As was mentioned, a mobile node may move from one network
to another due to some handoff mechanism, without the IP level being aware of it.
The agent discovery process is intended to enable the agent to detect such a move.
The agent may use one of two algorithms for this
purpose
Use of lifetime field: When a mobile node receives an agent advertisement from
a foreign agent that it is currently using or that it is now going to register with, it
records the lifetime field as a timer. If the timer expires betore the mobile node
receives another agent advertisement from the agent, then the node assumes
that it has lost contact with that agent. II, in the meantime, the mobile node has
received an agent advertisement from another agent and that advertisement has
not yet expired, the mobile node can register with this new agent. Otherwise, the
mobile node should use agent solicitation to find an agent.
 12.1MOBILE IP 365

Use of network prefix: The mobile node checks whether any newly received
agent advertisement is on the same network as the node's current care-of
address. Itit 1S not, the mobile node assumes that it has moved and may regs
ter with the agent whose advertisement the mobile node has just received.

Co-Located Addresses The discussion so far has involved the use of a care-of
address associated wIth a toreign agent; that is, the care-of address is an IP addres
for the toreign agent. This toreign agent will receive datagrams at this care-of
address, intended for the mobile node, and then forward them across the foreign
network to the mobile node. However, in some cases a mobile node may move to a
network that has no foreign agents or on which all foreign agents are busy. As
alternative, the mobile node may act as its own toreign agent Dy usina o
care-of address. A co-located care-of address is an IP address obtained by the mobile
node that B associated with the mobile node S Current intertace to a network.
n e means y wcn a mooue node acquires a co-1Ocated address i s oeyona

the scope ot Mobiie lP One means is to dynamically acquire a temporary P address

through an Internet service such as DHCP (Dynamic Host Configuration Protocol).
Another alternative is that the co-located address may be owned by the mobile
node as a long-term address for use only while visiting a given foreign network.

Registration
Once a mobile node has recognized that it is on a foreign network and has acquired a
care-of address, it needs to alert a home agent on its home network and request that
the home agent forward its IP traffic. The registration process involves four steps:
1. The mobile node requests the forwarding service by sending a registration
request to the foreign agent that the mobile node wants to use.
2. The foreign agent relays this request to the mobile node's home agent.
3. The home agent either accepts or denies the request and sends a registration
reply to the foreign agent.

4. The toreign agent relays this reply to the mobile node.

If the mobile node is using a co-located care-of address, then it registers

directly with its home agent, rather than going through a foreign agent.
The registration operation uses two types of messages, carried in UDP seg
ments (Figure 12.4). The registration request message consists of the following fields:
Type: 1,indicates that this is a registration request.
S : Simultaneous bindings. The mobile node is requesting that the home
agent retain its prior mobility bindings. When simultaneous bindings are
in effect, the home agent will forward multiple copies of the IP datagram,
one to each care-of address currently registered for this mobile node. Multi-
ple simultaneous bindings can be useful in wireless handoff situations, to
improve reliability.
B: Broadcast datagrams. Indicates that the mobile node would like to receive
copies of broadcast datagrams that it would have received if it were attached
to its home netwoK.

366 CHAPTER 12/ MOBILE IP AND WIRELESS APPLICATION PROTOCOL

1ype
s BDMc|7|| Lifetlme

Home address

Home agent

Care-of address

ldentifcation

Extensions

(a) Registratilon request message

pe Code
Lifetime
ddress

Home ngent

Identißcation

Extensions
(b) Registration reply message
Figure 124 Mobile IP Registration Messages
 12.1/ MOBILE IP 367

Care-Of Address: The IP address at this end of the tunnel. The home
agent
should forward IP datagrams that it receives with mobile node's home address
to this destination address.
Identification: A 64-bit number generated by the mobile node, used for match-
ing registration requests to registration replies and for security purposes, as
explained subsequentiy.
Extensions: The only extension so far defined is the authentication extension,
Cxplained subsequently.
The regístration reply message consists of the following fields:
Type: 3, indicates that this is a registration reply.
Code: Indicates result of
the registration request (Table 12.2).
Lifetime: If the code field indicates that the registration was accepted, the
number of seconds before the registration is considered expired. A value of
Zeroindicates that the mobile node has been de-registered.
Home Address: The home 1P address of the mobile node.
Home Agent: The
IP address
of the mobile node's home agent.

Table 12.2 Code Values for a Mobile IP

Registration KRepiy
Registration Successful Registration Denied by the Foreign Agent
registration accepted 64 reason unspecified
registration accepted, but simultaneous 65 administratively prohibited
mobility bindings unsupported 66 insufficient resources
67 mobile node failed authentication
Registration Denied by the Home Agent h o m e agent failed authentication

128 reason unspecified requested Lifetime too long

129 administratively prohibited 70 poorly formed Request
130 Insufficient resources 71 poorly formed Reply
131 mobile node failed authentication 72 requested encapsulation unavailable
132 foreign agent failed authentication 73 requested Van Jacobson compression
133 registration Identification mismatch unavailabie
77 invalid care-of address
134 poorly formed Request
135 too many simultaneous mobility bindings 78 registration timeout
136 unknown home agent address 80 home network unreachable (ICMP error
received)
81 home agent host unreachable (ICMP error
received)
82 home agent port unreachable (ICMP error
received)
88 home agent unreachable (other 1CMP error
received)
 Tunneling
Once a mobile node is registered with a home agent, the home agent must be
able to intercept IP datagrams sent to the mobile node's home address so that
these datagrams can be forwarded via tunneling. The standard does not mandate
a specific technique for this purpose but references ARP (Address Resolution
Protocol) as a possible mechanism. The home agent needs to inform other nodes
on the same network (the home network) that IP datagrams with a destination
address of the mobile node in question should be delivered (at the link level) to
this agent. In effect, the home agent steals the identity of the mobile node in
order to capture packets destined for that node that are transmitted across the
nome network.
For example, suppose that R3 in Figure 12.6 is acting as the home agent for a
mobile node that is attached to a foreign network elsewhere on the Internet. That
15,there is a host H whose home network is LAN Z that is now attached to some
foreign network. If host D has traffic forH, it will generate an IP datagram with H's
home address in the P destination address field. The IP module in D recognizes
that this destination address is on LAN Z and so passes the datagram down to the
ink layer with instructions to deliver it to a particular MAC-level address on Z.
Frior to this time, R3 has informed the IP layer at D that datagrams destined for
that particular addres should be sent to R3.Thus, D inserts the MAC address of
R3 in the destination MAC address field of the outgoing MAC frame. Similarly, it
an 1P datagram with the mobile node's home address arrives at router R2, it recog
nizes that the destination address is on LAN Z and will attempt to deliver the

370 CHAPTER 12/MOBILE IP AND WIRELESS APPLICATION PROTOCoL

LANX

RI
Internet
LAN Y

LAN Z

Figure 12.6 A Simple Internetworking Example

datagram to a MAC-level address on Z. Again. R2 has previously been informed

that the MAC-level address it needs
corresponds to R3.
For traffic that is routed across the Internet and arrives at R3 from the Inter
net, R5 must simply recognize that for this destination address, the datagram is to be
captured and forwarded.
To forward an IP datagram to a care-of address, the home agent puts the entire
IP datagram into an outer IP datagram. This is a form of encapsulation, just as plac-
ing an iP header in tront of a TCP segment encapsulates the TCP segment in an IP
datagram.Three options for encapsulation are allowed for Mobile IP:

IP-within-IP encapsulation: This is the simplest approach, defined in RFC 2003.

Minimal encapsulation: This approach involves fewer fields, defined in RFC 2004.
Generic routing encapsulation (GRE); This is a generic encapsulation procedure
that was developed prior to the development of Mobile IP, defined in RFC 1701.

We review the first two of these methods.

IP-within-IP Encapsulation With this approach, the entire IP datagram
becomes the payload in a new IP datagram (Figure 12.7a). The inner, original 1P
header is unchanged except to decrement TTL by 1.The outer header is a ful
P header. Two fields (indicated as unshaded in the figure) are copied from the
inner header: The version number is 4, which is the protocol identifier for IPv4,
and the type of service requested for the outer IP datagram is the same as that
requested for the inner IP datagram.
In the inner IP header, the source address refers to the host that is sending the
original datagram, and the destination address is the home address of the intended
recipient. In the outer IP header, the source and destination addresses refer to the
entry and exit points of the tunnel. Thus, the source address typically is the IP
address of the home agent, and the destination address is the care-of address for the
intended destination.
12.2 WIRELESS APPLICATION PROTOCOL
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 (eg. GSM, CDMA, and TDMA). WAP is
based on existing Internet standards, such as IP, XML, HTMIL, and HTT, 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 the use of mobile phones and terminals for data services are
the significant limitations of the devices and the networks that connect them. ine
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
nstance, mobile terminals must be extremely easy to use, much easier than worksta-
tions 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)
The WAP specification consists of a number of different protocols and modules,
whose relationship is depicted in Figure 12.8.

Architectural Overview
The WAP Programming Model is based on three clements: the client, the gateway,
and the original server (Figure 12.9). HTTP is used between the gateway and the
onginal server to transter content. The gateway acts as a proxy server for the
wireless domain. Its processor(s) provide services that offload the limited capabili
ties of the hand-held, mobile, wireless terminals For example, the gateway provides
DNS services, converts between WAP protocol stack and the WwW stack (HTTP
and TCP/P), encodes information from the Web into a more compact form that
minimizes wireless communication, and, in the other direction, decodes the com
pacted torm into standard web communication conventions. 1he gateway also
caches frequently requested information.

374 CHAPTER 12 / MOBILE IP AND WIRELESS APPLICATION PROTOCOL

Wireless Markup Language (WML) WMIScript

Wireless Application Eavironment (WAE

Wireless Session Protocel (WSP)

Wireless Transaction Protocol (WTP)

Wireless Transport Layer Security (WILS)

Wireless Datagram Protocol (wDP)

GSM D-AMPS 15-95 L 3G Bluetooth

Figure 12.8 WAP Protocol Stack

 Client Original server
Gateway
Encoded requests Requests
WA
Encoders CGI
Scripts
agent decoders ete.

r d Sponse pone (Content)Content

Figure 12.9 The WAP Programming Model

12.2/WIRELESSAPPLICATION PROTOCOL 375

HTML er
Ordinary HTTPTCP
Web server
HTML
ilter

Intern
wML
over
WML-capable HTPTCPP
Web server

wML ovN
HTTP/TC
PAP

Binary wMIL

over WAP
Mobile
ermin
erininal WAP
Wireless proxy
Nétwork
Wireless

Binary
WAP

Figure 12.10 WAP Infrastructuree

The WAP architecture is designed to cope with the two principal limitations of
Wireless web access: the limitations of the mobile node (mall screen size, limited
input capability) and the low data rates of wireless digital networks. Even with the
introduction of 3G wireless networks, which will provide broadband data rates, the
small hand-held mobile nodes will continue to have limited input and display capa
bilities. Thus WAP or a similar capability will be needed for the indefinite future

Wireless Markup Language

WML was designed to describe content and format for presenting data on devices
with limited bandwidth, limited screen size, and limited user input capability. It is
designed to work with telephone keypads, styluses, and other input devices common
to mobile, wireless communication. WML permits the scaling of displays for use
on two-line screens found in some small devices, as well as the larger screens found
on smart phones
 WMLScript
WMLScript is a seripting language with similarities to JavaScript. It is designed for
defining script-type programs in a user device with limited processing power and

12.2/WIRELESS APPLICATION PROTOCOL 377

Table 12.3 WML Tags

Tag Deseriptio Tag Description

Deck Structure Uer mP

Caccess
Accessconuo cfieldsetb Data entry items grouping

cCard Card detinition npup Data entry

chead Deck-level information (meta, coptgroup u b s e t of a choice list

access,tempiate) a Sngie choice in a list

cmeta>
Metainformation SselectP Cholce iB
ctemplate Deck-ievel event bindings Varlabies
wna Deck definition
enostfiel Set an http request variable
Content
Setvar S e t a variable in a task

mage men

Paragraph, visible content

imer SetALimer
Tasks
cTu a b i e data

URL
ctD Table row Go to a

Noaction
to ore
Go to previous card
Bold
crefresth> Screen redraw

arge Tont
e n t Binding
Linebreak
ADprevied anchor
mpaa
Italic Ancho Anchor

mau Small fo Response to user button press

rong rong tont conevent> ntrinsic event binding

Cu Underline
Wireless Application Environment
The WAE specifies an application framework for wireless devices such as mobile
telephones, pagers, and PDAs. In essence, the WAE consists of tools and formats
that are intended to ease the task of developing applications and devices supported
by WAP The major elements of the WAE model are as follows (Figure 12.11):

Ser agents
WML user agent

wTA user agent Other

Other agents
applications
and
Services/tormats services
WML WMLSCript
wIA Services URLs

WAP protocol stack and services

Device OS/services

Figure 12.1i WAE Client Components [WAPF98]

Wireless Session Protocol
WSP provides applications with an interface for two session services. The connection
oriented session service operates above the reliable transport protocol WTP, and the
connectionless session service operates above the unreliable transport protocol WDP
In essence, WSP is based on HTTP with some additions and modifications to optimize
its use over wireless channels. The principal limitations addressed are low data rate
and to loss of connection due to poor coverage or cell
susceptibility overloading
WSP is a transaction-oriented protocol based on the concept of a request and
reply. Each WSP protocol data unit (PDU) consists ofa body, which may contain
WML, WMLScript, or images, and a header, which contains information about the
data in the body and about the transaction. WSP also defines a server Push opera-
sends to a may be
tion, in which the server unrequested content lient device. This
used for broadcast messages or for services, such as news headlines or stock quotes,
that may be tailored to each client device.

WSP Service In general, a connection-mode WSP provides the following services:

Establish a reliable session from client to server and release thatsession in an

orderly manner.
Agree on a common level of protocol functionality using capability negotiation.
Exchange content between client and server using compact encoding
Suspend and resume a session.
Push content from server to client in an unsynchronized manner.

At the service level, wSP is defined in terms of a collection of service

primitives, With associated parameters. These service primitives define the interface
between WSP and users of WSP in the WAE.' At the protocol level, the WSP specifi-
cation defines a PDU format used to exchange data between peer WSP entities.

See Appendix 12C for a brief discussion of the concept of service primitives and parameters
380 CHAPTER 12/ MOBILE IP AND WIRELESS APPLICATION PROTOCOL

Client Provider Server Client Provider Server

o
cenect.in ect.ind
(RC, RS, RA, EH, E
SA, CA. CH, MO)

S-Connectrs S-Diacon
onnect.c
SH, NC)

(a) Successful session establishment (6) Active session termination

Client Provider Server Client Provider Server

SMethodlavoke.req
nd.ind C, M, R, RIE, R)
SL,M, R , RI, RB)

pend.ind
(Reason) Methodlavuks.rs
S-Methodlavoke.cnf
MethodResult.req
S-Resume.req
A,CA) S-MethodNResult.ind
e

S.MethodResut.res
AR dNesult.cn
SI, A)

(c) Session suspend and resume (d) Completed transaction

Client Provider Server Chent Provider Server

SFush.re4
SL PH, PB)
Push.ind S-CenfrmPush.ind

(e) Nonconfirmed data push

0 Confirmed data push

Figure 12.12 Wireless Session Protocol Primitives and Parameters
Wireless Transaction Protocol

WTP manages transactions by conveying requests and responses between a user

as a WAP browser) and an server for such activities as
application
agent (such
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
1s suitable
that suitable for implementationin "thin cients(e.g mobile nodes) and
for use over low-bandwidth wireless links. WTP includes the following features:

Three classes of transaction service.

Optional user-to-user reliability: WTP

received message.
user triggers the confirmation of each

Optional out-of-band data on acknowledgments.

PDU concatenation and delayed acknowledgment to reduce the number of
messages sent.

Asynchronous transactions.
no
WTPis transaction oriented rather than connection oriented. With W1P, there is
explicit connection setup teardown but rather reliable connectionless service.
or a

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
Wireless Transport Layer Security
WTLS provides security services between the mobile device (client) and the WAP
gateway. wTLS is based on the industry-standard Transport Layer Security (TLS)
Protocol, which is a refinement of the secure sockets layer (SSL). TLS is the
standardsecurity protocol used between Web browsers and Web servers. wTLSis
more efficient that TLS, requiring fewer message exchanges. To provide end-to-end
security, WTLS is used between the client and the gateway, and TLS is used between
the gateway and the target server. WAP systems translate between WTLS and TLS
within the WAP gateway. Thus, the gateway is a point of vulnerability and must be
given a high level of security from external attacks
WTLS provides the following features:
Data integrity: Ensures that data sent between the client and the gateway are
not modified, using message authentication
Privacy: Ensures that the data cannot be read by a third party, using encryption

For a detailed description of TLS, see [STALO3)

388 CHAPTER 12/ MOBILE IP AND WIRELESS APPLICATION PROTOCOL

wSP Client WTP Client Provider WTP Server WSP Server

S-MethodInvoke.req

TR-Iavoke.re -voke PDDU

Du. TR-Invoke.lnd
S-Methodinvoke.ind
S-MethodInvoke.res
ACKP D . TR-Invoke.res
TR-Invoke.cnt
S-Methodlnvoke.cnf S-MethodResult.req
ResultP D U .
TR-Result.req
TR-Result.ind
S-Method Result.ind

S-MethodResult.res
TR-Result.res ACK PDU
TR-Result.cnf
S-MethodResult.cnf

Figure 12.15 WSP-WTP Timing Diagram

 wiLS
Handshake Cipher Spec WTLS Alert wTP
Protocol
Protocol Protocol

WTLS Record Protocol

WDP or UDP/AP

Figure 12.16 WTLS Protocol Stack

12.2/WIRELESSAPPLICATION PROTOCOL 389

User data

Compres

Add MAC

Encrypt

record dheader
WTLS
Figure 12.17 WTLS Record Protocol Operation

higher-layer protocols. In particular, the Hypertext Transfer Protocol (HTTP), defined in

RFC 2068 and which provides the transfer service for Web client/server interaction, can
operate on top of WTLS Three higher-layer protocols are defined as part of WTLS: the
Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol.

WTLS Record Protocol The WTLS Record Protocol takes user data from the
next higher layer (WTP, WTLS handshake protocol, WTLS alert protocol, WTLS
change cipher spec protocol) and encapsulates these data in a PDU. The following
steps occur (Figure 12.17):

1. The payload is compressed using a lossless compression algorithm.

2. A message authentication code (MAC) is computed over the compressed data,
using HMAC. HMAC is a keyed hash code similar to (but more complex than)
the one described in Appendix 12B. One of several hash algorithms can be used
with HMAC, including MD-5 and SHA-1. The length of the hash code is 0, 5, or
10 bytes. The MAC is added after the compressed data.
3. The compressed message plus the MAC code are encrypted using a symmetric
encryption algorithm. The allowable encryption algorithms are DES, triple DES,
RC5, and IDEA.
4. The Record Protocol prepends a header to the encrypted payload.

The Record Protocol header consists of the following fields (Figure 12.18):
Content Type (8 bits): The higher-layer protocol above the WTLS Record
Protocol.
Cipher Spec Indicator (1 bit): If this bit is zero, it indicates that no compres-
Sion, MACprotection, or encryption is used.

Sequence Number Field Indicator (1 bit): Indicates whether a sequence num-

ber field is present.
Record Length Field Indicator (1 bit): Indicates whether a record length field
is present.
Wireless Datagram Protocol
WDP is used to adapt a higher-layer WAP protocol to the communication mechanism
(called the bearer) used between the mobile node and the WAP gateway. Adaptation
may include partitioning data into segments of appropriate size for the bearer and
interfacing with the bearer network. WDP hides details of the various bearer networks
from the other layers of WAP In some instances, WAP is implemented on top of P

WDP Service The WDP service is defined by two service primitives. The T-DUnit-
data primitive provides a nonconfirmed service with the following parameters:

Source address: Address of the device making a request to the WDP layer
Source port: Application address associated with the source address
Destination address: Destination address for the data submitted to WDP
Destination port: Application address associated with the destination address
User data: User data from the next higher layer, submitted to WDP for trans-
mission to the destination port

The T-Derror.ind primitive is used to alert a WDP user of a failure to deliver a

WDP datagram. In addition to the source address, source port, destination address,
and destination port parameters, T-Derror.ind includes an error code parameter
with local significance.

WDP Protocol The following fields are necessary in a WDPPDU:

Destination Port
Source Port
If the underlying bearer does not provide segmentation and reassembly, the
feature is implemented in WDP in a bearer-independent way.
For example, GSM (Global System for Mobile Communications) dictates a
format for a user data header, in which the header consists of a sequence of infor-
mation elements, and each element is defined by an identifier, a length, and one or
more bytes of value. The WDH PDU for GSM has the following structure
Header length (1 byte): Length of header
Port numbers identifier (1 byte): The value 5 indicates that this information
element consists of two port numbers

394 CHAPTER 12/ MOBILE IP AND WIRELESS APPLICATION PROTOcOL

Port numbers length (1 byte): The value 4 indicates that the value portion of
this information element is 4 bytes long.
Destination port (2 bytes)
Source port (2 bytes)
SAR identifier (1 byte): The value O indicates that this information element
consists of information for segmentation and reassembly
SAR length (1 byte): The value 3 indicates that the value portion of this
information element is 3 bytes long.
Datagram reference number (1 bytes): An identifier assigned to all of the
segments that make upa block of user data.
Number of segments (1 byte): The total number of segments that need to
be reassembled.

Segment count: A sequence number that identifies this segment within the
sequence of all segments that need to be reassembled to form the block of
user data.

User data (1 to n bytes)