Bluetooth Report Full

8/3/2019 Bluetooth Report Full

http://slidepdf.com/reader/full/bluetooth-report-full 1/61

CHAPTER 1

INTRODUCTION

In this age of computers and fast communication, everyone looks beyond the imagination

of what technology can offer. In this era of science and technology nothing seems to be

impossible what was thought to be a dream or fascination some years ago. Imagination is such

a powerful key and creativity is its answer, with these and a lot many of small experiences have

bought science and technology to its forefront in this fast paced generation. At that moment

when everything was thought to be perfect and nothing should be changed, in a lonely corner a

group of researchers in the northern most part of Europe started to dream about a small chip

which low in cost, consumes less power and easy to install. With the help of company Ericsson

in 1994 they started to built a chip that was thought to change the face of wireless

communications forever. In 1998 that dream came true and the first Bluetooth chip was ready

to face the market and in 2000 Ericsson shipped its first consumer Bluetooth product- a

Bluetooth headset based on Ericsson solution.A typical Bluetooth device enables a user to

communicate with a wireless headset connected wirelessly with a mobile phone, a laptop with a

printer a wireless keyboard and mouse which wirelessly communicate with the CPU, this and

many more, Our motivation behind this technology is “what makes it so simple” and its vast

reach of applications coming to the wireless communication between devices which transmit

sensitive data then comes the security which got our eye and starting to explore what really

does a typical Bluetooth device offers in terms of data security and integrity, this formed a base

and a group of like minded persons joined to explore in to this region.

1.1Bluetooth

Bluetooth, is a radio-frequency standard. This is the kind of technology, which was developed,

by number of vendors in close cooperation with each other. Conceived initially by Ericsson,

1



before being adopted by a myriad of other companies, Bluetooth is a standard for a small,

cheap radio chip to be plugged into computers, printers, mobile phones, etc. We can call it

cable replacement technology for all kind of lengthy wires around you. Actually it was thought

of for just putting the wire data on radio frequency but than soon was realised of the more

opportunities it can bring in.One might have given thought why is this technology developed

when IrDA (infrared Data Association) that is mostly used in television remotes can also be

used for this purpose. The problems, which take away this idea, are the line of sight, 1-meter

distance from the device to be controlled, one-way communication etc.Bluetooth is intended to

come around with the different weaknesses of the Infrared and other competing technologies.

Bluetooth was realised for more general use and wider area of technologies to be grouped

together. Taking this motto a lot of new aspects where Bluetooth could have been used or is

used are :-

1. Global usage.

2. Voice and data handling.

3. The ability to establish ad-hoc connections.

4. The ability to withstand interference from other sources in open band.

5. Very small size, in order to accommodate integration into variety of devices.

6. Negligible power consumption in comparison to other devices for similar use.

7. An open interface standard competitively low cost of all units, as compared to their non-

Bluetooth correspondents.

1.2 Bluetooth Technology

Bluetooth uses a frequency of 2.4 GHz, which has been set for industrial and scientific and m-

2



edical devices (ISM). A lot of different small devices use this band i.e. baby monitors, door

openers etc. Making sure that Bluetooth and these other devices don't interfere with one

another has been a crucial part of the design process. The interference is avoided by using a

very weak signal to the receiver of about 1 milliwatt. The range of the Bluetooth is just 10

meters approximately (maximum of 100 meters), but still it can pass through the walls of the

house. Another technology, which it uses to avoid interference, is the Spread-spectrum

frequency hoping .i.e. which means the change of transmitter’s frequency at 1600 times every

second which makes available the spectrum for other devices and merely remove the problem

of interference.The protocol stacks of the Bluetooth, which includes radio, Baseband, L2CAP,

and LMP etc is explained here. These protocols used for the communication between different

Bluetooth devices. A number of devices that you may already use take advantage of this same

radio-frequency band. Making sure that Bluetooth and these other devices don't interfere with

one another has been a crucial part of the design process.

Figure 1.1: Describing the Bluetooth Networking

Looking upon at the network architecture of Bluetooth devices connecting to each other and

form a group of devices called Piconet, and when two or more piconets communicate with each

other they are called scatternets which can accommodate up till 8 devices. In this piconet there

is one master and the others are all slaves. When the two Bluetooth devices come in range of

3



each other they communicate automatically and the conversation is done. When a piconet is

established the devices hop between the frequencies frequently.

Acesss Code(72 Bits) Packet Header(54 Bits) Payload(0-2745 Bits)

Figure 1.2: Bluetooth Packet

The packet through which data is transferred has a fixed format. It starts with a 72 bits access

code, which is evaluated by the master and is unique. The access code is very robust and

resistant to interference. Then come the packet header 54 bits and 0-2745 payloads, which

include all the required information to be transferred.

Fixed packet format

The link Manager is responsible for the following

1. Sending and receiving data

2. Connection set-up

3. Authentication

The protocol used for this purpose is called LMP (Link Manager Protocol)

1.3 Bluetooth Technical Details

The technology can be divided into two specifications: the core and the profile specifications.

The core specification introduces how the technology works, while the profile specification

concentrates on how to build interoperating devices using the core technologies. Bluetooth air

interface is based on a nominal antenna power of 0 dBm (1 mW) with extensions for operating

at up to 20 dBm (100 mW) . This interface Complies with ISM band rules up to 20 dBm in

America, Japan, and most European Countries. The Bluetooth radio uses frequency hopping

4



method to spread the energy across the ISM spectrum in 79 hops displaced by 1 MHz, starting

from 2.402 GHz and stopping at 2.480 GHz.

When Bluetooth-capable devices come within range of one another, an electronic conversation

determines whether they have data to share or whether one needs to control the other. The

electronic conversation occurs automatically and there is no need for the users to press a button

or give a command. Once the conversation has initiated, the devices, whether part of a

computer system or a stereo, form a network. The frame consisting of a transmit packet

followed by a receive packet in Figure 1.2 is the basic communication unit. Each packet is

composed of multiple slots (1, 3, or 5) of 625 . A typical single-slot frame hops at 1600 hops/s.

Multislot frames will allow higher data rates because of the elimination of the turnaround time

between packets and the reduction in header overhead. For example, single-slot packets can

have a maximum data rate of 172 kbps, while a five-slot, one-multislot frame will support a

721-kbps rate in the five-slot direction with a 57.6-kbps rate back channel in the one-slot

direction.

1.3.1 Network Architecture

Piconet is a basic unit of Bluetooth system; it consists of a master and up to seven active slave

nodes within a distance of about 10 meters. Multiple piconets in a large room can also exist and

they are called scaternets and they can be connected with a bridge.

Figure 1.3: Scatternets of 2 and 3 piconets

5



A piconet is a centralized TDM (Time Division Multiplexing) with the master controlling the

clock and determining which device gets to communicate in which time slot. The slaves can

only communicate with the master there is no possibility of slave-slave communication.The

figure 1.3 demonstrates scatternets.Piconets start with two connected devices such as portable

computer or a cellular phone, the devices are automatically configured and establish a

connection when they fall in a range of another Bluetooth device, it also permits automatic data

synchronisation. The devices are symmetric.This means that any Bluetooth radio can become a

master or slave radio, a ‘master/slave swap’ function enables to reverse the order of

master/slave configuration in a piconet. Bluetooth supports both point-point (piconet) and

point-multipoint connections (scatternet).

1.4 BLUETOOTH PROTOCOLS

The main aim of the Bluetooth specification is to guarantee the interoperability between

different applications by supporting any kind of services and providing the means to implement

Figure1.4 Bluetooth Protocol stack

them (service discovery, connection oriented, connectionless links). Figure 1.4 which shows

the complete Bluetooth core specific as well as adopted protocols, there are mainly five core

Bluetooth specific protocols which are important for communication between any two devices

6



are Radio, Baseband, Link manager protocol (LMP), Logical link control and adaptation

(L2CAP), Service discovery protocol (SDP), Radio frequency communication (RFCOMM).

1.4.1 Radio

A Bluetooth unit consists of a radio unit operating at 2.4 GHz band. This band has 79 different

Radio Frequency (RF) channels that are spaced at 1MHz. It uses a technique of transmission a

frequency hopping spread spectrum (FHSS) where the hopping sequence is a pseudo-random

sequence of 79-hop length, and it is unique for each ad hoc network.The establishment of a

physical channel is associated to the definition of a channel frequency hopping sequence which

has a very long period length and which does not show repetitive patterns over short time

interval. The FHSS system has been chosen to reduce the interference of nearby system

operating in the same range of frequency (for example, IEEE 802.11 WLANs) and make the

link robust. The nominal rate of hopping between to consecutive RF is 1600 hop/s. A Time

Division Duplex (TDD) scheme of transmission is adopted. The channel is divided into time

slots, each 625 µs in length, and each slot corresponds to a different RF hop frequency. The

time slots are numbered according to the Bluetooth clock of the master. The master can

transmit in even numbered time slots. Odd numbered time slots are reserved for slaves’

transmissions. The changing of RF used after transmitting or receiving a packet reduces the

interference from signals coming from other radio modules. The Bluetooth antenna has a

nominal power that permit a range for radio link from 10 cm to 10 m. This range can be

extended up to 100 m increasing the transmit power [12].

1.4.2 Baseband

Bluetooth baseband is responsible for (i) setting up physical connections between master and

slave (ii) sending and receiving different packets on physical channel. (iii) Synchronisation of

7



devices belonging to a piconet on a master clock. (iv) Managing of different power saving

states, which devices can stay in [12].

There are two types of connection:

1) SCO: Synchronous Connection Oriente (enables point-point connection oriented

communication between master and a specific slave)

2) ACL: asynchronous connectionless communication between a master and all slaves in a

piconet. It uses ARQ (Automatic repeat request for fast and reliable communication between

the devices)

1.4.3 LMP

It is responsible for link setup between Bluetooth devices and ongoing link management, link

configuration and authentication. It discovers other LM’s and communicates with them using

the link manager protocol to perform it functions it seeks the help of underlying link controller

(LC) in the baseband

1.4.4 L2CAP

The Logical Link Control and Adaptation Protocol (L2CAP) layer interfaces to the link

controller and allows multiple channels to share a single Bluetooth link. In this manner,

multiple different high-level protocols like TCP/IP and OBEX file transfer are used

simultaneously. It provides group management, including the handling of point-to-multipoint

connections and the negotiation of quality of service (QOS) between devices.

1.4.5 Service Discovery Protocol

The Service Discovery Protocol (SDP) provides a way to discover available Bluetooth services.

A Bluetooth device can act as an SDP client looking for services, or as SDP server providing a

service or services, or it can have both functions.

8



1.4.6 RFCOMM

The RFCOMM layer provides a mechanism for transmitting and receiving characters over a

Bluetooth link as if the application was talking to a serial port. Because of its simplicity and

familiarity, RFCOMM is used in many applications for serial data transfers.

1.5 Others

TCS

The Telephony Control Protocol Specification (TCS) layer controls voice and data calls,

provides group management, and handles signaling. The actual voice and data is transmitted

and received directly to and from the baseband via the HCI without going through the L2CAP

layer.

OBEX

The Object Exchange Protocol (OBEX) layer provides a simple mechanism for moving objects

like files, electronic business cards, and messages.

IrMC

The IrMC layer enables synchronization capabilities for devices like cell phones or PDAs

1.6 Bluetooth Profiles

A profile can be described as a vertical slice through the protocol stack. It defines options in

each protocol that are mandatory for the profile. It also defines parameter ranges for each

protocol. The profile concept is used to decrease the risk of interoperability problems between

different manufacturers' products.

9



There are namely 13 profiles when Bluetooth first appeared in to market there is constant

updations going on and at this point of time there are many additional profiles have been added.

13 profiles are described as below :

1. GAP: Generic access profile

2. SDAP: Service discover applikation profile

3. CTP: Cordless telephony profile

4. IP: Intercom profile

5. SPP: Serial port profile

6. HS: Headset profile

7. DNP: Dial up networking profile

8. FP: Fax profile

9. LAP : LAN (local area network ) access profile

10.GOEP: Generic object Exchange profile

11.OPP: Object push profile

12. FTP: File transfer profile

13. SP: Synchronisation profile

1) GAP:

This profile defines the generic procedures related to discovery of Bluetooth devices (idle

mode procedures) and link management aspects of connecting to Bluetooth devices (connecting

mode procedures). It also defines procedures related to use of different security levels

10



essentially this profile describes how the lower layers (LMP and Baseband) are used, along

with some higher layers.

2) SDP :

This profile defines the features and procedures for an application in a Bluetooth device to

discover services registered in other Bluetooth devices and retrieve any desired available

information pertinent to these services. Essentially, the service discovery profile defines the

protocols and procedures that shall be used by a service discovery application on a device to

locate services in other Bluetooth-enabled devices using the Bluetooth Service Discovery

Protocol (SDP).

3) CTP:

This profile defines the features and procedures that are required for interoperability between

different units active in the ‘3-in-1 phone’ use case. The ‘3-in-1 phone’ is a solution for

providing an extra mode of operation to cellular phones, using Bluetooth as a short-range

bearer for accessing fixed network telephony services via a base station. However, the 3-in-1

phone use case can also be applied generally for wireless telephony in a residential or small

office environment, for example for cordless-only telephony or cordless telephony services in a

PC – hence the profile name ‘Cordless Telephony’.

4) IP:

This profile defines the requirements for Bluetooth devices necessary for the support of the

intercom functionality within the 3-in-1 phone use case. The requirements are expressed in

terms of end-user services, and by defining the features and procedures that are required for

interoperability between Bluetooth devices in the 3-in-1 phone use case. More popularly, this

is often referred to as the ‘walkie-talkie’ usage of Bluetooth.

11



5) SPP:

The Serial Port Profile defines the requirements for Bluetooth devices necessary for setting up

emulated serial cable connections using RFCOMM between two peer devices. The

requirements are expressed in terms of services provided to applications, and by defining the

features and procedures that are required for interoperability between Bluetooth devices.

Essentially, the Serial Port Profile defines the protocols and procedures that shall be used by

devices using Bluetooth for RS232 (or similar) serial cable emulation. The scenario covered by

this profile deals with legacy applications using Bluetooth as a cable replacement, through a

virtual serial port abstraction (which in itself is operating system-dependent).

6) HS:

The Headset profile defines the requirements for Bluetooth devices necessary to support the

Headset use case. Essentially the Headset profile defines the protocols and procedures that shall

be used by devices implementing the usage model called ‘Ultimate Headset’. The most

common examples of such devices are headsets, personal computers, and cellular phones.

7) DNP:

The Dial-up Networking profile defines the requirements for Bluetooth devices necessary to

support the Dial-up networking use case. Essentially the Headset profile defines the protocols

and procedures that shall be used by devices implementing the usage model called ‘Internet

Bridge'. The most common examples of such devices are modems and cellular phones. Two

main scenarios are implemented: the Usage of a cellular phone or modem by a computer as a

wireless modem for connecting to a dial-up internet access server, or using other dial-up

services, and Usage of a cellular phone or modem by a computer to receive data calls.

12



8) FP:

The Fax profile defines the requirements for Bluetooth devices necessary to support the

Fax use case. Essentially the Fax profile defines the protocols and procedures that shall be used

by devices implementing the fax part of the usage model called ‘Data Access Points, Wide

Area Networks’. A Bluetooth cellular phone or modem may be used by a computer as a

wireless fax modem to send or receive a fax message.

9) LAP:

The LAN Access Profile for Bluetooth devices consists of 2 parts. Firstly, this profile defines

how Bluetooth-enabled devices can access the services of a LAN using PPP. Secondly, this

profile shows how the same PPP mechanisms are used to form a network consisting of two

Bluetooth-enabled devices. Basically this profile defines LAN Access using PPP over

RFCOMM. (There may be other means of LAN Access in the future).

10) GOEP:

The usage model can be, for example, Synchronization, File Transfer, or Object Push model.

Essentially, the purpose of this document is to work as a generic profile document for all

application profiles using the OBEX protocol.

11) OPP:

The object push usage model makes use of the underlying Generic Object Exchange

profile (GOEP) to define the interoperability requirements for the protocols needed by

applications. Typical scenarios covered by this profile are: Object Push, Business Card Pull &

Business Card Exchange, all of which involve the pushing/pulling of data objects between

Bluetooth devices.

13



12) FTP:

The file transfer usage model makes use of the underlying Generic Object Exchange Profile

(GOEP) to define the interoperability requirements for the protocols needed by applications.

Typical scenarios covered by this profile involving a Bluetooth device browsing , transferring

and manipulating objects on/with another Bluetooth device.

14



CHAPTER 2

REVIEW OF LITRATURE

Perkins C(1994) lays emphasis on adhoc network which according to him differ significantly

from existing networks. First of all the topology of interconnections may be quite dynamic.

Secondly most users will not wish to perform any administrative actions to set up such

anetwork. In order to provide service we do not assume that every computer is within comm-

unication range of every other computer. This lack of complete connectivitywould certainly be

a reasonable characteristic. Currently there is no method available which enables mobile

computers to freely roam about while still maintaining connections with each other.Thus as

regards as Routing protocols for existing networks have not been designed specically to

provide the kind of dynamic self starting behavior needed for adhoc networks Most protocols

exhibit their least desirable behaviour when presented with a highly dynamic inter-connection

topology. Moreover the convergence characteristics of existing routing protocols did not seem

good enough to fit the needs of adhoc networks. Lastly the wireless medium differs in

important ways from wired media, which would require modifications to whichever routing

protocol chosen to experiment with. DSDV is the routing method or protocol which may not be

close to any base station and can exchange data along changing and arbitary paths of

interconnection to afford computers along their number a path along which data can be

exchanged. In addition solution must remain compatible in cases where base station is

available.DSDV uses distance vector technique in which Distance Vector every node maintains

for each destination is a set of ranges over the neighbour . Node treats neighbour k as a next

hop for the paked destined x for and so on.

In order to keep the distance estimates upto date each node monitors the cost of its outgoing

links and periodically broadcasts to each one its neighbors its current estimate of the shortest

distance to every other node in the network.Thus DSDV models the mobile computers as

15



routers which are cooperating to forward packets as needed to each other.In this approach thus

can be utilized at either the network layer layer or below the network layer but still above the

MAC layer software in layer2. The information in the routing tables is similar to what is found

in routing tables with todays distance vector algorithms but includes a sequence number as well

as settling time data useful for damping out fluctuationsin route table updates.

Corson(1996) presented a loop-free, distributed routing protocol for mobile packet radio

networks. The protocol is intended for use in networks where the rate of topological change is

not so fast as to make "flooding" the only possible routing method, but not so slow as to make

one of the existing protocols for a nearly-static topology applicable. The routing algorithm

adapts asynchronously in a distributed fashion to arbitrary changes in topology in the absence

of global topological knowledge. The protocol's uniqueness stems from its ability to maintain

source-initiated, loop-free multipath routing only to desired destinations with minimal overhead

in a randomly varying topology. The protocol's performance, measured in terms of end-to-end

packet delay and throughput, is compared with that of pure flooding and an alternative

algorithm which is well-suited to the high rate topological change environment envisioned

here. For each protocol, emphasis is placed on examining how these performance measures

vary as a function of the rate of topological changes, network topology, and message traffic

level. The results indicate thenew protocol generally outperforms the alternative protocol at all

rates of change for heavy traffic conditions, whereas the opposite is true for light traffic. Both

protocols significantly outperform flooding for all rates of change except at ultra-high rates

where all algorithms collapse. The network topology, whether dense or sparsely connected, is

not seen to be a major factor in the relative.

Johnson(1996) states that an ad hoc network is a collection of wireless mobile hosts forming a

temporary network without the aid of any established infrastructure or centralized

administration. In such an environment, it may be necessary for one mobile host to enlist the

aid of other hosts in forwarding a packet to its destination,due to the limited range of each

16



mobile host’s wireless transmissions. This paper presents a protocol for routing in adhoc

networks that uses dynamic source routing. The protocol adapts quickly to routing changes

when host movement is frequent, yet requires little or no overhead during periods in which

hosts move less frequently. Based on results from a packet-level simulation of mobile hosts

operating in an ad hoc network, the protocol performs well over a variety of environmental

conditions such as host density and movement rates. For all but the highest rates of host

movement simulated, the overhead of the protocol is quite low, falling to just 1% of total data

packets transmitted for moderatemovement rates in a network of 24 mobile hosts. In all cases,

the difference in length between the routes used and the optimal route lengths is negligible, and

in most cases, route lengths are on average within a factor of 1.01 of optimal.

Murthy (1996) presented the wireless routing protocol (WRP). In WRP, routing nodes

communicate the distance and second-to-last hop for each destination. WRP reduces the

number of cases in which a temporary routing loop can occur, which accounts for its fast

convergence properties. A detailed proof of correctness is presented and its performance is

compared by simulation with the performance of the distributed Bellman-Ford algorithm

(DBF), DUAL (a loop-free distance-vector algorithm) and an ideal link-state algorithm (ILS),

which represent the state of the art of internet routing. The simulation results indicate That

WRP is themost efficient of the alternatives analysed.

Murthy S(1997) distributed algorithms for shortest-path problems are important in the context

of routing in computer communication networks. We present a protocol that maintains the

shortest-path routes in a dynamic topology, that is, in an environment where links and nodes

can fail and mover at arbitrary times. The novelty of this protocol is that it avoids the bouncing

effect and the looping problem that occur in the previous approaches of the distributed

implementation of Bellman-Ford algorithm. The bouncing effect refers to the very long

duration for convergence when failures happen or weights increase, and the nonterminating

exchanges of messages, or counting-to-infinity behavior, in disconnected components of the

17



network resulting from failures. The looping problems cause data packets to circulate and, thus,

waste bandwidth.These undesirable effects are avoided without any increase in the overall

message complexity of previous approaches required in the connected part of the network The

time complexity is better than the distributed Bellman-Ford algorithm encountering failures.

The key idea in the implementation is to maintain only loop-free paths, and search for the

shortest path only from this set.

Toh (1997) presents a new, simple and bandwidth efficient distributed routing protocol for

adhoc networks. Unlike the conventional distributed routing algorithims protocol does not

attempt to consistentantly maintain routing informationin every nodes. In an adhoc mobile

network where mobile hosts are acting as routers and where routes are made incosistent by

mobile hosts movement employed a new assosiativity-based routing scheme where route is

selected based on nodes having assosiativity states that imploys periods of stability.In this

manner routes selected are likely to be long lived and hence there is no need to restart

frequently resulting in higher attainable throughput.Thus the protocol is free from loops,

deadlocks and packet duplicates and has scalable memory requirements.Simulation results

obtained reveals that shorter and better routes can be discovered during route reconstruction.

Broch J(1998) An ad hoc network is a collection of wireless mobile nodes dynamically forming

a temporary network without the use of any existing network infrastructure or centralized

administration. Due to the limited transmission range of wireless network interfaces, multiple

network "hops" may be needed for one node to exchange data with another across the network.

In recent years, a variety of new routing protocols targeted specifically at this environment have

been developed, but little performance information on each protocol and no realistic

performance comparison between them is available. This paper presents the results of a detailed

packet-level simulation comparing four multi-hop wireless ad hoc network routing protocols

that cover a range of design choices: DSDV, TORA, DSR, and AODV. Here the NS-2 network

simulator to accurately model the MAC and physical-layer behavior of the IEEE 802.11

18



wireless LAN standard, including a realistic wireless transmission channel model, and present

the results of simulations of networks of 50 mobile nodes.

Traskbak(1998) give the overview of Bluetooth security and how it is designed. He also

discussed about the Bluetooth who according to him is the new technology for

wirelesscommunication.The target of the design is to connect different devices together

wirelessly in a small environment whose range at the movement is 10 meters.Bluetooth

employs several layer of data encryption and user authentication measures.It uses the

combination of Personal Identification Number (PIN) and a bluetooth adress to identify other

bluetooh devices.Also Bluetooth use a fast FHSS technique allowing only syncronised

receivers to acess the data. For security purpose these devices uses authorisation and

authenticatio to know who is the user and what are the devices and what are their rights. Also

Bluetooth employs one security level and three different security modes for prooer

scrunity.Apart from this Link Key, Encryption Key and the PIN code are the other security

measures used by the bluetooth devices.

Iwata (1999) consider a large population of mobile stations that are interconnected by a

multihop wireless network. The applications of this wireless infrastructure range from adhoc

networking (e.g., collaborative, distributed computing) to disaster recovery (e.g., fire, flood,

earthquake), law enforcement (e.g., crowd control, search-and-rescue),and military(automated

battlefield). Key characteristics of this system are the large number of users, their mobility, and

the need to operate without the support of a fixed (wired or wireless) infrastructure. The last

feature sets this system apart from existing cellular systems and in fact makes its design much

more challenging. In this environment, we investigate routing strategies that scale well to large

populations and can handle mobility. In addition,we address the need to support multimedia

communications, with low latency requirements for interactive traffic and quality-of-service

(QoS) support for real-time streams (voice/video). In the wireless routing area, several schemes

have already been proposed and implemented.(e.g., hierarchical routing, on-demandrouting,

19



etc.). We introduce two new schemes—fisheye State routing (FSR) and hierarchical state

routing (HSR)—which offer some competitive advantages over the existing schemes. We

compare the performance of existing and proposed schemes via simulation.

Perkins (1999) reported that The Ad hoc On-Demand Distance Vector (AODV) routing

protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to

dynamic link conditions, low processing and memory overhead, low network utilization, and

determines unicast routes to destinations within the ad hoc network. One distinguishing feature

of AODV is its use of a destination sequence number for each route entry. The destination

sequence number is created by the destination to be included along with any route information

it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is

simple to program. Given the choice between two routes to a destination, a requesting node is

required to select the one with the greatest sequence number. Route Requests (RREQs), Route

Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. These

message types are received via UDP, and normal IP header processing. So,for instance, the

requesting node is expected to use its IP address as the Originator IP address for the messages.

For broadcast messages, the IP limited broadcast address (255.255.255.255) is used.This means

that such messages are not blindly forwarded. However,AODV operation does require certain

messages (e.g., RREQ) to be disseminated widely, perhaps throughout the ad hoc network. The

range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation

is typically not required. As long as the endpoints of a communication connection have valid

routes to each other, AODV does not play any role.When a route to a new destination is

needed, the node broadcasts a RREQ to find a route to the destination. A route can be

determined when the RREQ reaches either the destination itself, or an intermediate node with a

'fresh enough' route to the destination. A fresh enough' route is a valid route entry for the

destination whose associated sequence number is at least as great as that contained in the

RREQ. The route is made available by unicasting a RREP back to the origination of the

20



RREQ. Each node receiving the request caches a route back to the originaton of the request,

so that the RREP can be unicast from the destination along a path to that originator, or likewise

from any intermediate node that is able to satisfy the request. Nodes monitor the link status of

next hops in active routes. When link break in an active route is detected, a RERR message is

used to notify other.nodes that the loss of that link has occurred. The RERR message indicates

those destinations (possibly subnets) which are no longer reachable by way of the broken link.

Inorder to enable this reporting mechanism, each node keeps a "precursor list", containing the

IP address for each its neighbors that are likely to use it as a next hop towards each destination.

The information in the precursor lists is most easily acquired during the processing for

generation of a RREP message, which by definition has to be sent to a node in a precursor list

If the RREP has a nonzero prefix.

Royer E(1999) states that an ad hoc mobile network is a collection of mobile nodes that are

dynamically and arbitrarily located in such a manner that the interconnections between nodes

are capable of changing on a continual basis. In order to facilitate communication within the

network, a routing protocol is used to discover routes between nodes. The primary goal of such

an ad hoc network routing protocol is correct and efficient route establishment between a pair

of nodes so that messages may be delivered in a timely manner. Route construction should be

done with a minimum of overhead and bandwidth consumption. This article examines routing

protocols for ad hoc networks and evaluates these protocols based on a given set of parameters.

The article provides an overview of eight different protocols by presenting their characteristics

and functionality, and then provides a comparison and discussion of their respective merits and

drawbacks.

Tabanne (1999) introduce here a novel routing protocol for a class of reconfigurable wireless

ad hoc networks. The main features of these ad hoc networks are increased nodes mobility, a

larger number of nodes, and a large network span. Here argued that current routing protocols

do not provide a satisfactory solution for routing in this type of environment. Here proposed a

21



scheme, called the Zone RAID Routing Protocol (ZRRP), which dynamically adjusts itself to

operational conditions by sizing a single network parameter the zone radius. More specifically,

ZRRP reduces the cost of frequent updates to the constantly changing network topology by

limiting the scope of the updates to the immediate neighborhood of the change. Also

performance of the scheme, evaluating the average number of control messages required to

discover a route within the network. Furthermore, we compare the scheme's performance with

reactive flood search and RAID link-state classes of routing protocols.

Das(2000) says that Ad hoc networks are characterized by multihop wireless connectivity,

frequently changing network topology and the need for efficient dynamic routing protocols. We

compare the performance of two prominent on-demand routing protocols for mobile ad hoc

networks: Dynamic Source Routing (DSR) and Ad Hoc On-Demand Distance Vector Routing

(AODV). A detailed simulation model with MAC andphysical layer models is used to study

interlayer interactions and their performance implications. We demonstrate that even though

DSR and AODV share similar on-demand behavior, the differences in the protocol mechanics

can lead to significant performance differentials. The performance differentials are analyzed

using varying network load, mobility, and network size. Based on the observations, we make

recommendations about how the performance of either protocol can be improved.

Raju (2000) introduced WRP-Lite, which is a table-driven routing protocol that uses non-

optimal routes, and compare its performance with the performance of the dynamic source

routing (DSR) protocol, which is an on-demand routing protocol for wireless ad-hoc networks.

We evaluate the performance of WRP-Lite and DSR for varying degree of mobility and traffic

in a 20-node network. The performance parameters are end-to-end delay, control overhead,

percentage of packets delivered, and hop distribution. We show that WRP-Lite has much better

delay and hop performance while having comparable overhead to DSR.

Hong (2002) The growing interest in Mobile Ad Hoc Network techniques has resulted in many

routing protocol proposals. Scalability issues in adhoc networks are attracting more attention

22



these days. In this paper, we will survey the routing protocols that address scalability. The

routing protocols we intend to include in the survey fall into three categories: (1) flat routing

protocols, (2) hierarchical routing approaches, and (3) GPS augmented geographical routing

schemes. The paper will compare the scalability properties and operational features of the

protocols and will discuss challenges in future routing protocol designs.

23



CHAPTER 3

PRESENT WORK

3.1 INTRODUCTION

With the growing popularity and falling prices of the mobile hand-held computing and

information exchange devices, the need and capability of these devices are also growing.

These growth and need are creating its own set of new problems and challenges. Some

examples of recent and not so recent wireless devices are cellular phones, personal digital

assistants, tablet PCs, and lap-top PCs. All of these have the capability and need to transfer

information over wireless medium to each other in a network. Currently, the wireless networks

that allow communication between mobile devices can be classified into the following two

categories:

(i) Networks having a fixed infrastructure: an example of such a network is a cellular phone

network. A mobile cellular phone depends on a fixed infrastructure of base stations that cover

fixed areas. A mobile phone communicates with the nearest base station and the base station in

turn transmits the information to another base station, wired network, or to another mobile

phone. When a mobile phone is at an intersection of the coverage areas of two base stations, it

is switched to the base station with the stronger signal without any break in the communication

and without the user becoming aware of it.

(ii) Networks that do not have a fixed infrastructure: this is an emerging but highly useful and

promising type of network communication method. There are several situations where such a

network would be indispensable; mostly, in unplanned events like natural disasters and wars,

but also in a planned event. For example, a meeting of businessmen scattered over a large

place having no fixed infrastructure will be best supported by this kind of networks. This type

of networks can be described as a network of mobile devices that is created or destroyed as

needed and hence it is named Mobile Ad-hoc Network or Bluetooth.The most distinguishing

24



aspect of Bluetooth is the lack of any fixed infrastructure and any central controlling authority.

When there is no central controlling authority, the devices comprising a network are all equal

and in such a situation, any decision needed to maintain a network becomes distributed. This

creates the need for distributed routing algorithms, resource allocation schemes, network entry

and exit rules, and network security. Moreover, as it is quite possible that a majority of the

mobile devices in such a network will be hand-held devices, the need to conserve battery power

will drive down the transmission power of the individual devices. Consequently,

communication between two devices would often require relay by intermediate devices, which

introduces the problem of multi-hop routing.

In wireless networks, physical links do not exist and a single transmission of a packet will

transfer a packet to multiple nodes within the communication range of a transmitting node at

the same time. We call this inherent broadcast of Bluetooths "local broadcast" to distinguish it

from global broadcast. It is guaranteed that at least a copy of a packet will reach a destination

node if every intermediate node, except the destination, repeats local broadcast without any

explicit routing, as long as such a path exists. However, routing is still needed for Bluetooths

because of the following reasons. If packets are transmitted by global broadcasts, excess copies

of each packet will be transmitted in the network and to the destination. Thus, global

broadcasts will entail unnecessary transmissions of packets, which waste battery power of

intermediate nodes for transmitting duplicated copies of packets at the same time that wastes

transmission bandwidth.Several routing protocols have been proposed for the mobile ad hoc

networks [1, 2, 3, 4]. These can be categorized as the proactive (also known as the table

driven) protocols, the reactive (known as source initiated or demand driven) protocols or the

hybrid of the reactive and proactive protocols. A categorization of the prominent ad hoc

routing protocols is shown in figure 3.1.

25



FIG 3.1 Categorisation Of Adhoc Routing Protocols.

a) Proactive protocols: In proactive routing protocols, routing information to reach all the

other nodes in a network is always maintained in the format of the routing table at every node.

When the network topology changes (i.e., existing nodes have moved, some new links have

been created or existing ones are dropped), such changes in link states are announced to all the

nodes in a network. Thus, routes to all possible destinations are discovered in advance of

packet transmissions.

If a proactive protocol is used for BLUETOOTHs, an immediate problem is that rapid changes

in network topology might overwhelm the network with control messages (messages for

updating the routing table at every node) and the excess messaging overhead will compromise

the throughput of actual data transmissions. Examples of proactive protocols are TORa(5),

DSDV (Destination Sequenced Distance Vector) protocol [6], WRP (Wireless Routing

Protocol) [7], and FSR (Fisheye State Routing) protocol [8]. The four protocols are also called

26

DSDV FSR ZRP

AODV DSR ABR WRP

Ad-hoc Routing

Protocols

Proactive

Protocols

Hybrid

Protocol

Reactive

Protocols

AODV: Ad hoc On Demand Distance VectorDSR: Dynamic Source Routing

ABR: Associativity Based Routing

DSDV: Destination Sequenced Distance VectorWRP: Wireless Routing Protocol

FSR: Fisheye State Routing

ZRP: Zone Routing Protocol



table-driven protocols since the routing table will be updated for each change in link states in a

network and routes are discovered using information stored in routing tables.

b) Reactive protocols: As its name suggests, this type of protocols discovers a route only

when actual data transmission takes place. When a node wants to send information to another

node in a network, a source node initiates a route-discovery process. Once a route is

discovered, it is maintained in the temporary cache at a source node unless it is expired or

unless some event happens (e.g., a link failure) that requires another route discovery to start

over again. Reactive protocols require less amount of routing information at each node,

compared to proactive protocols, as there is no need to obtain and maintain the routing

information for all the nodes in a network. Another advantage in reactive protocols is that

intermediate nodes do not have to make routing decisions.

An obvious disadvantage in reactive protocols is delay due to route discovery, called route

acquisition delay. Furthermore, if routing information changes frequently, as it is the case in

BLUETOOTHs, and if route discoveries are needed for those changed routes, reactive

protocols may result in a large volume of messaging overhead, since route recoveries require

global broadcasts. Currently popular reactive protocols are DSR (Dynamic Source Routing)

protocol [3], AODV (Ad hoc On Demand Distance Vector) protocol [2], and ABR

(Associativity Based Routing) protocol [9].

c) Hybrid (combination of proactive and reactive) Protocols: Because of the

initial delay due to route discovery and high control overhead in reactive protocols, a pure

reactive protocol may not be the best solution for routing in BLUETOOTHs. On the other

hand, a pure proactive protocol used for a large network may not be feasible because of the

need to keep a large routing table at all times. A protocol that uses the best features of both

reactive and proactive protocol may be a better solution for BLUETOOTHs. An example for

27



such an approach is the ZRP (Zone Routing Protocol) [10], although it is not the panacea for all

the limitations of other protocols.

Performance comparisons for ad hoc routing protocols have been reported in the recent past

[11, 12, 13, 14, 15, 16]. A comparison of DSR and AODV with some other protocols shows

that the performance of DSR is superior to AODV when node mobility is high, although DSR

has higher routing overhead as compared to AODV [11]. In a similar work by Das [12], it is

observed that, for metrics like delay and throughput that have real life application implications,

DSR performs better than AODV in conditions where the node density and/or node mobility

were low. According to Das, DSR always generated less control messages for routing than

AODV. However, Das argued that AODV resulted in less control messages than DSR under

high traffic load and high node mobility. Not awaring of any previously published work that

measures how much better WRP, DSR and AODV protocols are than a classical Distance

Vector protocol in ad-hoc networks. For example, how much better those BLUETOOTH

routing protocols will be than a classical Distance Vector protocol, in what aspects they are

better than Distance Vector protocol and in what conditions those BLUETOOTH routing

protocols will be better than Distance Vector protocol, surprisingly have not been answered. In

this thesis, effort has been made to find answers for such unanswered but significant questions

to understand the advantages of the BLUETOOTH routing protocols. In addition to these goals,

understanding the major properties in the existing BLUETOOTH routing protocols is also

discussed.

3.2. ROUTING PROTOCOL

In this section, the four existing routing protocols comparison are described in terms of their

implementation, design motivations and the major known characteristics.

28



DSDV (Destination Sequenced Distance Vector): DSDV protocol is a classic routing

protocol whose refined versions are used in the current wired networks. It is a proactive

protocol and is based on the concept of distance vector: every node in a network maintains a

distance table (a one-dimensional array or a vector, called distance vector), where each entry in

a distance table contains the shortest distance and the address of the next-hop router on the

shortest path to every destination in a network.

In DSDV protocol, each node knows only the distance to its directly connected neighbors at the

beginning. The distance vector initially contains only the distance to the direct neighbors (the

distance to all other nodes is initialized to be infinity). Every node exchanges its distance vector

with all its directly connected neighbors. After a node receives a distance vector from a

neighbor node, the node updates its own distance vector to reflect the least cost path to other

nodes that are not immediate neighbors. This process repeats until there is no more update in

the distance vector at all nodes in a network. When this process is completed, each node will

have a distance vector that contains the least cost path to all the other nodes in the network.

When routing information changes at any node (for example, link failures), a node sends its

new distance vector to all of its immediate neighbors. The new distance vector will be

propagated to all the other nodes in a network using the same procedure to propagate the

distance vector.

DSDV protocol has several advantages for BLUETOOTH wireless networks. First of all, the

protocol does not require a global broadcast, which is the property most essential for a routing

protocol for large networks. Another advantage is the short route acquisition delay. Since this

protocol is proactive, routing information for every destination should be available in the

routing table at each node. The lack of need for route discovery on demand results in short

route acquisition delay. The above two advantages also imply traffic load scalability, since the

29



messaging overhead of the protocol will be constant irrespective of traffic load as long as there

is no change in link states in a network.

The major known disadvantages in DSDV protocol are as follows :

1) The convergence time for propagating routing information will be long especially when the

link cost is increased Due to the long convergence time, it is possible that another change in

link states occurs while the information for the previous change in link cost has not been

completely propagated to the entire network. This could cause an erroneous routing decision,

well known as “counting-to-infinity problem”, which can result in temporary routing loops.

2) Another disadvantage in DSDV protocol is the non-availability of alternative paths. Since

the protocol uses a distributed approach, each node does not maintain the complete information

about link states in a network. Lack of complete knowledge of the link states for all links in a

network, each node is not aware of alternative paths to reach a destination. The unavailability

of the information for multiple alternative paths to reach a destination (if they exist) will make

the process of finding an alternative path during a sudden link failure a time-consuming

process, if not impossible.

3) The third problem is the large routing table. For ad-hoc networks as BLUETOOTH, the

contents of the routing tables will be short-lived. Maintaining large routing tables, while their

contents dynamically change in a short time, will result in high but unnecessary maintenance

overhead. Finally, Distance Vector protocol assumes symmetric links (e.g., costs of links are

same for the two directions on a link), which is not necessarily the case for wireless networks.

This is because each transmitting host usually uses different signal frequency in wireless

networks even when two hosts communicate with each other. Because of these problems,

DSDV protocol is seldom used in its original form.

30



Wireless Routing Protocol (TORA): WRP is proposed by Murthy [7]. WRP is an extension

of distance vector protocol that eliminates possibility of routing loops. Nodes in a network

using WRP maintain a set of four tables:

a) Link Cost Table: This table contains the cost of the link to each immediate neighbor node

and information about the status of the link to each immediate neighbor.

b) Distance Table: The distance table of a node contains a list of all the possible destination

nodes and their distances beyond the immediate neighbors.

c) Routing Table: The routing table contains a list of paths to a destination via different

neighbors. If a valid path exists between a source and a destination node, its distance is

recorded in the routing table along with information about the next-hop node to reach the

destination node.

d) Message Retransmission List (MRL): The MRL of a node contains information about

acknowledgement (ACK) messages from its neighbors. If a neighbor doesn’t reply with an

ACK for a hello message within a certain time, then this information is kept in its MRL and an

update is sent only to the non-responding neighbors.

WRP works by requiring each node to send an update message periodically. This update

message could be new routing information or a simple “hello” if the routing information hasn’t

changed from the previous update. After sending an update message to its all neighbors, a node

expects to receive an ACK from all of them. If an ACK message does not come back from a

particular neighbor, the node will record the non-responding neighbor in MRL and will send

another update to the neighbor node later.

The nodes receiving the update messages look at the new information in the update message

and then update their own routing table and link cost table by finding the best path to a

destination. This best path information is then relayed to all the other nodes so that they can

31



update their routing tables WRP avoids routing loops by checking the status of all the direct

links of a node with its direct neighbors, each time a node updates any of its routing

information.

Dynamic Source Routing (DSR) protocol : Dynamic Source Routing protocol, as its name

implies, is a source routing protocol: a complete sequence of intermediate nodes from a source

to a destination will be determined at a source node and all packets transmitted by a source

node to a destination follow the same path. Every packet header contains the complete

sequence of nodes to reach a destination. DSR protocol is a reactive protocol and its primary

motivations are, (1) to avoid periodic announcements of link states required in proactive

protocols, by separating route discovery from route maintenance, (2) to avoid long convergence

time of routing information and (3) to eliminate a large routing table for forwarding packets at

intermediate nodes. The routing table, in a sense that it is the data structure to always hold

routing information to reach every possible destination in a network, is not used in DSR

protocol. In DSR, routes are discovered on demand and route cache is used to hold routes that

are currently in use.DSR consists of two procedures route discovery and route maintenance.

Route Discovery: Every node in a network maintains a route cache that contains a list of hop-

by-hop routes to each destination node currently active and its expiration time (i.e., the time

after which a route is considered stale and discarded). Before a source node starts transmitting

data to a destination node, it first looks up its route cache to see if a valid route to that

destination exists. If such a route exists, then the route discovery process ends and the source

starts transmitting data using the route found in its route cache. Otherwise, a source node

broadcasts a route request packet (RRP) to find a route to reach the destination. This broadcast

is a global broadcast, which floods RRP in a network through all alternative paths to reach a

destination. While a RRP is being broadcast and propagated to the destination, a RRP adds the

address of every node it encounters to its list. If the same address appears more than once in the

32



list, a RRP drops itself to avoid a routing loop. When a RRP reaches the destination node, the

destination returns the learned path extracted from the RRP to the source node. For wireless

networks that consist of asymmetric links, the destination node can send that path information

back to the source node as a global broadcast, which allows DSR to work for asymmetric links.

b)Route Maintenance: Route maintenance in DSR is a mechanism to inform network failures to

all nodes in a network. Its primary motivation is to expedite detection of network failures by

explicitly announcing them to every node in a network using global broadcasts. No matter if it

is a link or node failure, a node that is connected to the other end of a failed link is responsible

for detecting a failure in DSR. On detecting a network failure, the detecting node broadcasts an

error message, called error packet, to all the other nodes in a network to inform the failure.

When other nodes receive an error packet, they will disable the paths that go through the failed

link in their route cache.

An obvious advantage in DSR is that source nodes are aware of existence of alternative paths,

which implies that recovery from a link failure will be easy and quick. Another advantage is

that there will not be a chance of a routing loop (or it is easy to detect and avoid one).

Furthermore, nodes do not have to maintain routing table, which is an advantage especially for

a large network where nodes continue to move.

Being a reactive protocol also means that a route is stored in the route cache only when one is

needed, which implies low maintenance overhead. Since most routes are short-lived and

network topology frequently changes in BLUETOOTHs, on-demand routing will make more

sense than proactive protocols in terms of maintenance overhead for routing information at

each node (this is because a node does not have to modify anything if a failed and/or changed

link is not a part of any active path from this node).

33



The disadvantage in DSR is long route acquisition delay due to route discovery if short

transmission delay is a significant factor. Long route acquisition delay may not be acceptable in

certain situations, such as mobile communication at a battlefield. It is also quite possible that

the path between a source and a destination may not be the shortest path (this is because

resumed links will not be explicitly advertised in DSR), resulting paths with in suboptimal end-

to-end delay. Another disadvantage is that messaging overhead of the protocol will be high

during busy time, when many connections must be established in a short time since broadcast is

used in route discovery. Large packet header will also cause low payload utilization, since each

packet has to contain a list of all the intermediate routers to reach a destination.

Ad hoc On Demand Distance Vector Routing : Ad-hoc On Demand Distance Vector

(AODV) protocol is a reactive routing protocol that has a motivation of providing a good

compromise between reactive source routing protocols and proactive protocols. The trade-off

problem AODV addresses is the one between high messaging overhead due to periodic

announcements of links states in proactive protocols and the large packet header to contain the

entire route information to reach a destination in source routing protocols. Unlike pure distance

vector protocols, routes are discovered and maintained on demand in AODV. Different from

DSR, AODV uses a distributed approach, meaning that source nodes do not maintain a

complete sequence of intermediate nodes to reach a destination. Different from Distance Vector

and WRP, each path is established as a pair of two streams of pointers chained between a

source and a destination node (details of this are described in a later section), which eliminates

need of broadcasting error packets on a link failure. Similar to DSR, AODV uses the route

discovery and route reply mechanism to create and maintain a route on demand.

a) Route Discovery: When a source node wants to send information to a destination node, it

first looks up its own routing table to see if a valid route exists. If a valid route does not exist, a

source node broadcasts a route request message that contains the source address, source

34



sequence number, destination address, destination sequence number, broadcast ID, and hop

count. The combination of the source address and the broadcast-ID is used to uniquely identify

each route request message while a route request message is globally broadcast. Any node that

has a valid route to the destination or the destination node is supposed to respond to route

request messages by sending a route reply message.

During a route discovery, two pointers are set up at every intermediate node between the source

and the destination nodes. The two pointers are the back pointer and the forward pointer. A

chain of the forward pointers is set up between a source and destination node while a route

request message propagates from the source node to a destination. Similarly, a chain of the

back pointers is set up while a route reply message propagates back from the destination (or

from a node that already has a valid route to the destination) to the source. As a result, all the

intermediate nodes on a route maintain a pair of the forward pointer and the back pointer for

every connection that goes through them.

Every route request contains a list of intermediate nodes that have been encountered. If the

same intermediate node appears more than once in the list, the route request message will be

dropped (the chain of forward pointers must be deleted for a route request message to be

deleted). This guarantees loop-free routing.

b) Route Maintenance: The route maintenance is performed using three different types of

messages: route-error message, “hello” message and route time-out message. The purpose of

the time-out message is obvious: if there is no activity on a route for a certain amount of time,

the route pointers at the intermediate nodes will time out and the link will be deleted at the

intermediate nodes. The periodic “hello” messages between immediate neighbors are required

to prevent the forward and backward pointers from expiration. If one of the links in a route

fails, a route-error message is generated by the node upstream (i.e., from an intermediate node

to source nodes on the link and the message is propagated to every source node in its upstream

35



that uses the failed link. Thus, the error packets will not be globally broadcast in AODV. Then,

the source nodes in the upstream will initiate the route discovery process.

Primary advantages in AODV protocol are as follow. Route caches are small in AODV,

because of its on-demand routing. Routes are guaranteed to be loop-free and valid.

Convergence time is short for propagating changes in link states because link failure

information will be propagated only to the nodes that are using a failed link (i.e., no broadcast

for error packets). Information of a link failure will be propagated following the back pointers

to reach such nodes. This implies that messaging overhead to announce link failures will be less

than that of DSR, where link failure information is broadcast. As another advantage, each data

packet does not contain the complete list of all the nodes on a route in AODV, which reduces

the size of message packet. Similar to DSR, a source node is aware of multiple alternative

paths.

One of the disadvantages in AODV protocol is that nodes can not perform routing (forwarding)

packets as aggregate (at least in the latest existing implementation of AODV). This is because a

set of pointers is used to maintain a route and each "flow" requires its own pair of back and

forward pointers. For the nodes where a large number of connections exist, overhead for

maintaining pairs of two pointers will be significant and may not be traffic-load scalable.

Another disadvantage is longer route acquisition delay compared to that for proactive protocols

since route discovery still must take place on demand. Different from DSR, AODV requires

periodic “hello” messages to maintain pointers set up at every node on a path. Use of broadcast

during route discovery, which contributes to high messaging overhead, is still the major

overhead. Yet another disadvantage of this protocol is that intermediate nodes can lead to

inconsistent routes if the source sequence number is very old and the intermediate nodes have a

higher but not the latest destination sequence number, thereby having stale entries. Also

multiple RouteReply packets in response to a single RouteRequest packet can lead to heavy

36



control overhead.Table 3.1 summarizes the discussions regarding the four routing protocols in

this section.

Table 3.1–

Major properties of the DSDV,TORA,DSR,AODV Protocols.

37

Properties DSDV TORA DSR AODV

Type of

routing

Proactive Proactive Reactive Reactive

Distributed YES (hop-by-hop)

YES (hop-by-hop)

NO (sourcerouting)

YES (hop-by-hop)

Routing loops Possible Not Possible Not Possible Not Possible

Use of

broadcast

No No Yes Yes

Control

Overhead

Constant to thenumber of sessions

Constant to thenumber of sessions

Affected by thenumber of sessions

Affected by thenumber of sessions

Routing

entries

All destinations All destinations Destinations inuse

Destinations inuse

Alternative

paths

Not available Not available Available Available

Request

response

Short Short Long (if notcached)

Long (if notcached)

Advantage Short responsetimeLow messageOH

Short responsetime

Quick pathrecovery

Small routingtableQuick recovery

Disadvantage Routing loopsLarge routingtableLongconvergencetime

Large routingtable

Long responsetimeLarge packetheader

Long responsetimeAggregaterouting is not

possible atintermediatenodes



CHAPTER 4

PROBLEM FORMULATION

4.1 PROBLEM STATEMENT

To compare the performance of the four routing protocols viz AODV,DSDV,DSR and TORA

described in the previous sections, simulation experiments are performed. In this section,

experiment modeling and design are described.

4.2 Methodology

To compare the four routing protocols, a parallel discrete event-driven simulator, Ns2, is used.

Observations focuses on three performance measurements to compare the four routing

protocols: mean end-to-end delay, packet delivery rate and routing overhead as measured by

the number of control packets generated for routing. The three measurements in our

experiments are defined as follows:

End-to-end Delay: The average time from the beginning of a packet transmission (including

route acquisition delay) at a source node until packet delivery to a destination.

Packet Delivery Rate(Throughput): Packet delivery rate is the ratio of the number of user

packets successfully delivered to a destination to the total number of user packets transmitted

by source nodes.

Messaging Overhead: The number of control packets generated for routing by each routing

protocol.

4.2.1 Network Simulator

Ns2 is an object oriented simulator, written in C++, with an OTcl interpreter as a frontend. Ns2

uses two languages because simulator has two different kinds of things it needs to do. On one

hand, detailed simulations of protocols require a systems programming language which can

efficiently manipulate bytes, packet headers, and implement algorithms that run over large data

sets. For these tasks run-time speed is important and turn-around time (run simulation, find

38



bug, fix bug, recompile, re-run) is less important. On the other hand, a large part of network

research involves slightly varying parameters or configurations, or quickly exploring a number

of scenarios. In these cases, iteration time (change the model and re-run) is more important.

Since configuration runs once (at the beginning of the simulation), run time of this part of the

task is less important. Ns2 meets both of these needs with two languages, C++ and OTcl .C++

is fast to run but slower to change, making it suitable for detailed protocol implementation.

OTcl runs much slower but can be changed very quickly (and interactively), making it ideal for

simulation configuration. In Ns2, the frontend of the program is written in TCL(Tool

Command Language). The backend of Ns2 simulator is written in C++ and when the tcl

program is compiled, a tracefile and namfile are created which define the movement pattern of

the nodes and keeps track of the number of packets sent, number of hops between 2 nodes,

connection type etc at each instance of time. In addition to these, a scenario file defining the

destination of mobile nodes along with their speeds and a connection pattern file(CBR file)

defining the connection pattern, topology and packet type are also used to create the trace files

and nam files which are then used by the simulator to simulate the network.

FIG 4.1 Simplified Users View Of NS2

[1][2] Also the network parameters can be explicitly mentioned during the creation of the

scenario and connection-pattern files using the library functions of the simulator.

39



4.2.2 Simulation

Here simulation is performed using ns2 over a three node network over an area of size 500m

over 400m.The location process is as follows The initial location of nodes 0,1,2 are

respectively (5,5),(490,285),(150,240)(the z coordinatesis assumed throughout to be zero).

1) At time 10,node 0 starts moving towards point (250,250)at a speed of 3m/sec.

2) At time 15,node 1 starts moving towards point (45,285) at a speed of 5m/sec.

3) At time 110 node o starts moving towards point (480,300) at a speed of 5m/sec.

This simulation is done for all the four routing protocols to be compared and lasts for 150 sec.A

TCP connection is initiated between the node 0 and node1

4.3 SAMPLE TCL SCRIPT

# A 3-node example for ad-hoc simulation with DSDV

# Define options

set val(chan) Channel/WirelessChannel # channel type

set val(prop) Propagation/TwoRayGround # radio-propagation model

set val(netif) Phy/WirelessPhy # network interface type

set val(mac) Mac/802_11 # MAC type

set val(ifq) Queue/DropTail/PriQueue # interface queue type

set val(ll) LL ≠link layer type

set val(ant) Antenna/OmniAntenna ≠ antenna model

set val(ifqlen) 50 # max packet in ifq

set val(nn) 3 # number of mobilenodes

set val(rp) DSDV # routing protocol

set val(x) 500 # X dimension of topography

set val(y) 400 # Y dimension of topography

set val(stop) 150 # time of simulation end

set ns [new Simulator]40



set tracefd [open simple-dsdv.tr w]

set windowVsTime2 [open win.tr w]

set namtrace [open simwrls.nam w]

$ns trace-all $tracefd

$ns use-newtrace

$ns namtrace-all-wireless $namtrace $val(x) $val(y)

# set up topography object

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)

create-god $val(nn)

# Create nn mobilenodes [$val(nn)] and attach them to the channel.

# configure the nodes

$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \

-macType $val(mac) \

-ifqType $val(ifq) \

-ifqLen $val(ifqlen) \

-antType $val(ant) \

-propType $val(prop) \

-phyType $val(netif) \

-channelType $val(chan) \

-topoInstance $topo \

-agentTrace ON \

-routerTrace ON \

-macTrace OFF \

-movementTrace ON

41



for {set i 0} {$i < $val(nn) } { incr i } {

set node_($i) [$ns node]

}

# Provide initial location of mobilenodes

$node_(0) set X_ 5.0

$node_(0) set Y_ 5.0

$node_(0) set Z_ 0.0

$node_(1) set X_ 490.0

$node_(1) set Y_ 285.0


$node_(2) set X_ 150.0

$node_(2) set Y_ 240.0


# Generation of movements

$ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0"



# Set a TCP connection between node_(0) and node_(1)

set tcp [new Agent/TCP/Newreno]

$tcp set class_ 2

set sink [new Agent/TCPSink]

$ns attach-agent $node_(0) $tcp

$ns attach-agent $node_(1) $sink

42



$ns connect $tcp $sink

set ftp [new Application/FTP]

$ftp attach-agent $tcp

$ns at 10.0 "$ftp start"

# Printing the window size

proc plotWindow {tcpSource file} {

global ns

set time 0.01

set now [$ns now]

set cwnd [$tcpSource set cwnd_]

puts $file "$now $cwnd"

$ns at [expr $now+$time] "plotWindow $tcpSource $file" }

$ns at 10.1 "plotWindow $tcp $windowVsTime2"

# Define node initial position in nam

for {set i 0} {$i < $val(nn)} { incr i } {

# 30 defines the node size for nam

$ns initial_node_pos $node_($i) 30

}

# Telling nodes when the simulation ends

for {set i 0} {$i < $val(nn) } { incr i } {

$ns at $val(stop) "$node_($i) reset";

}

# ending nam and the simulation

$ns at $val(stop) "$ns nam-end-wireless $val(stop)"

$ns at $val(stop) "stop"

$ns at 150.01 "puts \"end simulation\" ; $ns halt"

43



proc stop {} {

global ns tracefd namtrace

$ns flush-trace

close $tracefd

close $namtrace

}$ns run

44



CHAPTER 5

SIMULATION RESULTS

5.1 RESULTS AND ANALYSIS

As described in the previous chapter to obtain the results for four routing protocols using

simulation, discrete event simulator Ns2 is used. After simulating the program using constant

bit rate and scenario files we get the output in form of two files. One is called as the network

animator file (NAM) and the other is called the trace file. These two files are created in the due

course of running the program. Basically the two files stores the same things but in different

format. NAM file stores the output in such a way that it can be used by the animator to show an

animated result, and the trace file stores the output so that it can be analyzed.

Ns2 uses the TCL script for simulating the above mentioned scenario and its results are

depicted in Network Animator(NAM) which is infact the part of Ns2.Along with this Graphical

analysis is done using the another program called Tracegraph for the trace file generated.In this

section animation and graphical analysis is done one by one.

5.1.1 Animation Analysis

After simulation as per the parameters described in previous chapter(refer section4.2.3) the

animation results are obtained uning NAM.Details of these animations for which the simulatio

scenario is is common for all thethe routing protocols is described here.

Results

As simulation is of three node adhoc network for each of the routing oprotocols,at the

beginning nodes are too far away and a connection can not be set.The first TCP signalling

packet is transmitted at 10s but the connection can not be opened.Meanwhile nodes 0 and nodes

1 starts moving towards node 2.After 6 sec(pause time) a second reattempt occurs but still the

connection can not be established the pause time value is doubled to 12 sec.At time 28s

another transmission attempts occurs.The pause time value is doubled again to 24 sec and then

45



again to 48 sec.Thus only at time 100s connection has been established.The nodes 1 and 0 are

close to

each other so there is direct connection established.The nodes become further apart till the

direct link brakes.This scenario is shown in the following figures 5.1 and 5.2 which is a snap

shots of NAM at 124.15 sec.

Fig 5.1 TCP in a three node scenario for routing protocols for time 124.14 sec.

Fig 5.2 TCP in a three node scenario for routing protocols for time 58 sec.

When performing the simulation five phases of operation are observed.In the first and last

nodes are too far away and there is no connectivity.During phase 2 and 4 connection between

nodes 0 and 1 usind node 2 as a relay whereas in third phase,there is a direct path between node

0 and 1.Phase 2 at around time 40.Phase 3 starts at around 60 sec.At time 125.50 the fourth

phase starts and at time 149 sec it ends,which ends the whole connection.

46



5.1.2 Graphical Analysis

In the graphical analysis trace files(.tr) generated for all the four routing protocols viz

AODV,DSDV,DSR,TORA are analyzed for the parameters Throughput,End To End Delay and

Overhead using the graphs generated and Network information. Program used here is

tracegraph.In the following section results are depicted for the above mentioned protocols one

by one.

5.1.2.1 Results for Protocols

1) AODV Protocol

a)Simulation Information

TABLE 5.1 Simulation Information Of AODV protocol.

b)Throughput

● Throughput Of Sending Packets :

Figure 5.3 shows Throughput varies slowly with time.For simulation time range of 0-25

sec.Throughput varies in the range of 0 to 3 packets.Above that i.e. for the simulation time 25-

50 secThroughput is almost 0 packets.It abruptly rises to 45 packets for the time 51 sec.At

simulation time of 60 sec throughput falls to around 38 packets.It againvaries from 38 to 42

packets for a time range of 60 to 140 sec.Throughput immediately falls to about 5 packets at the

simulation time of about 150 sec.

47

Simulation Length In Seconds 139.5

Number Of Nodes 3

Number Of Sending Nodes 3

Number Of Receiving Nodes 3

Throughput 0.99

End To End Delay0.240 s

Routing Overhead 07



Fig 5.3 Throughput Of Sending Packets for AODV

● Throughput Of Receiving Packets :

As seen in figure 5.4 Throughput for receiving packets is concerned it is almost same for 0 to

50 sec period.At 50 second interval it increases to around 85 packets at almost around 55 sec.At

simulation time 65 sec it rises to around 90 packets.It varies from 75 to 90 for the simulation

time range of 66 to 145 sec.Throughput drops to around 1 packet beyond this.

Fig 5.4 Throughput Of Receiving Packets for AODV

48



c) End To End Delay :

Fig 5.5 Average End To End Delay for AODV

Figure 5.5 above average end to end delay varies in the range of 0 to 0.2 sec for a packet size

values of 0 to 50 packets. After the packet size of 60 end to end delay varies linearly with the

packet size upto the packet size of even 1000.

2)DSDV Protocol

a)Simulation Information:

TABLE 5.2 Simulation Information Of DSDV protocol


Number Of Nodes 3



Throughput 0.993

End To End Delay 0.1184 s

Routing Overhead 29

b)Throughput


From figure it is seen that throughput rise swiftly from 10 to 85 packets for the simulation time

49



Fig 5.6 Throughput Of Sending Packets for DSDV

range of 100 to 103 sec.It varies in the range of 75 to maximum upto 90 packets for rest of the

simulation time values i.e.upto around 125 sec.

● Throughput Of Receiving Packets

Fig 5.7 Throughput Of Receiving Packets for DSDV

Figure 5.7 shows almost the same throughput as that of sending packets for the simulation time

range of 0 to 100 sec that is negligible.It rapidly rise to 172 packets for simulation time of

50



above 100 sec.It again falls down to 140 packets for a simulation time range of 100 to 135

sec.Above 135 sec throughput again falls near to 0 packets.


Fig 5.8 Average End To End Delay for DSDV

Figure 5.8 demonstrates average end to end delay varies in the range of 0 to 0.2 sec for a

packet size values of 0 to 50 packets. After the packet size of 60 end to end delay varies

linearly with the packet size upto the packet size of even 1000.

3) DSR Protocol :

a)Simulation Information :

TABLE 5.3 Simulation Information Of DSR protocol

Simulation Length In Seconds 140

Number Of Nodes 3



Throughput 0.99

End To End Delay 0.155 s

Routing Overhead 50

51



b)Throughput


Fig 5.9 Throughput Of Sending Packets for DSR

From the figure it is clear that throughput immidiately increases from 0 to 38 packets in around

0 to 10 sec simulation time.It varies between 30 to 40 packets for th e simulation time values of

10 to 63 sec. At above 63 sec time throughput swiftly rises to about 83 packets from where it is

rises to about 83 packets from it is varies in the range of 62 to 128 sec.After 128 seconds

throughput abruptly to thr value of about 10 packets and from here onwards it again varies from

10 to 38 packets for the simulationtime range of 129 to 140 sec and above.

● Throughput Of Receiving Packets :

Figure 5.10 below shows Throughput is negligible or close to 0 for the simulation time upto 40

sec.At 40 sec Throughput rises to the value f 150 packets and from their on it changes gradually

from 125 to 150 packets for the simulation time range of about 40 to 60 sec.At above 60 sec

time throughput again rises fastly to about 250 packets.Upto simulation time of 130 sec

throughput range varies in between 225 to 250.At above 130 sec throughput again falls to the

value of less than 50 packetsand then again gain the value of nearly 145 packets at simulation

time of around 135 sec.For the time 135 and above it again varies between 125 to150 packets.

52



Fig 5.10 Throughput Of Receiving Packets for DSR


Fig 5.11 Average End To End Delay for DSR

Figure suggests that Average End To End delay rises from 0 to 0.15 second fastly for the

packet size of about 20. It falls down to 0 for the packet size of around 40.End To End delay

remains 0 for packet size range of 41 to 80. After that it rises linearly with packed size from 0

to 0.16 before again falling to 0 at the packet size of above 1000.Thus their is uneven rise and

fall in End To End Delay.

53



3) TORA Protocol :

a)Simulation Information :

TABLE 5.4 Simulation Information Of TORA protocol


Number Of Nodes 4



Throughput 0.992

End To End Delay 0.262s

Routing Overhead 5

b)Throughput


Fig 5.12 Throughput Of Sending Packets for TORA

Figure 5.12 shows throughput is 0 for the simulaton time upto 20 sec.After that it increases to

near 30 packets very rapidly for the simulation time between 19 to 22 .For the time values of

22to 40 sec it remains near to30 packets.It rises rapidly to 44 packets at simulation time of

around 45 sec and remains almost constan with avery small change upto 60 sec.At around 61 it

falls to 0 and remains near to zero for rest of the simulation time intervals.

54



● Throughput Of Receiving Packets

Fig 5.13 Throughput Of Receiving Packets for TORA

Here throughput rises from 0 to 28 packets for the time range of 10 to 22sec.It varies to a very

small values in the range of 23 to 28 packets for for the time values 23 to 37 sec.Throughput

toches the highest vlalue of aroun 45 packets at the simulation time of around 37. It varies in

the range of 32 to 45 packets for rest of the time intervals.


Fig 5.14 Average End To End Delay for TORA

55



Average End To End delay is 0 to 0.3 for the packet size of of 10 to 30.It falls to 0 for packet

size of around 40sec.From thereon End To End delay linearly with packet size frm 100 to 1000

before again decreasing slowly to zero at packet size above 1000.

56



CHAPTER 6

CONCLUSIONS AND FUTURE WORK

5.1 CONCLUSIONS

This research work evaluates the performance of four routing protocols for bluetooth (TORA, AODV

and DSR and DSDV protocol in their throughput, end-to-end delay and messaging overhead to

understand the advantages in the four protocols developed for bluetooth.Following things are

concluded.

1) Although DSR and AODV are both reactive protocols, DSR resulted in the best (i.e., the least)

messaging overhead and AODV generates higher throughput even than the two proactive protocols

(DSDV and TORA). Since the major difference between DSR and AODV for control overhead is the

lack of periodic route maintenance in DSR, the periodic “hello” messages used in AODV to maintain

routes was most probably responsible for DSR’s high control overhead.

2) Contrary to our prediction, DSDV performed much better than expected. DSDV resulted in nearly the

similar results in throughput (Figure 5.6 and 5.7) and even better in end-to-end delay, especially

compared to the two reactive protocols (AODV and DSR). The category where DSDV mostly resulted

in poor performance than the other three BLUETOOTH protocols was the messaging overhead (in the

number of control packets). DSR, against our expectation, resulted in worse performance in messaging

overhead. End-to-end delay for DSR is constantly longer than those of the three other protocols.

3) The impact of traffic load to the amount of messaging overhead for routing is observed high in

AODV.

4) Results suggest that DSR has the best scalability in messaging overhead, meaning that the number of

control packets in DSR will not increase sharply.

5) Throughput is quite high for all the four routing protocols

6) It is found that the DSR had the longest end-to-end delay and that TORA has the shortest end-to-end

delay..

57



7) Results suggest that one of the advantages in using the four routing protocols designed for

BLUETOOTHs is the good scalability for node density in messaging overhead. The results show that

increase throughput is minor for the three protocols designed for BLUETOOTHs (AODV, DSR and

TORA) .when node density is increased. The largest increase in the number of control packets when

node density is increased from low to high is 124.8% for AODV, 210.7% for DSR and 139.6% for

WRP, while it is 353.6% for Distance Vector.

8) It is observed that TORA resulted in a poor packet delivery rate or throughput.

9) DSDV results in the worst scalability, DSDV results in the highest increase rate in end-to-end delay.

This inversely implies that one of the primary advantages in the three routing protocols designed for

BLUETOOTHs is the scalability for node mobility in end-to-end delay.

10) Total number of packets transfered for DSR is much larger than DSDVand AODV.

11) TORA gives nopacket transfer at all for a three node network.

6.2 FUTURE SCOPE

Future study includes measuring the actual number of bytes transmitted for control messages, which

would be useful to better differentiate the two on-demand protocols. Another future work is to perform

the experiments for various different node migration speeds and increased number of nodes. We used

the node mobility of 3m/sec and 5m/sec this time. However, these node migration speeds are just one of

the possible velocities. Keeping the migration speed lower may lessen or rule out the cases of packets

getting dropped even before routing information is updated. This may affect the simulation results and

perhaps will bring out the strengths and weaknesses of different protocols unambiguously.

58



Appendix

ACO Authenticated Ciphering Offset

BD_ADDR Bluetooth Device Address

CA Certification Authority

CDC Certification Distribution Center

COF Ciphering Offset Number

FEC Forward Error Correction

FHSS Frequency Hoping Spread Spectrum

GFSK Gaussian Frequency Shift Keying

IEEE Institution of Electrical and Electronics Engineers

KDC Key Distribution Center

LFSR Linear Feedback Shift Register

LM Link Manager

LMP Link Manager Protocol

PDA Personal Digital Assistant

PIN Personal Identification Number

PKI Public Key Infrastructure

SIG Special Interest Group (as in Bluetooth SIG)

TTP Trusted Third Party

59



References

1. Broch J., Maltz DA, Johnson DB., Hu Y., and Jetcheva J,“A Performance Comparison

of Multi-Hop Wireless Network Routing Protocols”, Proceedings of the Fourth Annual

ACM/IEEE international Conference on Mobile Computing and Networking 1998, pp

25-30.

2. Cordeiro CM. and Agrawal DP“ Mobile Ad Hoc Networking”, Proceedings of the 20th

Brazilian Symposium on Computer Networks 2002, pp 125-186.

3. Corson MS. and Ephremides A. “A Distributed Routing Algorithm for Mobile Wireless

Networks”,ACM Baltzer Wireless Networks Journal 1 Vol 1,1995, pp 61-81.

4. Das SR., Perkins CE., and Royer EM,“ Performance Comparison of Two On-Demand

Routing Protocols for Ad Hoc Networks”, Proceedings of the IEEE INFOCOM 2000,pp

3-12.

5. Ford LR. and Fulkerson DR.“Flows in Network”, Princeton University Press Princeton,

NJ, 1962.

6. Hong X., Xu K., and Gerla M,“ Scalable Routing Protocols for Mobile Ad Hoc

Networks”, IEEE Network 2002, pp 11-21.

7. Iwata A., Chiang CC., Pei G., Gerla M., and Chen TW,“ Scalable Routing Strategies for

Ad hoc Wireless Networks”, IEEE Journal on Selected Areas in Communications,

Special Issue on Wireless Ad hoc Networks, Vol17No,1999, pp. 1369-1379.

8. Jaffe JM. And Moss FM “A Responsive Routing Algorithm for Computer Networks”,

IEEE Transaction of Communications 1982, 30(7),pp 1758-1762

60



9. Johnson DB. and Maltz DA. “Dynamic Source Routing in Ad-Hoc Wireless

Networking, Mobile Computing”; Kluwer Academic Publishing: New York, 1996.

10.Murthy S. and Gracia-Luna-Aceves JJ,“ An Efficient Routing Protocol for Wireless

Networks”, ACM Mobile Networks and Applications Journal, Special Issue on Routing

in Mobile Communications Networks 1996, pp 183-197.

11.Murthy S. and Garcia-Luna-Aceves JJ,“Loop-free Internet Routing Using Hierarchical

Routing Trees”, Proceedings of the IEEE INFOCOM 1997, pp 101-108.

12.Perkins C. and Bhagwat P,“ Highly Dynamic Destination Sequenced Distance Vector

Routing for Mobile Computers”,Proceedings of the SIGCOMM ’94 Conference on

Communication Architectures, Protocols and Applications 1994, pp 234-244.

13.Perkins C. and Royer EM“Ad hoc On Demand Distance Vector (AODV) Routing”,

Proceedings of the Second IEEE Workshop on Mobile Computing Systems and

Applications 1999; pp 90-100.

14.Raju J. and Garcia-Luna-Aceves JJ,“A Comparison of On Demand and Table Driven

Routing for Ad Hoc Wireless Networks”, Proceedings of IEEE International

Conference on Communications 2000, pp 1702-1706.

15.Royer E. and Toh CK“A Review of Current Routing Protocols for Ad Hoc Mobile

Wireless Networks”,IEEE Personal Communications 1999, pp 46-55.

16.Toh CK“ A Novel Distributed Routing Protocol to Support Ad hoc Mobile

Computing”,Proceedings of the IEEE Fifteenth Annual International Phoenix

Conference on Computers and Communications 1997, pp 1-36.

Bluetooth Report Full

Documents