About Me

Chennai, Tamil Nadu, India
Hello all! I am Suneetha Alluri. Pl. send your reviews and materials to the mail ID doeaccnotes@gmail.com

Friday, August 6, 2010

Networking and Mobile Communications - Wireless Application Protocol (WAP)

Chapter-8: Wireless Application Protocol (WAP)

January-2004 [18]

5.a)         What Is the fundamental difference between WML and HTML? Why is this difference important with respect to hand held devices?                    [10]

Differences Between HTML and WAP/WML

WAP/WML

HTML

Markup language for wireless communication

Markup language for wired communication

Makes use of variables

Does not use variables

WML script stored in a separate file

Javascript is embeded in the same HTML file

Images stored as WBMP

Images are stored as GIF, JPEG or PNG

WBMP is a 2 bit image

Size of the images are much larger in HTML

Case sensitive

Not case sensitive

WML has fewer tags than HTML

HTML has more tags than WML

A set of 'WML Cards' make a 'DECK'

A set of 'HTML pages' make a 'SITE'


b)         What is the fundamental difference between WML and HTML?                                    [4]

b)         Wireless Markup Language (WML) is optimized for limited capability devices and networks. Describe WML constrains, features and document model?                                 [6]

d)         Wireless markup language.                                                                                  [6]


WAP stands for Wireless Access Protocol, a general term used to describe the multi-layered protocol and related technologies that bring Internet content to mobile devices such as PDAs and cell phones.

Such devices are referred to as thin clients because they have one or more constraints in the form of display, input, memory, CPU, or other hardware or usability limitations. The platform constraints and the slower (and more expensive) bandwidth of cellular and related networks make standard Internet protocols difficult to utilize. Using the growing set of WAP tools and protocols, however, the mobile Internet is quite a capable tool.

In some cases, WML stands for Website META Language, a set of free Web-authoring tools for Unix. The acronym’s wider use, however, is to denote the phrase Wireless Markup Language, which is a special subset of XML (Extensible Markup Language), initially developed through the WAP (Wireless Applications Protocol) Forum begun by Ericsson, Motorola, Nokia, and Unwired Planet.

WML is designed with the constraints of small, narrowband devices (such as mobile phones and palm-sized computers) in mind. These constraints include small, often monochrome displays, limited user input facilities (small dial pads with few other keys and stylus input), narrowband network connections (often slower than standard dial-up access), and limited memory and computational resources.

WML includes four major functional areas. The first is text presentation and layout; WML includes text and image support, including a variety of formatting and layout commands. The second, the deck/card organizational metaphor, suggests that all information in WML is organized into a structure similar in nature to a collection of playing cards and decks that correspond somewhat to the page/site model found in HTML (Hypertext Markup Language) Web document structures. In this framework, cards signify one or more units of interaction, and each user action moves him one card deeper into the deck. Whereas a single HTML Web page may present a user with a variety of possible actions, each WML document (or card) contains just one function.

The third functional area, that of inter-card navigation and linking, includes support for explicitly managing the navigation between cards and decks. The fourth and final area is string parameterization and state management. Parameterization is a fancy programmer’s term having to do with passing information from one portion of a program to another through the use of arrayed data and preinitialized variables. State management pertains to the way in which a document reacts to a specific visitor on the basis of cookies (for example, think of the way an HTML Web page presents different information on a user based on cookie information that offers the details of his prior visits).

A major difference between HTML and WML is that the basic unit of navigation in HTML is a page, while that in WML is a card. A WML file can contain multiple cards and they form a deck. When a user goes to a WAP site, the mobile browser loads a WML file that contains a deck of cards from the server. Only one card will be shown on the screen of the wireless device each time. If the user goes to another card of the same deck, the mobile browser does not have to send any requests to the server since the file that contains the deck is already stored in the wireless device.


WML is designed in this way because wireless devices have a high latency for connecting to the server. Downloading a deck of cards at a time can lower the number of round trips to the server.
You can put links, text, images, input fields, option boxes and many other elements in a card.


WML Document Structure

Hello World WML Example

Let's take a look at our first WML example. It shows the structure of a typical WML document.

(helloWorldEg1.wml)


<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.3//EN" "http://www.wapforum.org/DTD/wml13.dtd">


<wml>

  <card id="card1" title="WML Tutorial">

    <p>Hello World</p>

  </card>


  <card id="card2" title="WML Tutorial">

    <p>Welcome to the world of WML</p>

</card>

</wml>


The result of the "Hello World" WML example in mobile phone emulators is shown below:
Wireless Access Protocol (WAP) is a result of continuous work to define an industry-wide standard for developing applications over wireless communication networks. The WAP Forum, originally founded by Ericsson, Motorola, Nokia, and Unwired PlanetWML, was formed to create global wireless protocol specification that works across differing wireless network technology types, for adoption by appropriate industry standards organization.

Wireless Markup Language (WML) is a markup language based on XML, and is used to specify content and user interface for narrow-band devices, including cellular phones and pagers. WML is designed with the constraints of small, narrow-band devices in mind. These constraints include:


  • Small display and limited user input facilities

  • Narrow band network connection

  • Limited memory and computational resources

  • The Wireless Markup Language is WAP’s analogy to HTML used on the WWW. WML is based on the Extensible Markup Language (XML). 

  • WML uses a deck/card metaphor to specify a service. A card is typically a unit of interaction with the user, that is, either presentation of information or request for information from the user. 

  • A collection of cards is called a deck, which usually constitutes a service. This approach ensures that a suitable amount of information is displayed to the user simultaneously since inter-page navigation can be avoided to the fullest possible extent.

  •    Key features of WML include:   
    · Variables
    · Text formatting features
    · Support for images
    · Support for soft-buttons
    · Navigation control
    · Control of browser history
    · Support for event handling (for e.g. telephony services)
    · Different types of user interactions, e.g. selection lists and input fields

  • WML can be binary encoded by the WAP Gateway/Proxy in order to save bandwidth in the wireless domain.

  • WMLScriptWMLScript is based on ECMAScript, 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.

  • WMLScript can be used for e.g. validation of user input. Since WML does not provide any mechanisms for achieving this, a round-trip to the server would be needed in order to determine if user input is valid or not if scripting was not available. Access to local functions in a wireless device is another area where WMLScript is used; for example access to telephony related functions. WMLScript does also support WMLScript Libraries. These libraries contain functions that extend the basic WMLScript functionality. This provides a means for future expansion of functions without having to change the core of WMLScript. Just as with WML, WMLScript can be binary encoded by the WAP Gateway/Proxy in order to minimise the amount of data sent over the air.
A Brief History of WAP

As previously stated, WAP refers to a wide range of technologies and protocols, all related to mobile Internet functionality. This functionality has roots dating back to the mid 1990s. At that time, several vendors were working on the mobile Internet problem as mobile device sales skyrocketed, and several competing technologies emerged:


  • Nokia's Narrow Band Sockets (NBS) and Tagged Text Markup Language (TTML)

  • Ericsson's Intelligent Terminal Transfer Protocol (ITTP)

  • Unwired Planet's Handheld Device Markup Language (HDML)

Each technology had its own purpose, but some overlapped with others in various areas. This diversity threatened to fragment the wireless industry along provider lines. In mid 1997, the WAP Forum was founded to aid in communication among the developers and to spur a common set of protocols and technologies. In the same year, the industry took another step forward with the formation of the Open Mobile Alliance (OMA), which combined several distinct development and standards bodies into one.

How Does WAP Work?

These articles will focus on the delivery of WML content to mobile devices over a cellular or related technology network. However, the delivery of many protocols and technologies takes the same route-namely, through a proxy server that bridges the gap between the wired Internet and the wireless service provider's network.


Figure 1.1 The WAP Gateway provides wireless networks with Internet access and optional content translation and filtering.

This proxy server manages the communication between the wireless client and the Internet server(s), acting as a gateway to the wired Internet. It caches content and in some cases even translates raw HTML into WAP-compatible protocols such as WML.

Many mobile devices have a built-in wireless browser. Although several different browsers are in use today among the various wireless providers, most browsers support WML, either natively or translated into HDML. A popular precursor to WML, the Handheld Device Markup Language (HDML), is still supported on several mobile platforms. However, due to the limitations of HDML (supporting only a handful of navigation tags and virtually no formatting tags), WML is becoming the most widely used mobile markup language. That said, if you plan to support a particular platform, it's best to test your code extensively on that particular device.

Note: When coding for the general public, be careful to stick to the standards and avoid using proprietary extensions to the various languages, no matter how tempting the feature set of the extensions. If you decide to provide the extensions to those who can use them, you should take the necessary server steps to identify the connecting browser and deliver code customized for that browser.

What Is WML?

WML (Wireless Markup Language) is the dominant language in use with wireless devices today. Essentially, WML is a subset of HTML, but has its roots in XML. Those developers with a solid base in XML should have a relatively easy time coding WML.

The current WML standard is 1.3, although many mobile devices in use today support only the WML 1.1 standard. Therefore it's prudent to stay away from 1.3-specific features, unless you know that your target market's devices are 1.3-ready.

There are several key differences between WML and standard HTML, including the following:

WML is highly structured and very particular about syntax. Several current HTML browsers allow for "messy" code such as missing tags and other formatting snafus. Such mistakes are not allowed in WML; the mobile browser will complain and generally won't display the page.

  • WML is case sensitive. The tags <b> and <B> are treated as different tags, although they accomplish the same purpose (bold text). Therefore, you must be careful to match the case of your opening tags with your closing tags (for example, <b>This is bold</B> will not work as expected).

  • Many tags have required attributes. Developers accustomed to HTML may be used to including only attributes they need-in some WML tags, you must include a few attributes, even if they are blank or default.

  • WML pages are structured in "decks" (see the next section), allowing for multiple pages to be defined in each WML file.

WML also has a client-side scripting language, WMLScript, to help automate particular tasks, validate input, and so on. WMLScript is a subset of JavaScript and will be covered in a later article

Understanding Decks

WML pages are structured within "decks," allowing several pages ("cards") to be defined in each WML file. This deck analogy allows multiple pages to be delivered to the mobile client at the same time, minimizing the loading time between related pages. However, the limited memory on most devices constrains the deck size, usually to less than 1024 bytes. Therefore, careful consideration and planning should go into any WAP application; don't start coding without investing time in planning.

Note: Remember your audience. Mobile users generally scroll through cards rapidly and will be reading on a display that's a mere handful of characters wide (usually less than 20 characters) and usually less than 10 lines high. Keep your content to a minimum, provide an intuitive navigation structure, and optimize your decks to maximize links within the deck and minimize links outside of the deck.

Visualizing a physical "deck of cards" structure can help in understanding the principles of WML. For example, suppose we have three simple cards (pages) as shown below:


Figure 1.2 - The physical card analogy to WML decks helps visualize how they work.

These cards together form a deck and are delivered to the mobile device in one file. Now suppose that each card links to the next (card one links to card two, which links to card three, and so on), and that each card also has a "back" link to take the user back to the previous card. As the user navigates the deck, the cards stack in memory as shown below:


Figure 1.3 - As the user follows the links through the deck, the cards stack up in memory.

A developer accustomed to HTML might be tempted to implement the "back" feature by providing a link to the deck, specifying the previous card. However, this would cause the mobile device to re-request the whole deck before redisplaying the card-a card it already had in memory.

Instead, you should use the tag, which tells the browser to remove the current page and display the previous page in the history list (like using the Back button on a PC browser). Of course, the content of the previous page might need to be refreshed each time it's accessed; in that case, valid techniques could include recalling the whole deck or specifying that the page not be cached. Proper navigation will be covered in future articles.


Figure 1.4 - The <prev> tag "pops" the top card off the stack (out of the history list), redisplaying the previous card in the history.

Setting Up Your Server for WML

To configure your Web server to deliver WML, you must define the related MIME types for WML content. Web servers and client browsers use MIME (Multipurpose Internet Mail Extensions) to communicate the type of data that is being sent. Before sending data, the server sends a MIME identifier to the client browser, identifying the format of the following data. The client browser can then properly decode and apply the data. Most WML applications require three MIME types, as listed in the following table.


File Extension

MIME Type Definition

Use

.wml

text/vnd.wap.wml

WML source file

.wmls

text/vnd.wap.wmlscript

WML script file

.wbmp

image/vnd.wap.wbmp

Wireless bitmap file (image)

To add MIME types to your Web server, you must have administrator access to the server. The following sections cover setting up Microsoft's Internet Information Server (IIS) and Apache for WML. If you're using another type of server, read your server's documentation for more information on adding MIME types

To add the MIME types to IIS, open the Internet Information Services Management Console (MC). Access to this console varies depending on which specific operating system you're using and how you installed IIS, but can usually be found under Administrative Tools (Windows 2000) or Option Pack (Windows NT).

Open the IIS MC, click on the server to expand its tree, and then right-click on Default Web Site and choose Properties. (Note: If you don't want all the sites on your server to be able to deliver WML, right-click on those sites you want to be WML-enabled and then continue following these steps.)

Click on the HTTP Headers tab and then click on the File Types button under the MIME Map section. In the File Types dialog, click on New Type and enter the extension and MIME definition ("Content Type") from the preceding table. Click on OK. Repeat this process for the other two MIME types.

When you're finished, close the Web Site Properties dialog by clicking on OK. On some servers, there may be nodes or devices that also define HTTP codes and need to inherit the new setting(s). Choose the appropriate options for your system. Exit the IIS MC. Usually you won't need to restart the IIS service, but it wouldn't hurt to do so just in case.

Tip: Before exiting the Web Site Properties, you may want to add an entry for WML on the Documents tab (such as index.wml). This causes the server to display that document by default, eliminating the need for your visitors to specify a particular file in the URL to access your site.

Adding MIME Types to Apache

To add MIME types to Apache, you must edit the httpd.conf file. This file's location varies from system to system.

This file uses "AddType" lines to define MIME types. Find the section where these appear and add the following lines:

     AddType text/vnd.wap.wml .wml

     AddType text/vnd.wap.wmlscript .wmls

     AddType image/vnd.wap.wbmp .wbmp

Save and close the file and restart the Apache server to reload the configuration with the new MIME types.

Tip: You may want to add "index.wml" or comparable entry to the DirectoryIndex section of the Apache configuration file (requires running mod_dir). This causes the server to display that document by default, eliminating the need for your visitors to specify a particular file in the URL to access your site.

A Sample WML Deck

Now that your server is set up to handle WML correctly, let's try serving up a sample page. The following listing shows the bare minimum coding necessary to contain a WML deck, consisting of a single, blank card:

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

      <card id="Card1" title="Sample ">

      </card>

</wml>

The first line of the preceding code specifies that the file is XML and version 1.0-compatible. The second line defines the XML scope of the file; namely, that its DOCTYPE is WML, and where the Document Type Definition (DTD) can be found.

Tip: If you're unfamiliar with XML and don't fully understand these lines, just make sure that they appear at the beginning of all your WML documents.

The next line begins the WML definition with the <wml> tag.

The <card> tag defines a card in the deck. Note that the id and title attributes can be anything you choose, but should be short and to the point, and the id must contain only letters and numbers (no punctuation or spaces).

If you want to try the preceding example, create the file on your Web server (in plain text form), adding the following lines between the <card> tags to provide content for the card:

<p>

A Sample Card

</p>

Place the file in an accessible directory with adequate permissions to access it from an external browser. Now visit the Wapalizer at http://www.gelon.net. Type the URL to the file in the Wapalizer box and click on the Wapalize button. You should see a screen similar to the output below.



Figure 1.5 - Your sample page in the Openwave simulator.




b)         What are the primary goals of the WAP Forum efforts and how are they reflected In the WAP protocol architecture? In which situation is WTP not used? What are the disadvantages of implementing TCP/IP directly over the mobile network?                     [8]

g)         What are the important functions of a WAP Gateway?                                               [4]

b)         What is the functionality of the WAP gateway? Why is this functionality required? Draw a simple diagram showing how the WAP gateway interfaces with wireless devices.                 [4]

a)         Explain WAP stack. Prove that WAP session protocol and WAP transaction protocol over UDP conserves bandwidth as compared to TCP over IP.                                                      [9]

b)         Why does WAP define its own security layers and does not rely on the security provided by the mobile phone network? Discuss the important functions WSP and WAE.                 [9]

a)         Draw and explain the WAP network configuration. Also discuss the WAP protocol stack.             [9]

b)         How does a WAP Gateways act as a bridge between the mobile world and the Internet?                [4]

b)         Explain each of the following in detail with reference to WAP:

i)          Wireless Datagram Protocol

ii)         Wireless Transaction Protocol

iii)                Wireless Session Protocol                                                                         [6]

c)         What are Wireless Application Protocol (WAP) gateway and its main functions?                [4]

WAP WIRELESS COMMUNICATION

WAP, Wireless Application Protocol aims to provide Internet content and advanced telephony services to digital mobile phones, pagers and other wireless terminals. The protocol family works across different wireless network environments and makes web pages visible on low-resolution and low-bandwidth devices. WAP phones are "smart phones" allowing their users to respond to e-mail, access computer databases and to empower the phone to interact with Internet-based content and e-mail.

WAP specifies a Wireless application Environment and Wireless Protocols. The Wireless application environment (WAE) is based on WSP (Wireless Session Protocol) and WTP (Wireless Transaction Protocol).

The OSI Model for Wireless Communication







WAP Protocol stack

The basic construction of WAP architecture can be explained using the following model. The order of the independent levels – which are a hierarchy - has the advantage that the system is very flexible and can be scaled up or down. Because of the different levels – or stacks - this is called the "WAP Stack", which is divided into 5 different levels.


  • Application Layer: Wireless Application Environment (WAE).

  • Session Layer: Wireless Session Protocol (WSP).

  • Transaction Layer: Wireless Transaction Protocol (WTP).

  • Security Layer: Wireless Transport Layer Security (WTLS).

  • Transport Layer: Wireless Datagram Protocol (WDP).

Each stack overlaps with the stack below. This stack architecture makes it possible for software manufacturers to develop applications and services for certain stacks. They may even develop services for stacks which are not specified yet.

The WAP stack is an entity of protocols which cover the wireless data transfer. The diagram above shows the order of the different stacks and their protocols. This includes the stacks responsible for the layout as well as the stacks resposible for the actual data transfer. The highest level or stack is the one which deals with the layout. A lower stack is responsible for the transfer and the security through WTLS (Wireless Transport Layer Security). All stacks lower than this one are being called network stack. Due to this hierarchy of stacks any changes made in the network stacks will have no influence over the stacks above

Application Layer (WAE and WTA)

The environment for wireless applications (Wireless Application Environment WAE) and the application for wireless phones (Wireless Telephony Application WTA) are the highest layer in the hierarchy of WAP architechture. These two are the main interface to the client device, which gives and controls the description language, the script language of any application and the specifics of the telephony. WAE and WTA have only a few easy functions on the client device, like the maintenance of a history list, for example.

Session Layer (Wireless Session Protocol WSP)

The Wireless Session Protocol (WSP) has all the specifications for a session. It is the interface between the application layer and the transfer layer and delivers all functions that are needed for wireless connections. A session mainly consists of 3 phases: start of the session, transfering information back and forth and the end of the session. Additionally, a session can be interrupted and started again (from the point where it was interrupted.)

Transaction Layer (Wireless Transaction Protocol WTP)

The specifications for the transfer layer are in the Wireless Transaction Protocol (WTP). Like the User Datagramm Protocol (UDP), the WTP runs at the head of the datagramm service. Both the UDP and the WTP are a part of the standard application from the TCP/IP to make the simplified protocol compatible to mobile terminals. WTP supports chaining together protocol data and the delayed response to reduce the number of transmissions. The protocol tries to optimize user interaction in order that information can be received when needed.

Wireless Transport Layer Security WTLS

The Wireless Transport Layer Security (WTLS) is a optional layer or stack which consists of description devices. A secure transmission is crucial for certain applications such as e-commerce or WAP-banking and is a standard in these days. Furthermore WTLS contains a check for data integrity, user authentification and gateway security.

Transport Layer (Wireless Datagram Protocol WDP)

The Wireless Datagram Protocol (WDP) represents the transfer or transmission layer and is also the interface of the network layer to all the above stacks/layers. With the help of WDP the transmission layer can be assimilated to the specifications of a network operator. This means that WAP is completely independent from any network operator. The transmission of SMS, USSD, CSD, CDPD, IS-136 packet data and GPRS is supported. The Wireless Control Message Protocol (WCMP) is an optional addition to WAP, which will inform users about occurred errors.


WTLS

Wapforum version 11/99

Wireless Transport Layer Security is a protocol based on the TLS protocol. It is used with the WAP transport protocols and has been optimised for use over narrow-band communication channels. The WTLs layer is above the transport protocol layer. The required security layer of the protocol determines whether it is used or not. It provides a secure transport service interface that preserves the transport service interface below; additionally it provides an interface for managing secure connections. WTLS aims to provide privacy, data integrity and authentication between two communication applications. Among its features are datagram support, optimised handshaking and dynamic key refreshing. It is optimised for low-bandwidth bearer networks with relatively long latency.

The WTLS Record Protocol is a layered protocol. The Record Protocol takes messages to be transmitted, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, and decompressed, then delivered to higher-level clients. Four record protocol clients are described in the WTLS standard; the change cipher spec protocol, the handshake protocol, the alert protocol and the application data protocol. If a WTLS implementation receives a record type it does not understand, it ignores it. Several records can be concatenated into one transport SDU. For example, several handshake messages can be transmitted in one transport SDU. This is particularly useful with packet-oriented transports such as GSM short messages.


Handshake
protocols

Alert Protocol

Application
Protocol

Change Cipher
Spec Protocol

Record protocol


The handshake protocol is made up of 3 sub-protocols. All messages are encapsulated in a plaintext structure.

WTP

WAPforum WTP 11/6/99

The Wireless Transaction Protocol provides the services necessary for interactive browsing applications. During a browsing session the client requests information from a server and the server responds with the information. This is referred to as a transaction. WTP runs on a datagram service and possible a security service.

Advantages of WTP include:

  • Improved reliability over datagram services

  • Imported efficiency over connection oriented services

  • As a message oriented protocol, it is designed for services oriented towards transactions.

Main features:


  • 3 kinds of transaction services.


    • Class 0 Unreliable invoke messages with no result messages

    • Class 1: Reliable invoke messages with no result messages

    • Class 2: Reliable invoke messages with exactly one reliable result message.
  • Reliability achieved by using unique transaction identifiers, acknowledgements, duplicate removal; and retransmissions.

  • No explicit set up or tear down phases.

  • Optional user-to-user reliability.

  • Optionally the last acknowledgement of the transaction may contain out-of-band information.

  • Concatenation may be used to convey multiple PDUs in one service data unit of the datagram transport.

  • The basic unit of interchange is an entire message, not a stream of bytes.

  • Mechanisms are provided to minimize the number of transactions replayed as a result of duplicate packets.

  • Abort of outstanding transactions.

  • For reliable invoke messages, both success and failure reported.

  • Asynchronous transactions allowed.

The protocol data unit (PDU) consists of the header and data (if present). The header contains a fixed part and a variable part; The variable parts are carried in the Transport Information Item (TPI). Each PDU has its own fixed header (the fixed headers vary slightly in structure). As an example, the structure of the invoke PDU fixed header appears below:


1

2-5

6

7

8

Con

PDU Type

GTR

TTR

RID

TID

Version

TIDnew

U/P

RES

RES

TCL

CON continue flag (1 bit):
The continue flag indicates the presence of any TPIs in the variable part. If the flag is set, there are one or more TPIs in the variable portion of the header. If the flag is clear, the variable part of the header is empty. This flag is also used as the first bit of a TPI, and indicates whether the TPI is the last of the variable header. If the flag is set, another TPI follows this TPI. If the flag is clear, the octet after this TPI is the first octet of the user data.

PDU type
The PDU type determines the length and structure of the header and dictates what type of WTP PDU the PDU is (Invoke, Ack, etc). This provides information to the receiving WTP provider as to how the PDU data should be interpreted and what action is required.

The following PDU types are defined:

PDU Code

PDU Type

0x01

Invoke

0x02

Result

0x03

Ack

0x04

Abort

0x05

Segmented Invoke

0x06

Segmented Result

0x07

Negative Ack

Group trailer (GTR) and Transmission trailer (TTR) flag (2 bit):
When segmentation and re-assembly is implemented, the TTR flag is used to indicate the last packet of the segmented message. The GTR flag is used to indicate the last packet of a packet group.

GTR/TTR flag combinations:

GTR TTR Description

00

Not last packet

01

Last packet of message

10

Last packet of packet group

11

Segmentation and Re-assembly NOT supported.

The default setting should be GTR=1 and TTR=1, that is, WTP segmentation and re-assembly not supported.

RID Re-transmission Indicator (1 bit):
Enables the receiver to differentiate between packets duplicated by the network and packets re-transmitted by the sender. In the original message the RID is clear. When the message gets re-transmitted the RID is set.

TID Transaction identifier (16 bit):
The TID is used to associate a packet with a particular transaction.

Version
The current version is 0X00

TIDnew flag
This bit is set when the Initiator has wrapped the TID value, i.e. set it to be lower than the previous TID value.

U/P
When this flag is set it indicates that the Initiator requires a User acknowledgement from the server WTP user. The WTP user confirms every received message.

RES
This is a reserved bit and its value should be set to 0.

TCL
The transaction class shows the desired transaction class in the invoke message.

Packet sequence number (8 bit):
This is used by the PDUs belonging to the segmentation and re

WSP

WAP WSP 5/11/99

The Session layer protocol family in the WAP architecture is called the Wireless Session Protocol, WSP. WSP provides the upper-level application layer of WAP with a consistent interface for two session services. The first is a connection-mode service that operates above a transaction layer protocol WTP, and the second is a connectionless service that operates above a secure or non-secure datagram transport service.

The Wireless Session Protocols currently offer services most suited for browsing applications. WSP provides HTTP 1.1 functionality (it is a binary form of HTTP) and incorporates new features such as long-lived sessions, a common facility for data push, capability negotiation and session suspend/resume. The protocols in the WSP family are optimized for low-bandwidth bearer networks with relatively long latency. Requests and responses can include both headers and data. WSP provides push and pull data transfer WSP functions on the transaction and datagram services.

Messages can be in connection mode or connectionless. Connection mode messages are carried over WTP. In this case the protocol consists of WTP protocol messages with WSP PDUs as their data. Connectionless messages consist only of the WSP PDUs.

The general structure of the WSP PDU is as follows:


1 bite1 bite



TID/PIDPDU Type

Type Specific Contents


TID/PID
Transaction ID or Push ID. The TID field is used to associate requests with replies in the connectionless session service. The presence of the TID is conditional. It is included in the connectionless WSP PDUs, and is not included in the connection-mode PDUs. In connectionless WSP, the TID is passed to and from the session user as the "Transaction Id" or "Push Id" parameters of the session primitive

PDU type
The Type field specifies the type and function of the PDU. The type numbers for the various PDUs are defined below. The rest of the PDU is type-specific information, referred to as the contents.

Number

Name Assigned

0x00

Reserved

0x01

Connect

0x02

ConnectReply

0x03

Redirect

0x04

Reply

0x05

Disconnect

0x06

Push

0x07

ConfirmedPush

0x08

Suspend

0x09

Resume

0x10–0x3

FUnassigned

0x40

Get

0x41

Options (Get PDU)

0x42

Head (Get PDU)

0x43

Delete (Get PDU)

0x44

Trace (Get PDU)

0x45-0x4

FUnassigned (Get PDU)

0x50-0x5

FExtended Method (Get PDU)

0x60

Post

0x61

Put (Post PDU)

0x62–0x6

FUnassigned (Post PDU)

0x70-0x7

FExtended Method (Post PDU)

0x80-0x

FFReserved



The WAP Forum is the industry association that has developed the de-facto world standard for wireless information and telephony services on digital mobile phones and other wireless terminals. The primary goal of the WAP Forum is to bring together companies from all segments of the wireless industry to ensure product interoperability and growth of the wireless market.

WAP is designed in a layered fashion so that it can be extensible,flexible, and scalable. As a result, the WAP protocol stack is divided into five layers:

*       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 utilise 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 below alongside a typical Internet Protocol stack.


Note that the mobile network bearers in the lower part of the figure above are not part of the WAP protocol stack.

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. In the chapter "WAP - the wireless service enabler" the WAP WAE programming model was introduced. This chapter will focus on the various components of WAE:

*       Addressing model
A 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).

*       WMLScript
A lightweight scripting language. WMLScript is based on ECMAScript, 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.

Hardware and Software Requirement:

At minimum, developing WAP applications requires a web server and a WAP simulator. Using simulator software while developing a WAP application is convenient as all the required software can be installed on the development PC.

Although software simulators are good in their own right, no WAP application should go into production without testing it with actual hardware. The following list gives a quick overview of the necessary hardware and software to test and develop WAP applications:

*       a Web server with connection to the Internet

*       a WML to develop WAP application

*       a WAP simulator to test WAP application

*       a WAP gateway

*       a WAP phone for final testing

Microsoft IIS or Apache on Windows or Linux can be used as the web server and Nokia WAP Toolkit version 2.0 as the WAP simulator.

Please have look at WAP - Useful Resources to find out all the above components.

Configure Web Server for WAP:

In the WAP architecture, the web server communicates with the WAP gateway, accepting HTTP requests and returning WML code to the gateway. The HTTP protocol mandates that each reply must include something called a Multi-Purpose Internet Mail Extensions (MIME) type.

In normal web applications, this MIME type is set to text/html, designating normal HTML code. Images, on the other hand, could be specified as image/gif or image/jpeg, for instance. With this content type specification, the web browser knows the data type that the web server returns.

In WAP applications a new set of MIME types must be used, as shown in the following table:


File type

MIME type

WML (.wml)

text/vnd.wap.wml

WMLScript (.wmls)

text/vmd.wap.wmlscript

WBMP (.wbmp)

image/vnd.wap.wbmp


In dynamic applications, the MIME type must be set on the fly, whereas in static WAP applications the web server must be configured appropriately.

For more information about configuring MIME types for your web server, please consult your web server documentation

The topmost layer in the WAP architecture is made up of WAE (Wireless Application Environment), which consists of WML and WML scripting language.

WML scripting language is used to design applications that are sent over wireless devices such as mobile phones. This language takes care of the small screen and the low bandwidth of transmission. WML is an application of XML, which is defined in a document-type definition.

WML pages are called decks. They are constructed as a set of cards, related to each other with links. When a WML page is accessed from a mobile phone, all the cards in the page are downloaded from the WAP server to mobile phone showing the content.

WML commands and syntaxes are used to show content and to navigate between the cards. Developers can use these commands to declare variables, format text, and show images on the mobile phone.

WAP Program Structure:

A WML program is typically divided into two parts: the document prolog and the body. Consider the following code:




<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//EN"

"http://www.wapforum.org/DTD/wml12.dtd">

<wml>

<card>



...

</card>

...more cards...

</wml>

The first line of this text says that this is an XML document and the version is 1.0. The second line selects the document type and gives the URL of the document type definition (DTD). This DTD gives the full XML definition of WML. The DTD referenced is defined in WAP 1.1, but this header changes with the versions of the WML. The header must be copied exactly so that the tool kits automatically generate this prolog.

The body is enclosed within a <wml>...</wml> tag pair as shown above. The body of a WML document can consist of one or more of the following:

*       Deck

*       Card

*       Content to be shown

*       Navigation instructions

WML Commands:

The commands used in WML are summarized as follows:

Formatting:

Command

Description

<p>

Paragraph

<b>

Bold

<big>

Large

<em>

Emphasized

<I>

Italicized

<small>

Small

<strong>

Strongly Emphasized

<u>

Underlined

<br>

Line Break

Inserting images:

<img src="image-path/image - name" alt="Picture not available" />

Using Tables:

Command

Description

<table>

Definition of a table

<tr>

Defining a row

<td>

Defining a column

<Thead>

Table header

Variables:

Declared as:

<setvar name="x" value="xyz"/>

Used as:

$ identifier or
$ (identifier) or
$ (Identifier; conversion)

Forms:

Command

Description

<select>

Define single or multiple list

<input>

Input from user

<option>

Defines an option in a selectable list

<fieldset>

Defines a set of input fields

<optgroup>

Defines an option group in a selectable list

Task Elements

Command

Description

<go>

Represents the action of switching to a new card

<noop>

Says that nothing should be done

<prev>

Represents the action of going back to the previous card

<refresh>

Refreshes some specified card variables.

Events:

The various events are as follows:

Command
Description

<do>

Defines a do event handler

<onevent>

Defines an onevent event handler

<postfield>

Defines a postfield event handler

<ontimer>

Defines an ontimer event handler

<onenterforward>

Defines an onenterforward handler

<onenterbackward>

Defines an onenterbackward handler

<onpick>

Defines an onpick event handler

Sample WML Program:

Keep the following WML code into info.wml on your server. If your server is WAP enabled then you can access this page using any WAP device.

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.2//EN"

"http://www.wapforum.org/DTD/wml12.dtd">

<!-- WML prolog.declaration of file type and version>



<wml>

<!-- Declaration of the WML deck>

<card id="info" newcontext="true">

<!-- declaration of a card in deck>

<p align="center"><b>Information Center</b></p>

<!--paragraph declaration to display heading>

<p>

<!--paragraph declaration to display links>

<a href="Movie.wml">1. Movies info.</a>

<a href="Weather.wml">2. Weather Info.</a>

<!--declaration of links for weather and movies>

</p>

</card>

<!-- card end>

</wml>

<!-- program end>

WMLScript (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 WMLScript, the wireless device can do some of the processing and computation. This reduces the number of requests and responses to/from the server.

This chapter will give brief description of all the important WML Script components.

WML Script Components:

WML Script is very similar to Java Script. Almost WML Script components have similar meaning as they have in Java Script. A 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

Check for complete detail of The WML 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

Check for complete detail of WML Script Control Statements.

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:


maths.wmls#squar()


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 arithmetic operations.
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()

WML Scripts Comments:

There are two types of comments in WMLScript:

*       Single-line comment: To add a single-line comment, begin a line of text with the // characters.

*       Multi-line comment: To add a multi-line comment, enclose the text within /* and */.

These rules are the same in WMLScript, JavaScript, Java, and C++. The WMLScript engine will ignore all comments. The following WMLScript example demonstrates the use of comments:


// This is a single-line comment.



  /* This is a

     multi-line comment. */



  /* A multi-line comment can be placed on a single line. */


WML Script Case Sensitivity:

The WMLScript language is case-sensitive. For example, a WMLScript function with the name WMLScript_Function is different from wmlscript_function. So, be careful of the capitalization when defining or referring to a function or a variable in WMLScript.

Whitespaces in WMLScript:

Except in string literals, WMLScript ignores extra whitespaces like spaces, tabs and newlines. Hence, the code in the earlier "Hello World" example can be typed in the following way and the result will remain the same:

WML Script Statement Termination by Semicolons:

A semicolon is required to end a statement in WMLScript. This is the same as C++ and Java. Note that JavaScript does not have such requirement but WML Script makes it mandatory.

A vast majority of WAP services are available in the market. You may to contact to some WAP lover to have a big list of all the available services and then you can start accessing those services from your WAP enabled mobile phone.

However, some examples of useful mobile services are in the following fields:

Banking:

*       Accessing account statements

*       Paying bills

*       Transferring money between accounts

Finance:

*       Retrieving stock and share prices

*       Buying and selling stocks and shares

*       Looking up interest rates

*       Looking up currency exchange rates

Shopping:

*       Buying everyday commodities

*       Browsing and buying books

*       Buying CDs

Ticketing:

*       Booking or buying airline tickets

*       Buying concert tickets

*       Booking theatre tickets

Entertainment:

*       Retrieving restaurant details

*       Looking up clubs

*       Finding out what is playing in what cinemas

*       Playing solitaire games

*       Playing interactive games

Weather:

*       Retrieving local weather forecasts

*       Looking up weather at other locations

E- Messaging:

*       Voice mail

*       Unified Messaging

*       Enhanced support of legacy SMS services


1.a)      How can a Bluetooth network have more than 8 nodes? Draw such a network with 10 nodes and clearly mark the different nodes and parts of the network.                             [4]

b)         Write short notes on any two topics

iii)        Blue-tooth Protocol stock                                                                         [5]

a)         Blue tooth Protocol stack                                                                                      [6]

a)         Explain briefly the types of links available with Bluetooth network.                                       [4]

b)         Bluetooth is aimed for ad-hoc network with a very limited coverage and without need for an infrastructure. Explain its Physical and Medium Access Control Layers.                  [9]

a)         Why do not other RF (Radio Frequency) devices interfere with Bluetooth Devices?       [4]
Bluetooth is a short-range wireless technology that allows both voice and data to be transmitted between electronic devices. Originally conceived as a means to implement hands-free mobile phone use without a cable between the handset and the headset, companies have developed some very exciting, futuristic applications for Bluetooth. With this technology, people really could send and receive voice or data to or from any device or person in a network using a small lapel-mounted device a la Star Trek.
The Bluetooth Special Interest Group (SIG), which was founded in 1998 by Ericsson, IBM, Nokia, and Toshiba, authored the current standard. Today, over 2000 members of the Bluetooth SIG as well as vendors of both integrated circuits and development tools have helped designers to create Bluetooth end products.

What's in a Bluetooth System?

There are four basic parts to any Bluetooth system: a radio frequency (RF) component, a baseband or link control unit, link management software, and the supporting application software.

Bluetooth Radio—The Bluetooth radio is a short-distance, low-power radio operating in the unlicensed spectrum of 2.4-gigahertz (GHz). The radio uses a nominal antenna power of 0-dBm (1-mW) and has a range of 10 meters (33-feet). Optionally, a range of 100 meters (about 328-feet) may be achieved by using an antenna power of 20-dBm (100-mW). Data is transmitted at a maximum rate of up to 1-Mbits-per-second (Mbps). However, communication protocol overhead limits the practical data rate to a little over 721-Kbits-per-second (Kbps).


Figure 1:  Block diagram of a typical Bluetooth radio.

The Bluetooth radio employs spectrum spreading, whereby the transmission hops among 79 different frequencies between 2.402- and 2.480-GHz at nominal rate of 1600-hops/s. Spectrum spreading minimizes interference from other devices in the 2.4-GHz band, such as microwave ovens and other wireless networks. If a transmission encounters interference, it waits 1/1600th of a second (625-┬Ásec) for the next frequency hop and retransmits on a new frequency. Frequency hopping also provides data security because two packets of data are never sent consecutively over the same frequency, and the changing frequencies are pseudo-random.

Bluetooth Baseband and Link Controller—The second part of a Bluetooth system is the Link Controller, the supervisory function which handles all the Bluetooth baseband functions, that include encoding voice and data packets, error correction, slot delimitation, frequency hopping, radio interface, data encryption, and link authentication. In addition, the Link Controller also executes Link Management software.

The Bluetooth standard supports two link types: the synchronous connection oriented (SCO) link, used primarily for voice communications, and the asynchronous connection-less (ACL) link, used for packet data. Each link type supports 16 different packet types. Any two devices in a Bluetooth system may use either link type and may change link types during a transmission. Over these links, Bluetooth supports an asynchronous data channel, three synchronous voice channels at 64-Kbps, or simultaneous asynchronous data and synchronous voice channels. The asynchronous channel can support an asymmetric link of 721-Kbps in either direction and 57.6-Kbps in the return direction or a 432.6-Kbps symmetric link.

Link Manager—The third component of a Bluetooth system, the Bluetooth Link Manager software governs the communication between various Bluetooth devices, such as a phone and a PC. The Link Manager's control includes setting up the communication link and performing authentication, configuration, and other protocols.

Application Software—The fourth component of a Bluetooth system is the application software embedded in the end product (e.g., PDA, mobile phone, or keyboard). All Bluetooth devices are required to have Bluetooth-compatible sections in the application software so that any Bluetooth device will work with any other one
Bluetooth Tutorial - Specifications

  What is Bluetooth? Well you can get lots of different definitions, but essentially Bluetooth is the term used to describe the protocol of a short range (10 meter) frequency-hopping radio link between devices. These devices are then termed Bluetooth - enabled. Documentation on Bluetooth is split into two sections, the Bluetooth Specification and Bluetooth Profiles.
  • The Specification describes how the technology works (i.e the Bluetooth protocol architecture),
  • The Profiles describe how the technology is used  (i.e how different parts of the specification can be used to fulfil a desired function for a Bluetooth device)

The Specification is examined first,  then the Profiles.

 Bluetooth Specification Protocol Stack:



Click on a section of the diagram* above, for a tutorial of its functions

    In more detail: Bluetooth is the name given to a new technology using short-range radio links, intended to replace the cable(s) connecting portable and/or fixed electronic devices. It is envisaged that it will allow for the replacement of the many propriety cables that connect one device to another with one universal radio link. Its key features are robustness, low complexity, low power and low cost. Designed to operate in noisy frequency environments, the Bluetooth radio uses a fast acknowledgement and frequency hopping scheme to make the link robust. Bluetooth radio modules operate in the unlicensed ISM band at 2.4GHz, and avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet. Compared with other systems in the same frequency band, the Bluetooth radio hops faster and uses shorter packets. The following pages give more detail about different sections of the protocol, note this tutorial is completely up to date with the latest version of the bluetooth Specification (ver 1.1)



Specification Table Of Contents:




1


v1.1



The Radio layer defines the requirements for a Bluetooth transceiver operating in the 2.4 GHz ISM band.





2


v1.1



The Baseband layer describes the specification of the Bluetooth Link Controller (LC) which carries out the baseband protocols and other low-level link routines.





3


v1.1



The Link Manager Protocol (LMP) is used by the Link Managers (on either side) for link set-up and control.





4


v1.1



The Host Controller Interface (HCI) provides a command interface to the Baseband Link Controller and Link Manager, and access to hardware status and control registers.





5


v1.1



Logical Link Control and Adaptation Protocol (L2CAP) supports higher level protocol multiplexing, packet segmentation and reassembly, and the conveying of quality of service information.





6


v1.1



The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10.





7


v1.1



The Service Discovery Protocol (SDP) provides a means for applications to discover which services are provided by or available through a Bluetooth device. It also allows applications to determine the characteristics of those available services.




b)         How Internet may be supported on mobile links. Draw the architecture and functional components of mobile IP. Describe data transfer from a mobile node to a fixed node and vice-versa.                [9]

a)What is mobile IP? Draw & describe the mobile IP architecture and its functional components.       [12]

b)What is mobile IP? Explain with the help of a neat diagram how a mobile user remains on line irrespective of his current position.                                                                              [9]


The Mobile IP protocol allows location-independent routing of IP datagrams on the Internet. Each mobile node is identified by its home address disregarding its current location in the Internet. While away from its home network, a mobile node is associated with a care-of address which identifies its current location and its home address is associated with the local endpoint of a tunnel to its home agent. Mobile IP specifies how a mobile node registers with its home agent and how the home agent routes datagrams to the mobile node through the tunnel.

Mobile IP provides an efficient, scalable mechanism for roaming within the Internet. Using Mobile IP, nodes may change their point-of-attachment to the Internet without changing their home IP address. This allows them to maintain transport and higher-layer connections while roaming. Node mobility is realized without the need to propagate host-specific routes throughout the Internet routing fabric.

How Mobile IP works

A mobile node can have two addresses - a permanent home address and a care of address (CoA), which is associated with the network the mobile node is visiting. There are two kinds of entities in Mobile IP:


  • A home agent stores information about mobile nodes whose permanent home address is in the home agent's network.

  • A foreign agent stores information about mobile nodes visiting its network. Foreign agents also advertise care-of addresses, which are used by Mobile IP.

A node wanting to communicate with the mobile node uses the permanent home address of the mobile node as the destination address to send packets to. Because the home address logically belongs to the network associated with the home agent, normal IP routing mechanisms forward these packets to the home agent. Instead of forwarding these packets to a destination that is physically in the same network as the home agent, the home agent redirects these packets towards the foreign agent through an IP tunnel by encapsulating the datagram with a new IP header using the care of address of the mobile node.

When acting as transmitter, a mobile node sends packets directly to the other communicating node through the foreign agent, without sending the packets through the home agent, using its permanent home address as the source address for the IP packets. This is known as triangular routing. If needed, the foreign agent could employ reverse tunneling by tunneling the mobile node's packets to the home agent, which in turn forwards them to the communicating node. This is needed in networks whose gateway routers have ingress filtering enabled and hence the source IP address of the mobile host would need to belong to the subnet of the foreign network or else the packets will be discarded by the router.

The Mobile IP protocol defines the following:


  • an authenticated registration procedure by which a mobile node informs its home agent(s) of its care-of-address(es);

  • an extension to ICMP Router Discovery, which allows mobile nodes to discover prospective home agents and foreign agents; and

  • the rules for routing packets to and from mobile nodes, including the specification of one mandatory tunneling mechanism and several optional tunneling mechanisms.

IP version 4 assumes that a node’s IP address uniquely identifies its physical attachment to the Internet. Therefore, when a corespondent host (CH) tries to send a packet to a mobile node (MN), that packet is routed to the MN’s home network, independently of the current attachment of that MN (this is because CHs do not have any knowledge of mobility). 

When the MN is on its home network, and a CH sends packets to the mobile node, the Mobile Node obtains those packets and answers them as a normal host (this is one important requirement in Mobile IP), but if the MN is away from its home network, it needs an agent to work on behalf of it. That agent is called Home Agent (HA). This agent must be able to communicate with the MN all the time that it is “on-line”, independently of the current position of the MN. So, HA must know where the physical location of the MN is. 

In order to do that, when the MN is away from home, it must get a temporary address (which is called care-of address), which will be communicated to the HA to tell its current point of attachment. This care-of address can be obtained by several ways, but the most typical one is that the MN gets that address from an agent. In this case, this agent is called Foreign Agent (FA). 

Therefore, when a MN is away from home, and it’s connected to a foreign network, it detects is on a different network and sends a registration request through the FA to the HA requesting mobile capabilities for a period of time. The HA sends a registration reply back to the MN (through the FA) allowing or denying that registration. This is true when the Mobile Node is using a Foreign Agent for the registration. If the Mobile Node obtains the care-of address by other meanings, that step (registration through the FA) is not necessary.  If the HA allows that registration, it will work as a proxy of the MN. When MN’s home network receives packets addressed to the MN, HA intercepts those packets (using Proxy ARP), encapsulates them, and sends them to the care-of address, which is one of the addresses of the FA. The FA will decapsulate those packets, and it will forward them to the MN (because it knows exactly, where the MN is). 

Encapsulation is the method used by the HA to deliver information to the MN putting an extra IP header on top of the packet and tunnelling that packet to the MN (when it's on a foreign network). Tunneling and encapsulation are defined in  IP in IP tunneling and IP encapsulation within IP. 

So, when the MN is on a foreign network, it uses its home agent to tunnel encapsulated packets to itself via FA. This occurs until the lifetime expires (or the MN moves away). When this happens (time out) MN must register again with its HA through the FA (if the MN obtains its care-of address for other meanings, it acts as its own FA). 

When the MN moves to another network and it detects so, it sends a new registration request through (one more time) the new FA. In this case, HA will change MN’s care-of address and it will forward encapsulated packets to that new care-of address (which, usually, belongs to the FA). Some extensions of Mobile IP allows to a MN to have several care-of addresses. Then, HA will send the same information to all the care-of addresses. This is particularly useful when the MN is at the edges of cells on a wireless environment, and it is moving constantly. 

MN bases its movement detection basically looking at periodic adverts of the FA (and HA), which sends to its localnet. Those messages are one extension of the ICMP router discovery messages and they are called Agent Advertisement (because they advertises a valid agent for Mobile Nodes). 

There are two different methods to detect network movement: 

a) The first method is based on network prefixes. For further information look at Mobile IP RFC 2002  (section 2.4.2.2, page 22). This method is not included in our current implementation. 

b) The second method is based upon the Lifetime field within the main body of the ICMP Router Advertisement portion of the Agent Advertisement. Mobile nodes keep track of that Lifetime and if it expires, it sends an Agent Solicitation (asking for a new Agent Advertisement) and it presumes that it has been moved. 

When the MN returns to its home network, it does not require mobility capabilities, so it sends a deregistration request to the HA, telling it that it’s at home (just to deactivate tunneling and to remove previous care-of address(es)). 

At this point, MN does not have to (de)register again, until it moves away from its network. The detection of the movement is based on the same method explained before.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.