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.1 Bluetooth 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 nonBluetooth correspondents. 1.2 Bluetooth Technology Bluetooth uses a frequency of 2.4 GHz, which has been set for industrial and scientific and m2

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

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

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

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 communication 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 hosts 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 specically 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., re, ood, earthquake), law enforcement (e.g., crowd control, search-and-rescue),and military(automated battleeld). Key characteristics of this system are the large number of users, their mobility, and the need to operate without the support of a xed (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 trafc 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 schemessheye 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 nonoptimal 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 trafc 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) at 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

Ad-hoc Routing Protocols

Proactive Protocols

Reactive Protocols

Hybrid Protocol DSDV WRP FSR ZRP AODV DSR ABR

DSDV: Destination Sequenced Distance Vector WRP: Wireless Routing Protocol FSR: Fisheye State Routing

AODV: Ad hoc On Demand Distance Vector DSR: Dynamic Source Routing ABR: Associativity Based Routing

ZRP: Zone Routing Protocol

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

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 doesnt 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 hasnt 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 hopby-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 endto-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.

Properties Type of routing Distributed Routing loops Use of broadcast Control Overhead Routing entries Alternative paths Request response Advantage

DSDV Proactive YES (hop-byhop) Possible No Constant to the number of sessions All destinations Not available Short Short response time Low message OH Routing loops Large routing table Long convergence time

TORA Proactive YES (hop-byhop) Not Possible No Constant to the number of sessions All destinations Not available Short Short response time Large routing table

DSR Reactive NO (source routing) Not Possible Yes Affected by the number of sessions Destinations in use Available Long (if not cached) Quick path recovery Long response time Large packet header

AODV Reactive YES (hop-byhop) Not Possible Yes Affected by the number of sessions Destinations in use Available Long (if not cached) Small routing table Quick recovery Long response time Aggregate routing is not possible at intermediate nodes

Disadvantage

37

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) set val(prop) set val(netif) set val(mac) set val(ifq)

Channel/WirelessChannel

# channel type

Propagation/TwoRayGround # radio-propagation model Phy/WirelessPhy Mac/802_11 # network interface type # MAC type

Queue/DropTail/PriQueue # interface queue type

LL link layer

set val(ll) set val(ant)

set val(ifqlen) set val(nn) set val(rp) set val(x)

type

Antenna/OmniAntenna 50 3 DSDV 500 400

antenna model

# max packet in ifq # number of mobilenodes # routing protocol # X dimension of topography # Y dimension of topography # time of simulation end
40

set val(y)

set val(stop) 150 set ns [new Simulator]

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_(1) set Z_ 0.0 $node_(2) set X_ 150.0 $node_(2) set Y_ 240.0 $node_(2) set Z_ 0.0 # Generation of movements $ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0" $ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0" $ns at 110.0 "$node_(0) setdest 480.0 300.0 5.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. Simulation Length In Seconds Number Of Nodes Number Of Sending Nodes Number Of Receiving Nodes Throughput End To End Delay Routing Overhead 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 2550 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.
139.5 3 3 3 0.99 0.240 s 07

47

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

Simulation Length In Seconds Number Of Nodes Number Of Sending Nodes Number Of Receiving Nodes Throughput End To End Delay Routing Overhead b)Throughput Throughput Of Sending Packets :

148.8 3 3 2 0.993 0.1184 s 29

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. c) End To End Delay :

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 Number Of Nodes Number Of Sending Nodes Number Of Receiving Nodes Throughput End To End Delay Routing Overhead

140 3 3 2 0.99 0.155 s 50

51

b)Throughput Throughput Of Sending Packets :

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 c) End To End Delay :

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 Simulation Length In Seconds Number Of Nodes Number Of Sending Nodes Number Of Receiving Nodes Throughput End To End Delay Routing Overhead b)Throughput Throughput Of Sending Packets :
148.8 4 4 2 0.992 0.262s 5

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. c) End To End Delay :

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 DSRs 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 EMAd 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 CKA 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.

61