PHAODV: Power aware heterogeneous routing protocol for MANETs

PHAODV: Power aware heterogeneous routing protocol for MANETs

Haidar Safa, Marcel Karam, Bassam MoussaQ1

Department of Computer Science, American University of Beirut, Beirut, LebanonQ2

a r t i c l e i n f o

Article history:Received 30 July 2013Received in revised form20 May 2014Accepted 23 July 2014

Keywords:Heterogeneous routingPower-awareMANETsAODV

a b s t r a c t

Devices in mobile ad hoc networks (MANETs) have limited power resources and may be equipped withdifferent transmission technologies. These characteristics make MANET traditional routing protocolsinconvenient in a heterogeneous environment. Hence, the need for designing routing protocols thatsupport interoperability between heterogeneous nodes and efficiently uses the available resources. Inthis paper, we propose a power aware routing protocol for a MANET formed of heterogeneous nodes. Theproposed approach takes into consideration the battery status of nodes when building the routing table;in addition, in case of the existence of multiple routes between two nodes, the route that consumes leastpower is selected and the nodes falling on this route will be added to the routing table. Also, theproposed approach ensures fair distribution of routing load among the nodes and avoids exhaustingnodes that are falling on optimal routes across the network, thus providing better connectivity andextending the network lifetime. We implemented the protocol as an extension to JiST/SWANS networksimulator, and compared its performance to other heterogeneous and power aware routing protocolsfound in the literature.

& 2014 Elsevier Ltd. All rights reserved.

1. Introduction

Mobile devices in a MANET come in different sizes and shapes,have varying transmission/receiving and processing capabilitiesand could operate across different frequency bands (Chlamtacet al., 2003)Q3 . They do however have few things in common, theyare equipped with powerful processing units capable of runningmore sophisticated and power demanding applications. They mayalso have more than one wireless interface of different wirelesstechnologies such as Wi-Fi (Next-Generation Wireless Technology,2006) and Bluetooth (Chatschik, 2001). This heterogeneityrequires the establishment and maintenance of heterogeneousroutes throughout the network. Traditional routing protocols suchas DSDV (Perkins, 1994) and AODV (Perkins, 1997) showed goodperformance in MANETs formed of homogeneous nodes; however,these protocols do not provide interoperability support, and as aresult, cannot establish heterogeneous route (i.e., route formed ofheterogeneous nodes). Also, certain nodes may fall on optimalroutes that relate a set of sources to their destinations. Thecontinuous use of these nodes leads to depleting their limitedpower resources and thus their disappearance from the network,thus affecting the network connectivity and reliability. A scenariois illustrated in Fig. 1 in which node C falls on routes connecting

nodes S1, S2 and S3 to destinations D1, D2 and D3 respectively.A power unaware routing algorithm will keep on using node C inall routes (R1, R2, and R3) regardless of its power status, thusleading to depleting its energy and affecting the connectivitybetween these sources and destinations.

A power aware routing protocol will consider all nodes' powerduring route establishment. Therefore, nodes that have higherpower resources are given higher priority to participate in therouting process. Such a protocol should also ensure fair distribu-tion of routing load among the nodes and wisely use all nodes'available power to prolong the network lifetime. In this work,which is an extension to our work in Safa et al. (2013), wedesigned a power aware routing protocol for a heterogeneousnodes-based MANET. The proposed protocol was implemented asan extension to the JIST/SWANS (Jist/Swans Webpage) simulatorand tested under various scenarios to evaluate its performancecompared to other routing protocols found in the literature such asAODV (Perkins, 1997), HAODV (Safa et al., 2007), OTRP (AlAamriet al., 2009, 2013), OTRPHA (AlAamri et al., 2010), and a poweraware variation of OLSR (Kunz, 2008).

2. Related work and background

Previous and recent work on heterogeneous MANET routingprotocols have not defined the heterogeneity clearly (AlAamriet al., 2010; Avudainayagam et al., 2003; Clausen and Jacquet, 2003;

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

6768697071727374757677787980818283848586878889909192939495969798

Contents lists available at ScienceDirect

journal homepage: www.elsevier.com/locate/jnca

Journal of Network and Computer Applications

http://dx.doi.org/10.1016/j.jnca.2014.07.0351084-8045/& 2014 Elsevier Ltd. All rights reserved.

E-mail addresses: [email protected] (H. Safa), [email protected] (M. Karam),[email protected] (B. Moussa).

Please cite this article as: Safa H, et al. PHAODV: Power aware heterogeneous routing protocol for MANETs. Journal of Network andComputer Applications (2014), http://dx.doi.org/10.1016/j.jnca.2014.07.035i

Journal of Network and Computer Applications ∎ (∎∎∎∎) ∎∎∎–∎∎∎

www.sciencedirect.com/science/journal/10848045

www.elsevier.com/locate/jnca

http://dx.doi.org/10.1016/j.jnca.2014.07.035



mailto:[email protected]







Fujiwara et al., 2012; Kunz, 2008; Liu et al., 2011; Souto et al.,2012; Stuedi, 2005; Tan et al., 2009; Xie et al., 2007; Zhang et al.,2011). For some of them, a heterogeneous network is a networkcomprising mobile nodes with different energy supplies, differenttransmission powers, or different data rates (Avudainayagam et al.,2003; Liu et al., 2011; Zhang et al., 2011; Xie et al., 2007). Othershave ignored the node heterogeneity and focused on routing amongheterogeneous networks each of which is comprised of homoge-neous nodes (Fujiwara et al., 2012). Few have defined heteroge-neous network as a network comprising mobile nodes withmultiple interfaces (AlAamri et al., 2010; Clausen and Jacquet,2003; Kunz, 2008; Safa et al., 2007; Souto et al., 2012). In thiswork, we define heterogeneous MANET as a network formed ofheterogeneous nodes and some of these nodes may have more thanone wireless interface and the wireless interfaces can be of differentwireless technologies; thus, the routes are heterogeneous routes.

The Optimized Link State Routing, OLSR (Clausen and Jacquet,2003), is a heterogeneous routing protocol that presents theconcept of multi-point relays, MPR, to improve link state routingperformance in MANETs. It is a proactive and table-driven protocolin which nodes periodically broadcast Hello messages over alltheir interfaces to advertise themselves, discover their neighbors,and acquire sufficient knowledge about them. Nodes use theacquired information to select their MPRs and to maintain up-to-date routing tables which are built through a shortest pathalgorithm. A node receiving a Hello message uses it to update itsset of one-hop and two-hop neighbors. MPR nodes are selectedfrom the set of one hop neighbors reachable by a node. Selectednodes can tell from the Hello messages whether they wereselected as MPRs by the source of Hello message. The MPRselection mechanism is shown in Fig. 2. A node selected as MPRkeeps track of all its selector nodes and periodically broadcaststopology control messages to notify other nodes of the networktopology. Topology control messages are forwarded by MPR nodesonly to minimize the number of messages flooding the network.One of the main problems of OLSR is that it results in large sizedrouting tables and a large number of periodic messages floodedacross the network, hence exhausting its resources. OLSR as wellfails to provide a route connecting sources and destinations usingnon-alike radio signals.

An energy efficient variation of OLSR was proposed in Kunz(2008). This variation introduces two modifications to enhance thenetwork life time: the MPR selection criteria and the path selec-tion algorithm. These modifications aim at avoiding the use of

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Fig. 1. Power aware routing algorithm will avoid exhaustion of node C.

Fig. 2. OLSR multi point relay (MPR) selection.

H. Safa et al. / Journal of Network and Computer Applications ∎ (∎∎∎∎) ∎∎∎–∎∎∎2





nodes with low residual energy level in the MPR set and to favorthe selection of routes avoiding the use of exhausted nodes thusextending their existence in the network and the network lifetime. However, this approach did not provide a solution for themain drawback in OLSR leading to a waste of nodes' energybecause sending and receiving a large number of topology controlmessages were not eliminated. The routing concepts of OLSR werealso used in Souto et al. (2012) but with a new mechanism tocalculate the routes and select the MPRs.

An On-demand Tree-based Routing Protocol (OTRP) was pro-posed in AlAamri et al. (2009, 2013). This protocol combines theidea of hop-by-hop routing such as AODV with an efficient routediscovery algorithm called the Tree-based Optimized Flooding(TOF) to improve the scalability of ad hoc networks when thereis no previous knowledge about the destination. Route discoveryoverheads are minimized by selectively flooding the networkthrough a limited set of nodes that are called branching-nodesbecause they form a tree-based structure to scan the network.Branching nodes, also called rebroadcasting nodes, are selectedbased on their locations that are obtained by using GPS. When asource node wants to communicate with a destination and noprevious route exists, it divides its transmission area into fourquadrants each of which has its own scanning process to rebroad-cast Route Request (RREQ) packets. The source node selects abranching node in each quadrant and appends to RREQ packet itsown location and addresses of four branching-nodes that willrebroadcast the RREQ packet in the four quadrants. Upon receivingthe RREQ packet, a node checks whether it is one of the branching-nodes indicated in the RREQ packet. If it is then it will process thepacket and repeat the same procedure until reaching the destina-tion, otherwise the packet is ignored. Processing the RREQ packetincludes finding branching-nodes, updating the RREQ packet andthen rebroadcasting it. However, since each selected node does notbroadcast RREQ packets back to the quadrant where the packetcomes from, therefore it chooses only three branching-nodes torebroadcast. Only the source node of RREQ packet selects fournodes as first time for broadcasting the packetQ4 . If the a node fails inselecting branching nodes, then normal broadcasting will becarried. OTRP does not perform well in a heterogenous environ-ment as it selects rebroadcast nodes according to its location only.For example, if all branching nodes are from the same type as thesource node, then the destination that is from a different typecannot be reached unless all nodes are rebroadcasting. This meansthat OTRP will behave like AODV with higher overheads and delaywhere all nodes will rebroadcast to find a route.

Another heterogeneity-aware OTRP based routing discoverystrategy was proposed in AlAamri et al. (2010), hence it is calledOTRP Heterogeneity-Aware (OTRP-HA). OTRP-HA extends OTRP tobe aware of the several features to select rebroadcasting nodes.These features include local density of node, node location, nodetype, and connectivity. In OTRP-HA, the source node does notselect rebroadcasting nodes; however, the decision to rebroadcastis left to the relay nodes. The route discovery process goes throughfour RREQ retries (trials) to find the destination. In each trial, thereare different numbers of conditions to relay RREQ packet. If thereis no route found in trial 1 then the source node retries again withmore rebroadcasting nodes. If there are unreachable nodes or noroute was found through three trials, then all nodes will rebroad-cast the RREQ packets. If a node receives a RREQ packet it thenchecks if it satisfies the rebroadcasting conditions for the currentRREQ retry. If yes, then it forwards the packets, otherwise it dropsit. The decision to rebroadcast depends on the availability ofdestination node type in the received node. If the destinationnode type is known then the relay nodes' type must be the sameas the destination. In this case, these nodes will rebroadcast if theysatisfy the following conditions: (1) local density and location in

the first trial, (2) location only in the second trial, and (3) all nodesthat have the same type as the destination node rebroadcasts inthe third trial. In case the destination type is unknown, then (1) inthe first trial powerful nodes are the only nodes to rebroadcast.(2) In the second trial, only nodes that have the same type as thesource node type and satisfy the conditions of local density andlocation should rebroadcast. (3) In the third trial, all nodes thatsatisfy the location and local density conditions rebroadcast.A node not receiving any route replies from a certain destinationwill add that destination to a set of unreachable nodes to avoidfuture routing to that node.

The device-energy-load-aware relaying framework (DELAR)(Liu et al., 2011) exploits the feature of device heterogeneity inan ad hoc network. It focused on heterogeneous ad hoc networkscomprising mobile nodes with different energy supplies. The mainideas are that data forwarding should attempt to utilize nodeswith powerful or unlimited power supplies as much as possible inorder to conserve energy of nodes with limited power. Therefore,the routing cost metric involved takes into account the residualenergy and congestion status of a node.

Ad hoc On-demand Distance Vector (AODV) protocol is a tabledrive reactive protocol in which routes are discovered on an on-demand basis. In AODV each node keeping a routing table containsnext hope to be used to reach destination. On receiving datapacket each node checks its routing table for a valid route to thedestination; if such a route exists, then only it forwards the packetto the next hope. There are mainly two important phases in AODVprotocol: route discovery phase and route maintenance phase.During the route discovery phase, source node floods a RREQpacket in the network. When a node receives RREQ packet, itchecks if it has the destination information. If it has, then it sends aroute reply (RREP) message to the sender. Otherwise it floods thesame RREQ packet to its neighbors. If there is no reply within acertain time interval the source node assumes that there is noavailable route to the destination. In this case, after a certaininterval of time source node again broadcasts the RREQ messagefor route discovery. In order to avoid the duplication, each requestcontains a sequence number. When a node receives a RREQmessage, it checks whether the sequence number has not seenbefore. Otherwise it discards the message. If the node have notseen the sequence number before then it sets up a reverse pathtowards the source node. The intermediate node updates itsrouting table with the address of the neighbor from which thefirst copy of the broadcast RREQ packet received. When thisrequest reaches the destination, it sends the reply to the sourcethrough this reverse path. After that the data from the source canbe disseminated through the reverse path is called the forwardpath. Each node is associated with a route timer. The forward pathis deleted when the timer expires. Figure 3 represents the route

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132Fig. 3. AODV route discovery process.

H. Safa et al. / Journal of Network and Computer Applications ∎ (∎∎∎∎) ∎∎∎–∎∎∎ 3





discovery process in AODV. In the route maintenance phase, eachnode periodically sends a HELLO packet to its neighbors. Failure ofreceiving HELLO packet indicates that the neighbor has movedaway. So the link to this neighbor is marked as broken in therouting table.

The heterogeneous AODV that was proposed in Safa et al.(2007) extends AODV to support heterogeneous MANET by allow-ing the use of nodes using heterogeneous network interfaces inthe same route. HAODV considers the transmission interfaces suchas Wi-Fi and Bluetooth present at each node in the network whenbuilding the routing table. Also, it aims at using stable nodes inroutes. This stability is measured in terms of the successfullydelivered packets by a node with respect to all the packets handedto it. However, HAODV is not power-aware and its performancewas not compared to other heterogenous routing protocols.

Notwithstanding the important contributions of the existingsolution, there is still a need for a power-aware routing approachthat supports coexistence of nodes equipped with heterogeneouswireless interfaces in one MANET. This protocol should connectheterogeneous devices in a seamless way and be able to establishheterogeneous routes between sources and destinations.

Table 1 presents a summary of the major features of the relatedwork approaches.

3. Power aware heterogenous AODV–PHAODV

In this section, we present the proposed power aware hetero-geneous AODV (PHAODV) routing protocol that uses efficiently theenergy available in nodes when establishing and maintainingheterogeneous routes in the network. The protocol extends andenhances our work in Safa et al. (2013), which is built on HAODVrouting protocol, a previous work of ours (Safa et al., 2007) but notpower aware.

HAODV allows heterogeneous nodes in a route regardless of thenodes' underlying technology. In this paper, in addition to refiningthe proposed approach, the proposed PHAODV, we have comparedit with two more significant related works found in the literature(i.e., OTRP, AlAamri et al., 2009, 2013 and OTRPHA, AlAamri et al.,2010) and considered more simulation scenarios such as scalabil-ity and network size.

3.1. Basic concepts of PHAODV

The proposed PHAODV assumes that the nodes are enabledwith an interoperability (Safa et al., 2009, 2006) model which is amiddleware installed between the application layer and the lowerlayers to enable nodes using different transmission technologies tocommunicate. Furthermore, this middleware which is responsiblefor handling the packet conversion from one technology toanother provides a unified addressing scheme that hides the

differences of addressing paradigms used by different technologies.Readers can refer to Safa et al. (2009, 2006) for more details.However, in this proposed work, we use a method called theConvert to delegate the conversion procedure to the interoperabilitymodel. Figure 4 shows the pseudo code for this algorithm. It showsthat the capability layer in the interoperability model is able to fetchthe capabilities of each node and returns the type of each transmis-sion interfaces (e.g., W, B, or W/B). To reduce the number ofconversions, the algorithm states that when two consecutive nodesequipped with the same interfaces (such as W/B node), the packetwill be forwarded using the interface type through which it wasreceived. Other than this conversion, AODV routing messages(RREQ, RREP, etc.) remain the same.

The proposed PHAODV assumes that the nodes are enabledwith an interoperability (Safa et al., 2009, 2006) model that is amiddleware which is installed between the application layer andthe lower layers of the protocol stack. The main functionality ofthe middleware is enabling nodes using different transmissiontechnologies to communicate. In other words, the middleware isresponsible for handling the packet conversion from one technol-ogy to another. Readers can refer to Safa et al. (2009, 2006) formore details. However, for the sake of simplicity, in this proposedwork we use a method called the Convert to invoke the middle-ware conversion procedure as shown in Fig. 4. The figure showsthat the capability layer in the interoperability model can fetch thecapabilities of each node and returns the type of its transmissioninterfaces (e.g., W, B, or W/B). To reduce the number of conver-sions, the algorithm states that when two consecutive nodes areequipped with the same interfaces (such as W/B node), the packetwill be forwarded using the interface type through which it wasreceived. Other than this conversion, AODV routing messages(RREQ, RREP, etc.) remain the same.

The information acquired by a node about its neighbors throughrouting messages is stored in the neighbors' list with an identifica-tion of the interface through which this information was acquired.The interface identifier is used as an indication of the signal typebetween neighbor nodes in future communication. This informationis not appended to the packets' headers and is kept in the routingtables to avoid any unnecessary increase in the packet size.

To select stable routes, the proposed protocol assumes thateach node maintains two parameters in its memory: the DeliveryCounter (DC) parameter which is used to measure the node'sstability during the route establishment taking into considerationthe node's delivery history and the Load Balance (LB) parameterwhich is used to measure the load on the node (Zhong et al.,2003). These parameters are given as

DC ¼ 0:1� DCþPacketCounter ð1Þ

LB¼ 1�Packets_number_in_waiting_listAmmount_of _Buffer

ð2Þ

where PacketCounter is the number of packets successfullydelivered to neighboring nodes during a period of time,Packets_number_in_waiting_list is the number of queued packetsto be transmitted, and Ammount_of_Buffer is the node buffer size.

When a route request message is forwarded, DC_RouteLB_Route, Conv_Route, and PC_Route are computed. DC_Route isdefined as the sum of delivery counters of nodes in the path fromthe source to the destination and given in Eq. (3). LB_Route isdefined as the sum of load balances of these nodes and given inEq. (4). Conv_Route is defined as the sum of the accumulatedconversion cost, C, of nodes in the path from the source to thedestination and is given in Eq. (5)

DC_Route¼∑iϵSDC_Routei ð3Þ

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Table 1Summary of related work.

Approach Proactive Reactive Hybrid Interfaceaware

Poweraware

OLSR X – – X –

EOLSR X – – X XAODV – X – – –

DELAR X – – – XHAODV – X – X –

OTRP – X X – –

OTRP-HA – X X X –

Proposed PHOADV – X X X X






where DC_Routei is the delivery counter at node i belonging to theset of nodes forming the route S

LB_Route¼∑iϵSLB_Routei ð4Þ

where LB_Routei is the load balance at node i belonging to the setof nodes forming the route S

Conv_Route¼∑SC ð5Þ

where S is the set of nodes forming the route.PC_Route represents the energy cost and is defined as a

function of transmission costs over links, TC, and the batterystatus of nodes, BR. It is given in Eq. (7)

PC ¼ f ðTC;BRÞ ð6Þ

PC ¼ α� TCþð1�αÞ � BR ð7Þwhere 0rαr1 and α can be configured either for saving batteryenergy of nodes or using cheaper energy-wise routes.

The value of α is very critical. In this work, we have set it to 0.35after performing several simulation runs to measure the energywhile varying α as shown later on in the performance section.

The presence of battery status ratio in the energy cost helps toavoid the exhaustion of nodes falling on efficient routes when only

the hop count parameter is used to build routing tables. The TCand BR at each node are computed as following:

TC ¼ CostacqþCosttran ð8Þ

where Costacq is the cost of acquiring the channel for transmissionor reception; it could be CostWacq for Wi-Fi or CostBacq for Blue-tooth, and Costtran is the cost of transmission of a packet over a linkthat is given as Costtran ¼msize � b where msize is the message sizeto be transmitted in bytes and b is the cost per byte and varieswhile using Wi-Fi or Bluetooth.

The battery status ratio of a node is given as

BR¼ IBECBE

ð9Þ

where IBE is the initial battery energy of the node in Joules, supplied atstart-up and CBE is the current battery energy present at the node.

To avoid the overuse of certain nodes, the battery cost BR of anode increases when it consumes more of its energy. The currentbattery energy, CBE, varies according to the state of the node. If thenode is idle, it uses a constant fraction of its energy every secondand its CBE is updated whenever a state change occurs from idle tosending or receiving using a timer to record the number ofseconds the node spent in an idle state. This counter is resetwhenever the node enters the idle state. CBE is updated using the

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Fig. 4. Conversion algorithm pseudo-code.






following equation:

CBE¼ CBE�CI � t ð10Þwhere CI is the energy spent each second by an idle node and t isthe idle duration of a node in seconds.

When a node moves from transmitting or receiving state toanother state, its CBE is updated using Eqs. (11) and (12)

CBE¼ CBE�TC ð11Þwhere TC is the transmission cost given in Eq. (8)

CBE¼ CBE�RC ð12Þwhere RC ¼ CostacqþCostrec and Costacq is the cost of acquiring thechannel as described earlier and Costrec is the cost of receiving apacket over a link and given as Costrec ¼msize � r where msize is themessage size received in bytes and r is the cost per byte and varieswhile using Wi-Fi or Bluetooth.

3.2. Route request/reply messages in PHAODV

The route request message in the proposed PHAODV contains thefields described in Table 2. The fields rReqID, destIP, origIP, destSeqNum,origSeqNum and unknownDestSeqNum are set by the originator of theroute request. The originator also sets the Conv_Route and hopCountfields. The hopCount is incremented at each node as the messagetravels across the network till it reaches the destination. Other fieldsare initialized by the originator as per Eqs. (1), (2) and (7) and updatedat the intermediate nodes as will be described shortly. The originatorincludes its stability, load balance and energy parameters in therequest. Each intermediate node updates these values by adding tothem its own values before forwarding it again. In route request, anode uses all the available interfaces supported by different technol-ogies as in the case of multi-interfaced nodes.

A node receiving a route request processes it as illustrated inthe flowchart of Fig. 5 which can be described as follows. The nodechecks first if it has already received a RREQ with same OriginatorIP address and RREQ id. Then:

1. If the node has already received a RREQwith the same Originator IPaddress and RREQ id, it silently discards the newly received RREQ.

2. If the node has not received previously a RREQ with the sameOriginator IP address and RREQ id, it looks up its routing tablefor an entry about the source node to make sure that it has avalid up-to-date route to the originator. If such an entry doesnot exist, the node uses the parameters existing in the RREQmessage to update its routing table. Then in both cases (if anentry about the source is found or not), the node proceeds bychecking if itself is the destination as follows:

(a) If the node is the destination of the RREQ, it will generatethe RREP message with DC_Route, LB_Route, Conv_Routeand PC_Route of RREP copied from the RREQ.

(b) If the node is not the destination, and its residual energy issmaller than a certain threshold (as discussed later inSection 3.4), it will silently discard the RREQ.

(c) If the node is not the destination, its residual energy islarger than a certain threshold, but it does not have a validroute to the destination, then it updates the DC_Route,LB_Route, Conv_Route, and PC_Route of this RREQ usingEqs. (13)–(16) and floods the RREQ to its neighbors

DC_Route¼DC_RouteþDC ð13Þ

LB_Route¼ LB_RouteþLB ð14Þ

Conv_Route¼ Conv_RouteþC ð15Þ

PC_Route¼ PC_RouteþPC ð16Þwhere the conversion cost, C, is set to zero if the node isnot ‘W/B’.

(d) If the node is not the destination, its residual energy islarger than a certain threshold, but it does have a validroute to the destination, then it will generate the RREPmessage for the source node using the data present in itsrouting table. The RREP message has the same fieldspresent in the RREQ and is expected over any networkinterface a node uses. However, in this case DC_Route,LB_Route, Conv_Route, and PC_Route will be updated usingEqs. (17)–(20) as follows:

DC_Route¼DC_RouteþDC_Dest ð17Þ

LB_Route¼ LB_RouteþLB_Dest ð18Þ

Conv_Route¼ Conv_RouteþConv_Dest ð19Þ

PC_Route¼ PC_RouteþPC_Dest ð20Þwhere the fields DC_Dest, LB_Dest, Conv_Dest and PC_Destare routing table entries as described in Table 3.

When a node receives more than one RREP messages to thesame destination with the same sequence number, it will calculatethe union selection parameter W, given in Eq. (21), of each of theseroutes. The route that has the smallest W value will be selected.The Union Selection Parameter is calculated as follows:

W ¼ a1 � Nþ 1N� ð�a2 � DC_Routeþa3 � LB_Route

þa5 � PC_RouteÞþa4 � Conv_Route ð21Þ

where a1, a2, a3, a4 and a5 are the weights assigned to hop count N,DC_Route, LB_Route, Conv_Route and PC_Route respectively. Theseweights are preset by the network administrator. We do not dividea4nConv_Route by the number of hops, because if we do so, thenany time conversion cost C¼0, the Conv_Route will remain thesame but it will be divided by a larger number and hence W willdecrease while it should remain at the same value.

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Table 2Parameters in a route request message.

rReqID Route request identification numberdestIp Destination node IP addressorigIP Originator node IP addressdestSeqNum Latest known destination sequence numberorigSeqNum Originator node sequence numberhopCount Hop count from originator nodeDC_Route Delivery counter parameter held at node resembling its stabilityLB_Route Load balance parameter held at node resembling the load present on itConv_Route Conversion cost resembling the cost of transforming packets from one technology to anotherPC_Route Energy cost associated with the routeunknownDestSeqNum Flag indicating if the destination sequence number is unknown






A node receiving a route request adds the sending node to itsset of neighboring nodes (i.e., neighbors participating in therouting process). Nodes in this set are expected to exchange Hellomessages periodically. Failing to receive Hello messages from acertain node will result in removing it from the neighbor set andconsidering all routes through this node invalid, causing an errormessage to be sent to the affected nodes to announce this linkbreak down.

3.3. Routing table at nodes

The selected routes are kept in nodes routing tables. Thedestination node IP-address is the key to the required table entry.These entries are updated in response to Hello message, Errormessage and route requests and replies. The route table entries aredescribed in Table 3.

3.4. Energy management at nodes

Controlling energy consumption is ensured by maintaining athreshold which decides the participation of nodes in the routingprocess, in addition to another threshold used for invalidating theroutes in use. These thresholds are supplied by the networkadministrator. The threshold related to participation in routing isa certain percentage of the node's initial energy, 25% in oursimulations. When the node is left with just this energy percen-tage, it participates in routes only when it is a source or adestination. Otherwise, the node simply ignores the routingmessages it receives. The invalidation of the routes takes placewhen the node consumes a certain percentage of its residualenergy, 15% in our simulations of PHAODV. The residual energyratio is given as TTH ¼ ðPBE�CBEÞ=PBE, where PBE is the previousbattery residual energy of a node before it encounters a set ofactivities that consumes part of its energy and CBE is the currentbattery residual energy of the node. This ratio, TTH, should be less

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Table 3Parameters in a route table entry.

nextHop The address of the next hop in the route to the destinationdestSeqNum Latest known sequence number for destination nodehopCount Hop count for known route to destinationinterfaceNum Interface number used in routing to this destinationDC_Dest Delivery counter over route to reflect stability of nodes over the routeLB_Dest Load balance over the nodes in the routeConv_Dest Conversion cost resembling all the conversions over the routePC_Dest Energy cost associated with the route

Fig. 5. RREQ processing flowchart.






than a certain percentage supplied to the protocol at the start-upphase. PBE is updated periodically to reflect the use of a node'senergy. When the node energy consumption exceeds the routevalidity threshold, the node considers routes that it is itself amember of, invalid, and sends route error messages to its neigh-bors announcing its disappearance from the networkQ5 . Uponreceiving this error message, neighbors will remove routes passingthrough this node from their routing tables. This announcementwill not remove the node from the network since it will belistening to the channel and ready to participate in any routingactivity with new battery ratio and updated costs for establishedroutes, if its residual energy allows that. A node will be removedfrom the network and will show no activity once its energy isconsumed.

Different types of nodes are supplied with different initialenergies, 2 Mega Joules for a Wi-Fi node and 1 mJ for a Bluetoothnode. A Bluetooth node is supplied with energy less than that of aWi-Fi node. It is worth noting that the energy consumed by aBluetooth node is less than that of Wi-Fi.

4. Simulation results and analysis

We implemented the proposed power_aware heterogeneousrouting protocol, PHAODV, as an extension to JIST/SWANS (Jist/Swans Webpage) simulator and compared its performance to thatof AODV (Perkins, 1997), HAODV (Safa et al., 2007), EOLSR (Kunz,2008), OTRP (AlAamri et al., 2009, 2013), and OTRPHA (AlAamriet al., 2010).

4.1. Simulation environment

To obtain some preliminary results, we have set a simulationenvironment that consists of 100 nodes distributed randomly overan 800�800 m2

field. A node can be equipped with only a Wi-Fiinterface, a Bluetooth interface or Wi-Fi and Bluetooth interfaces.The number of nodes in each category was varied to create a set ofnine different topologies thus increasing heterogeneity in thesimulation scenarios. The first topology consists of nodes all usinghomogeneous interfaces (i.e. 100 nodes using Wi-Fi). Then thetopologies are varied by decreasing the number of nodes usingWi-Fi by 10 in favor of increasing the number of nodes usingBluetooth only by 5 and that of nodes using both transmissiontechnologies by 5 as well. The topologies used in our simulationexperiments are summarized in Table 4.

The source node is always selected randomly from thoseenabled with Wi-Fi interface only, while the destination is selectedrandomly from other nodes in the network. By using thesetopologies, we aim at evaluating the proposed PHAODV as theheterogeneity in the network increases. In our experiments, weborrowed the values for energy consumption parameters fromFeeney (2001), Lansford et al. (2001), and Lundberg et al. (2004) asshown in Table 5.

The weights used for the various routing parameters used byPHAODV and HAODV in computing the union selection parameterare presented in Table 6.

The simulations are run for 300 s with a request rate of oneUDP packet every 3 s per node. The request rate combined withthe network size and the simulation time form the total number ofmessages that should be sent across the network. These messagesare divided over the simulation time and thus result in a set ofmessages that should be sent by various nodes. Source anddestination nodes are selected randomly for each of such mes-sages. For example, a network formed of 100 nodes, a request rateof one packet every 3 s and 300 s simulation time result in 10,000messages that need to be sent. Dividing this number of messages

over the 300 s simulation time results in 33 messages sent at thesame time across the network. Node speed ranged from 0.01 m/sto 2 m/s and the pause time was set to 100 s.

To pick the suitable value for α appearing in the power costcomputation as specified in Eq. (7), we performed a set ofsimulations and collected the results related to energy consump-tion in the network. The results are plotted in Fig. 6 which showsthat the energy consumption was the least with an α equal to 0.35.Thus this value is the most suitable for use in the route establish-ment procedure of the proposed PHAODV.

4.2. Simulation scenarios

We have measured parameters such as node reachability,traffic, energy consumption, and network lifetime, and varied

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Table 4Distribution of capabilities among nodes.

Topologynumber

Wi-Finodes

Bluetoothnodes

Wi-Fi/Bluetoothnodes

Total

1 100 0 0 1002 90 5 5 1003 80 10 10 1004 70 15 15 1005 60 20 20 1006 50 25 25 1007 40 30 30 1008 30 35 35 1009 20 40 40 100

Table 5Values used for energy costs in simulations.

Parameter Wi-Fi value Bluetooth value

Byte sent cost 1.89 mW s 0.31 mW sByte received cost 0.49 mW s 0.08 mW sChannel acquiring for transmission cost 246 mW s 41 mW sChannel acquiring for receiving cost 56.1 mW s 9.35 mW sIdle second cost 74 mW s 0.1739 mW s

Table 6Weights of routing parameters used by PHAODV and HAODV.

Parameter HAODV PHAODV

Hop count factor 0.4 0.35Stability factor 0.15 0.1Load balance factor 0.15 0.1Conversion factor 0.3 0.2Power factor 0 0.25

Fig. 6. Variation of α.






other parameters such as heterogeneity level and simulation time.We have used the central limit theorem (Andel and Yasinsac,2006) to calculate the number of runs required for achieving atleast a 90% confidence level with 7 precision value of 1%. Therequired number of runs for each scenario was found to be 5.

4.2.1. Node reachabilityNode reachability is computed as the ratio of messages

received by destination nodes to that of messages sent by sourcenodes thus reflecting the availability of routes connecting variousnodes across the network. In this scenario, we measure thereachability parameter against the heterogeneity level. We initiallystart with a homogeneous network then increase the level ofheterogeneity using the topologies shown in Table 4. For eachtopology five runs were performed. In each run we selected arandom Wi-Fi node to be the source and a random correspondingdestination for each packet. Figure 7 shows the effect of hetero-geneity on node reachability. It shows that the protocols that arenot enabled with an interoperability model, capable of transform-ing the messages sent by a Wi-Fi node to a Bluetooth format, willfail to deliver these messages if the destination is Bluetooth. Thisexplains the decrease in reachability experienced by AODV andEOLSR as the heterogeneity increases. HAODV and PHAODVexperience stable reachability ratio due to the presence of theinteroperability model. This lessens the effect of heterogeneity onreachability. OTRP and OTRPHA experience the lowest reachabilityrates due to the use of location related information in theestablishment of routes; this information is not stable because ofmobility and hence the effect on node reachability. Although OTRPand OTRPHA use similar strategies in building routes to undiscov-ered nodes, OTRPHA outperforms OTRP in node reachabilitybecause the decision of forwarding a request, in OTRPHA, is madeat the node itself rather than receiving a previously selected set ofrebroadcasting nodes as in the case of OTRP.

4.2.2. Average trafficAverage traffic is calculated as the approximate total number of

bytes traveling across the network. To compute the average traffica protocol imposes on the network, the average message size iscalculated and then multiplied with the total number of messagesused in a scenario. Figure 8 shows the average traffic caused byeach of AODV, HAODV, PHAODV, EOLSR, OTRP, and OTRPHA.It shows an advantage of AODV, HAODV, PHAODV, OTRP andOTRPHA over EOLSR. EOLSR keeps the highest traffic as a result ofits proactive nature. The increase in traffic experienced by AODV isdue to the continuous failure of establishing a route to thedestinations which results in continuously issuing route requests.AODV actually increases the life time of the route request in termsof acceptable hop counts ignoring the fact that the source and thedestination are of different nature and there is no possibility toestablish a route between them. The increase experienced byHAODV and PHAODV is due to the use of two-interfaced nodesin establishing routes. These nodes use both interfaces and initiatemore messages than single interfaced nodes. OTRP routing strat-egy results in more stable and lower traffic. The stability is relatedto the change in the network topology where few nodes areparticipating in routing activities with the decrease of Wi-Fienabled nodes which eventually will be exhausted and will nolonger take any role in routing activities. OTRPHA experiences ahigher routing overhead than that of OTRP but similar to that ofAODV. That is because it is more flexible than OTRP in deciding onwhich nodes should take part in the routing process before using aflooding strategy similar to that used in AODV.

4.2.3. Energy consumptionTo study the energy consumption nodes start with an initial

energy and this energy will be decremented according to the nodeactivity as previously described. A ratio of the average energyconsumed by a node to that of the average initial energy of a nodein the network is plotted in Fig. 9. The average consumed energy isthe sum of the consumed energy by nodes in a scenario divided bythe network size. The average initial energy is the sum of nodes'initial energy divided by the network size. To measure the energyconsumed by nodes, we give a Bluetooth node half the initialenergy given to a Wi-Fi node or a two interfaced node (i.e. aBluetooth node gets 1 mJ as initial energy and others get 2 mJ).Figure 9 shows that EOLSR consumes more energy as an effect toits large number of routing messages as opposed to other proto-cols. The increase in energy consumption by AODV as heteroge-neity changes is the result of the continuous attempts of the Wi-Finodes to establish routes to Bluetooth nodes, selected as randomdestinations for messages, and thus the waste of valuable energy.The decrease in energy consumption shown by HAODV andPHAODV is due to the use of Bluetooth nodes in routes acrossthe network. These nodes use less energy than those used byWi-Fi nodes. PHAODV almost maintains a stable energy consump-tion rate due to its ability to use different transmission technol-ogies in routes and the power awareness approach which avoidsthe overuse of nodes' residual energy. The increase in energyconsumption shown by AODV, HAODV and PHAODV is the result ofthe attempts to establish routes lost due to node mobility. While

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Fig. 7. Node reachability.

Fig. 8. Network traffic.






OTRP shows the least energy consumption, this is due to the loss ofsome source nodes which are depleted while trying to build routesto unreachable destinations. Compared to it, OTRPHA energyconsumption is excessive where it involves most of the Wi-Fiavailable interfaces in search for routes and exhausts most of thesenodes attempting to reach moving nodes.

4.2.4. Network lifetimeNetwork lifetime is represented by the number of dead nodes

during a simulation. As this number increases, lifetime of thenetwork shortens. Networks with 20% of their member nodesdepleted are considered to be dead. This limit is shown as bold linein Fig. 10. In this scenario, out of the 100 nodes used, 50 nodeswere enabled with Wi-Fi interfaces, 20 nodes with Bluetoothinterfaces and 30 nodes with both interfaces. The simulationswere run for 800 s with a packet rate of two packets every 3 s.In the first scenario, the source nodes were equipped with Wi-Fiinterface only while the destination nodes can be equipped witheither Bluetooth Wi-Fi or both. In the second scenario, source anddestination nodes have homogeneous interfaces. As Fig. 10(a) shows,PHAODV allows the network to survive the entire simulation timewhile all the other protocols fail to reach the end of the simulationtime with an alive network. Under AODV and OTRPHA, the networksurvives until the 240th second. Both protocols exhibit a continuousdegradation in performance due to the absence of an efficient powermanagement technique and their inability to use heterogeneousinterfaces on routes across the network, which leads to the exhaustionof nodes capable of using the Wi-Fi technology. These nodes will keepon initiating route requests to build routes to the required destinations,until their energy fades away and they disappear from the network.OTRPHA will keep on using discovered routes to destinations. Nodesfalling on these paths will become exhausted and their energy will be

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132

Fig. 9. Energy consumption.

Fig. 10. Network lifetime: (a) when message source is a Wi-Fi node and (b) when sources and destinations are homogeneous.






depleted because these nodes will keep performing their requiredrouting task regardless of their energy resources. OTRP suffers thesame as OTRPHA; although the network survives for a longer periodunder OTRP but the lack of an energy management technique leads tothe loss of nodes from the network and eventually losing the networkwhen 20% of its nodes are dead. EOLSR reaches the 360th second withan alive network. EOLSR loses nodes in the network due to the largerouting overhead it posses on nodes. HAODV successfully reaches the570th second with an alive network and then starts loosing the nodesfalling on optimal routes across the network and performing routingtasks related to other nodes regardless of their energy status. Figure 10(b) shows the network lifetime when messages sent across thenetwork have sources and destinations of the same type. The sourceand destination being of the same nature allows AODV to extend thenetwork lifetime. The lack of interoperability support under AODVleaves less effect on the network lifetime when compared to the firstscenario. AODV succeeds in reaching the 430th second with an alivenetwork. Due to its proactive nature, EOLSR will extensively use nodes'energy in periodic hello and topology control messages and will loosethe network at the 430th second as well. We observe that theperformance of OTRP was not significantly affected. Indeed, OTRP lostthe network after making use of the nodes falling on suitable nodesjoining various sources to their destinations. OTRPHA improved itsperformance when the sources and destinations are of the samenature. Nodes under OTRPHA have more flexibility now in discoveringand maintaining routes to destinations. Routing nodes are capable ofchoosing the suitable routes and taking place in the routing procedurerather than being selected by sending nodes as in OTRP. With thesource and the destination being of the same type, the networkunder OTRPHA survives for a longer period of time and the nodes areexhausted less often. HAODV loses the network in the 690th second.PHAODV shows better network lifetime and reaches the end of thesimulations with only 10% of the nodes dead. This improvementis the result of decreasing the load on Wi-Fi nodes and allowingthe selection of other nodes as messages sources. The presence ofpower awareness in PHAODV avoids exhausting nodes falling onoptimal routes. PHAODV shows the most stable performance andexhibits an acceptable node loss throughout the simulation timein both scenarios.

4.2.5. Network sizeThe effect of increase in network size on the performance of the

protocols is presented in Fig. 11. The figure shows the nodereachability and the average consumed energy against varyingnetwork size that starts at 50 nodes then increases to 100, 200 andfinally 400 nodes. Distribution of nodes over various transmissiontechnologies is as mentioned earlier. Other parameters were notchanged. We kept the field size as 800�800 m2, the simulationtime 300 s, and the message sending rate to 1 message every 3 sper node. The same analysis could be applied to figure out thenumber of messages sent every second over the network. Sourcesof the messages are the nodes enabled with Wi-Fi interfaces onlyand the destinations are randomly selected.

The effect of network size on node reachability is shown inFig. 11(a). We can easily observe when the node density increases,the ability to establish routes in the network decreases and thusnode reachability is negatively affected as the field gets denserwith participating nodes. This could be justified as it follows.When the node density increases, a higher number of messageswill be flooding the network at the same time. As a result, nodeswill use more of their resources to serve as routing nodes for otherrequests and this leaves a negative effect on nodes life and thusaffects routes establishment and reachability later. Also, it is worthto mention with a large number of messages flooded in thenetwork, the probability of collision and retransmission will

increase. The advantage HAODV and PHAODV have over AODVOTRP, OTRPHA and EOLSR is the result of the interoperabilitymodel and their success in delivering packets with Bluetoothdestinations as opposed to all other protocols which fail to do that.

Figure 11(b) shows the effect of change in network size onenergy consumption. As the network size increases, averageenergy consumed in the network increases because of the largenumber of flooded messages in the network. The decrease in nodereachability, in Fig. 11(a), is reflected by an increase in energyconsumption. EOLSR consumes most of the nodes' energies inattempts to select MPR and keep nodes in knowledge of thenetwork topology. AODV, HAODV and PHAODV consume theenergy in issuing route requests and building routes throughoutthe network. The energy consumption by AODV when networksizes are 200 and 400 nodes and its overcoming of that by EOLSRis the result of the excessive use of Wi-Fi and two interfaced nodesenergy by AODV which fails to include Bluetooth nodes in routingprocedures. Note that energy costs of Wi-Fi nodes are much higherthan that of Bluetooth nodes. This is the same case with OTRPHA,relying the routing decisions on neighboring Wi-Fi nodes, whichuse their energy and affect the overall energy consumption in thenetwork. OTRP, as a result of the source node decision on whichnodes to forward route requests before flooding the network,shows less energy consumption than OTRPHA but this is notenough to compete with HAODV and PHAODV which are capableof transmitting messages between nodes using different transmis-sion technologies. PHAODV shows best average energy consump-tion due to its energy consumption control strategy. PHAODVprohibits the extensive use of nodes in routing procedures andthrough the use of the Bluetooth nodes it provides better controlon energy consumption in the network.

123456789

101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566

676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132Fig. 11. Network size: (a) reachability and (b) energy.






5. Conclusion and ongoing work

In this paper, we have proposed a power aware heterogeneousrouting protocol that considers the node's residual energy and thepower costs when establishing heterogeneous routes between nodes.Two thresholds were used by nodes to control further their energyconsumption. The first threshold aims at keeping a node aware of thechanges in its residual energy and enables it of invalidating routesusing it as an intermediate node and thus establishing new routesusing up to date information about nodes' energy status. The secondthreshold aims at preventing nodes from being exhausted overroutes when it is possible to use alternative routes. The proposedapproach was implemented as an extension to the JiST/SWANSnetwork simulator and its performance was compared to that ofAODV, HAODV, energy aware OLSR, OTRP, and OTRPHA. The perfor-mance metrics taken into consideration were node reachability,routing overhead, energy consumption, and network lifetime. Thiswork is still ongoing. We are currently simulating more scenarioswith different node densities and higher mobility rates to evaluatethe scalability and observe the performance of the network withhigher speed of nodes.

The proposed solution is practical because multi-interfacednodes can play the role of a router that hides the interfaceheterogeneity among the nodes. A limitation that we are stillstudying can be described when a node that is equipped withmultiple interfaces starts to flood broadcast messages (such asinitiating RREQ) in all these interfaces. Furthermore, a node mayreceive route replies and error messages in all its interfaces, not tomention the Hello messages that are used to maintain connectivitywith neighboring nodes. It is true that multi interfaced nodesimprove reachability but this comes at the cost of depleting theirenergy faster than other single-interfaced node due to theirparticipation in routing activity more frequently. These nodes willkeep on using their energy and participating in routes till theyreach specified threshold which might occur more frequently thansingle interface nodes. Furthermore, even with the proposedapproach, a multi-interfaced node with low energy could continueto fall on optimal routes and such a node could offer a linkbetween heterogeneous nodes where no other link is possible.Thus, such a node could suffer energy shortage and fade out fromthe network. Preserving the energy of such nodes is a challengingtask and elongating their lifetime is essential for reliable messagestransmission across the network. Also, it is worth mentioning thatthe proposed approach used error messages to recommend usingenergy thresholds. It would be a good enhancement to integrateupdate messages to the proposed messages which allows a nodeto signal to neighboring nodes its residual energy status andenforce the modification of power costs associated with routesof which it is a member. Another possible modification could bethe use of dynamic thresholds that depends on the node residualenergy, which might result in lessening the route error messagestraveling across the network to invalidate routes.

References

802.11n: Next-Generation Wireless Technology, April 2006.AlAamri H, Abolhasan M, Wysocki T, Lipman J. Optimised relay selection for route

discovery in reactive routing. Ad Hoc Netw 2013;11(January (1)):70–88.

AlAamri H, Abolhasan M, Wysocki T, Lipman J. On optimising route discovery formulti-interface and power-aware nodes in heterogeneous MANETs. In: Theproceedings of the sixth international conference on wireless and mobilecommunications (ICWMC 2010); September 2010. p. 244–9.

AlAamri H, Abolhasan M, Wysocki T, Lipman J. On optimising route discovery inabsence of previous route information in MANETs. In: The proceedings of theIEEE 69th vehicular technology conference VTC2009; 2009.

Andel TR, Yasinsac A. On the credibility of manet simulations. Computer 2006;39(July (7)):48–54.

Avudainayagam A, Lou W, Fang Y. Dear: a device and energy aware routing protocolfor heterogeneous ad hoc networks. J Parallel Distrib Comput 2003;63(2):228–36.

Chatschik B. An overview of the bluetooth wireless technology. IEEE Commun Mag2001;39(December (12)):86–94.

Chlamtac I, Conti M, Liu J. Mobile ad hoc networking: imperatives and challenges.Ad Hoc Netw 2003;1(July (1)):13–64.

Clausen T, Jacquet P. Optimized link state routing protocol (olsr); 2003.Feeney LM. An energy consumption model for performance analysis of routing

protocols for mobile ad hoc networks. Mob Netw Appl 2001;6(3):239–49.Fujiwara S, Ohta T, Kakuda Y. An inter-domain routing for heterogeneous mobile ad

hoc networks using packet conversion and address sharing. In: 32nd Interna-tional conference on distributed computing systems workshops (ICDCSW2012); June 2012. p. 349–55.

Jist/Swans Webpage ⟨http://jist.ece.cornell.edu/⟩.Kunz T. Energy-efficient variations of olsr. In: Wireless communications and mobile

computing conference, 2008. IWCMC '08. International; August 2008. p. 517–22.Lansford J, Stephens A, Nevo R. Wi-fi (802.11b) and bluetooth: enabling coexistence.

IEEE Netw 2001;15(September/October (5)):20–7.Liu W, Zhang C, Yao G, Fang Y. DELAR: a device-energy-load aware relaying

framework for heterogeneous mobile ad hoc networks. IEEE J Select AreasCommun 2011;29(September (8)):1572–84.

Lundberg M, Eliasson J, Svensson L, Lindgren P. 2004. Context aware poweroptimizations of wireless embedded internet systems. In: Proceedings of the21st IEEE instrumentation and measurement technology conference, 2004.IMTC 04, vol. 1; May 2004. p. 91–95.

Perkins C, Elizabeth Royer. Ad-hoc on-demand distance vector routing. In: Proceed-ings of the second IEEE workshop on mobile computing systems and applica-tions; 1997. p. 90–100.

Perkins C, Bhagwat Pravin. Highly dynamic destination-sequenced distance-vectorrouting (dsdv) for mobile computers. In: SIGCOMM '94: Proceedings of theconference on communications architectures, protocols and applications, ACM,New York, NY, USA; 1994. p. 234–44.

Safa H, Artail H, Shibli R. An interoperability model for supporting reliability andpower-efficient routing in manets. Int J Ad Hoc Ubiquitous Comput 2009;4(2):71–83.

Safa H, Artail H, Karam M, Ollaic H, Abdallah R. HAODV: a new routing protocol tosupport interoperability in heterogeneous manet. In: Proceedings of the IEEE/ACS international conference on computer systems and applications; May 2007.AICCSA '07. p. 893–900.

Safa H, Karam M, Moussa B. 2013. A novel power aware heterogeneous routingprotocol for MANETs. In: Proceedings of the 27th IEEE international conferenceon advanced information networking and applications (AINA-2013); Barcelona,Spain; March 2013. p. 25–8.

Safa H, Artail H, Shibli R. 2006. An abstract model for supporting interoperability inmobile ad-hoc networks. In: Proceedings of the IEEE international conferenceon wireless and mobile computing, networking and communications, 2006.WiMob'2006, Montreal, Canada; June 2006. p. 45–52.

Souto E, Aschoff R, Lima Junior J, Melo R, Sadok D, Kelner J. HTR: a framework forinterconnecting wireless heterogeneous devices. In: 2012 IEEE consumercommunications and networking conference (CCNC 2012); January 2012. p.645–9.

Stuedi P, Alonso G. Transparent heterogeneous mobile ad hoc networks. In: Thesecond annual international conference on mobile and ubiquitous systems:networking and services, 2005. MobiQuitous 2005; July 2005. p. 237–46.

Tan L, Yang P, Chan S. Error-aware and energy-efficient routing approach in manets.Int J Commun Syst 2009;22(1):37–51.

Xie F, Du L, Bai Y, Chen L. 2007. Energy aware reliable routing protocol for mobile adhoc networks. In: Wireless communications and networking conference, 2007.WCNC 2007; IEEE; March 2007. p. 4313–7 Q6.

Zhang X, Qian Z, Li T, Qian L, Fu C, Li Y. An efficient routing protocol forheterogeneous wireless ad hoc networks. In: Proceedings of the 2011 interna-tional conference on multimedia technology (ICMT 2011); July 2011. p. 172–5.

Zhong X, Mei S, Wang Y, Wang J. Stable enhancement for aodv routing protocol. In:14th IEEE proceedings on personal, indoor and mobile radio communications,2003. PIMRC 2003, vol. 1; September 2003. p. 201–5.

123456789

1011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

60616263646566676869707172737475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117



http://jist.ece.cornell.edu/




Documents

PHAODV: Power aware heterogeneous routing protocol for MANETs