Professional Documents
Culture Documents
Wireless IP and WAP PDF
Wireless IP and WAP PDF
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.
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.
o Mobile Node: This is the mobile device, the one moving around the internetwork.
o Home Agent(HA): This is a router on the home network that is responsible for
catching datagrams intended for the mobile node and forwarding them to it when it is
traveling. It also implements other support functions necessary to run the protocol.
o Foreign Agent(FA): This is a router on the network to which the mobile node is
currently attached. It serves as a “home away from home” for the mobile node,
normally acting as its default router as well as implementing Mobile IP functions.
Depending on the mode of operation, it may receive forwarded datagrams from the
home agent and forward them to the mobile node. It also supports the sharing of
mobility information to make Mobile IP operate. The foreign agent may not be
required in some Mobile IP implementations but is usually considered part of how the
protocol operates.
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.
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.
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.
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.
This is a care-of address assigned directly to the mobile node using some means external to
Mobile IP. For example, it may be assigned on the foreign network manually, or
automatically using DHCP. In this situation, the care-of address is used to forward traffic
from the home agent directly to the mobile node.
Mobile IP Functions
An important difference between Mobile IP and our mail forwarding example is one that
represents the classic distinction between people and computers: people are smart and
computers are not. To this end, Mobile IP includes a host of special functions that are used to
set up and manage datagram forwarding. To see how these support functions work, we can
describe the general operation of Mobile IP as a simplified series of steps:
1. Agent Communication: The mobile node finds an agent on its local network by
engaging in the Agent Discovery process. It listens for Agent Advertisement
messages sent out by agents and from this can determine where it is located. If it
doesn't hear these messages it can ask for one using an Agent Solicitation message.
2. Network Location Determination: The mobile node determines whether it is on its
home network or a foreign one by looking at the information in the Agent
Advertisement message.
If it is on its home network it functions using regular IP. To show how the rest of the process
works, let's say the device sees that it just moved to a foreign network. The remaining steps
are:
3. Care-Of Address Acquisition: The device obtains a temporary address called a care-
of address. This either comes from the Agent Advertisement message from the
foreign agent, or through some other means. This address is used only as the
destination point for forwarding datagrams, and for no other purpose.
4. Agent Registration: The mobile node informs the home agent on its home network
of its presence on the foreign network and enables datagram forwarding, by
registering with the home agent. This may be done either directly between the node
and the home agent, or indirectly using the foreign agent as a conduit.
5. Datagram Forwarding: The home agent captures datagrams intended for the mobile
node and forwards them. It may send them either directly to the node or indirectly to
the foreign agent for delivery, depending on the type of care-of address in use.
Datagram forwarding continues until the current agent registration expires. The device can
then renew it. If it moves again, it repeats the process to get a new care-of address and then
registers its new location with the home agent. When the mobile node returns back to its
home network, it deregisters to cancel datagram forwarding and resumes normal IP operation.
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 encompasses the first three steps in the simplified five-step Mobile IP
operational summary I gave in the topic on general operation. The main goals of agent
discovery include the following:
o Orientation: The node uses the agent discovery process to determine where it is.
Specifically, it learns whether it is on its home network or a foreign network by
identifying the agent that sends it messages.
o Care-Of Address Assignment: The agent discovery process is the method used to
tell a mobile node the care-of address it should use, when foreign agent care-of
addressing is used.
Mobile IP agents are routers that have been given additional programming to make them
“Mobile IP aware”. The communication between a mobile node and the agent on its local
network is basically the same as the normal communication required between a device on an
IP network and its local router, except more information needs to be sent when the router is
an agent.
Once a mobile node has completed agent discovery, it knows whether it is on its home
network or a foreign network. If on its home network it communicates as a regular IP device,
but if on a foreign network it must activate Mobile IP. This requires that it communicate with
its home agent so information and instructions can be exchanged between the two. This
process is called home agent registration, or more simply, just registration.
The main purpose of registration is to actually start Mobile IP working. The mobile node
must contact the home agent and tell it that it is on a foreign network and request that
datagram forwarding be turned on. It also must let the home agent know its care-of address so
the home agent knows where to send the forwarded datagrams. The home agent in turn needs
to communicate various types of information back to the mobile node when registration is
performed. Note that the foreign agent is not really involved in registration, except perhaps to
relay messages, as we will see.
Successful registration establishes what is called in the standard a mobility binding between a
home agent and a mobile node. For the duration of the registration, the mobile node's regular
home address is tied to its current care-of address and the home agent will encapsulate and
forward datagrams addressed to the home address over to the care-of address. The mobile
node is supposed to manage its registration and handle various events using several actions:
o Registration: The mobile node initiates a registration when it first detects it has
moved from its home network to a foreign network.
o Deregistration: When the mobile node returns home, it should tell the home agent to
cancel forwarding, a process called deregistration.
o Reregistration: If the mobile node moves from one foreign network to another, or if
its care-of address changes, it must update its registration with the home agent. It also
must do so if its current registration is about to expire, even if it remains stationary on
one foreign network.
Each registration is established only for a specific length of time, which is why regular
reregistration is required whether the device moves or not. Registrations are time-limited to
ensure that they do not become stale. If, for example, a node forgets to de-register when it
returns home, the datagram forwarding will eventually stop when the registration expires.
To perform registration, two new message types have been defined in Mobile IP: the
Registration Request and the Registration Reply. Each of these does what you would expect
from its name. Interestingly, these are not ICMP messages like the ones used in agent
discovery; they are User Datagram Protocol (UDP) messages. Thus, technically speaking,
registration is performed at a higher layer than the rest of Mobile IP communication. Agents
listen for Registration Requests on well-known UDP port #434, and respond back to mobile
nodes using whatever ephemeral port the node used to send the message.
Registration Procedures
There are two different procedures defined for registration, depending on the type of care-of
address used by the mobile node and other specifics we will get into shortly. The first is the
direct registration method, which has just two steps:
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
4. Foreign agent processes Registration Reply and sends back to mobile node.
Figure 29.3 Mobile IP registration process
The first, simpler method is normally used when a mobile node is using a co-located care-of
address. In that situation, the node can easily communicate directly with the home agent, and
the mobile node is also set up to directly receive information and datagrams from the home
agent. When there is no foreign agent, this is obviously the method that must be used. It is
also obviously the method used when a mobile node is de-registering with its home agent
after it arrives back on the home network.
The second method is required when a mobile node is using a foreign care-of address. Recall
that in this situation, the mobile node doesn't have its own unique IP address at all; it is using
a shared address given it by the foreign agent, which precludes direct communication
between the node and the home agent. Also, if a mobile node receives an Agent
Advertisement with the “R” flag set, it also should go through the foreign agent, even if it has
a co-located care-of address.
Note that the foreign agent really is just a “middleman”; the exchange is still really between
the home agent and the mobile node. However, the foreign agent can deny registrations if the
request violates whatever rules are in place for using the foreign network. It is for this reason
that some foreign agents may require that they be the conduit for registrations even if the
mobile node has a co-located care-of address. Of course, if the foreign agent can't contact the
home agent the registration will not be able to proceed.
The description above is really a highly simplified explanation of the basics of registration.
The Mobile IP standard specifies many more details on exactly how agents and nodes
perform registration, including particulars on when requests and replies are sent, how to
handle various special conditions such as invalid requests, rules for how home agents
maintain a table of mobility bindings, and much more. The standard covers the definition of
extensions to the regular registration messages to support authentication, which is required
for secure communications (see the topic on security issues for more details). It also includes
the ability to have a mobile node maintain more than one concurrent binding, when needed.
29.2.5 Mobile IP Data Encapsulation
Once a mobile node on a foreign network has completed a successful registration with its
home agent, the Mobile IP datagram forwarding process described in the general operation
topic will be fully “activated”. The home agent will intercept datagrams intended for the
mobile node as they are routed to its home network, and forward them to the mobile node.
This is done by encapsulating the datagrams and then sending them to the node's care-of
address.
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.
The encapsulation process creates a logical construct called a tunnel between the device that
encapsulates and the one that decapsulates. This is the same idea of a tunnel used in
discussions of virtual private networks (VPNs), IPSec tunnel mode, or the various other
tunneling protocols used for security. The tunnel represents a medium over which datagrams
are forwarded across an arbitrary internetwork, with the details of the encapsulated datagram
(meaning the original IP headers) temporarily hidden.
Figure 29.4 Mobile IP tunneling
In Mobile IP, the start of the tunnel is the home agent, which does the encapsulation. The end
of the tunnel depends on what sort of care-of address is being used:
o Foreign Agent Care-Of Address: The foreign agent is the end of the tunnel. It
receives encapsulated messages from the home agent, strips off the outer IP header
and then delivers the datagram to the mobile node. This is generally done using layer
two, because the mobile node and foreign agent are on the same local network, and of
course, the mobile node does not have its own IP address on that network (it is using
that of the foreign agent.)
o Co-Located Care-Of Address: The mobile node itself is the end of the tunnel and
strips off the outer header.
Normally, the tunnel described above is used only for datagrams that have been sent to the
mobile node and captured by the home agent. When the mobile nodes wants to send a
datagram, it doesn't tunnel it back to the home agent; this would be needlessly inefficient.
Instead it just sends out the datagram directly using whatever router it can find on its current
network, which may or may not be a foreign agent. When it does this, it uses its own home
address as the source address for any requests it sends. As a result, any response to those
requests will go back to the home network. This sets up a “triangle” of sorts for these kinds of
transactions:
1. The mobile node sends a request from the foreign network to some third party device
somewhere on the internetwork.
2. The third party device responds back to the mobile node. However, this sends the
reply back to the mobile node's home address on its home network.
3. The home agent intercepts the response on the home network and tunnels it back to
the mobile node.
This process is illustrated in Figure 134. The reverse transaction would be pretty much the
same, just in the reverse order. In that case the third party (Internet) device would send a
request to mobile node, which would be received and forwarded by the home agent. The
mobile node would reply back directly to the Internet host.
There may be situations where it is not feasible or desired to have the mobile node send
datagrams directly to the internetwork using a router on the foreign network as we just saw.
In this case, an optional feature called reverse tunneling may be deployed, if it is supported
by the mobile node, the home agent and if relevant, the foreign agent.
When this is done, a reverse tunnel to complement the normal one is set up between the
mobile node and the home agent, or between the foreign agent and the home agent,
depending on care-of address type. All transmissions from the mobile node are tunneled back
to the home network where the home agent transmits them over the internetwork, resulting in
a more symmetric operation rather than the “triangle” just described. This is basically what I
described earlier as being “needlessly inefficient”, because it means each communication
requires four steps. Thus, it is used only when necessary.
One situation where reverse tunneling may be required is if the network where the mobile
node is located has implemented certain security measures that prohibit the node from
sending datagrams using its normal IP address. In particular, a network may be set up to
disallow outgoing datagrams with a source address that doesn’t match its network prefix.
This is often done to prevent “spoofing” (impersonating another’s IP address.)
Another open standard providing mobile users of wireless terminals access to telephony and
information services is Wireless Application Protocol (WAP). The name "Wireless
Application Protocol" (WAP) is misleading. WAP is not actually a protocol at all, in the
sense that HTTP and IP are protocols. In fact, WAP involves multiple protocols and complete
network architecture for delivery of wireless content. WAP specifies architecture based on
layers that follow the OSI model fairly closely. Designed to work with all wireless network
technologies such as GSM, CDMA, and TDMA.
The wireless industry hopes that WAP devices will become popular for ecommerce
applications like online banking. In the short term, it is more likely that useful WAP
applications will simply extend the functions of telephone and allow us to answer a phone
message with an email, for example. The early WAP applications have featured news feeds,
stock quotes, and weather forecasts. Significant backlash against the hype and optimism
surrounding WAP has certainly occurred as a result of the uncertainly about its future.
In this chapter first we discuss the main components of a Mobile IP, co-located address and
the concept of tunnelling. Then we focus the WAP architecture, the basic WAP model and
different cache models for WAP.
The Wireless Application Protocol (WAP) is a universal, open standard developed by the
WAP Forum to provide mobile users of wireless phones and other wireless terminals such as
pagers and personal digital assistants (PDAs) access to telephony and information services,
including the Internet and the Web. WAP is designed to work with all wireless network
technologies (e.g., GSM, CDMA, andTDMA).WAP is based on existing Internet standards,
such as IP, XML, HTML, and HTTPp, as much as possible. It also includes security
facilities. Ericsson, Motorola, Nokia, and Phone.com established the WAP Forum in 1997,
which now has several hundred members. At the time of this writing, the current release of
the WAP specification is version 2.0.
Strongly affecting tThe use of mobile phones and terminals for data services are the
significant limitations of the devices and the networks that connect them. The devices have
limited processors, memory, and battery life. The user interface is also limited, and the
displays small. The wireless networks are characterized by relatively low bandwidth, high
latency, and unpredictable availability and stability compared to wired connections.
Moreover, all these features vary widely from terminal device to terminal device and from
network to network. Finally, mobile, wireless users have different expectations and needs
from other information systems users. For instance, mobile terminals must be extremely easy
to use, much easier than workstations and personal computers. WAP is designed to deal with
these challenges.
The WAP specification includes
• A programming model based on the WWW Programming Model
• A markup language, the Wireless Markup Language, adhering to XML
• A specification of a small browser suitable for a mobile, wireless terminal
• A lightweight communications protocol stack
• A framework for wireless telephony applications (WTAs)
WAP is designed in a layered fashion so that it can be extensible, flexible, and scalable. As a
result, tThe WAP protocol stack is divided into five layers.: The WAP protocol architecture is
shown in figure 29.5 alongside a typical Internet Protocol stack.
• Application Layer Wireless Application Environment (WAE). This layer is of most
interest to content developers because it contains, among other things, device
specifications and the content development programming languages, WML and WML
Script.
• Session Layer Wireless Session Protocol (WSP). Unlike HTTP, WSP has been
designed by the WAP Forum to provide fast connection suspension and reconnection.
• Transaction Layer Wireless Transaction Protocol (WTP). The WTP runs on top of a
datagram service such as User Datagram Protocol (UDP) and is part of the standard suite
of TCP/IP protocols used to provide a simplified protocol suitable for low bandwidth
wireless stations.
• Security Layer Wireless Transport Layer Security (WTLS). WTLS incorporates
security features that are based upon the established Transport Layer Security (TLS)
protocol standard. It includes data integrity checks, privacy, service denial, and
authentication services.
• Transport Layer Wireless Datagram Protocol (WDP). The WDP allows WAP to be
bearer-independent by adapting the transport layer of the underlying bearer. The WDP
presents a consistent data format to the higher layers of the WAP protocol stack, thereby
offering the advantage of bearer independence to application developers.
Each of these layers provides a well-defined interface to the layer above it. This means that
the internal workings of any layer are transparent or invisible to the layers above it. The
layered architecture allows other applications and services to utilize the features provided by
the WAP-stack as well. This makes it possible to use the WAP-stack for services and
applications that currently are not specified by WAP. The WAP protocol architecture is
shown in figure alongside a typical Internet Protocol stack.
Figure 29.5 WAP protocol architecture
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).
WML Scripts
WML Script (Wireless Markup Language Script) is the client-side scripting language of
WML (Wireless Markup Language). A scripting language is similar to a programming
language, but is of lighter weight. With WML Script, the wireless device can do some of the
processing and computation. This reduces the number of requests and responses to/from the
server.
The functions used are stored in a separate file with the extension .wmls. The functions are
called as the filename followed by a hash, followed by the function name.
Example: maths.wmls#squar()
In the example, maths.wmls is the file name and squar() is the function name.
29.3.2.1 WML Scripts Standard Libraries:
There are six standard libraries totally. Here is an overview of them:
• Lang: The Lang library provides functions related to the WMLScript language core.
Example Function: abs(),abort(), characterSet(),float(), isFloat(), isInt(), max(),
isMax(), min(), minInt(), maxInt(), parseFloat(), parseInt(), random(), seed()
• Float: The Float library contains functions that help us perform floating-point
arithmeticoperations.
Example Function: sqrt(), round(), pow(), ceil(), floor(), int(), maxFloat(), minFloat()
• String: The String library provides a number of functions that help us manipulate
strings.
Example Function: length(), charAt(), find(), replace(), trim(), compare(), format(),
isEmpty(), squeeze(), toString(), elementAt(), elements(), insertAt(), removeAt(),
replaceAt()
• URL: The URL library contains functions that help us manipulate URLs.
Example Function: getPath(), getReferer(), getHost(), getBase(), escapeString(),
isValid(), loadString(), resolve(), unescapeString(), getFragment()
• WMLBrowser: The WMLBrowser library provides a group of functions to control
the WML browser or to get information from it.
Example Function: go(), prev(), next(), getCurrentCard(), refresh(), getVar(), setVar()
• Dialogs: The Dialogs library contains the user interface functions.
Example Function: prompt(), confirm(), alert()
WTP is transaction oriented rather than connection oriented. With WTP, there is no explicit
connection setup or teardown but rather a reliable connectionless service. WTP Transaction
Classes WTP provides three transaction classes that may be invoked by WSP or another
higher layer protocol:
• Class 0: Unreliable invoke message with no result message
• Class 1: Reliable invoke message with no result message
• Class 2: Unreliable invoke message with one reliable result message
Class 0 provides an unreliable datagram service, which can be used for an unreliable push
operation. Data from a WTP user are encapsulated by WTP (the initiator, or client) in an
Invoke PDU and transmitted to the target WTP (the responder, or server), with no
acknowledgment. The responder WTP delivers the data to the target WTP user.
Class 1 provides a reliable datagram service, which can be used for a reliable push operation.
Data from an initiator are encapsulated in an Invoke PDU and transmitted to the responder.
The responder delivers the data to the target WTP user and acknowledges receipt of the data
by sending back an ACK PDU to the WTP entity on the initiator side, which confirms the
transaction to the source WTP user. The responder WTP maintains state information for some
time after the ACK has been sent to handle possible retransmission of the ACK if it gets lost
and/or the initiator retransmits the Invoke PDU.
Many applications on the Web today require a secure connection between a client and the
application server. WTLS is the security protocol to ensure secure transactions on WAP
terminal. WTLS is based upon the industry standard Transport Layer Security (TLS)
protocol, formerly known as Secure Socket Layer (SSL).
WTLS has been optimized for use over narrow-band communication channels. It ensures data
integrity, privacy, authentication, and denial-of-service protection. For Web applications, that
employ standard Internet security techniques with TLS, the WAP gateway automatically and
transparently manages wireless security with minimal overhead. It provides end-to-end
security and application-level security. This includes security facilities for en-/decrypting,
strong authentication, integrity, and key management. WTLS complies with regulations on
the use of cryptographic algorithms and key lengths in different countries.
The primary goal is to provide security between client and server in terms of:
• Privacy Data sent is not presented in clear text to make it difficult for another
network user to look at the data. This is done through encrypting the data stream.
• Data integrity If a network user where able to change the sent data, it should be
detected by the client or server that sent the data. This is done through message
digests.
• Authentication A network partner can be sure that he or she is connected with the
true desired partner and not with someone else who pretends to be it. This is done
through digital certificates.
• Denial of service Rejecting and detecting data that is not successfully verified. This is
done through a WTLS function.
Figure 207 the location of WTLS in the WAP architecture model and the internal WTLS
architecture with its different WTLS protocols
Record protocol
The record protocol is the interface to the upper layer (transaction or session layer) and to the
lower layer (transport layer). The record protocol receives messages from the upper layer to
be transmitted. It optionally compresses the data, applies a message authentication code
(MAC), and encrypts and transmits the message. Received data is decrypted, verified,
decompressed, and delivered to a higher layer of the client. Four protocols are defined that
cooperate very closely with the record protocol in a client implementation environment:
• Handshake protocol
This protocol consists of three sub-protocols that allow peers to agree to security
parameters for the record layer. The handshake protocol is responsible for the
negotiation process between the client and server.
• 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.
dependent issues, global interoperability can be acquired using mediating gateways. WDP
architecture is shown in figure.29.7
Figure 29.7 Wireless Datagram Protocol
WDP offers a consistent service at the Transport Service Access Point to the upper layer
protocol of WAP. This consistency of service allows for applications to operate transparently
over different available bearer services. The varying heights of each of the bearer services
shown in Figure 4-2 illustrates the difference in functions provided by the bearers and thus
the difference in WDP protocol necessary to operate over those bearers to maintain the same
service offering at the Transport Service Access Point is accomplished by a bearer adaptation.
WDP can be mapped onto different bearers, with different characteristics. In order to
optimise optimize the protocol with respect to memory usage and radio transmission
efficiency, the protocol performance over each bearer may vary. However, the WDP service
and service primitives will remain the same, providing a consistent interface to the higher
layers.
The WDP layer operates above the data capable bearer services supported by the various
network types. As a general datagram service, WDP offers a consistent service to the upper
layer protocol (Security, Transaction and Session) of WAP and communicate transparently
over one of the available bearer services. WDP supports several simultaneous communication
instances from a higher layer over a single underlying WDP bearer service. The port number
identifies the higher layer entity above WDP. This may be another protocol layer such as the
Wireless Transaction Protocol (WTP) or the Wireless Session Protocol (WSP) or an
application such as electronic mail. By reusing the elements of the underlying bearers, WDP
can be implemented to support multiple bearers and yet be optimized for efficient operation
within the limited resources of a mobile device.
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.
• 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
The gateway works as a WAP proxy. It receives requests from the client, transforms an
HTTP message, and sends it (based on the Uniform Resource Locator (URL)) to the
addressed Web server. When the Web server returns the response, the gateway transforms it
again into a bit-coded output. It then sends it to the mobile network, which directs it to the
WAP client. This method allows the data content and applications to be hosted in standard
Web servers using traditional Web technology.
The WAP gateway is also able to work as a WAP application server (see Figure 193 on page
486). This solution does not need a Web server. It can be used to support end-to-end security
configurations. This could be for applications which require higher access control or a
guarantee of service, like those used for Wireless Telephony Application (WTA) (see 14.5.2,
“Wireless Telephony Application (WTA)” on page 498).
The WAP gateway decreases the response time to the WAP terminal by aggregating data
from different Web servers and caching frequently used information. It also divides large
HTTP responses into smaller transmission units before sending the responses to the client.
The WAP gateway can also interface with subscriber databases and use information to
dynamically customize WML pages for a certain group of users.
The WAP gateway provides transition between the Internet and different non-voice mobile
services. These might be services such as Short Message Services (SMS), Circuit Switched
Data (CSD), or General Packet Radio Services (GPRS).
Usage of a WAP gateway
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.
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
4. The gateway does the bit-encoding, transforms the request into an HTTP message,
and sends it to the Web server (addressed by the URL).
5. The origin server replies to the request by returning a single deck (refer to 14.3.1,
“WML” on page 486), if it is stored in textual format in the origin server.
7. On its way through the gateway, the textual format of each deck has to be onverted
into a format that is better suited for over-the-air transmission to WAP terminals. This
conversion is done by the gateway using the WML encoder to convert the textual
format into a binary format.
8. The gateway sends the encoded content to the client via the WAP protocol stack
layers (refer to Figure 197 on page 496) over the wireless network.
9. At the client’s WAP terminal, the data is received and can be displayed and
interpreted, for example, by a microbrowser.
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.
Existing mark-up languages and content written in those mark-up languages presume that
devices have similar display sizes, memory capacities, and software capabilities. Content is
also largely oblivious to the available network bandwidth and perceived network latency.
Moreover, users may have content presentation preferences that also cannot be transferred to
the server for consideration.
Recently, work has begun within the World-Wide Web Consortium (W3C) to define
mechanisms for describing and transmitting information about the capabilities of Web clients
and the display preferences of Web users. The Composite Capabilities/Preferences Profile
(CC/PP) note defines a high-level structured framework for describing this information using
the Resource Description Framework (RDF). CC/PP profiles are structured into named
“components,” each containing a collection of attribute-value pairs, or properties. Each
component may optionally provide a default description block containing either a set of
default values for attributes of that component or a URI that refers to a document containing
those default values.
WTA provides tools for building telephony applications. It is primarily designed for network
operators, carriers, and equipment vendors. Network security and reliability is a major
consideration. Extensions are added to the standard WML/WML Script browser to support an
additional WTA Application Programming Interface (WTAI). WTAI includes the following
functions: call control, network text messaging, phone book interface, indicator control, and
event processing.
LBS Services
Tracking
This is a rather large category that contains everything from the difficult fleet applications to
enabling mobile commerce. Fleet applications typically entail tracking vehicles for purposes
of the owning company knowing the whereabouts of the vehicle and/or operator. Tracking is
also an enable of mobile commerce services. A mobile user could be tracking and provided
information that he has predetermined he desires, such as notification of a sale on men's suits
at a store close to the user's current proximity.
i-Mode
WAP uses a special language called Wireless Markup Language (WML) for communication
between a special protocol conversion device called a WAP Gateway (GW) and content on
the Internet. The WAP GW converts between WML and HTML, allowing delivery of WAP
based content to a WAP capable mobile device.
In most networks today, the connection between the MSC and the GW is circuit switched as
indicated in the illustration above in which the MSC must utilize the Public Switched
Telecommunications Network (PSTN) to connect to the GW. As mobile network operators
deploy next generation packet-data technologies such as General Packet Radio Service
(GPRS), the connection between the MSC and the WAP GW will be upgraded to leverage the
faster packet connection facilitated by the GPRS network. In contrast to WAP, iMode utilizes
an overlay packet network for direct communications (no gateway needed) to the content
providers on the Internet.
i-Mode is the packet-based service for mobile phones offered by Japan's leader in wireless
technology, NTT DoCoMo. i-mode is built on a firm foundation of advanced technology. The
use of packet transmissions offers continuous access, while the use of a subset of HTML
makes content creation easy and provides simple conversion of existing websites. NTT
DOCOMO's packet-switched technology was specifically designed to provide users with
"always-on" network access, eliminating the need to log on or off. In turn, i-mode the service
developed for this packet-switched technology provides the most efficient wireless access
possible as no dedicated radio channel is required. The result is lower costs for customers as
they are billed according to volume of data sent and received, rather than by time spent
connected. i-mode offers one more significant benefit i.e., mobile voice and data service in a
single convenient package. This voice/data flexibility is unprecedented. People can download
information about events, restaurants, etc., and then make reservations, or place calls to
numbers searched in the i-mode directory.
SyncML
SyncML is the leading open industry standard for universal synchronization of remote data
and personal information across multiple networks, platforms and devices. The SyncML
initiative recently consolidated into the Open Mobile Alliance (OMA), contributing their
technical work to the OMA technical Working Groups: Device Management Working Group
and Data Synchronization Working Group. SyncML's goal is to have networked data that
support synchronization with any mobile device, and mobile devices that support
synchronization with any networked data. SyncML is intended to work on transport protocols
as diverse as HTTP, WSP (part of WAP) and OBEX and with data formats ranging from
personal data (e.g. vCard & vCalendar) to relational data and XML documents.
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.
•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.