HAODV: a New Routing Protocol to Support Interoperability in Heterogeneous MANET Haidar Safa1, Hassan Artail2, Marcel Karam1, Hala Ollaic1, and Rasha Abdallah1 1

2

Department of Computer Science Department of Electrical and Computer Engineering American University of Beirut, Beirut, Lebanon {hs33, hartail, mk62, hao04, rma47}@aub.edu.lb protocol data units, etc. These features of MANET may result in network partitioning, and inconsistency in routing tables, and can make the portability of MANET’s applications exposed to many serious problems such as data loss and insufficient reliability. Coexistence and interoperability between heterogeneous mobile devices is a challenging issue. Current MANET routing protocols ignore paths between or through heterogeneous devices equipped with different communication interfaces and become obsolete when a single MANET contains a set of heterogeneous devices as shown in Figure 1. In this figure, routing protocols such as AODV and DSDV fail to identify the paths between the WIFI enabled node called SRC and the Bluetooth enabled node called DST1 since these protocols do not support interoperability. In addition, to reach node DST2 from node SRC, these routing protocols will select the route path1 in which all the nodes are WIFI enabled. However, if interoperability is supported, a shorter route (i.e. path2) could be considered.

Abstract In today’s MANET, nodes can be equipped with one or more wireless communications interfaces that support different wireless technologies such as WIFI IEEE 802.11 and Bluetooth. Each technology implements distinct hardware and logical specifications. Current AODV routing protocol becomes inefficient when used in a network formed of heterogeneous devices. Indeed AODV in its nature search the paths between homogeneous devices and ignore the ones between heterogeneous devices. In this paper, we propose a heterogeneous AODV protocol that interoperates between WIFI and Bluetooth technologies in a single MANET. The extended algorithm takes into consideration several factors when building the routes such as network stability, traffic, conversion rate; in addition to the shortest path.

1. Introduction Mobile ad-hoc networks (MANETs) have been a topic of great interest in the last years especially with the emergence of mobile devices. They are known by their dynamic topology where nodes are free to join and leave the network, or move at anytime. In such network environment, each node, in addition to being a host, it can play the role of a router forwarding messages to other. Routing algorithms in MANET must be able to adapt to dynamic network topology and should not only select but also maintain a stable, reliable, and short path that connects the source node to its destination. DSDV [13] and AODV [14] routing protocols proved efficiency in discovering the shortest path from a source to its destination in a MANET. However, these routing protocols make the assumption that the ad hoc network is homogeneous; that is all the mobile nodes have the same capabilities in terms of processing capacity, transmission range, and number networking interfaces. Today’s MANET nodes can be equipped with one or more wireless communications cards that support different wireless technologies such as WIFI IEEE 802.11 [11] and Bluetooth [2, 3]. Each technology implements distinct hardware and logical specifications, radio frequencies,

1-4244-1031-2/07/$25.00©2007 IEEE

Figure 1. An example of a heterogeneous MANET In this paper, we propose a Heterogeneous AODV (HAODV) routing protocol to support and optimize routing in heterogeneous networks. The rest of this paper is organized as follows. In the remaining of this section a brief overview of AODV is given. In Section 2 we survey some related work. In Section 3 we present our proposed Heterogeneous AODV protocol. Section 4 compares the proposed Heterogeneous AODV to AODV and to another protocol called HBRD [6] that supports routing in heterogeneous networks. Finally conclusion and future work are drawn in section 5.

893

nodes. From a Hello message, the mobile node receives information about its immediate neighbors and 2-hop neighbors, and selects MPRs accordingly (for details of the MPR selection mechanism, please refer to [8]). A TC message originates at an MPR node announcing who has selected it as an MPR. Such messages are relayed by other MPRs throughout the entire network, enabling the remote nodes to discover the links between an MPR and its selectors. Based on such information, the routing table is calculated using the shortest-path algorithm [9]. In OLSR, a "flat" mechanism is employed, whereby a node sends Hello and TC messages through all its interfaces without regard to the link capacities of the other nodes. This results in a large amount of control messages being propagated through the network. To reduce this overhead and make the routing algorithm more scalable, Hierarchical OLSR (HOLSR) was proposed in [16]. In HOLSR, the nodes are organized into multiple logical topology levels. Nodes that are equipped with only one interface, offering limited data rate and transmission range participate at topology Level 1. Nodes at the topology Level 2 are equipped with two interfaces, one of which is a wireless interface capable of communicating with Level 1 nodes. Topology Level 3 nodes are equipped with three wireless interfaces capable of communicating in turn with Level 1 and Level 2 nodes and with other Level 3 nodes. At each logical topology level, nodes form clusters, and exchange network topology information independently. A cluster head acts as a gateway through which messages from cluster members are relayed to other parts of the network. Unlike the original (flat) OLSR, which transmits the same topology control information from all interfaces, in HOLSR each interface sends out topology information relating only to its own level reducing the amount of topology control information messages that must be exchanged at different levels of the hierarchical network topology. However in HOLSR each cluster head needs to be aware of the membership information of its peer cluster heads, therefore a new hierarchical message is introduced to transmit the membership information of a cluster to the higher hierarchical level nodes. In topological terms, the higher a given node is located, the more information it obtains about the network. Generally speaking, nodes at the highest topology level possess full knowledge of all the nodes in the network; consequently, the sizes of their routing tables are as large as they would be under OLSR. On the other hand, because the topology information required by lower-level nodes is limited in scope, the sizes of their routing tables are consequently reduced from those of the original (flat) OLSR. We observe that HOLSR limits the propagation of the topology information but incurs more overhead since hierarchical messages are periodically propagated between the cluster heads to keep them aware of the

1.1. Ad-Hoc on Demand Distance Vector (AODV) AODV routing protocol is a reactive routing protocol where a node builds the optimal path to a certain destination only when required [14]. An AODV node discovers its neighbors by periodically broadcasting Hello messages. Such messages will have a TTL value of 1 to insure that the message propagates to immediate neighbors only. By exchanging Hello messages, neighboring nodes update their routing tables with information about their neighbors. This information will be used later on, during the path discovery phase. Path discovery is initiated whenever a node needs to communicate with another node that it has no up-to-date routing information about it in its routing table. It is done through reverse and forward path setup. AODV consists of broadcasting routing request (RREQ) messages to neighbors querying them for recent routing information about the destination. A RREQ packet maintains information about the source and destination address, a broadcast id, the hop count, in addition to the source and destination sequence numbers which keep track of the ‘freshness’ of the RREQ message. The RREQ message is flooded across the network until it reaches the destination node or some intermediate node that holds up-to-date route information about the destination. At this moment, a routing reply (RREP) message will be sent through the intermediate nodes using the reverse path that has been previously built towards the source node. The RREP packet contains information about the source and destination address, the destination sequence number, hop count, and the lifetime of the packet. If an intermediate node receives further RREPs, it will propagate them only if they contain some greater destination sequence number or the same destination sequence number with a smaller hop count. By always selecting the RREP having the smallest hop count, AODV succeeds in building the shortest path from the source to the destination.

2. Related Work Several papers in the literature have tackled the problem of interoperability and routing in a heterogeneous MANET [5, 6, 8, 12, 15, 16, 17]. In [8], an Optimized Link State Routing protocol (OLSR) was proposed to support routing in a heterogeneous MANET where nodes have multiple interfaces. OLSR optimizes the pure link state protocol by propagating the topology information via selected nodes called multipoint relays (MPRs). Two types of control messages are used for topology information: the Hello message and Topology Control (TC) message. A node sends a Hello message to identify itself and to report a list of neighboring mobile

894

membership information of their peers. We also observe that HOLSR improves the scalability of the network but it impacts the network reliability. Indeed, in HOLSR if two nodes belong to different clusters want to communicate, the data will normally travel up to a higher topological level in which the destination node is located then will travel down to the destination. The reliability issue is raised when the cluster head at a higher topological level fails to locate the destination. This is can happen when nodes in a higher level are not connected directly or indirectly. Consequently, HOLSR may impact the node reachability and the network reliability even when the source and the destination are not heterogeneous. In [5], a scheme that supports interoperability between heterogeneous interfaces in MANETS was proposed. This scheme uses a unique IP address as a node identifier, a unique interface index for each node interface, and the Dynamic Source Routing protocol (DSR) [4] to support interoperability. In DSR, the sending node first discovers the complete route to reach the destination. The path is an ordered sequence of network hops (i.e., node identifiers) between the source and the destination. Then each packet sent carries this path in its header. The scheme proposed in [5] consists of defining the path using not only the node identifier but also the interface(s) that shall be used at each node. This will increase the size of each packet’s header. In [6], AODV was also extended to support heterogeneous networks in a way that is biased to the most capable nodes. A Heterogeneous Biased Route Discovery (HBDR) was introduced as a method to avoid choosing resource-limited nodes along the built path. HBDR makes use of the delay value which is based on the heterogeneous properties of the node to favor choosing it. In other words, HBDR worked on categorizing the nodes in a network as powerful nodes, limited nodes, and weak nodes to force the route discovery towards the most powerful nodes. However, the underlying scheme for supporting heterogeneity in MANETs does not mention communication interfaces heterogeneity or shows how this heterogeneity is solved. In [17], the notion of clustering and the notion of a stable networking were combined to produce a heterogeneous routing protocol that uses both AODV and DSDV. Indeed, in this protocol mobile nodes are grouped in many clusters where each cluster represents a local subnet. The cluster head nodes form what is called network backbone. Then AODV is used in the network backbone and DSDV is used inside local subnets. This protocol increases the scalability of the network by selecting nodes with higher transmission range and data rate to form the backbone networks. However, it fails to address the heterogeneity that may exist between communication interfaces. Another clustering based interoperability model was also proposed in [12]. In

general, clustering schemes suffer from the problem of adding lots of overhead to the cluster heads since they will be responsible for forwarding the packets and managing the nodes throughout the network. AODV determines the optimal path based on hop counts. However, in MANET, other factors such as stability of the node, and network traffic might be of equal, if not higher, importance. In [18] AODV was enhanced to support route selection based on a variety of factors such as route stability and traffic rather than just hop counts. However, this enhancement did not address the issue of interoperability between heterogeneous communication interfaces.

3. Proposed Heterogeneous AODV (HAODV) The selected routes in the Enhanced AODV [18] are composed of homogeneous hops, in terms of network interfaces, and the algorithm did not consider heterogeneous environment where different technologies are employed. In this paper we use our interoperability model proposed in [15] and the Enhanced AODV to propose a Heterogeneous AODV routing protocol (HAODV). The proposed protocol selects the shortest stable routes which may be composed of nodes equipped with heterogeneous communication interfaces. For example, consider the network topology shown in Figure 1 in which nodes are enabled with different technologies: Bluetooth, WIFI, or both. In a typical AODV implementation, the optimal route from node SRC to node DEST2 will be route path1. Although a shorter route might exist through path path2, but AODV, which does not support interoperability, will not consider this shorter path since it will only follow the nodes with a WIFI interface. The proposed HAODV will evaluate all the possible routes and select the optimal one. The proposed HAODV allows having heterogeneous nodes in a route regardless of the nodes’ underlying technology. It assumes that the nodes are enabled with an interoperability model that is responsible for handling the packet conversion from one technology to another. Readers can refer to [15] for more details. HAODV uses a method called Convert to delegate the conversion procedure to the interoperability model. Figure 2 shows the pseudo code for this algorithm. As the figure shows, the capability layer in [15] is able to fetch the capabilities of each node and returns the type of the capability (e.g., W, B, or W/B). This algorithm also states that when we have a W/B node followed by a W/B neighbor, they will communicate using their WIFI interfaces since WIFI is assumed to be more stable and robust than Bluetooth. Other than this conversion, AODV routing messages (RREQ, RREP, etc) will remain the same.

895

lower layers to replace the headers and forward the packet. The three fields DC_route, LB_route, and Conv_route are added to the Route Table Cache of each node. The route table entry is used to record the route that found. When RREQ is initiated, DC_route, LB_route, and Conv_route are set to zero before being updated later on. Indeed, when a node receives a RREQ, it first checks if it has received a RREQ with same Originator IP address and RREQ id. If it is, the node silently discards the newly received RREQ. Otherwise, if the node is not the destination of this route request or it does not have an entry about the valid route in its route table cache, it will add its own address and update the DC_route, LB_Route, and Conv_Route of this RREQ using equations (3), (4), and (5) given below then broadcast the RREQ to its neighbors. DC_route = DC_route + DC (3)

Figure 2. Conversion pseudo-code As mentioned earlier, AODV was enhanced in [18] to support path selection based on a variety of factors such as path stability and traffic rather than just hop counts. The enhanced protocol assumes that each node maintains two parameters in its memory: Delivery Counter (DC) parameter and Load Balance (LB) parameter. The delivery counter is used to measure the node’s stability during the route establishment and is calculated as follow: (1) DC = 0.1 × DC +PacketCoun ter

LB_route = LB_route + LB

(4)

Conv_ route= Conv_ route+ C

(5)

where the conversion cost, C, is set to zero if the node is not ‘W/B’ If the node has an entry about the valid route record to the same destination node in its route table cache, it will generate the RREP message for the source node. The DC_route, LB_Route, and Conv_Route will be updated as follows: DC_route = DC_route + DC_route_entry (6)

where PacketCounter is the number of packets successfully delivered to neighboring nodes. The Load Balance parameter is used to measure the load on the node and is calculated as follow: Packets _ number _ in _ waiting _ list (2) LB = 1 − Amount _ of _ Buffer

LB_route = LB_route + LB_route_entry

(7)

Conv_ route= Conv_ route + Conv_route_entry

(8)

where the conversion cost, C, is set to zero if the node is not ‘W/B’. If the node is just the destination of the RREQ, it will generate the RREP message too, and DC_route, LB_Route, and Conv_route of RREP are just copied form the RREQ. When the node receives more than one RREP messages to the same destination node with the same sequence number, it will calculate the Union Selection parameter W, given in equation (9), of these routes. The route that has the smaller W value will be recorded in the route table cache and prepared for data transmission. The Union Selection Parameter is calculated as follow: 1 (9) W = a × N + (−a × DC _ route + a × LB _ route) + a × Conv _ route

In [18], two new fields, DC_route and LB_route are added to AODV routing messages: RREQ and RREP. DC_route is computed as being the sum of the delivery counters of the nodes in the path from the source to the destination. Similarly, LB_route is the sum of the Load Balances of these nodes. In our proposed HAODV protocol another field, Conversion route (Conv_route), is added to AODV routing messages. Conv_route is the sum of the accumulated conversion cost, C, of the nodes in the path from the source to the destination. Conversion cost may occur only at nodes enabled with two heterogeneous interfaces (i.e. ‘W/B’ nodes). Conv_route increases each time a conversion from one technology to another occurs. It is important to take into consideration this cost, because switching between the two technologies requires reformatting the packets. This process involves a trip to

1

N

2

3

4

where a1, a2, a3 and a4 are the weights assigned to hop count N, DC_route, LB_route, conv_route respectively. These weights are preset by the network administrator depending on the business needs of the network. We do not divide a4*Conv_route by the number of hops, because if we do so, then any time conversion cost C = 0, the Conv_route will remain the same but it will be divided by

896

a larger number and hence W will decrease while it should remain at the same value. When the node creates a reverse route to the Originator IP Address in its routing table cache with the RREQ message, it checks if a route to the Originator IP Address already exists. If it is, then it is updated only if either the Originator Sequence Number in the RREQ is higher than the destination sequence number of the Originator IP Address in the route table, or the sequence numbers are equal, but the Union Selection Parameter W as calculated by DC_route, LB_route, and conv_route in the RREQ, is now smaller than the existing one in the routing table. Note that, an optimal path in one scenario might not be optimal in the other. It all depends on the assigned weights to each of the four factors. These weights could be saved in a configuration file accessible by the AODV routing protocol.

Table 1. n1-n2-n5-n6-n7-n8-n9-n10 Path N (Hop-count) n1-n2 1 n2-n5 2 n5-n6 3 n6-n7 4 n7-n8 5 n8-n9 6 n9-n10 7 Table 2. n1-n2-n5-n6- n7-n4-n10 Path N (Hop-count) n1-n2 1 n2-n5 2 n5-n6 3 n6-n7 4 n7-n4 5 n4-n10 6

4. Performance Analysis

4.2. Scenario with proposed HAODV

4.1. Scenario with AODV

Consider a scenario where we give the highest priority to minimizing hop count (a1 = 40%). Next in priorities comes minimizing conversion cost (a4 = 30%). Let us assume that the network is reasonably available and stable; hence LB_route and DC_route are assigned the same low weight (a2 = a3 = 15%). Note that the weights can be modified by the network administrator as need arise. And finally, we make the following assumptions about nodes of Figure 3: - The stability of node ‘W’ or node ‘W/B’ is likely to be higher than that of node ‘B’ since Bluetooth enabled machines are generally very mobile PDAs while WiFi enabled machines are laptops, less likely to move in the short amount of time. Hence we assign DC(W or W/B) = 2 and DC(B) = 1 - The traffic load on ‘W/B’ nodes is higher than the load on ‘W’ or ‘B’ only nodes since a ‘W/B’ node would be receiving requests from both ‘B’ and ‘W’ nodes. For this example, we assign LB (W/B) = 0.5 and LB(W or B) = 0.9 (Load Balance represents network availability) - Let C be equal to 1. The value is chosen in accordance with the previous values. The ongoing W calculation along the three paths will be illustrated respectively in Tables 3, 4, and 5. Note that the conversion cost is only considered when a ‘W/B’ node receives a packet from a ‘B’ node and has to forward it to a ‘W’ node, or when a ‘W/B’ node receives a packet from a ‘W’ node and forwards it to a ‘B’ node. Suppose that the RREQ from n9 arrives first to n10 as shown in Table 3. Since this is the first request to be received from n1, n10 will send back a RREP through n9 regardless of W. The RREP message will be propagated back though the reverse path n10-n9-n8-n7-n6-n5-n2-n1.

Consider a scenario where we have the network topology shown in Figure 3. The original AODV algorithm will send the RREQ messages through two possible paths where at each node the hop count is being incremented since it is the only parameter taken into consideration. Tables 1 and 2 show how the hop-count will be updated throughout the propagated RREQ messages.

Figure 3. Topology of a heterogeneous MANET As the RREQ messages propagate to the destination node n10, the latter will reply through the path with the least hop count which is in this case n1-n2-n5-n6-n7-n4n10. Hence, it will unicast a RREP message to node n4 which will send this RREP message throughout the reverse path until it reaches n1 and then the route between n1 and n10 is correctly built, and data messages will follow this path as long as it is valid.

897

Once RREP reaches n1, n1 will update its routing table accordingly, and will begin sending packets to n10 through this path.

reverse path (n4, n3, n2, and n1) will update its routing information to reflect the choice of the optimal path. Once the RREP propagates to n1, n1 will become ready to start communicating with n10 via the optimal path.

Table 3. W calculation through n1-n2-n5-n6-n7-n8-n9n10 Path n1-n2 n2-n5 n5-n6 n6-n7 n7-n8 n8-n9 n9n10

LB_route 1.4 1.9 2.4 3.3 4.2 5.1

DC_route 4 6 8 10 12 14

N 2 3 4 5 6 7

Conv_route 0 0 0 0 0 0

W 0.60 0.99 1.39 1.79 2.20 2.60

6

16

8

0

3.01

4.3. Delay, Heterogeneity

LB_route

DC_route

N

Conv_route

W

n1-n2 n2-n5 n5-n6 n6-n7 n7-n4

1.4 1.9 2.4 3.3 3.8

4 6 8 10 12

2 3 4 5 6

0 0 0 0 0

0.60 0.99 1.39 1.79 2.19

n4-n10

4.7

14

7

0

2.60

Table 5. W calculation through n1-n2-n3-n4-n10 Path

LB_route

DC_route

N

Conv_route

W

n1-n2 n2-n3 n3-n4

1.4 2.3 2.8

4 5 7

2 3 4

0 1 2

0.60 1.36 2.04

n4-n10

3.7

9

5

2

2.44

Reacheability,

and

We have developed a simulator in Java in order to compare the performance of the proposed HAODV versus the traditional AODV and HBDR. The comparison goal was to measure the delay and node reachability when the number of nodes and the heterogeneity of the network increase. Delay was chosen as an indicator of the algorithm’s effectiveness because it can reflect the cost of hop-count, the cost of traffic, and the cost of the instability of a certain network path. Node reachability was considered to study the reliability of the three algorithms as the heterogeneity of the network increases. Table 6 shows the distribution of the nodes with different interfaces (Bluetooth, WIFI, or Bluetooth and WIFI) among the different cases. At the beginning all the nodes had a WIFI interface, then we increase the number of nodes having a different interfaces. We have considered in our simulation 9 network topologies with increasing heterogeneity. These topologies are shown in Table 6.

Table 4. W calculation through n1-n2-n5-n6-n7-n4n10 Path

Node

Table 6 - Distribution of nodes in the simulated network topologies

Assume that there was some network delay and a n4’s RREQ message reaches n10 late as shown in Table 4. n10 checks the RREQ sequence number and finds that this is an up-to-date message with a smaller W (2.60). Hence, it will send a new RREP to n1 through the reverse path n10-n4-n7-n6-n5-n2-n1. Once an intermediate node receives the RREP message which has a smaller W (and same destination sequence number), it will update its routing table accordingly (to build the forward path) and it will forward the RREP to the next node on the reverse path. Table 5 shows that the optimal path would go through n1-n2-n3-n4-n10 because it has the lowest W due to its small hop count. This small hop count affected both the cumulative LB_route and DC_route. Although along this path, a conversion between the two technologies would take place; its cost is still affordable compared to the other factors. So, assuming that n10 will send the RREP message associated with this new W, every node on the

Wifi /Bluetooth Nodes

Total Nodes

Topology #

Wifi Nodes

Bluetooth Nodes

1

50

0

0

50

2

45

2

3

50

3

40

5

5

50

4

35

8

7

50

5

30

10

10

50

6

25

12

13

50

7 8 9

20 15 10

15 17 20

15 18 20

50 50 50

Table 7 shows how the delay was affected when using the traditional AODV, the proposed HAODV, and HBDR when sending a data packet through the algorithm’s optimal path. The value of the delay was calculated as follows: delay= 10× (N −1) + 5 × NW / B + 5 × N B + 5 × Conv (10) where N is the number of hops traversed in a certain path, NW/B is the number of ‘W/B’ nodes encountered in the path, NB is the number of B nodes encountered along the

898

path, and Conv is the rate of conversions that took place through the path. ‘W/B’ nodes were assumed to increase the traffic along the path since they may receive request from a higher number of neighbors compared to ‘W’ and ‘B’ nodes. Hence the path delay is proportional to the number of ‘W/B’ nodes in the path. A ‘B’ node is considered to increase the instability of the network and specifically of a certain path; hence the total delay was increased in accordance with the number of ‘B’ nodes in a path. The number of conversions that took place along a path is also taken into account when calculating the overall time needed for a packet to be sent from the source to the destination node. Table 7 shows the calculated delay for traversing the shortest path in AODV versus the optimal path with respect to W in the proposed HAODV. As the table shows, the three algorithms started by following the same path at the beginning. This is due to the fact that the first network topology used contained only WIFI nodes which mean that the network is homogeneous in nature. However, as the heterogeneity increased, we can note that the proposed HAODV succeeded in finding a path that causes a smallest delay for packet delivery. Furthermore, HAODV managed to find a path between a source and destination when the AODV and HBDR path discovery techniques failed to do so (as shown in the last three topologies where an infinity delay means that the destination is unreachable). This is due to the fact that HAODV can manage to find a path that passes through a ‘W’ intermediate node for example, when the source and destination nodes both use the Bluetooth interface.

however AODV and HBDR’s reachabilty decreased as the heterogeneity increased. 100 90

Reachability

80 70 60 50

AODV

40

ProposedHAODV

30

HBDR

20 10 0 1

2

3

4

5

6

7

8

9

Heterogeneity

Figure 4. Heterogeneity versus node reachability Finally the delay was measured under network topologies with varying sizes. Figure 5 shows that the proposed HAODV often managed to find a path that causes a smaller delay than the other two algorithms. This can be easily explained since HAODV supports interoperability. In Figure 5, when the number of nodes is 18, we observe that AODV and HBDR result in a higher delay. This is due to the fact that in this particular network topology, these two algorithms followed a long path in which nodes are WIFI enabled. However, the proposed HAODV followed a shorter path of heterogeneous nodes. 160

Table 7 - Heterogeneity versus delay

140

AODV Delay

HAODV delay

HBDR

120

95

95

95

100

2

95

95

100

3

100

100

100

4

120

115

120

60

5

125

115

125

40

6

140

115

140

7

20

∞

135

∞

7

∞

135

∞

7

∞

135

∞

Delay

Topology # 1

AODV Proposed HAODV HBDR

80

0 6

12

18

24

30

36

Number of Nodes

Having noted that AODV and HBDR failed to find a path in some topologies, Figure 4 shows the percentage of reachable nodes from a certain node to every other node in a network of 50 participating nodes. Again, we notice that the three algorithms were equivalent in terms of reachability in a homogeneous network as the source node was able to communicate with every other node;

Figure 5. Delay versus increasing number of nodes

5. Conclusion and Future Work In this paper, we have shown that the OnDemand Ad-Hoc Distance Vector algorithm can

899

[4] J. Broch, D. Johnson, and D. Maltz, “the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks,” InternetDraft, draft-ietf-manet-dsr-01.txt, December 1998.

be optimized to support routing in heterogeneous networks in a way that takes various parameters into consideration. In this context, we have proposed a heterogeneous AODV protocol in which the optimal route is defined not only in terms of the path with the smallest hop-count, but also in terms of the path with the lowest traffic, highest stability, and effective conversion rate in heterogeneous networks. The presented protocol is open to further research and enhancements. Typically, interference between different technologies that use the same frequency must be catered for. In addition, security issues, power limitations, and processing capabilities are to be studied in the context of designing routing protocols for heterogeneous MANETs. In this work, to evaluate the performance of the proposed HAODV versus the traditional AODV and HBDR and obtain some preliminary results, we have developed our own simulator prototype using JAVA. We have studied the behaviors of these three protocols in terms of delay and node reachability (i.e., reliability) under different network topologies with increasing heterogeneity and increasing number of participating nodes. The preliminary obtained results are very encouraging. In our current and future work, we are evaluating the performance of the proposed protocol compared to AODV and HOLSR [16] using a standardized simulator. We are aware of the fact that conducting data and performance analysis using standardized simulators such as NS2 [10] or Glomosim [1] is a better choice for the results of this algorithm to be formally evaluated.

[5] J. Broch, D. Maltz, and D. Johnson “Supporting Hierarchy and Heterogeneous Interfaces in Multi-Hop Wireless Ad Hoc Networks,” Int’l Symposium on Parallel Architectures, Algorithms and Networks, 1999, pp. 370-375. [6] I. Chakeres and E. Belding-Royer, “Resource Biased Path Selection in Heterogeneous Mobile Networks,” University of California Santa Barbara, Department of Computer Science, Technical Report 2003-18, July 2003. [7] I. Chlamtac, M. Conti and J Liu, “Mobile ad hoc networking: imperatives and challenges”, Ad Hoc Networks, vol 1, Issue 1, pp 13–64, July 2003. [8] T. Clausen, P. Jacquet, et. al.; “Optimized link state routing protocol,” RFC 3626; October, 2003. [9] E.Dijkstra, “A note on two problems in connexion with graphs,” Numerische Mathematik, pp. 269-271,1959. [10] K. Fall, K. Varadhan. NS notes and documents. The VINT Project. UC Berkeley, LBL, USC/ISI, Xerox PARC, February 2000. Available from http://www.isi.edu/nsnam/ns/ns-documentation.html. [11] IEEE Std 802.11. “Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) specification,” 1999 edition [12] P. Manzoni and J. Cano “Providing interoperability between IEEE 802.11 and Bluetooth protocols for Home Area Networks. Computer Networks,” Computer Networks, vol. 42, n0.1, May 2003, pp. 23-37. [13] C. Perkins “Ad Hoc Networking” Addison-Wesley, Second Edition, 2004. [14] C. Perkins and E. Royer “Ad-hoc On-Demand Distance Vector Routing”, Proc. of the Second IEEE Workshop on Mobile Computer Systems and Applications, February 1999, pp.90-100. [15] H. Safa, H. Artail, R. Shibli. “An Abstract Model for Supporting Interoperability in Mobile Ad-hoc Networks,” Proc. of the second IEEE Int’l Conf. on Wireless and Mobile Computing, Networking and Communications, WiMob’2006, 2006, pp. 45-52. [16] L. Villasenor-Gonzalez, Y. Ge, and L. Lamont “HOLSR: A Hierarchical Proactive Routing Mechanism for Mobile Ad Hoc Networks,” IEEE Communications Magazine, vol. 43, no. 7, July 2005, pp. 118-125. [17] K. Xu and M. Gerla, “A Heterogeneous Routing Protocol Based on a New Stable Clustering Scheme,” Proc. Military Communications Conf., MILCOM 2002, Oct. 2002, pp. 838-843.

6. References [1] L. Bajaj, M. Takai, K. Tang, R. Bagrodia, and M. Gerl. “GloMoSim: A Scalable Network Simulation Environment,” CSD Technical Report, #990027, UCLA, 1997.

[18] X. Zhong, Y. Wang, S. Mei, and J. Wang “Stable Enhancement for AODV Routing Protocol”, Proc. 14th IEEE Int’l Symposium on Personal, Indoor and Mobile Radio Communications, 2003, pp.201-205.

[2] C. Bisdikian, “An overview of the Bluetooth wireless technology,” IEEE Communication Magazine, December 2001. [3] Bluetooth SIG, Specification of the Blurtooth System version 1.1, 2001.

900