Abstract This research aims to modify an existing mobile ad-hoc network (MANET) reactive routing protocol (AODV) into

a hybrid protocol by introducing adaptive, proactive behavior to improve its performance. Under our proposed scheme, route maintenance decisions are based on predicted values of 'link-breakage times' (when the next-hop node will move out of transmission range) obtained from a series of position/velocity estimates of the next-hop node. These estimates are based on the power level of the received MAC frames. If a link is about to break, proactive discovery of new routes to all destinations using the next-hop node depends on the history of traffic to that destination. We simulated (using thens2 simulator) numerous test conditions using VBR and TCP traffic and compared performance metrics for the original and modified versions of the protocol. We were able to achieve a significant reduction in mean packet latency for VBR traffic and a reduction in control overhead in TCP traffic, while incurring other small penalties for both types of traffic. Also, a comparison of some performance metrics for TCP and VBR traffic led us to conclude that slight modifications in TCP can lead to its improved performance over MANETs.

Introduction A wireless ad-hoc network is a collection of mobile/semi-mobile nodes with no pre-established infrastructure, forming a temporary network. Each of the nodes has a wireless interface and communicates with each other over either radio or infrared. Laptop computers and personal digital assistants that communicate directly with each other are some examples of nodes in an ad-hoc network. Nodes in the ad- hoc network are often mobile, but can also consist of stationary nodes, such as access points to the Internet. Semi mobile nodes can be used to deploy relay points in areas where relay Figure 1 show a simple ad-hoc network with three nodes. The outermost nodes are not within transmitter range of each other. However the middle node can be used to forward packets between the outermost nodes. The middle node is acting as a router and the three nodes have formed an ad-hoc network.

Figure 1 An ad-hoc network uses no centralized administration. This is to be sure that the network wont collapse just because one of the mobile nodes moves out of transmitter range of the others. Nodes should be able to enter/leave the network as they wish. Because of the limited transmitter range of the nodes, multiple hops

may be needed to reach other nodes. Every node wishing to participate in an adhoc network must be willing to forward packets for other nodes. Thus every node acts both as a host and as a router. A node can be viewed as an abstract entity consisting of a router and a set of affiliated mobile hosts. A router is an entity, which, among other things runs a routing protocol. A mobile host is simply an IPaddressable host/entity in the traditional sense. Ad-hoc networks are also capable of handling topology changes and malfunctions in nodes. It is fixed through network reconfiguration. For instance, if a node leaves the network and causes link breakages, affected nodes can easily request new routes and the problem will be solved. This will slightly increase the delay, but the network will still be operational. Wireless ad-hoc networks take advantage of the nature of the wireless communication medium. In other words, in a wired network the physical cabling is done a priori restricting the connection topology of the nodes. This restriction is not present in the wireless domain and, provided that two nodes are within transmitter range of each other, an instantaneous link between them may form.
HOST

HOST

Router

HOST

Figure 2

Figure 3 Over the last few years ad-hoc networking has attracted a lot of research interest. This has led to creation of a working group at the IETF that is focusing on mobile ad-hoc networking, called MANET (MANET, 2002), (Corson, 1999). Figure 8.19 shows the relation of MANET to mobile IP and DHCP. While mobile IP and DHCP handle the connection of mobile devices to a fixed infrastructure, MANET comprises mobile routers, too. Mobile devices can be connected either directly with an infrastructure using Mobile IP for mobility support and DHCP Figure 8.19 MANETs and mobile IP 331 as a source of many parameters, such as an

IP address. MANET research is responsible for developing protocols and components to enable ad-hoc networking between mobile devices. It should be noted that the separation of end system and router is only a logical separation. Typically, mobile nodes in an Adhoc scenario comprise routing and end system functionality. The reason for having a special section about ad-hoc networks within a chapter about the network layer is that routing of data is one of the most

difficult issues in ad-hoc networks. Some examples for routing algorithms suited to ad-hoc networks. NB: routing functions sometimes exist in layer 2, not just in the network layer (layer 3) of the reference model. Bluetooth, for example, offers forwarding/routing capabilities in layer 2 based on MAC addresses for ad-hoc networks. One of the first ad-hoc wireless networks was the packet radio network started by ARPA in 1973. It allowed up to 138 nodes in the ad-hoc network and used IP packets for data transport. This made an easy connection possible to the Arpanet, the starting point of todays Internet. Twenty radio channels between 1718.4-1840 MHz were used offering 100 or 400 kbit/s. The system used DSSS with 128 or 32 chips/bit. A variant of distance vector routing was used in this adhoc network (Perlman, 1992). In this approach, each node sends a routing advertisement every 7.5 s. These advertisements contain a neighbor table with a list of link qualities to each neighbor. Each node updates the local routing table according to the distance vector algorithm based on these advertisements. Received packets also help to update the routing table. A sender now transmits a packet to its first hop neighbor using the local neighbor table. Each node forwards a packet received based on its own local neighbor table. Several enhancements to this simple scheme are needed to avoid routing loops and to reflect the possibly fast changing topology. The following sections discuss routing problems and enhanced routing mechanisms for ad-hoc networks in more detail. Perkins (2001a) comprises a collection of many routing protocols together with some performance considerations. initial

Characteristics Ad-hoc networks are often characterized by a dynamic topology due to the fact that nodes change their physical location by moving around. This favors routing protocols that dynamically discover routes over conventional routing algorithms like distant vector and link state [23]. Another characteristic is that a host/node has very limited CPU capacity, storage capacity, battery power and bandwidth, also referred to as a thin client. This means that the power usage must be limited thus leading to a limited transmitter range. The access media, the radio environment, also has special characteristics that must be considered when designing protocols for ad-hoc networks. One example of this may be unidirectional links. These links arise when for example two nodes have different strength on their transmitters, allowing only one of the host to hear the other, but can also arise from disturbances from the surroundings. Multihop in a radio environment may result in an overall transmit capacity gain and power gain, due to the squared relation between coverage and required output power. By using multihop, nodes can transmit the packets with a much lower output power. It is important to acknowledge the properties or characteristics of mobile ad hoc networks (MANETs), since these properties have a signicant impact on the design of security protocols for MANETs. Although these properties are detailed in various papers [8] [3] [9] [10], security protocols that do not suit these characteristics are frequently published. The thesis is therefore started by dening the characteristics of MANETs. The security implications of the characteristics are discussed where applicable.

Network Infrastructure There is no xed or pre-existing infrastructure in an ad hoc network: all network functionality (routing, security, network management etc.) is performed by the nodes themselves. Due to the nodes limited transmission range, data dissemination is achieved in a multi- hop fashion; nodes can therefore be considered as hosts and routers. Although the lack of infrastructure opens a new window of opportunity for attacks, the author believes the lack of infrastructure can help to ensure the survivability of the network in a very hostile environment. This holds true not only from a network security perspective, but also when the users of the network are under physical attack. Ad hoc networks may be spontaneously formed with no a priori knowledge of the physical location and networking environment. Mantes lack of infrastructure thus makes it suitable for various applications where conventional networks fall short. Some researchers have already addressed security issues in hybrid ad hoc networks. Hybrid ad hoc networks combine conventional network infrastructure with multi-hopping. This derivative of ad hoc networks will nd useful application where xed infrastructure can be extended through multi-hop networks or where the functionality (and performance) of multi-hop networks can be enhanced by relying on some infrastructure. The access point does not just control medium access, but also acts as a bridge to other wireless or wired networks. Several wireless networks may form one logical wireless network, so the access points together with the fixed network in between can connect several wireless networks to form a larger network beyond actual radio coverage

Figure 4 Typically, the design of infrastructure-based wireless networks is simpler because most of the network functionality lies within the access point, whereas the wireless clients can remain quite simple. This structure is reminiscent of switched Ethernet or other star-based networks, where a central element (e.g., a switch) controls network flow. This type of network can use different access schemes with or without collision. Collisions may occur if medium access of the wireless nodes and the access point is not coordinated. However, if only the access point controls medium access, no collisions are possible. This setting may be useful for quality of service guarantees such as minimum bandwidth for certain nodes. The access point may poll the single wireless nodes to ensure the data rate. Infrastructurebased networks lose some of the flexibility wireless networks can offer, e.g., they cannot be used for disaster relief in cases where no infrastructure is left. Typical cellular phone networks are infrastructure-based networks for a wide area . Also satellite-based cellular phones have an infrastructure - the satellites. Infrastructure does not necessarily imply a wired fixed network. Ad-hoc wireless networks,

however, do not need any infrastructure to work. Each node can communicate directly with other nodes, so no access point con- trolling medium access is necessary. Figure 2 shows two ad-hoc networks with three nodes each. Nodes within an ad-hoc network can only communicate if they can reach each other physically, i.e., if they are within each others radio range or if other nodes can forward the message. Nodes from the two networks shown in Figure 2 cannot, therefore, communicate with each other if they are not within the same radio range. In ad-hoc networks, the complexity of each node is higher because every node has to implement medium access mechanisms, mechanisms to handle hidden or exposed terminal problems, and perhaps priority mechanisms, to pro- vide a certain quality of service. This type of wireless network exhibits the greatest possible flexibility as it is, for example, needed for unexpected meetings, quick replacements of infrastructure or communication scenarios far away from any infrastructure.

Figure 5 Clearly, the two basic variants of wireless networks (here especially WLANs), infrastructure-based and ad-hoc, do not always come in their pure form. There are networks that rely on access points and infrastructure for basic services (e.g.,

authentication of access, control of medium access for data with associated quality of service, management functions), but that also allow for direct communication between the wireless nodes. However, ad-hoc networks might only have selected nodes with the capabilities of forwarding data. Most of the nodes have to connect to such a special node first to transmit data if the receiver is out of their range. From the three WLANs presented, IEEE 802.11and HiperLAN2 are typically infrastructure-based networks, which additionally support ad-hoc networking. However, many implementations only offer the basic infrastructure-based version. The third WLAN, Bluetooth is a typical wireless ad-hoc network. Bluetooth focuses precisely on spontaneous ad-hoc meetings or on the simple connection of two or more devices without requiring the setup of an infrastructure. Network Topology Nodes in ad hoc networks may be mobile resulting in a dynamic, weakly connected topology. Since node mobility is unrestricted, the topology may be unpredictable. The net- work will however demonstrate global mobility patterns which may not be completely random. The topology is weakly connected due to transient, error-prone wireless connectivity. The users may therefore experience unavailability of essential security services. Node mobility and wireless connectivity allow nodes to spontaneously join and leave the network, which makes the network amorphous. Security services must be able to scale seamlessly with rapid changes in network density. Self-Organization MANETs cannot rely on any form of central administration or control; this is essential to avoid a single point of attack [1]. A self-organized MANET cannot rely on any form of oline trusted third party (TTP); the network can thus be

initialized by a distributed on-line TTP. A pure or fully self-organized MANET does not rely on any form of TTP whatsoever , i.e. the on-line TTP is also eliminated. Nodes will therefore only have compatible devices with the same software installed. In the extreme case, the nodes will not even share a common set of security system parameters. The lack of a TTP may force the end-users to actively participate in the setup of security associations. A (fully) self-organized MANET has some inherent security implications: ->Fully self-organized MANETs are open in nature: similar to the internet, any user can join the network at random. Access control to applications will have to be provided at the application layer with a varying degree of user interaction ->Each user will be its own authority domain, hence responsible for generating and distributing its own keying material. As pointed out by Douceur any node can generate more than one identity when there is no of-line TTP. It is thus clear that it will be very dicult (if not impossible) to limit users to one and only one unique identity in a (fully) self-organized setting. ->The network will always be vulnerable to the active insider adversary. In fact, the Dolev-Yao adversary model is too restrictive, for example, it fails to capture information an adversary may gain from detailed knowledge of the protocols in use. An interesting topic for future research will be the adversary model in open ad hoc networks. -> It will be dicult to hold malicious nodes accountable for their actions, since they can always rejoin the network under a dierent (new) identity.

Literature Survey Impact of Node Mobility on MANET Routing Protocols Models A Mobile Ad-Hoc Network (MANET) is a self-configuring network of mobile nodes connected by wireless links to form an arbitrary topology without the use of existing infrastructure. In this paper, we have studied the effects of various mobility models on the performance of two routing protocols Dynamic Source Routing (DSR-Reactive Protocol) and Destination-Sequenced Distance-Vector (DSDV-Proactive Protocol). For experiment purposes, we have considered four mobility scenarios: Random Waypoint, Group Mobility, Freeway and Manhattan models. These four Mobility Models are selected to represent possibility of practical application in future. Performance comparison has also been conducted across varying node densities and number of hops. Experiment results illustrate that performance of the routing protocol varies across different mobility models, node densities and length of data paths. Empirical results illustrate that the performance of a routing protocol varies widely across different mobility models and hence the study results from one model cannot be applied to other model. Hence we have to consider the mobility of an application while selecting a routing protocol. DSR gives better performance for highly mobile networks than DSDV. DSR is faster in discovering new route to the destination when the old route is broken as it invokes route repair mechanism locally whereas in DSDV there is no route repair mechanism. In DSDV, if no route is found to the destination, the packets are dropped.

A Survey of QoS Routing Solutions for Mobile Ad Hoc Networks This document offers an up-to-date survey of most major contributions to the pool of QoS routing solutions for MANETs published in the period 1997-2006. We include a thorough overview of QoS routing metrics, resources and factors affecting performance and classify the protocols found in the literature. We also summaries their operation and describe their interactions with the medium access control (MAC) protocol, where applicable. This provides the reader with insight into their differences and allows us to highlight trends in protocol design and identify areas for future research. The majority of the solutions proposed in the literature till now have focused on providing QoS based on two metrics: throughput and delay. Of these, the more common is throughput. This is probably because assured throughput is somewhat of a lowest common denominator requirement; most voice or video applications require some level of guaranteed throughput in addition to their other constraints. However, many other metrics are also used to quantify QoS and in this work we cover most of them and provide examples of their use. To some extent this is an historical limitation, since mobile devices are becoming increasingly powerful and capable. However, it still holds true that such devices generally have less computational power, less memory and a limited (battery) power supply, compared to devices such as desktop computers typically employed in wired networks. This factor has a major impact on the provision of QoS assurances, since low memory capacity limits the amount of QoS state that can be stored, necessitating more frequent updates, which incur greater overhead. Additionally, QoS routing generally incurs a greater overhead than besteffort routing in the first place, due to the extra information being disseminated. These factors lead to a higher drain on mobile nodes' limited battery power supply.

Dynamic Source Routing in Ad Hoc Wireless Networks 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 mobile hosts wireless transmissions. This paper presents a protocol for routing in ad hoc networks that uses dynamic source routing. Routing protocols in conventional wired networks generally use either distance vector or link state routing algorithms, both of which require periodic routing advertisements to be broadcast by each router. In distance vector routing each router broadcasts to each of its neighbor routers its view of the distance to all hosts, and each router computes the shortest path to each host based on the information advertised by each of its neighbors. In link state routing each router instead broadcasts to all other routers in the network its view of the status of each of its adjacent network links, and each router then computes the shortest distance to each host based on the complete picture of the network formed from the most recent link information from all routers. In addition to its use in wired networks, the basic distance vector algorithm has also been adapted for routing in wireless ad hoc networks, essentially treating each mobile host as a router. Finally, we are beginning implementation of the protocol on notebook computers for use by students in an academic environment.

QoS-Aware Routing Based on Bandwidth Estimation for Mobile Ad Hoc Networks We believe that such QoS support can be achieved by either finding a route to satisfy the application requirements or offering network feedback to the application when the requirements cannot be met. We propose a QoS-aware routing protocol that incorporates an admission control scheme and a feedback scheme to meet the QoS requirements of real-time applications. The novel part of this QoS-aware routing protocol is the use of the approximate bandwidth estimation to react to network traffic. Our approach implements these schemes by using two bandwidth estimation methods to find the residual bandwidth available at each node to support new streams. We simulate our QoS-aware routing protocol for nodes running the IEEE 802.11medium access control. Results of our experiments show that the packet delivery ratio increases greatly, and packet delay and energy dissipation decrease significantly, while the overall end-to-end throughput is not impacted, compared with routing protocols that do not provide QoS support. We propose a QoS-aware routing protocol, which is based on residual bandwidth estimation during route set up. Our QoS-aware routing protocol is built off AODV, in which the routing table is used to forward packets, Hello messages are used to detect broken routes and Error messages are used to inform upstream hosts about a broken route. We explore two ways to perform bandwidth estimation, and we incorporate both an adaptive feedback-based scheme and an admission control scheme. The accurate measurement of the capacity of a multi-hop mobile network is an open issue right now. Further study of the802.11 MAC layers behavior could be helpful to understand this capacity issue. Also, in a real scenario, shadowing will cause a nodes transmission range to vary, and it will not be the ideal circle that is assumed here.

Performance Evaluation of MANET Routing Protocols under CBR and FTP traffic classes Understanding the performance of routing protocols in ad hoc networks is a key feature to determine which routing protocol is best suited for which type of network scenario. From the literature survey it was found that there is a lot of work done on evaluating the performance [3] of various MANET routing protocols for CBR traffic but there is very little work done for variable bit rate like FTP, TELNET type of traffic.So, in this paper it is proposed to evaluate and analyze the performance of proactive (WRP) and reactive (AODV, DSR) routing protocols based on traffic generators like FTP under different network scenarios like pause time, offered load (i.e. number of source destination pairs), node speed. For CBR traffic, we have presented 3 different scenarios, varying pause time, offered load (i.e. number of source destination pairs) and average node speed.In pause time scenario, performance analysis shows that AODV performs better than DSR and WRP in terms of packet delivery ratio, throughput and routing message overhead. WRP exhibits the worst performance in terms of packet delivery ratio, throughput and routing message overhead. But for average end-to-end delay WRP shows the best performance while DSR shows worst performance in terms of average end-toend delay. we have simulated the AODV, DSR and WRP routing protocols and evaluated the performance under CBR and FTP traffics. Performance of each routing protocols evaluated using a detailed simulation-based analysis. Performance metrics considered are packet delivery ratio.

Project Introduction A Mobile Ad Hoc Network generally does not have any infrastructure and each mobile host also acts as a router. Communication between various hosts takes place through wireless links. Direct communication can take place between hosts that are within the communication range of the antennas of the respective hosts; otherwise, communication is achieved through multi-hop routing. Figure 1 represents a MANET of 3 nodes. Node2 can communicate directly with Node 1 and Node 3. But any communication between Nodes 1 and 3 must be routed through Node 2.

Figure 1 The following are the salient features of MANETs: Dynamic Topologies: All nodes in the MANET generally move with varying velocities, and hence the network topology changes dynamically. Frequent link breaks are quite common. New nodes may join the network or existing nodes can leave the network. The dynamic changes in the network topology pose the biggest challenge to routing in Ad Hoc Networks.

Asymmetrical Communication: Each node in the Ad Hoc Network may have antennas of different characteristics, and hence symmetrical, bidirectional communication over the same link is not always possible. In some cases, only unidirectional communication is possible Bandwidth limitations: Since the nodes communicate via wireless links, the realized throughput in these networks when compared to a wired network of similar size is quite small. The relatively lower capacity of the wireless links does not facilitate transmission of delay-constrained traffic (real-time or multimedia traffic). Moreover, the wireless links are quite error-prone, which may further degrade throughput due to upper layer retransmissions, etc. Energy limitations: The nodes in the MANET are generally battery operated. Hence, energy conservation techniques and energy-aware routing in MANETs become necessary. /Existing routing protocols in wired networks (both link state and distance vector) are not suitable for MANETs. These routing protocols distribute topological information across the network to update other nodes of topological changes. This mechanism is not suitable in MANETs, because there are frequent topological changes as the nodes move randomly causing frequent link breakages. In the experimental results illustrate that performance of the routing protocol AODV varies across different random mobility models: Random Waypoint, Random Walk with Reflections and Random Walk with Wrapping. The performances of latest three mobility models have been evaluated in [12] with AODV routing protocol. The results show that Random Waypoint Model is the best model which outperforms both Random Walk Model and Random Direction Model in both scenarios. The results indicate that Random Waypoint produces the

highest throughput but the throughput of the Random Walk Model and Random Direction drastically falls over a period of time. Existing System The existing routing protocols in MANETs can be classified into two categories: (1)Table-driven routing protocols, and (2) On-demand routing protocols. Fig 2 shows the classification along with some examples of existing MANET protocols.

Figure 2 Table Driven or Proactive Protocols Table-driven protocols) generate frequent updates protocols (proactive

of network topology information to

maintain a consistent view of the network at all nodes. These nodes are required to maintain tables containing topology information, so that any node wishing to communicate with any other node may do so by computing a route to the destination node from the table. It is fairly expensive in terms of table size and

control overhead to maintain a table of topological information of all nodes. The chief disadvantage of this method is that the nodes may be maintaining topological information about nodes with which it may never communicate. Destination Sequenced Distance Vector Routing Destination-Sequenced Distance-Vector (DSDV) Routing is based on the classical Bellman-Ford routing scheme. DSDV, unlike traditional distance vector protocols, guarantees loop-freedom by tagging each route table entry with a sequence number to order the routing information. Each node maintains a routing table with all available destinations along with information like next hop, the number of hops to reach to the destination, sequence number of the destination originated by the destination node, etc. DSDV uses both periodic and triggered routing updates to maintain table consistency. Triggered routing updates are used when network topology changes are detected , so that routing information is propagated as quickly as possible. Routing table updates can be of two types - "full dump" and incremental. Full dump packets carry all available routing information and may require multiple network protocol data units (NPDU);incremental packets carry only information changed since the last full dump and should fit in one NPDU in order to decrease the amount of traffic generated. Dynamic Source Routing Dynamic Source Routing (DSR), as the name suggests, is based on the concept of source routing. There are no periodic routing advertisements; instead, routes are dynamically determined based on cached information or on the result of a route discovery process. In source routing, the sender of the packet specifies the complete sequence of the nodes that the packet has to take. The sender explicitly lists this route in the packets

header, identifying each forwarding hop by the address of the next node to which the packet must be sent on its way to the destination host. A key advantage of source routing is that intermediate hops do not need to maintain routing information in order to route the packet they receive, since the packets themselves already contain all the necessary routing information. Unlike conventional routing protocols, the DSR protocol does not periodically transmit route advertisements, thereby reducing control overhead, particularly during periods when little or no significant host movement is taking place. The DSR protocol consists of two mechanisms: Route Discovery and Route Maintenance. When a mobile node wants to send a packet to some destination, it first consults its route cache for a non-expired route. If the node does not have such a route, it will initiate route discovery by broadcasting a route request (RREQ) packet, which contains the addresses of the source node and the destination, and a unique sequence number request id, which is set by the source node. Each node in the network maintains a list of (source address, request id) pair that it has recently received from any host in order to detect duplicate route requests received. Ad-hoc On-Demand Distance Vector Routing (AODV) is essentially a combination of both DSR and DSDV. It borrows the conception of sequence numbers from DSDV, plus the use of the on-demand mechanism of route discovery and route maintenance from DSR. It is called a pure on-demand route acquisition system; nodes that do not lie on active paths neither maintain any routing information nor participate in any periodic routing table exchanges. It is loop-free, self-starting, and scales to a large number of mobile nodes. AODV Process Normal RREQ and RREP processing mechanism of AODV is as follows: The source node S tries to send a packet to destination D. If S does not know the next hop for D, then it broadcasts a route request message. The RREQ

message propagates in all directions to reach the destination D. the intermediate nodes that receive the RREQ message forward the packet to all its one hop adjacent nodes. If the destination, D, receives a RREQ message through a node N, then it sends a RREP to S by forwarding it to N since N may contain at least one routing table entry for S. On receiving the RREQ message through different nodes, the destination D will send the RREP message through different nodes and they may reach the source node through different possible paths. At the end, the source node S will have different possible resolved paths to select from based on defined criteria. Proposed System Standard AODV routing process broadcasts route request to all nodes. In the proposed scheme, a table of nodes in a given neighborhood (one-hop nodes) is maintained. When a message is transmitted, only a subset of nodes in each neighborhood is allowed to transmit. The number of selected nodes can be varied dynamically depending on the application and required quality of service. In this proposed scheme, the parameters that are used are defined in Table 1. Each node in the network will forward a route request message if and only if a condition based on its neighborhood density at that instance is satisfied. The proposed scheme minimizes network congestion due to redundant transmission. If the RREQ is received from an intermediate node then there will be at least one possible path which includes that node in its path list. Therefore, if only selected nodes are allowed to forward the RREQ packet, then only these nodes will be included in the path list. In this proposed scheme, the neighborhood density of an intermediate node is considered as a criterion in RREQ forwarding decision at intermediate node. It means that if the number of nodes in the neighborhood is high, then the probability of any node transmitting will decrease

and hence reduces the transmission overhead. Random selection of nodes from the neighborhood set increases the chance of full network coverage. Greater savings could be achieve by using a range dependent technique to select nodes for transmission but this can only be achieved at the cost of greater complexity. In this proposed system we improve the performance of AODV routing protocol using VBR traffic process, the VBR traffic models being able to capture both the real data styles and various compression techniques are needed. The content based approach to the modeling of VBR data streams is one of the research directions aimed at solving this problem. The VBR coded data has a very complicated structure. The previous attempts to characterize VBR data streams by various stochastic models without understanding the nature of the coding process have not been fully successful and have only limited usability. Such models focused only on matching the trace statistics or queuing analysis. The introduction of data content into the VBR data modeling allows us to create realistic VBR data traffic based not only on global statistical parameters but also on the data style, scene or object description. Since the particular data stream is a combination of scene characteristic and coding algorithm specific mapping, it is desirable to separate them by identifying the independent descriptor variables characterizing the scene, frame, and objects.

Implementation & Methodology SOFTWARE SPECIFICATIONS 1. OS 2. Simulator 3. Language 4. Graph 5. Protocol Design : Linux (vmware) : NS2 : Tcl/Tk : GNUplot : CC

HARDWARE SPECIFICATIONS

1. Processor Type 2. Processor Speed 3. RAM

: Pentium IV : 2.7GHz : 1GB

Overview of ns-2 simulation test bed NS-2 is n event driven packet level network simulator developed as a part of the VINT project (Virtual Internet Test bed).Version 1 of NS was developed in 1995 and with version 2 in 1996. The Ns-2 with C++/OTCL integration feature. Version 2 included a scripting language called Object oriented Tcl (OTcl). It is an open source software package available for both Windows 32 and Linux platforms. NS-2 has many and expanding uses included. To evaluate that performance of existing network protocols To evaluate new network protocols before use.

 To run large scale experiments not possible in real experiments To simulate a variety of ip networks.

NS -2 is an object oriented discrete event simulator. or race conditions Back end is C++ event scheduler. Protocols mostly Fast to run, more control

Simulator maintains list of

events and executes one event after another. Single thread of control: no locking

Front end is OTCL Creating scenarios, extensions to C++ protocols fast to write and change

Characteristics of NS-2 NS-2 implementation the following features Multicasting Simulation of wireless networks Terrestrial (cellular, Adhoc, GPRS, WLAN, BLUETOOTH), satellite IEEE 802.11 can be simulated, Mobile IP and Ad hoc protocols such as DSR, TORA, DSDV and AODV Routing

Software Tools used with NS-2

In the simulation, there are the two tools are used. NAM(Network Animator) xGraph

NAM (Network Animator) NAM provides a visual interpretation of the network topology created. The application was developed as part of the VINT project. Its feature is as follows. Provides a visual interpretation of the network created Can be executed directly from a Tcl script Controls include play; stop fast forward, rewind, pause, a display speed controller button and a packet monitor facility. Presented information such as throughput, number packets on each link

X Graph X- Graph is an X-Window application that includes: Interactive plotting and graphing Animated and derivatives to use Graph in NS-2 the executable can be called within a TCL script. This will then load a graph displaying the information visually displaying the information of the file produced from the simulation. The output is a graph of size 800 x 400 displaying information on the traffic flow and time. Simulation tool

NS2 are often growing to include new protocols. LANs need to be updated for new wired/wireless support. ns are an object oriented simulator, written in C++, with an OTcl interpreter as a front-end. The simulator supports a class hierarchy in C++ and a similar class hierarchy within the OTcl interpreter (also called the interpreted hierarchy). The two hierarchies are closely related to each other; from the users perspective, there is a one-to-one correspondence between classes in the interpreted. 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 bug, fix bug, recompile, rerun) 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. Ns 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. NS (via tclcl) provides glue to make objects and variables appear on both languages. Modules Architecture model Route discovery

 Route switching mechanism Resource State Maintenance Performance evaluation Architecture model In the ns-2 802.11 code, a transmitted packets reception is conditional upon the SINR being higher than the threshold for the particular modulation scheme that the packet was transmitted with. However, both the standard, as well as commercial WLAN cards also require the absolute signal power to be above a modulation mode-specific threshold for reliable signal reception. Random Way point Each node stores the rate that was last used for transmission to each of its neighbors with which it has communicated, as well as the numbers of contiguous missed or received ACKs. Since the transmission rate is likely to change multiple times per second, following the fluctuations due to shadowing, it is impractical to report every change to the network layer protocols. Instead, the rate in use by each packet is recorded, and the average rate is calculated in a sliding window. Route discovery In the newly proposed protocol, once a session being admitted by StAC has found a suitable route and its CS neighbors have been tested during the SREQ/SREP exchange (stage 2), a backup route for the session must be found.

Resource State Maintenance

StAC uses a source route header extension to carry a source nodes view of the available residual capacity at the nodes on a sessions route. If, upon forwarding a data packet, a node detects that the sources view differs from its own estimate of the residual capacity by a given amount, and no update has been sent to that source node recently, an update packet is sent. Performance evaluation That StAC and StAC-backup are not multirate aware, and hence, a fixed 6 Mbps BPSK mode transmission rate is assumed. Simulations of StAC-multirate and StAC-multirate-backup employ the multirate MAC model described above.

Data Flow Diagram

Architecture model

VBR Traffic allocation

Send RREQ

Route Discovery

NO

Request discard

ano

YES

Path Establishment

reach destination

Yes
Buy SmartDraw!- purchased copies print this document without a watermark . Visit www.smartdraw.com or call 1-800-768-3729.

Performance evaluation

Conclusion and Future Enhancement We presented a new framework of content based approach to modeling of VBR data sources. This approach is based on the fact that typical data compression algorithms such as MPEG-2 in order to encode the original data stream have explored a variety of high-correlated features in both spatial and temporal scale. Identification of various features descriptors and their influence on the final bit rate is the key point in the content-based data modeling. We outlined the separation principle which isolates the independent data features from their specific use during the compression. Such separation allows us to accommodate both current (MPEG-2) and future coding algorithms (e.g. regionbased, object-based or modelbased coding) into the same framework by specification of only algorithmic, coding specific part of the model. The data feature part of the model could remain the same. The classification of higher level features such as camera movement, zooming, panning, etc.,In the future, by identifying and separating other independent data features, we would like to accommodate new content-based data coding techniques into the same framework. The proposed approach to VBR data traffic modeling also has great synergy with recent work on content-based image/data search and retrieval

AODV Process
//#include <ip.h> #include <aodv/aodv.h> #include <aodv/aodv_packet.h> #include <random.h> #include <cmu-trace.h> //#include <energy-model.h> #define max(a,b) #define CURRENT_TIME //#define DEBUG //#define ERROR #ifdef static static static #endif /* */ int hdr_aodv::offset_; static class AODVHeaderClass : public PacketHeaderClass { public: AODVHeaderClass() : PacketHeaderClass("PacketHeader/AODV", sizeof(hdr_all_aodv)) { bind_offset(&hdr_aodv::offset_); } } class_rtProtoAODV_hdr; static class AODVclass : public TclClass { public: AODVclass() : TclClass("Agent/AODV") {} TclObject* create(int argc, const char*const* argv) { assert(argc == 5); //return (new AODV((nsaddr_t) atoi(argv[4]))); return (new AODV((nsaddr_t) Address::instance().str2addr(argv[4]))); } } class_rtProtoAODV; int AODV::command(int argc, const char*const* argv) { if(argc == 2) { Tcl& tcl = Tcl::instance(); if(strncasecmp(argv[1], "id", 2) == 0) { tcl.resultf("%d", index); return TCL_OK; DEBUG int extra_route_reply = 0; int limit_route_request = 0; int route_request = 0; ( (a) > (b) ? (a) : (b) ) Scheduler::instance().clock()

TCL Hooks

} if(strncasecmp(argv[1], "start", 2) == 0) { btimer.handle((Event*) 0); #ifndef AODV_LINK_LAYER_DETECTION htimer.handle((Event*) 0); ntimer.handle((Event*) 0); #endif // LINK LAYER DETECTION rtimer.handle((Event*) 0); return TCL_OK; } } else if(argc == 3) { if(strcmp(argv[1], "index") == 0) { index = atoi(argv[2]); return TCL_OK; } else if(strcmp(argv[1], "log-target") == 0 || strcmp(argv[1], "tracetarget") == 0) { logtarget = (Trace*) TclObject::lookup(argv[2]); if(logtarget == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "drop-target") == 0) { int stat = rqueue.command(argc,argv); if (stat != TCL_OK) return stat; return Agent::command(argc, argv); } else if(strcmp(argv[1], "if-queue") == 0) { ifqueue = (PriQueue*) TclObject::lookup(argv[2]); if(ifqueue == 0) return TCL_ERROR; return TCL_OK; } else if (strcmp(argv[1], "port-dmux") == 0) { dmux_ = (PortClassifier *)TclObject::lookup(argv[2]); if (dmux_ == 0) { fprintf (stderr, "%s: %s lookup of %s failed\n", __FILE__, argv[1], argv[2]); return TCL_ERROR; } return TCL_OK; } } return Agent::command(argc, argv); } /* */ AODV::AODV(nsaddr_t id) : Agent(PT_AODV), Constructor

btimer(this), htimer(this), ntimer(this), rtimer(this), lrtimer(this), rqueue() { index = id; seqno = 2; bid = 1; /* Get Position Sundaresh k - Elysium Technologies*/ xpos = 0.0; ypos = 0.0; zpos = 0.0; MobileNode *iNode; iEnergy = 0.0; LIST_INIT(&nbhead); LIST_INIT(&bihead); logtarget = 0; ifqueue = 0;

} /* */

Timers

void BroadcastTimer::handle(Event*) { agent->id_purge(); Scheduler::instance().schedule(this, &intr, BCAST_ID_SAVE); } void HelloTimer::handle(Event*) { agent->sendHello(); double interval = MinHelloInterval + ((MaxHelloInterval - MinHelloInterval) * Random::uniform()); assert(interval >= 0); Scheduler::instance().schedule(this, &intr, interval); } void NeighborTimer::handle(Event*) { agent->nb_purge(); Scheduler::instance().schedule(this, &intr, HELLO_INTERVAL); } void RouteCacheTimer::handle(Event*) { agent->rt_purge(); #define FREQUENCY 0.5 // sec Scheduler::instance().schedule(this, &intr, FREQUENCY); } void LocalRepairTimer::handle(Event* p) { // SRD: 5/4/99 aodv_rt_entry *rt; struct hdr_ip *ih = HDR_IP( (Packet *)p);

/* you get here after the timeout in a local repair attempt */ /* fprintf(stderr, "%s\n", __FUNCTION__); */ rt = agent->rtable.rt_lookup(ih->daddr()); if // // // /* /* (rt && rt->rt_flags != RTF_UP) { route is yet to be repaired I will be conservative and bring down the route and send route errors upstream. The following assert fails, not sure why */ assert (rt->rt_flags == RTF_IN_REPAIR); */

//rt->rt_seqno++; agent->rt_down(rt); // send RERR #ifdef DEBUG fprintf(stderr,"Node %d: Dst - %d, failed local repair\n",index, rt>rt_dst); #endif } Packet::free((Packet *)p); } /* */ void AODV::id_insert(nsaddr_t id, u_int32_t bid) { BroadcastID *b = new BroadcastID(id, bid); assert(b); b->expire = CURRENT_TIME + BCAST_ID_SAVE; LIST_INSERT_HEAD(&bihead, b, link); } /* SRD */ bool AODV::id_lookup(nsaddr_t id, u_int32_t bid) { BroadcastID *b = bihead.lh_first; // Search the list for a match of source and bid for( ; b; b = b->link.le_next) { if ((b->src == id) && (b->id == bid)) return true; } return false;

Broadcast ID Management

Functions

void AODV::id_purge() { BroadcastID *b = bihead.lh_first; BroadcastID *bn;

double now = CURRENT_TIME; for(; b; b = bn) { bn = b->link.le_next; if(b->expire <= now) { LIST_REMOVE(b,link); delete b; } }

/* */ Helper Functions

double AODV::PerHopTime(aodv_rt_entry *rt) { int num_non_zero = 0, i; double total_latency = 0.0; if (!rt) return ((double) NODE_TRAVERSAL_TIME ); for (i=0; i < MAX_HISTORY; i++) { if (rt->rt_disc_latency[i] > 0.0) { num_non_zero++; total_latency += rt->rt_disc_latency[i]; } } if (num_non_zero > 0) return(total_latency / (double) num_non_zero); else return((double) NODE_TRAVERSAL_TIME); } /* */ static void aodv_rt_failed_callback(Packet *p, void *arg) { ((AODV*) arg)->rt_ll_failed(p); } /* * This routine is invoked when the link-layer reports a route failed. */ void AODV::rt_ll_failed(Packet *p) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); aodv_rt_entry *rt; nsaddr_t broken_nbr = ch->next_hop_; #ifndef AODV_LINK_LAYER_DETECTION drop(p, DROP_RTR_MAC_CALLBACK); Link Failure Management Functions

#else /* * Non-data packets and Broadcast Packets can be dropped. */ if(! DATA_PACKET(ch->ptype()) || (u_int32_t) ih->daddr() == IP_BROADCAST) { drop(p, DROP_RTR_MAC_CALLBACK); return; } log_link_broke(p); if((rt = rtable.rt_lookup(ih->daddr())) == 0) { drop(p, DROP_RTR_MAC_CALLBACK); return; } log_link_del(ch->next_hop_); #ifdef AODV_LOCAL_REPAIR /* if the broken link is closer to the dest than source, attempt a local repair. Otherwise, bring down the route. */ if (ch->num_forwards() > rt->rt_hops) { local_rt_repair(rt, p); // local repair // retrieve all the packets in the ifq using this link, // queue the packets for which local repair is done, return; } else #endif // LOCAL REPAIR { drop(p, DROP_RTR_MAC_CALLBACK); // Do the same thing for other packets in the interface queue using the // broken link -Mahesh while((p = ifqueue->filter(broken_nbr))) { drop(p, DROP_RTR_MAC_CALLBACK); } nb_delete(broken_nbr); } #endif // LINK LAYER DETECTION } void AODV::handle_link_failure(nsaddr_t id) { aodv_rt_entry *rt, *rtn; Packet *rerr = Packet::alloc(); struct hdr_aodv_error *re = HDR_AODV_ERROR(rerr); re->DestCount = 0; for(rt = rtable.head(); rt; rt = rtn) { // for each rt entry rtn = rt->rt_link.le_next; if ((rt->rt_hops != INFINITY2) && (rt->rt_nexthop == id) ) { assert (rt->rt_flags == RTF_UP); assert((rt->rt_seqno%2) == 0); rt->rt_seqno++;

re->unreachable_dst[re->DestCount] = rt->rt_dst; re->unreachable_dst_seqno[re->DestCount] = rt->rt_seqno; #ifdef DEBUG fprintf(stderr, "%s(%f): %d\t(%d\t%u\t%d)\n", __FUNCTION__, CURRENT_TIME, index, re->unreachable_dst[re->DestCount], re->unreachable_dst_seqno[re->DestCount], rt->rt_nexthop); #endif // DEBUG re->DestCount += 1; rt_down(rt); } // remove the lost neighbor from all the precursor lists rt->pc_delete(id); } if (re->DestCount > 0) { #ifdef DEBUG fprintf(stderr, "%s(%f): %d\tsending RERR...\n", __FUNCTION__, CURRENT_TIME, index); #endif // DEBUG sendError(rerr, false); } else { Packet::free(rerr); } } void AODV::local_rt_repair(aodv_rt_entry *rt, Packet *p) { #ifdef DEBUG fprintf(stderr,"%s: Dst - %d\n", __FUNCTION__, rt->rt_dst); #endif // Buffer the packet rqueue.enque(p); // mark the route as under repair rt->rt_flags = RTF_IN_REPAIR; sendRequest(rt->rt_dst); // set up a timer interrupt Scheduler::instance().schedule(&lrtimer, p->copy(), rt->rt_req_timeout);

void AODV::rt_update(aodv_rt_entry *rt, u_int32_t seqnum, u_int16_t metric, nsaddr_t nexthop, double expire_time) { rt->rt_seqno = seqnum; rt->rt_hops = metric; rt->rt_flags = RTF_UP; rt->rt_nexthop = nexthop; rt->rt_expire = expire_time; } void AODV::rt_down(aodv_rt_entry *rt) { /*

* Make sure that you don't "down" a route more than once. */ if(rt->rt_flags == RTF_DOWN) { return; } // assert (rt->rt_seqno%2); // is the seqno odd? rt->rt_last_hop_count = rt->rt_hops; rt->rt_hops = INFINITY2; rt->rt_flags = RTF_DOWN; rt->rt_nexthop = 0; rt->rt_expire = 0; } /* rt_down function */ /* */ void AODV::rt_resolve(Packet *p) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); aodv_rt_entry *rt; /* * Set the transmit failure callback. That * won't change. */ ch->xmit_failure_ = aodv_rt_failed_callback; ch->xmit_failure_data_ = (void*) this; rt = rtable.rt_lookup(ih->daddr()); if(rt == 0) { rt = rtable.rt_add(ih->daddr()); } /* * If the route is up, forward the packet */ if(rt->rt_flags == RTF_UP) { assert(rt->rt_hops != INFINITY2); forward(rt, p, NO_DELAY); } /* * if I am the source of the packet, then do a Route Request. */ else if(ih->saddr() == index) { rqueue.enque(p); sendRequest(rt->rt_dst); } /* * A local repair is in progress. Buffer the packet. */ else if (rt->rt_flags == RTF_IN_REPAIR) { rqueue.enque(p); Route Handling Functions

} /* * I am trying to forward a packet for someone else to which * I don't have a route. */ else { Packet *rerr = Packet::alloc(); struct hdr_aodv_error *re = HDR_AODV_ERROR(rerr); /* * For now, drop the packet and send error upstream. * Now the route errors are broadcast to upstream * neighbors - Mahesh 09/11/99 */ assert (rt->rt_flags == RTF_DOWN); re->DestCount = 0; re->unreachable_dst[re->DestCount] = rt->rt_dst; re->unreachable_dst_seqno[re->DestCount] = rt->rt_seqno; re->DestCount += 1; #ifdef DEBUG fprintf(stderr, "%s: sending RERR...\n", __FUNCTION__); #endif sendError(rerr, false); drop(p, DROP_RTR_NO_ROUTE); } } void AODV::rt_purge() { aodv_rt_entry *rt, *rtn; double now = CURRENT_TIME; double delay = 0.0; Packet *p; for(rt = rtable.head(); rt; rt = rtn) { // for each rt entry rtn = rt->rt_link.le_next; if ((rt->rt_flags == RTF_UP) && (rt->rt_expire < now)) { // if a valid route has expired, purge all packets from // send buffer and invalidate the route. assert(rt->rt_hops != INFINITY2); while((p = rqueue.deque(rt->rt_dst))) { #ifdef DEBUG fprintf(stderr, "%s: calling drop()\n", __FUNCTION__); #endif // DEBUG drop(p, DROP_RTR_NO_ROUTE); } rt->rt_seqno++; assert (rt->rt_seqno%2); rt_down(rt); } else if (rt->rt_flags == RTF_UP) { // If the route is not expired, // and there are packets in the sendbuffer waiting,

// forward them. This should not be needed, but this extra // check does no harm. assert(rt->rt_hops != INFINITY2); while((p = rqueue.deque(rt->rt_dst))) { forward (rt, p, delay); delay += ARP_DELAY; } } else if (rqueue.find(rt->rt_dst)) // If the route is down and // if there is a packet for this destination waiting in // the sendbuffer, then send out route request. sendRequest // will check whether it is time to really send out request // or not. // This may not be crucial to do it here, as each generated // packet will do a sendRequest anyway. sendRequest(rt->rt_dst); } } /* */ void AODV::recv(Packet *p, Handler*) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); assert(initialized()); //assert(p->incoming == 0); // XXXXX NOTE: use of incoming flag has been depracated; In order to track direction of pkt flow, direction_ in hdr_cmn is used instead. see packet.h for details. if(ch->ptype() == PT_AODV) { ih->ttl_ -= 1; recvAODV(p); return; } /* * Must be a packet I'm originating... */ if((ih->saddr() == index) && (ch->num_forwards() == 0)) { /* * Add the IP Header */ ch->size() += IP_HDR_LEN; // Added by Parag Dadhania && John Novatnack to handle broadcasting if ( (u_int32_t)ih->daddr() != IP_BROADCAST) ih->ttl_ = NETWORK_DIAMETER; } /* Packet Reception Routines

* I received a packet that I sent. Probably * a routing loop. */ else if(ih->saddr() == index) { drop(p, DROP_RTR_ROUTE_LOOP); return; } /* * Packet I'm forwarding... */ else { /* * Check the TTL. If it is zero, then discard. */ if(--ih->ttl_ == 0) { drop(p, DROP_RTR_TTL); return; } } // Added by Parag Dadhania && John Novatnack to handle broadcasting if ( (u_int32_t)ih->daddr() != IP_BROADCAST) rt_resolve(p); else forward((aodv_rt_entry*) 0, p, NO_DELAY); } void AODV::recvAODV(Packet *p) { struct hdr_aodv *ah = HDR_AODV(p); struct hdr_ip *ih = HDR_IP(p); assert(ih->sport() == RT_PORT); assert(ih->dport() == RT_PORT); /* * Incoming Packets. */ switch(ah->ah_type) { case AODVTYPE_RREQ: recvRequest(p); break; case AODVTYPE_RREP: recvReply(p); break; case AODVTYPE_RERR: recvError(p); break; case AODVTYPE_HELLO: recvHello(p); break; default:

fprintf(stderr, "Invalid AODV type (%x)\n", ah->ah_type); exit(1); } } void AODV::recvRequest(Packet *p) { struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p); aodv_rt_entry *rt; /* * Drop if: * - I'm the source * - I recently heard this request. */ if(rq->rq_src == index) { #ifdef DEBUG fprintf(stderr, "%s: got my own REQUEST\n", __FUNCTION__); #endif // DEBUG Packet::free(p); return; } if (id_lookup(rq->rq_src, rq->rq_bcast_id)) { #ifdef DEBUG fprintf(stderr, "%s: discarding request\n", __FUNCTION__); #endif // DEBUG Packet::free(p); return;

/* * Cache the broadcast ID */ id_insert(rq->rq_src, rq->rq_bcast_id);

/* * We are either going to forward the REQUEST or generate a * REPLY. Before we do anything, we make sure that the REVERSE * route is in the route table. */ aodv_rt_entry *rt0; // rt0 is the reverse route rt0 = rtable.rt_lookup(rq->rq_src); if(rt0 == 0) { /* if not in the route table */ // create an entry for the reverse route. rt0 = rtable.rt_add(rq->rq_src); }

rt0->rt_expire = max(rt0->rt_expire, (CURRENT_TIME + REV_ROUTE_LIFE)); if ( (rq->rq_src_seqno > rt0->rt_seqno ) || ((rq->rq_src_seqno == rt0->rt_seqno) && (rq->rq_hop_count < rt0->rt_hops)) ) { // If we have a fresher seq no. or lesser #hops for the // same seq no., update the rt entry. Else don't bother. rt_update(rt0, rq->rq_src_seqno, rq->rq_hop_count, ih->saddr(), max(rt0->rt_expire, (CURRENT_TIME + REV_ROUTE_LIFE)) ); if (rt0->rt_req_timeout > 0.0) { // Reset the soft state and // Set expiry time to CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT // This is because route is used in the forward direction, // but only sources get benefited by this change rt0->rt_req_cnt = 0; rt0->rt_req_timeout = 0.0; rt0->rt_req_last_ttl = rq->rq_hop_count; rt0->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT; } /* Find out whether any buffered packet can benefit from the * reverse route. * May need some change in the following code - Mahesh 09/11/99 */ assert (rt0->rt_flags == RTF_UP); Packet *buffered_pkt; while ((buffered_pkt = rqueue.deque(rt0->rt_dst))) { if (rt0 && (rt0->rt_flags == RTF_UP)) { assert(rt0->rt_hops != INFINITY2); forward(rt0, buffered_pkt, NO_DELAY); } } } // End for putting reverse route in rt table /* * We have taken care of the reverse route stuff. * Now see whether we can send a route reply. */ rt = rtable.rt_lookup(rq->rq_dst); // First check if I am the destination .. if(rq->rq_dst == index) { #ifdef DEBUG fprintf(stderr, "%d - %s: destination sending reply\n", index, __FUNCTION__); #endif // DEBUG // Just to be safe, I use the max. Somebody may have // incremented the dst seqno. seqno = max(seqno, rq->rq_dst_seqno)+1; if (seqno%2) seqno++;

sendReply(rq->rq_src, 1, index, seqno, MY_ROUTE_TIMEOUT, rq->rq_timestamp); } Packet::free(p);

// // // // // //

IP Destination Hop Count Dest IP Address Dest Sequence Num Lifetime timestamp

// I am not the destination, but I may have a fresh enough route. else if (rt && (rt->rt_hops != INFINITY2) && (rt->rt_seqno >= rq->rq_dst_seqno) ) { //assert (rt->rt_flags == RTF_UP); assert(rq->rq_dst == rt->rt_dst); //assert ((rt->rt_seqno%2) == 0); // is the seqno even? sendReply(rq->rq_src, rt->rt_hops + 1, rq->rq_dst, rt->rt_seqno, (u_int32_t) (rt->rt_expire - CURRENT_TIME), // rt->rt_expire - CURRENT_TIME, rq->rq_timestamp); // Insert nexthops to RREQ source and RREQ destination in the // precursor lists of destination and source respectively rt->pc_insert(rt0->rt_nexthop); // nexthop to RREQ source rt0->pc_insert(rt->rt_nexthop); // nexthop to RREQ destination #ifdef RREQ_GRAT_RREP sendReply(rq->rq_dst, rq->rq_hop_count, rq->rq_src, rq->rq_src_seqno, (u_int32_t) (rt->rt_expire - CURRENT_TIME), // rt->rt_expire - CURRENT_TIME, rq->rq_timestamp); #endif // TODO: send grat RREP to dst if G flag set in RREQ using rq->rq_src_seqno, rq->rq_hop_counT // DONE: Included gratuitous replies to be sent as per IETF aodv draft specification. As of now, G flag has not been dynamically used and is always set or reset in aodv-packet.h --- Anant Utgikar, 09/16/02. Packet::free(p); } /* * Can't reply. So forward the */ else { ih->saddr() = index; ih->daddr() = IP_BROADCAST;

Route Request

rq->rq_hop_count += 1; // Maximum sequence number seen en route if (rt) rq->rq_dst_seqno = max(rt->rt_seqno, rq->rq_dst_seqno); forward((aodv_rt_entry*) 0, p, DELAY); } } void AODV::recvReply(Packet *p) { //struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p); aodv_rt_entry *rt; char suppress_reply = 0; double delay = 0.0; #ifdef DEBUG fprintf(stderr, "%d - %s: received a REPLY\n", index, __FUNCTION__); #endif // DEBUG /* * Got a reply. So reset the "soft state" maintained for * route requests in the request table. We don't really have * have a separate request table. It is just a part of the * routing table itself. */ // Note that rp_dst is the dest of the data packets, not the // the dest of the reply, which is the src of the data packets. rt = rtable.rt_lookup(rp->rp_dst); /* * If I don't have a rt entry to this host... adding */ if(rt == 0) { rt = rtable.rt_add(rp->rp_dst); } /* * Add a forward route table entry... here I am following * Perkins-Royer AODV paper almost literally - SRD 5/99 */ if ( (rt->rt_seqno < rp->rp_dst_seqno) || // newer route ((rt->rt_seqno == rp->rp_dst_seqno) && (rt->rt_hops > rp->rp_hop_count)) ) { // shorter or better route // Update the rt entry rt_update(rt, rp->rp_dst_seqno, rp->rp_hop_count, rp->rp_src, CURRENT_TIME + rp->rp_lifetime); // reset the soft state rt->rt_req_cnt = 0; rt->rt_req_timeout = 0.0;

rt->rt_req_last_ttl = rp->rp_hop_count; if (ih->daddr() == index) { // If I am the original source // Update the route discovery latency statistics // rp->rp_timestamp is the time of request origination rt->rt_disc_latency[rt->hist_indx] = (CURRENT_TIME - rp->rp_timestamp) / (double) rp->rp_hop_count; // increment indx for next time rt->hist_indx = (rt->hist_indx + 1) % MAX_HISTORY; } /* * Send all packets queued in the sendbuffer destined for * this destination. * XXX - observe the "second" use of p. */ Packet *buf_pkt; while((buf_pkt = rqueue.deque(rt->rt_dst))) { if(rt->rt_hops != INFINITY2) { assert (rt->rt_flags == RTF_UP); // Delay them a little to help ARP. Otherwise ARP // may drop packets. -SRD 5/23/99 forward(rt, buf_pkt, delay); delay += ARP_DELAY; } }

} else { suppress_reply = 1; }

/* * If reply is for me, discard it. */ if(ih->daddr() == index || suppress_reply) { Packet::free(p); } /* * Otherwise, forward the Route Reply. */ else { // Find the rt entry aodv_rt_entry *rt0 = rtable.rt_lookup(ih->daddr()); // If the rt is up, forward if(rt0 && (rt0->rt_hops != INFINITY2)) { assert (rt0->rt_flags == RTF_UP); rp->rp_hop_count += 1; rp->rp_src = index; forward(rt0, p, NO_DELAY); // Insert the nexthop towards the RREQ source to // the precursor list of the RREQ destination rt->pc_insert(rt0->rt_nexthop); // nexthop to RREQ source } else {

// I don't know how to forward .. drop the reply. #ifdef DEBUG fprintf(stderr, "%s: dropping Route Reply\n", __FUNCTION__); #endif // DEBUG drop(p, DROP_RTR_NO_ROUTE); } } } void AODV::recvError(Packet *p) { struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_error *re = HDR_AODV_ERROR(p); aodv_rt_entry *rt; u_int8_t i; Packet *rerr = Packet::alloc(); struct hdr_aodv_error *nre = HDR_AODV_ERROR(rerr); nre->DestCount = 0; for (i=0; i<re->DestCount; i++) { // For each unreachable destination rt = rtable.rt_lookup(re->unreachable_dst[i]); if ( rt && (rt->rt_hops != INFINITY2) && (rt->rt_nexthop == ih->saddr()) && (rt->rt_seqno <= re->unreachable_dst_seqno[i]) ) { assert(rt->rt_flags == RTF_UP); assert((rt->rt_seqno%2) == 0); // is the seqno even? #ifdef DEBUG fprintf(stderr, "%s(%f): %d\t(%d\t%u\t%d)\t(%d\t%u\t%d)\n", __FUNCTION__,CURRENT_TIME, index, rt->rt_dst, rt->rt_seqno, rt->rt_nexthop, re->unreachable_dst[i],re->unreachable_dst_seqno[i], ih->saddr()); #endif // DEBUG rt->rt_seqno = re->unreachable_dst_seqno[i]; rt_down(rt); // Not sure whether this is the right thing to do Packet *pkt; while((pkt = ifqueue->filter(ih->saddr()))) { drop(pkt, DROP_RTR_MAC_CALLBACK); } // if precursor list non-empty add to RERR and delete the precursor list if (!rt->pc_empty()) { nre->unreachable_dst[nre->DestCount] = rt->rt_dst; nre->unreachable_dst_seqno[nre->DestCount] = rt->rt_seqno; nre->DestCount += 1; rt->pc_delete(); } } }

if (nre->DestCount > 0) { #ifdef DEBUG

fprintf(stderr, "%s(%f): %d\t sending RERR...\n", __FUNCTION__, CURRENT_TIME, index); #endif // DEBUG sendError(rerr); } else { Packet::free(rerr); } Packet::free(p); } /* */ Packet Transmission Routines

void AODV::forward(aodv_rt_entry *rt, Packet *p, double delay) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); //**********Get Position, Energy Sundaresh k - Elysium Technologies iNode = (MobileNode *) (Node::get_node_by_address(index)); xpos = iNode->X(); ypos = iNode->Y(); iEnergy = iNode->energy_model()->energy(); printf("at Time (%.6f), Position of %d is X: %.4f and Y: %.4f \n", CURRENT_TIME,index,xpos,ypos); printf("at Time (%.6f): Updated Energy for Node %d is Energy %.4f \n",CURRENT_TIME, index, iEnergy); if(ih->ttl_ == 0) { #ifdef DEBUG fprintf(stderr, "%s: calling drop()\n", __PRETTY_FUNCTION__); #endif // DEBUG drop(p, DROP_RTR_TTL); return;

if (ch->ptype() != PT_AODV && ch->direction() == hdr_cmn::UP && ((u_int32_t)ih->daddr() == IP_BROADCAST) || ((u_int32_t)ih->daddr() == here_.addr_)) { dmux_->recv(p,0); return; } if (rt) { assert(rt->rt_flags == RTF_UP); rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT; ch->next_hop_ = rt->rt_nexthop; ch->addr_type() = NS_AF_INET; ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction

} else { // if it is a broadcast packet // assert(ch->ptype() == PT_AODV); // maybe a diff pkt type like gaf assert(ih->daddr() == (nsaddr_t) IP_BROADCAST); ch->addr_type() = NS_AF_NONE; ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction } if (ih->daddr() == (nsaddr_t) IP_BROADCAST) { // If it is a broadcast packet assert(rt == 0); /* * Jitter the sending of broadcast packets by 10ms */ Scheduler::instance().schedule(target_, p, 0.01 * Random::uniform()); } else { // Not a broadcast packet if(delay > 0.0) { Scheduler::instance().schedule(target_, p, delay); } else { // Not a broadcast packet, no delay, send immediately Scheduler::instance().schedule(target_, p, 0.); } } } void AODV::sendRequest(nsaddr_t dst) { // Allocate a RREQ packet Packet *p = Packet::alloc(); struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p); aodv_rt_entry *rt = rtable.rt_lookup(dst); assert(rt); /* * Rate limit sending of Route Requests. We are very conservative * about sending out route requests. */ if (rt->rt_flags == RTF_UP) { assert(rt->rt_hops != INFINITY2); Packet::free((Packet *)p); return; } if (rt->rt_req_timeout > CURRENT_TIME) { Packet::free((Packet *)p); return; }

// rt_req_cnt is the no. of times we did network-wide broadcast // RREQ_RETRIES is the maximum number we will allow before // going to a long timeout. if (rt->rt_req_cnt > RREQ_RETRIES) { rt->rt_req_timeout = CURRENT_TIME + MAX_RREQ_TIMEOUT; rt->rt_req_cnt = 0; Packet *buf_pkt; while ((buf_pkt = rqueue.deque(rt->rt_dst))) { drop(buf_pkt, DROP_RTR_NO_ROUTE); } Packet::free((Packet *)p); return; } #ifdef DEBUG fprintf(stderr, "(%2d) - %2d sending Route Request, dst: %d\n", ++route_request, index, rt->rt_dst); #endif // DEBUG // Determine the TTL to be used this time. // Dynamic TTL evaluation - SRD rt->rt_req_last_ttl = max(rt->rt_req_last_ttl,rt->rt_last_hop_count); if (0 == rt->rt_req_last_ttl) { // first time query broadcast ih->ttl_ = TTL_START; } else { // Expanding ring search. if (rt->rt_req_last_ttl < TTL_THRESHOLD) ih->ttl_ = rt->rt_req_last_ttl + TTL_INCREMENT; else { // network-wide broadcast ih->ttl_ = NETWORK_DIAMETER; rt->rt_req_cnt += 1; } } // remember the TTL used for the next time rt->rt_req_last_ttl = ih->ttl_; // // // // PerHopTime is the The factor 2.0 is Also note that we done network wide roundtrip time per hop for route requests. just to be safe .. SRD 5/22/99 are making timeouts to be larger if we have broadcast before.

rt->rt_req_timeout = 2.0 * (double) ih->ttl_ * PerHopTime(rt); if (rt->rt_req_cnt > 0) rt->rt_req_timeout *= rt->rt_req_cnt; rt->rt_req_timeout += CURRENT_TIME; // Don't let the timeout to be too large, however .. SRD 6/8/99 if (rt->rt_req_timeout > CURRENT_TIME + MAX_RREQ_TIMEOUT) rt->rt_req_timeout = CURRENT_TIME + MAX_RREQ_TIMEOUT;

rt->rt_expire = 0; #ifdef DEBUG fprintf(stderr, "(%2d) - %2d sending Route Request, dst: %d, tout %f ms\n", ++route_request, index, rt->rt_dst, rt->rt_req_timeout - CURRENT_TIME); #endif // DEBUG // Fill out the RREQ packet // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rq->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->prev_hop_ = index; // AODV hack ih->saddr() ih->daddr() ih->sport() ih->dport() = = = = index; IP_BROADCAST; RT_PORT; RT_PORT;

// Fill up some more fields. rq->rq_type = AODVTYPE_RREQ; rq->rq_hop_count = 1; rq->rq_bcast_id = bid++; rq->rq_dst = dst; rq->rq_dst_seqno = (rt ? rt->rt_seqno : 0); rq->rq_src = index; seqno += 2; assert ((seqno%2) == 0); rq->rq_src_seqno = seqno; rq->rq_timestamp = CURRENT_TIME; Scheduler::instance().schedule(target_, p, 0.); } void AODV::sendReply(nsaddr_t ipdst, u_int32_t hop_count, nsaddr_t rpdst, u_int32_t rpseq, u_int32_t lifetime, double timestamp) { Packet *p = Packet::alloc(); struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p); aodv_rt_entry *rt = rtable.rt_lookup(ipdst); #ifdef DEBUG fprintf(stderr, "sending Reply from %d at %.2f\n", index, Scheduler::instance().clock()); #endif // DEBUG assert(rt); rp->rp_type = AODVTYPE_RREP; //rp->rp_flags = 0x00;

rp->rp_hop_count = hop_count; rp->rp_dst = rpdst; rp->rp_dst_seqno = rpseq; rp->rp_src = index; rp->rp_lifetime = lifetime; rp->rp_timestamp = timestamp; // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rp->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_INET; ch->next_hop_ = rt->rt_nexthop; ch->prev_hop_ = index; // AODV hack ch->direction() = hdr_cmn::DOWN; ih->saddr() = index; ih->daddr() = ipdst; ih->sport() = RT_PORT; ih->dport() = RT_PORT; ih->ttl_ = NETWORK_DIAMETER; Scheduler::instance().schedule(target_, p, 0.); } void AODV::sendError(Packet *p, bool jitter) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_error *re = HDR_AODV_ERROR(p); #ifdef ERROR fprintf(stderr, "sending Error from %d at %.2f\n", index, Scheduler::instance().clock()); #endif // DEBUG re->re_type = AODVTYPE_RERR; //re->reserved[0] = 0x00; re->reserved[1] = 0x00; // DestCount and list of unreachable destinations are already filled // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + re->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->next_hop_ = 0; ch->prev_hop_ = index; // AODV hack ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction ih->saddr() ih->daddr() ih->sport() ih->dport() = = = = index; IP_BROADCAST; RT_PORT; RT_PORT;

ih->ttl_ = 1; // Do we need any jitter? Yes if (jitter) Scheduler::instance().schedule(target_, p, 0.01*Random::uniform()); else Scheduler::instance().schedule(target_, p, 0.0); } /* */ Neighbor Management Functions

void AODV::sendHello() { Packet *p = Packet::alloc(); struct hdr_cmn *ch = HDR_CMN(p); struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_reply *rh = HDR_AODV_REPLY(p); #ifdef DEBUG fprintf(stderr, "sending Hello from %d at %.2f\n", index, Scheduler::instance().clock()); #endif // DEBUG rh->rp_type = AODVTYPE_HELLO; //rh->rp_flags = 0x00; rh->rp_hop_count = 1; rh->rp_dst = index; rh->rp_dst_seqno = seqno; rh->rp_lifetime = (1 + ALLOWED_HELLO_LOSS) * HELLO_INTERVAL; // ch->uid() = 0; ch->ptype() = PT_AODV; ch->size() = IP_HDR_LEN + rh->size(); ch->iface() = -2; ch->error() = 0; ch->addr_type() = NS_AF_NONE; ch->prev_hop_ = index; // AODV hack ih->saddr() = ih->daddr() = ih->sport() = ih->dport() = ih->ttl_ = 1; } index; IP_BROADCAST; RT_PORT; RT_PORT;

Scheduler::instance().schedule(target_, p, 0.0);

void AODV::recvHello(Packet *p) { //struct hdr_ip *ih = HDR_IP(p); struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p); AODV_Neighbor *nb;

nb = nb_lookup(rp->rp_dst); if(nb == 0) { nb_insert(rp->rp_dst); } else { nb->nb_expire = CURRENT_TIME + (1.5 * ALLOWED_HELLO_LOSS * HELLO_INTERVAL); } } Packet::free(p);

void AODV::nb_insert(nsaddr_t id) { AODV_Neighbor *nb = new AODV_Neighbor(id); assert(nb); nb->nb_expire = CURRENT_TIME + (1.5 * ALLOWED_HELLO_LOSS * HELLO_INTERVAL); LIST_INSERT_HEAD(&nbhead, nb, nb_link); seqno += 2; // set of neighbors changed assert ((seqno%2) == 0);

AODV_Neighbor* AODV::nb_lookup(nsaddr_t id) { AODV_Neighbor *nb = nbhead.lh_first; for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) break; } return nb; } /* * Called when we receive *explicit* notification that a Neighbor * is no longer reachable. */ void AODV::nb_delete(nsaddr_t id) { AODV_Neighbor *nb = nbhead.lh_first; log_link_del(id); seqno += 2; // Set of neighbors changed assert ((seqno%2) == 0); for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) { LIST_REMOVE(nb,nb_link); delete nb; break; } }

handle_link_failure(id); } /* * Purges all timed-out Neighbor Entries - runs every * HELLO_INTERVAL * 1.5 seconds. */ void AODV::nb_purge() { AODV_Neighbor *nb = nbhead.lh_first; AODV_Neighbor *nbn; double now = CURRENT_TIME; for(; nb; nb = nbn) { nbn = nb->nb_link.le_next; if(nb->nb_expire <= now) { nb_delete(nb->nb_addr); } } }

AODV Communication

#include <assert.h> #include <cmu-trace.h> #include <aodv/aodv_rqueue.h> #define CURRENT_TIME #define QDEBUG /* */ Packet Queue used by AODV. Scheduler::instance().clock()

aodv_rqueue::aodv_rqueue() { head_ = tail_ = 0; len_ = 0; limit_ = AODV_RTQ_MAX_LEN; timeout_ = AODV_RTQ_TIMEOUT; } void aodv_rqueue::enque(Packet *p) { struct hdr_cmn *ch = HDR_CMN(p); /* * Purge any packets that have timed out. */ purge(); p->next_ = 0; ch->ts_ = CURRENT_TIME + timeout_; if (len_ == limit_) { Packet *p0 = remove_head(); // decrements len_

assert(p0); if(HDR_CMN(p0)->ts_ > CURRENT_TIME) { drop(p0, DROP_RTR_QFULL); } else { drop(p0, DROP_RTR_QTIMEOUT); } } if(head_ == 0) { head_ = tail_ = p; } else { tail_->next_ = p; tail_ = p; } len_++; #ifdef QDEBUG verifyQueue(); #endif // QDEBUG }

Packet* aodv_rqueue::deque() { Packet *p; /* * Purge any packets that have timed out. */ purge(); p = remove_head(); #ifdef QDEBUG verifyQueue(); #endif // QDEBUG return p; } Packet* aodv_rqueue::deque(nsaddr_t dst) { Packet *p, *prev; /* * Purge any packets that have timed out. */ purge(); findPacketWithDst(dst, p, prev); assert(p == 0 || (p == head_ && prev == 0) || (prev->next_ == p)); if(p == 0) return 0; if (p == head_) { p = remove_head(); } else if (p == tail_) { prev->next_ = 0; tail_ = prev; len_--; } else { prev->next_ = p->next_; len_--; } #ifdef QDEBUG verifyQueue(); #endif // QDEBUG return p; } char aodv_rqueue::find(nsaddr_t dst) { Packet *p, *prev;

findPacketWithDst(dst, p, prev); if (0 == p) return 0; else return 1; } /* */ Private Routines

Packet* aodv_rqueue::remove_head() { Packet *p = head_; if(head_ == tail_) { head_ = tail_ = 0; } else { head_ = head_->next_; } if(p) len_--; return p; } void aodv_rqueue::findPacketWithDst(nsaddr_t dst, Packet*& p, Packet*& prev) { p = prev = 0; for(p = head_; p; p = p->next_) { // if(HDR_IP(p)->dst() == dst) { if(HDR_IP(p)->daddr() == dst) { return; } prev = p; }

void aodv_rqueue::verifyQueue() { Packet *p, *prev = 0; int cnt = 0; for(p = head_; p; p = p->next_) { cnt++; prev = p; } assert(cnt == len_); assert(prev == tail_); }

/* void aodv_rqueue::purge() { Packet *p; while((p = head_) && HDR_CMN(p)->ts_ < CURRENT_TIME) { // assert(p == remove_head()); p = remove_head(); drop(p, DROP_RTR_QTIMEOUT); } } */ bool aodv_rqueue::findAgedPacket(Packet*& p, Packet*& prev) { p = prev = 0; for(p = head_; p; p = p->next_) { if(HDR_CMN(p)->ts_ < CURRENT_TIME) { return true; } prev = p; } return false;

void aodv_rqueue::purge() { Packet *p, *prev; while ( findAgedPacket(p, prev) ) { assert(p == 0 || (p == head_ && prev == 0) || (prev->next_ == p)); if(p == 0) return; if (p == head_) { p = remove_head(); } else if (p == tail_) { prev->next_ = 0; tail_ = prev; len_--; } else { prev->next_ = p->next_; len_--; } #ifdef QDEBUG verifyQueue(); #endif // QDEBUG } } p = prev = 0;

AODV Routing Table Formation

#include <aodv/aodv_rtable.h> //#include <cmu/aodv/aodv.h> /* */ The Routing Table

aodv_rt_entry::aodv_rt_entry() { int i; rt_req_timeout = 0.0; rt_req_cnt = 0; rt_dst = 0; rt_seqno = 0; rt_hops = rt_last_hop_count = INFINITY2; rt_nexthop = 0; LIST_INIT(&rt_pclist); rt_expire = 0.0; rt_flags = RTF_DOWN; /* rt_errors = 0; rt_error_time = 0.0; */ for (i=0; i < MAX_HISTORY; i++) { rt_disc_latency[i] = 0.0; } hist_indx = 0; rt_req_last_ttl = 0; LIST_INIT(&rt_nblist); }; aodv_rt_entry::~aodv_rt_entry() { AODV_Neighbor *nb; while((nb = rt_nblist.lh_first)) { LIST_REMOVE(nb, nb_link); delete nb; } AODV_Precursor *pc; while((pc = rt_pclist.lh_first)) { LIST_REMOVE(pc, pc_link); delete pc; }

} void aodv_rt_entry::nb_insert(nsaddr_t id) { AODV_Neighbor *nb = new AODV_Neighbor(id); assert(nb); nb->nb_expire = 0; LIST_INSERT_HEAD(&rt_nblist, nb, nb_link); } AODV_Neighbor* aodv_rt_entry::nb_lookup(nsaddr_t id) { AODV_Neighbor *nb = rt_nblist.lh_first; for(; nb; nb = nb->nb_link.le_next) { if(nb->nb_addr == id) break; } return nb; } void aodv_rt_entry::pc_insert(nsaddr_t id) { if (pc_lookup(id) == NULL) { AODV_Precursor *pc = new AODV_Precursor(id); assert(pc); LIST_INSERT_HEAD(&rt_pclist, pc, pc_link);

} }

AODV_Precursor* aodv_rt_entry::pc_lookup(nsaddr_t id) { AODV_Precursor *pc = rt_pclist.lh_first; for(; pc; pc = pc->pc_link.le_next) { if(pc->pc_addr == id) return pc; } return NULL; } void aodv_rt_entry::pc_delete(nsaddr_t id) { AODV_Precursor *pc = rt_pclist.lh_first;

for(; pc; pc = pc->pc_link.le_next) { if(pc->pc_addr == id) { LIST_REMOVE(pc,pc_link); delete pc; break; } } } void aodv_rt_entry::pc_delete(void) { AODV_Precursor *pc; while((pc = rt_pclist.lh_first)) { LIST_REMOVE(pc, pc_link); delete pc; }

bool aodv_rt_entry::pc_empty(void) { AODV_Precursor *pc; if ((pc = rt_pclist.lh_first)) return false; else return true;

/* */ The Routing Table

aodv_rt_entry* aodv_rtable::rt_lookup(nsaddr_t id) { aodv_rt_entry *rt = rthead.lh_first; for(; rt; rt = rt->rt_link.le_next) { if(rt->rt_dst == id) break; } return rt; } void aodv_rtable::rt_delete(nsaddr_t id) { aodv_rt_entry *rt = rt_lookup(id); if(rt) { LIST_REMOVE(rt, rt_link); delete rt; } }

aodv_rt_entry* aodv_rtable::rt_add(nsaddr_t id) { aodv_rt_entry *rt; assert(rt_lookup(id) == 0); rt = new aodv_rt_entry; assert(rt); rt->rt_dst = id; LIST_INSERT_HEAD(&rthead, rt, rt_link); return rt; }

TCL Script
set set set set set set set set set set set opt(chan) opt(prop) opt(netif) opt(mac) opt(ifq) opt(ll) opt(ant) opt(x) opt(y) opt(cp) opt(sc) Channel/WirelessChannel Propagation/TwoRayGround Phy/WirelessPhy Mac/802_11 Queue/DropTail/PriQueue Antenna/OmniAntenna 1500 ;# X dimension of the topography 300 ;# Y dimension of the topography "cbr/cbr_rate21" "scen/scen-1500x300-50-0-20-1" ;# MAC type

LL

set opt(ifqlen) 50 ;# max packet in ifq set opt(nn) 100 ;# number of nodes set opt(seed) 0.0 set opt(stop) 300.0 ;# simulation time set opt(tr) out.tr ;# trace file set opt(nam) out.nam ;# animation file set opt(rp) AODV ;# routing protocol script #set opt(lm) "off" ;# log movement set opt(agent) AODV set opt(energymodel) EnergyModel ; #set opt(energymodel) RadioModel ; set opt(radiomodel) RadioModel ; set opt(initialenergy) 100 ;# Initial energy in Joules #set opt(logenergy) "on" ;# log energy every 150 seconds

#set opt(lm) #set opt(imep) #set opt(debug) #set opt(errmodel) #set opt(em) #set opt(ps) #set opt(pi) set opt(usepsm)

"off" "OFF" "OFF" "" "" 128 0.33 1

;# log movement

;# for errmodel ;# set to name of errmodel file ;# cbr data pkt size ;# cbr data interval ;# use power saving mode

set opt(usespan) set opt(spanopt) #set opt(slaver)

1 1 ""

;# use span election ;# use psm optimization ;# remote drive an ad-hockey at this ip addr

# ====================================================================== set AgentTrace set RouterTrace set MacTrace LL set delay_ LL set mindelay_ LL set maxdelay_ #LL set bandwidth_ #LL set off_prune_ #LL set off_CtrMcast_ #source rp Agent/CBR set sport_ Agent/CBR set dport_ 25us 50us 0 0 0 0 0 0 0 0 0 1460 ;# not used ;# not used ;# not used ON ON 0

ON

#Agent/TCPSink set sport_ #Agent/TCPSink set dport_ #Agent/TCP set sport_ #Agent/TCP set dport_ #Agent/TCP set packetSize_

#if [TclObject is-class Scheduler/RealTime] { # Scheduler/RealTime set maxslop_ 10 #} # unity gain, omni-directional antennas # set up the antennas to be centered in the node and 1.5 meters above it Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 1.5 Antenna/OmniAntenna set Gt_ 1.0 Antenna/OmniAntenna set Gr_ 1.0 # Initialize the SharedMedia interface with parameters to make # it work like the 914MHz Lucent WaveLAN DSSS radio interface Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 1.559e-11 Phy/WirelessPhy set RXThresh_ 3.652e-10 Phy/WirelessPhy set Rb_ 2.0e6 Phy/WirelessPhy set Pt_ 0.2818 Phy/WirelessPhy set freq_ 914e+6 Phy/WirelessPhy set L_ 1.0 #source mac # the above parameters result in a nominal range of 250m set nominal_range 250.0 set configured_range -1.0

set configured_raw_bitrate -1.0 # ======================================================================

set ns_ [new Simulator] set topo [new Topography] set tracefd [open $opt(tr) w] set namtrace [open $opt(nam) w] set prop [new $opt(prop)] #$ns_ use-newtrace $topo load_flatgrid $opt(x) $opt(y) #ns-random 1.0 $ns_ trace-all $tracefd $ns_ namtrace-all-wireless $namtrace 1500 300 # # Create god # set god_ [create-god $opt(nn)] #global node setting $ns_ node-config -adhocRouting $opt(agent) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channelType $opt(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -energyModel $opt(energymodel) \ -idlePower 1.0 \ -rxPower 1.0 \ -txPower 1.0 \ -sleepPower 0.001 \ -transitionPower 0.2 \ -transitionTime 0.005 \ -initialEnergy $opt(initialenergy)

$ns_ set WirelessNewTrace_ ON set AgentTrace ON set RouterTrace ON set MacTrace ON for {set i 0} {$i < $opt(nn) } {incr i} { set node_($i) [$ns_ node] $ns_ initial_node_pos $node_($i) 30;

$node_($i) random-motion 0 } source $opt(sc) # # # # # # $ns_ $ns_ $ns_ $ns_ $node_(1) $node_(1) $node_(1) $node_(0) $node_(0) $node_(0) at at at at 0.0000 0.0000 0.0000 0.0000 set set set set set set agentTrace ON macTrace ON routerTrace ON macTrace ON agentTrace ON routerTrace ON

;# disable random motion

"$node_(1) "$node_(2) "$node_(1) "$node_(2)

add-mark m2 red circle" add-mark m2 red circle" label \"Sender\"" label \"Receiver\""

set udp_(0) [new Agent/TCP] $ns_ attach-agent $node_(1) $udp_(0) set null_(0) [new Agent/TCPSink] $ns_ attach-agent $node_(2) $null_(0) set cbr_(0) [new Application/FTP] $cbr_(0) set packetSize_ 512 $cbr_(0) set interval_ 5.0 $cbr_(0) set random_ 1 $cbr_(0) set maxpkts_ 10000 $cbr_(0) attach-agent $udp_(0) $ns_ connect $udp_(0) $null_(0) $ns_ at 2.5568388786897245 "$cbr_(0) start" #$ns_ at 177.000 "$node_(0) set ifqLen" # # Tell all the nodes when the simulation ends # for {set i 0} {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop) "$node_($i) reset"; } $ns_ at $opt(stop) "puts \"NS EXITING...\" ; $ns_ halt" puts "Starting Simulation..." $ns_ run