28IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

PAPER Special Section on Challenged Networking Technologies and Its Service Quality

PRIOR: Prioritized Forwarding for Opportunistic Routing

Taku YAMAZAKI†a), Student Member, Ryo YAMAMOTO††,†††, Member, Takumi MIYOSHI††††,†††,Takuya ASAKA†††††, Senior Members, and Yoshiaki TANAKA†,†††, Fellow

SUMMARY In ad hoc networks, broadcast forwarding protocols calledOR (opportunistic routing) have been proposed to gain path diversityfor higher packet delivery rates and shorter end-to-end delays. Ingeneral backoff-based OR protocols, each receiver autonomously makesa forwarding decision by using certain metrics to determine if a randombackoff time is to be applied. However, each forwarder candidate mustwait for the expiration of the backoff timer before forwarding a packet.Moreover, they cannot gain path diversity if the forwarding path includeslocal sparse areas, and this degrades performance as it strongly dependson the terminal density. In this paper, we propose a novel OR protocolcalled PRIOR (prioritized forwarding for opportunistic routing). In PRIOR,a terminal, called a prioritized forwarder and which forwards packetswithout using a backoff time, is selected from among the neighbours.In addition, PRIOR uses lightweight hop-by-hop retransmission controlto mitigate the effect of terminal density. Moreover, we introduce anenhancement to PRIOR to reduce unnecessary forwarding by using anexplicit acknowledgement. We evaluate PRIOR in comparison withconventional protocols in computer simulations.key words: ad hoc network, opportunistic routing, forwarder selection,retransmission control

1. Introduction

Ad hoc networks are self-distributed infrastructure-freenetworks consisting of mobile terminals such as smartphoneswithout relying on any infrastructure. However, thenetwork topology varies over time as a result of unstablewireless communications and terminal mobility. In ad hocnetworks, unicast routing protocols such as DSR (dynamicsource routing) [1] and AODV (ad-hoc on-demand distancevector) [2], which establish a specific transmission routebetween a source and a destination before the source initiatesdata transmission, have been proposed. However, they aredesigned to use the established route continuously until the

Manuscript received May 10, 2016.Manuscript revised August 29, 2016.†The authors are with the Department of Communications

and Computer Engineering, Waseda University, Tokyo, 169-8555Japan.††The author is with the Graduate School of Informatics and

Engineering, The University of Electro-Communications, Chofu-shi, 182-8585 Japan.†††The authors are with the Global Information and Telecommu-

nication Institute, Waseda University, Tokyo, 169-8555 Japan.††††The author is with the College of Systems Engineering and

Science, Shibaura Institute of Technology, Saitama-shi, 337-8570Japan.†††††The author is with the Faculty of System Design, TokyoMetropolitan University, Hino-shi, 191-0065 Japan.

a) E-mail: taku_yamazaki@aoni.waseda.jpDOI: 10.1587/transcom.2016CQP0008

route is broken even if a better route exists. Moreover,route re-establishment occurs frequently as a result of linkdisruptions in high mobility or poor wireless environments.

IDMH (Integrated dynamic multi-hopping) [3] hasbeen proposed as a way to adapt to temporary wirelessquality variations. IDMH makes 1-hop detours around adisrupted link and makes 1-hop shortcuts by using routeinformation acquired from the routing protocol upon routeestablishment. However, it requires close cooperation witha datalink protocol, as it modifies the transmission sequenceof that protocol. Moreover, it cannot handle 2-hop detoursor shortcuts since the transmission sequences are mostly foror optimized for the 1-hop case.

Broadcast-based forwarding protocols called OR (op-portunistic routing) have been proposed for more flexiblepacket forwarding [4]. In wireless communications, everyterminal in the sender’s communication range can receivea packet simultaneously because of the broadcast nature ofwireless communications. By exploiting this characteristic,OR protocols can forward packets by using multiple receiversamong neighbours without relying on a specific route. Thus,each receiver should make a forwarding decision based onvarious metrics (e.g. hop count, packet transmission successrate, signal strength, and geographical information). As aresult, it can gain forwarding path diversity and redundancyby selecting eligible forwarders appropriately according tothe metrics.

ExOR (Extremely opportunistic routing) [5], [6]and MORE (MAC-independent opportunistic routing andencoding) [7] that forward a packet based on a prioritydefined by a forwarder list on a packet header have beenproposed. However, they are difficult to adapt to highmobility environments since the forwarder list becomesobsolete immediately.

GeRaF (Geographic random forwarding) [8], [9], whichforwards a packet based on a geographical information, hasbeen proposed as a location based OR protocol. However,GeRaF uses a single path to forward packets, since it selectsa single receiver when it chooses the next-hop receiver byexchanging RTS/CTS messages (request to send/clear tosend). In addition, it requires every terminal to be equippedwith GPS (global positioning system) to acquire positions.Furthermore, it is difficult to track the position accurately invarious environments.

Backoff-based OR protocols [10]–[14] that forwardpackets based on a backoff time derived from hop counts

Copyright © 2017 The Institute of Electronics, Information and Communication Engineers

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING29

have been proposed for ad hoc networks and wireless sensornetworks. They can adapt the terminals’ mobility to updatethe cost information immediately by using received packets.However, they increase the transmission delay since eachpotential forwarder must wait for the expiration of the backofftimer before forwarding packets. Moreover, they cannot gainsufficient path diversity if there is no potential forwarderbetween the source and destination. Thus, their performancestrongly depends on the terminal density and deteriorates ifit is sparse.

In this paper, we propose a novel OR protocolnamed PRIOR (prioritized forwarding for opportunisticrouting). In PRIOR, each forwarder selects a next-hopforwarder called a PF (prioritized forwarder) that forwardsa packet without using a backoff time. In addition, weprovide an optimized backoff time calculation for makingthe backoff time of terminals closest to the destinationshorter as they are to be prioritized for the next-hop.Furthermore, to alleviate the performance degradation insparse environments, we propose a lightweight hop-by-hopautonomous retransmission control based on the neighbourrelation with a PF which is designated by the senderof the packet. In addition, we introduce explicitACK (acknowledgement) to suppress unnecessary packetforwarding on the basis of the differences in hop countsbetween the sender and each receiver.

2. Backoff-Based Opportunistic Routing

This section focuses on backoff-based OR protocols [10]–[14] from the perspective of mobile ad hoc networks. Notethat we will consolidate and/or alter names, formulas, andvariables from those of the original papers in order tomake them apply to mobile ad hoc networks and to makecomparisons of protocols easier.

Backoff-based OR protocols have two routing phases:discovering a destination and forwarding reply packets anddata packets. In this paper, we will call these phasesthe “discovery phase” and “data phase”, respectively. Forrouting, every terminal has a table, called a “cost table”,which has entries that contain at least an address, hop count,sequence number, and lifetime. Each receiver records orupdates the entries of the cost table by using only packetsfrom the reverse path if it is necessary. Therefore, theseprotocols are only good for bidirectional flows. They canadapt the topological changes by using the above mechanismsince each terminal updates the cost information by usingreceived packets.

Discovery phase: If a source does not have a costentry of a destination in its table before the source initiatesthe packet transmission, the source floods request packetstowards the destination. Note that the request packetsmust contain at least a source address, destination address,hop count of the packet traversed, sequence number, andTTL (time to live). When the destination receives the requestpacket, the terminal broadcasts a reply packet back towardsthe source. Here, each receiver performs forwarding in

the same way as data packet forwarding since at least onereverse forwarding path back to the source has already beenestablished during the flooding. Thus, the receivers can makea transition to the data phase to forward the reply packet. Ifthe source has not received any reply packet after a certainperiod, the source starts to flood request packets again. Whenthe count of the request packet flooding reaches a thresholdthat represents the maximum count, the source discards thekept packet since the destination has not been found.

Data phase: After receiving a reply packet or adata packet, each terminal autonomously makes forwardingdecisions based on the backoff time. Here, the reply packetsand data packets contain at least a source address, destinationaddress, hop count to the destination, hop count of thepacket traversed, and sequence number. Upon receivingthese packets, each receiver r calculates the expected hopcount hrd to the destination d and the difference in hopcounts δr ,

hrd = hid − 1 (1)δr = hrd − hrd (2)

where hid denotes the hop count between the previousforwarder i and the destination d that was recorded in thepacket as the hop count to the destination during the previousforwarding. Here, hrd denotes the hop count between thereceiver r and the destination d recorded in receiver r’scost table. Ideally, if the packet only traversed one by onewithout any shortcuts or detours, the hop count hrd in r’scost table will be equal to hid − 1. Namely, hrd will beequal to hrd only under the above condition. Therefore, thereceiver r can estimate how many hops it is to the destinationby calculating the difference in hop counts δr . Here, if δr isequal to 0, it is assumed that the receiver r is 1-hop closerto the destination than the previous forwarder i. Thus, itis estimated that the receiver r is on a regular path. If δrless than 0, it is assumed that the receiver r is closer to thedestination than the terminals on the regular path. Thus,it is estimated that the receiver r is on a |δr |-hop shortcutpath. Otherwise, namely δr more than 0, it is assumed thereceiver r is same hop count as or farther to the destinationthan the previous forwarder i. Thus, it is estimated thatthe receiver r is on a δr -hop detoured path. Therefore,each receiver r calculates a backoff time br based on δrand becomes a potential forwarder. After the calculation, ifthe potential forwarder receives the same packet during thebackoff time, it regards the packet as an implicit ACK andcancels the forwarding because the other terminal alreadyforwarded the packet. The data phase basically follows theabove scheme. However, the details of the conditions dependon each protocol. The details of the backoff time calculationand the specifications of these protocols are described in thefollowing subsections.

2.1 SSR

SSR (Self-selective routing) calculates a backoff time br

30IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

Fig. 1 Examples of backoff time calculation for (a) SSR, (b) SRP, and (c) LFBL.

based on two types of function,

br =

uTssr

1 − δr(δr ≤ 0)(

1 + uδr)Tssr (otherwise)

(3)

where Tssr denotes a scaling factor and u denotes a uniformrandom number drawn from (0, 1). Figure 1(a) showsan example of the backoff time calculation. SSR adds afixed backoff time according to whether δr ≤ 0 or not;hence, it separates potential forwarders into two groups andcalculates br based on the functions for each group. If theforwarder receives the same packet again after forwardingit, the terminal broadcasts an explicit ACK packet at once.If a terminal receives the ACK packet, it cancels its ownpacket forwarding and ignores any subsequent receipt of thesame packet. If the destination receives the data packet, itbroadcasts an explicit ACK packet instead of the data packetin order to suppress unnecessary packet transmissions.

The backoff time calculation of SSR is designed toincrease the forwarding probability of the receiving terminalscloser to the destination. However, the lower bound ofbr remains the same in each group, as can be seen fromFig. 1 (a). Therefore, a potential forwarder cannot alwaysforward a packet even if it is the closest to the destinationamong the group. Moreover, although SSR uses an explicitACK in order to reduce unnecessary packets, its receivercannot know whether or not the sender is closer to thedestination than the receiver. Namely, the packet may notbe forwarded correctly, and it may excessively cancel packetforwarding. Furthermore, SSR has a disadvantage that itsperformance strongly depends on the terminal density. Thatis, if a sparse area exists between the source and destination,there are not enough potential forwarders to gain forwardingpath diversity.

2.2 SRP

SRP (Self-selecting reliable routing protocol) [12] is anenhanced variant of SSR. In SRP, the backoff time br iscalculated as

br =

uTpri (erd = 1)

uTsrp

4(erd = 0 ∧ δr = 0)

(1 + u)Tsrp

4(erd = 0 ∧ δr < 0)

(1 + u)Tsrp

2(erd = 0 ∧ δr = 1)

(4)

where Tpri and Tsrp denote scaling factors, erd indicateswhether the terminal r forwarded the previous packet or not.Here, if erd is equal to 1, r forwarded the previous packet.If erd is not equal to 1, r did not forward the previouspacket. In SRP, the reply and data packets also includea TTL that is set to hsd plus log2 hsd when the source sinitiates transmission. Figure 1(b) shows an example of thebackoff time calculation. If the value of erd that is basedon a result of the previous packet forwarding is equal to 1,the potential forwarder calculates the smallest backoff timeto avoid collisions among terminals (erd = 1). Then, SRPgives each receiver r (δr = 0) the highest priority. UnlikeSSR, the receiver r ignores the packet when the calculated δris larger than 1. In other words, SRP does not take detours ofmore than two hops. Moreover, potential forwarders regard adata packet as an implicit ACK when it receives the same datapacket with a δr greater than 0. After the packet forwarding,the forwarder waits a random backoff time. If it receivesthe same packet during the backoff time, it broadcasts anexplicit ACK packet. Otherwise, it retransmits the packetand re-calculates the random backoff time. After that, if itstill has not received the same packet again, the forwarder rrepairs a forwarding path so as to increase the hop count inits table by 2. Then, if the increased hop count hrd plusthe hop count of the packet traversed is less than TTL, theterminal retransmits the packet with the increased hop count.

SRP also faces the same problem of explicit ACKs asSSR. Moreover, it eliminates detours over two hops ratherthan having a route repair. Although this elimination avoidsexcessive use of detours and may stop unnecessary packetforwarding, it may be difficult to change the forwardingpath immediately. Furthermore, each potential forwarderadds a small backoff time to avoid collisions; SRP makesprioritized forwarding decisions autonomously even thoughsuch decisions are based on the result of the previous packet

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING31

forwarding.

2.3 LFBL

LFBL (Listen first, broadcast later) [13], [14] chooses froma variety of a backoff time calculation methods. The backofftime calculation could be purely random, slotted random,and DVR (distance + variance + random). Note that DVR isnot described in the original paper, and it is difficult to selectan appropriate forwarder in the case of the purely randommethod. Therefore, here, we will describe LFBL based onslotted random method; the backoff time br is calculated as

br =

uTlfbl (δr ≤ 0)

(1 + u) Tlfbl (otherwise)(5)

where Tlfbl denotes a scaling factor. Figure 1(c) shows anexample of this calculation assuming that the upper boundof the backoff time br is equal to 0.5 when δr is equal to 0.To normalize br , Tlfbl is set to 1. The slotted random methodseparates potential forwarders into two groups according toδr . In LFBL, potential forwarders regard a data packet asan implicit ACK when it receives the same data packet withδr > 0. When δr is equal to or less than 0, it re-calculatesbr .

Although LFBL separates potential forwarders into twogroups, the upper and lower bounds of the group are fixed,as can be seen from Fig. 1(c). Therefore, the forwardingdecision of the receiver strongly depends on the randomlygenerated value. In particular, the receiver may not forwardthe packet even when it is the closest to the destination amongthe potential forwarders, and thus, it may not be able tosuppress the hop count and unnecessary packet forwarding.

3. Prioritized Forwarding for Opportunistic Routing

3.1 Concept

Here, we describe our novel OR protocol called PRIOR(prioritized forwarding for opportunistic routing) that is freeof the disadvantages of the previous protocols by introducingan immediate relay. In PRIOR, each forwarder specifies asingle next-hop terminal as a PF (prioritized forwarder) thatforwards a packet without using a backoff time.

In addition, we describe an efficient backoff timecalculation that always prioritizes a terminal closest to thedestination. Moreover, we add a hop-by-hop retransmissioncontrol based on the backoff time to improve link reliabilityin sparse environments that degrade the performance ofconventional OR protocols because of the lack of pathdiversity.

However, a potential forwarder may end up forwardingor retransmitting a packet if it fails to implicitly acknowledgeit because of packet loss. This may consume networkresources and in turn affect performance in dense environ-ments. In particular, the retransmission control in such anenvironment would have a bad effect in terms of network

load. Hence, to prevent network resources from beingexhausted, we introduce an explicit ACK that will be treatedon the basis of the difference in hop counts between thesender and each receiver in order to cancel unnecessarypacket transmissions.

3.2 Opportunistic Routing Using Prioritized Forwarders

As mentioned above, PRIOR uses a PF that is able toforward packets without using a backoff time. The forwarderexplicitly selects a PF from among its neighbours when itforwards a packet and updates the PF address in it. Thus, thePF will be updated every time the packet is forwarded. Thefollowing describes the details of PRIOR.

Requirements: PRIOR requires three conditions: asin the case of the conventional protocols, (1) every terminalonly uses broadcast to eliminate the influence of datalinkprotocols; (2) there are bidirectional flows that allow the costtable to be updated by using reverse path packets. (3) Unlikethe conventional protocols, PRIOR requires a sender addressto forward a packet using PFs. In general, datalink layerprotocols add the sender address to the frame header beforea packet is transmitted. Therefore, each receiver obtainsthe sender address from the datalink layer if it is available.Otherwise, PRIOR adds the sender address to the packetheader before transmission in order to give it to the receivers.

In PRIOR, every terminal has a cost table that containsentries including a destination address, hop count to thedestination, PF address, sequence number, and lifetime. Theupdate of the entry is similar to the conventional one. Notethat each packet is unique to be determined based on apair of the source and sequence number. Figure 2 showsthe flowchart of the packet reception in PRIOR. First, eachterminal checks the following conditions upon receiving arequest, reply, and data packet as follows: (1) the receiver

Fig. 2 Flowchart of the packet reception in PRIOR.

32IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

does not have a cost entry, (2) the receiver has a cost entry, butthe sequence number in its table is smaller than the sequencenumber of the received packet, and (3) the sequence numberin its table is the same as the sequence number of the receivedpacket and the hop count in its table is larger than the hopcount that the packet traversed. If the receiver satisfies anyof the above conditions, the receiver records or updates theentry to the source in its table by using the information in thepacket. Then, the sender is recorded or updated as the PF tothe source. Therefore, PRIOR can also adapt the topologicalchanges by using above mechanism which is similar to theconventional backoff-based OR protocols.

Next, we describe the way of setting PFs in conjunctionwith the discovery phase and the data phase.

Discovery phase: Figure 3 and Fig. 4 show theflowchart of the request phase of a source and the flowchartof a request packet reception respectively. First, if thesource does not have an entry for the destination in itscost table before it initiates packet transmission, it floodsrequest packet towards the destination and waits for the replypacket from the destination. The request packet containsa source address, destination address, sender address (if itis necessary), hop count of the packet traversed, sequencenumber, and TTL. Upon receiving the request packet, thereceiver records or updates the cost entry according to theabove information. Then, if the request packet is new tothe receiver, it rebroadcasts the request packet towards thedestination. Otherwise, it discards the packet in order toavoid unnecessary flooding. When the destination receivesthe request packet, it broadcasts a reply packet towards thesource only once. Here, each receiver of the reply packetmakes a forwarding decision in the same way as in thedata packet forwarding since the reverse forwarding path hasalready been established by the time of the request packetflooding. Therefore, every forwarder shifts to the data phasein order to forward the reply packet. If the source does notreceive any reply packet after a certain time, it floods requestpackets with an increase in the sequence number and TTLin order to expand the flooding area. When the count of therequest packet flooding reaches a threshold that representsthe maximum count, the source discards the kept packet sincethe destination has not been found.

Data phase: Figure 5 and Fig. 6 show the flowchartof a reply and data packet reception and the flowchart of thepacket forwarding. Here, each terminal autonomously makesa forwarding decision upon receiving a reply or data packet.The reply and data packets each contain a source address,destination address, sender address (if it is necessary), PFaddress, hop count to the destination, hop count of the packettraversed, sequence number, and TTL. Note that the sourcesets the TTL to twice the hop count to the destination in orderto tolerate a certain level of bandwidth devouring. Everyterminal performs the forwarding process at once even ifthey receive a duplicated packet.

Figure 7 shows an example of the packet forwardingsequence in PRIOR. Upon receiving a data or reply packet,each receiver checks whether the packet has already been

Fig. 3 Flowchart of the request phase of a source in PRIOR.

Fig. 4 Flowchart of the request packet reception in PRIOR.

received or not. If it has not, the receiver checks thefollowing two conditions. (1) If the sender coincides withthe receiver’s PF, the receiver ignores the packet since itmay cause a forwarding loop and the sender regards itself asineligible to forward. Since then, it ignores the same packet.(2) If the receiver coincides with the PF in the packet, itforwards the packet without using a backoff time since thesender regards the receiver as the appropriate terminal toforward the packet to the destination. If the receiver satisfiesneither (1) nor (2), it becomes a potential forwarder andwaits a backoff time br . The details of the backoff timecalculation can be found in Sect. 3.3. When the potentialforwarder receives the same packet during the backoff time,

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING33

Fig. 5 Flowchart of the reply packet or data packet reception in PRIOR.

it calculates δr according to Eq. (2). If δr is larger than 0,the potential forwarder regards the packet as an implicit ACKand cancels its own forwarding. Otherwise, it ignores thepacket. Note that if the terminal A and terminal B are notwithin the communication range each other, both terminalforward the packet redundantly since they cannot sense oneanother’s packet forwarding. To solve this, we introduce anexplicit ACK to cancel the unnecessary packet forwarding.The details of the explicit ACK can be found in Sect. 3.6.

Figure 8 shows an example of the established forward-ing path as simulated by the network simulator, QualNet [15].The simulation generated a single bidirectional flow. Thefigure shows the established forwarding path after 10 secondshad elapsed. The terminals have the next-hop PF and the hopcounts are distributed; hence they are able to make a flexibleforwarding decision by selecting the PF from the neighboursof the forwarder.

3.3 Backoff Time Calculation

In the conventional protocols, each receiver calculates thebackoff time for the terminal closest to the destinationto prevent collisions or gain diversity from the next-hopterminal before it forwards packets. However, doing so may

Fig. 6 Flowchart of the reply packet or data packet forwarding in PRIOR.

Fig. 7 Example of forwarding sequence in PRIOR.

Fig. 8 Forwarding path example.

34IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

Fig. 9 Concept of backoff time calculation in PRIOR.

enlarge the hop count and increase unnecessary forwardingsince multiple terminals may be able to forward the packettowards the next-hop within the backoff time. Thus,we propose a novel backoff time calculation mechanismthat autonomously prioritizes the terminal closest to thedestination among the potential forwarders to make the delayas short as possible.

Figure 9 shows the concept of the backoff timecalculation in PRIOR. In general, we assume that datapackets are forwarded bidirectionally between the sourceand destination in a dense environment. In other words,we assume that every terminal has sufficient opportunity toupdate their cost entries accurately according to topologicaland radio environmental changes. Accordingly, we expectthat forwarders directly and stably communicate with theirneighbours. In this situation, when a sender i transmitsa packet, a receiver r calculates δr by using hid of thereceived packet and its hrd . If the receiver r is a neighbourof the sender i, the receiver r has hrd in a range ofhid − 1 ≤ hrd ≤ hid + 1. The receiver r subtracts hrdfrom hid − 1 to calculate δr according to Eq. (2). Therefore,receiver r calculates δr in the range of 0 ≤ δr ≤ 2. Note thatthere may be some cases in which a packet is forwarded via ashortcut path or takes a detour of over three hops because oftemporary factors such as a brief improvement in the radioenvironment. We regard such cases as non-neighbour onesin which δr < 0 or δr > 2. Hence, if receiver r calculatesa δr in the range of 0 ≤ δr ≤ 2 when it receives a packet,it received that packet with a higher probability than thoseof the terminals that calculate a δr in the range of δr < 0or δr > 2. Therefore, the joint reception probability thatthe packet is simultaneously received by multiple terminalswith the same δr range 0 ≤ δr ≤ 2 will also be muchhigher than the joint reception probability that the packet issimultaneously received by terminals with ranges δr < 0 orδr > 2. In contrast, when the simultaneous packet receiptsfrom multiple terminals which calculate the same δr in arange of δr < 0 or δr > 2, their joint reception probabilityof the packet is much lower than the one ranges 0 ≤ δr ≤ 2.

Therefore, to reduce collisions, a receiver r with 0 ≤δr ≤ 2 requires a large window for the random backoff time.In contrast, a receiver with δr < 0 or δr > 2 does not requirea large window since the chance of a collision is not as large.

Fig. 10 Example of backoff time calculation in PRIOR (Tmax = 1.0).

In light of the above characteristics, r calculates a fixedbackoff time based on a sigmoid function that converges to 0or 1 by respectively decreasing or increasing δr , and it addsa random backoff time based on the change in the sigmoidfunction. The fixed backoff time ςr (δr ) is calculated as

ςr (δr ) =1

1 + exp(−α (δr − β)) (6)

where α denotes the gain of ςr (δr ) and β is a parameterto shift the inflection point. r calculates a fixed backofftime ςr (δr ) that determines the priority based on the sigmoidfunction according to δr . Namely, ςr (δr ) is a lower boundof the backoff time for each δr . Moreover, r adds a randombackoff time to the fixed backoff time according to thechange in the function. The random backoff time µr (δr )is calculated as

µr (δr ) = u(ςr (δr + γ) − ςr (δr )

)(7)

where γ denotes the boundary between slots. u denotesa uniform random number of (0, 1). The random backofftime µr (δr ) is based on the difference between ςr (δr + γ)and ςr (δr ). Therefore, ςr (δr ) plus µr (δr ) will always besmaller than ςr (δr + 1). By using ςr (δr ) and µr (δr ), thebackoff time br is calculated as

br = Tmax

(ςr (δr ) + µr (δr )

)(8)

where Tmax denotes the maximum backoff time. Finally,the receiver r calculates the backoff time br by computingthe product of the scaling factor Tmax and the sum of thefixed backoff time ςr (δr ) and µr (δr ). Figure 10 shows anexample of this calculation, assuming that the upper boundof the backoff time br is equal to 0.5 when δr = 0 under thecondition α = β = γ = 1.

Note that the backoff time calculation of PRIOR isversatile even though only a hop count is taken into aconsideration as a metric. This is because a sigmoid functioncan take not only a discrete value such as the hop count,but also a continuous value. Moreover, the backoff timecalculation can be made to work with metrics that havedifferent ranges of δr simply by changing the followingparameters; gain α, inflection point β, and boundary γ.

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING35

Fig. 11 Update procedure of prioritized forwarder for the current path.

Fig. 12 Update procedure of prioritized forwarder for the reverse path.

3.4 Updating Prioritized Forwarders

In PRIOR, each forwarder always requires the next-hop PFto be in a suitable position between it and the destination.However, in mobile environments, the PF may go out ofthe previous hop forwarders’ communication range or moveto an ineligible position for packet forwarding due to thetopological changes. To deal with such topological changes,PRIOR adaptively changes the PFs by determining whetherthe packet was forwarded by the PF or not. Figure 11 andFig. 12 show examples of PF updates. Note that these updatesequences are applied to a specific sequence number andsource address pair only once.

Figure 11 shows an example of the update procedure ofPF for the current path. First, when the forwarder receivesthe forwarded packet, it checks whether the packet wasforwarded by the PF or not. If the PF forwarded the packet,the forwarder does nothing. If the PF did not forward thepacket, the forwarder changes the PF to the next forwarderof the received packet. Figure 12 shows an example ofthe update procedure of the PF for the reverse path. Whenthe terminal receives the packet, it checks the sender of thepacket. If the packet was forwarded by the PF of the reversepath, in other words, the PF to the source, the terminal doesnothing. Otherwise, the terminal changes the PF to thesource to the sender of the received packet.

Note that PRIOR may degrade the performance inhigh mobility environments since PFs become obsolete ina short time. Therefore, we evaluate the performance in highmobility by using computer simulations in Sect. 4.

3.5 Hop-by-Hop Retransmission Control

In conventional OR protocols, if the network is sparse or localsparse areas exist in a forwarding path, it cannot gain path

Fig. 13 Retransmission terminal restriction based on neighbour relationswith PFs.

diversity since they cannot establish multiple forwardingpath simultaneously. To assist the packet forwarding in suchsparse environment, PRIOR uses a retransmission controlbased on the neighbour relation with the PF of the receivedpacket.

Figure 13 shows an example of the retransmissionterminal restriction based on neighbour relations. First, theforwarder checks the neighbour relation with the PF of thereceived packet after the packet has been forwarded. Then, ifthe forwarder is the PF, it initiates a retransmission control. Ifthe forwarder is a neighbour of the PF and its δr is the sameas or smaller than 1, it initiates a retransmission control.Then, the terminal checks the cost entry of the PF on itstable. If the hop count to the PF is 1, it regards the PF asa neighbour. Otherwise, the terminal r does not initiate theretransmission control and discards the kept packet. Theforwarder that initiates a retransmission control calculatesthe retransmission backoff time cr as follows:

cr = br + ϵTmax (9)

where ϵ denotes an interval to wait to receive a packet.Note that ϵ should be set to large enough value to avoid aninterference with the last packet forwarding. If the forwarderreceives the same packet before the timer expiration, theforwarder r calculates δr . If δr is equal to or less than 0,the forwarder r regards the packet as an implicit ACK andfinishes the retransmission control. If r has not receivedthe same packet during cr , it regards the absence as aloss and retransmits the packet. After that, r increasesthe retransmission count and re-calculates cr . Then, if theretransmission count reaches a threshold that represents themaximum retransmission count, the terminal finishes theretransmission control and discards the kept packet.

3.6 Hop Count Based Explicit Acknowledgement

In backoff-based OR protocols, a forwarder acknowledgesa received packet only when it receives duplicate packetssent by multiple senders. However, if the forwarder failsto receive duplicated packets, the terminal forwards orretransmits the packet, and this consumes network resources.SSR and SRP solve this problem by using explicit ACKs.However, this has a disadvantage that all receivers that

36IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

Fig. 14 Explicit acknowledgement for backward area terminals.

Fig. 15 Explicit acknowledgement for an isolated terminal.

include a next-hop forwarder cancel packet forwarding evenif the next-hop forwarder has not succeeded in forwardingthe packet to the other terminal. Therefore, it may cause adeadlock.

To overcome the disadvantages of the former explicitACKs, we introduce an explicit ACK mechanism into PRIORconsidering the hop count to the destination to suppressunnecessary packet forwarding and retransmissions. InPRIOR, an ACK packet consists of a source address,destination address, hop count to the destination, andsequence number. Figure 14 and Fig. 15 show examplesof an explicit ACK packet transmission. Note that to makethem easier to read, these figures do not show all of thearrows to the terminal that represent completed forwarding.

Figure 14 shows an example of an explicit ACK packettransmission for backward area terminals. If a terminalreceives the same packet after the packet was forwarded, ittransmits an explicit ACK packet and the receiver r calculatesδr . If δr is larger than 0, it cancels the forwarding andperforms no more forwarding. If δr is equal to or less than 0,the terminal ignores the ACK packet. When the destinationreceives the data packet, the destination always broadcaststhe explicit ACK packet even if the destination has alreadyreceived the packet.

Figure 15 shows an example of explicit ACK packettransmission for an isolated terminal. During the packetretransmission, if all of the neighbours have finishedforwarding the same packet, the packet will never beforwarded again. As a result, the forwarder misunderstandsthat the packet is lost and retransmits it again. Therefore, a PFtransmits an explicit ACK packet if it receives a packet thathas already been acknowledged. By receiving the explicitACK packet, the previous forwarder can acknowledge thepacket even if all of the neighbours have already forwardedit.

4. Performance Evaluation

4.1 Simulation Setup

The computer simulation evaluated the performance ofAODV, SSR, SRP, LFBL, and PRIOR. Note that in whatfollows, we call PRIOR with the explicit ACK PRIOR-E.

Common environment: We used QualNet [15] as anetwork simulator. Terminals were placed randomly in a1,000 m × 1,000 m simulation area. Every terminal usedIEEE 802.11b and disabled RTS/CTS. Their transmissionrates were set to 11 Mbps, and the communication rangewas set to approximately 150 m. We generated a singlebidirectional traffic using UDP (user datagram protocol) andchose a pair of terminals randomly chosen from all of them.The pair transmitted 1 Mbyte data consisting of one thousand1 kbyte packets each other. We performed simulations withand without the retransmission control. Although AODVdoes not have a retransmission control function, it can usethe built-in ARQ of IEEE 802.11MAC [16]. SSR andLFBL also do not have retransmission control function andonly use broadcast, which cannot be applied to ARQ inIEEE 802.11 MAC. Thus, SSR and LFBL cannot use theretransmission control. Furthermore, although SRP has aretransmission control function, it must be combined with aroute repair. Therefore, as recommended in the paper [12],we set the maximum retransmission count n to 2 for SRP.Meanwhile, AODV, PRIOR, and PRIOR-E can change themaximum retransmission count n; for them, we set n to 0, 1,and 3. The maximum count of the request packet floodingis 5. Each cost entry timeout was set to 3 seconds. Tssrand Tlfbl were set to 2.5 ms. Tpri was set to 0.5 ms. Tsrpand Tmax were set to 5 ms. In PRIOR, α and γ are setto 1 since this avoids overlapping backoff time ranges foreach δr . To maximize the amount of random backoff time,β was set to 0.5. ϵ was set to 3 since it avoids interferencewith the current packet forwarding. Note that the parametersused for calculating the backoff time are different from thoseof the original papers [10]–[13]. In [10]–[12], SSR andSRP were evaluated by using Tssr and Tsrp of tens of or ahundred milliseconds in low throughput environments; theirsimulations were supposed to be of fixed ad hoc sensornetworks. In [13], LFBL was evaluated by using a Tlfblof a few milliseconds in high throughput environments; thesimulations in this case were supposed to be of mobile adhoc networks. Therefore, we chose the parameters such thatthe backoff time would be a few milliseconds.

Simulation 1: This simulation evaluated the impact ofvarying the terminal density on the performance. A randomwaypoint mobility model was used, and the moving speedwas randomly chosen from 0 m/s to 10 m/s without using awaiting time. The number of terminals was varied from 20to 200 in steps of 20.

Simulation 2: This simulation evaluated the impact ofchanging the mobility on performance. A random waypointmobility model was used, and the moving speed was fixed

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING37

Fig. 16 Results of simulation 1: (a) packet transmission success rate, (b) average hop count, (c) averageend-to-end delay, and (d) total number of transmitted packets.

without using a waiting time. The moving speed was variedfrom 0 m/s to 20 m/s in 2 m/s steps.

We evaluated the protocols in terms of their (a) packettransmission success rate, (b) average hop count, (c) averageend-to-end delay, and (d) total number of transmitted packets.Note that we did not include out of order packets in thesimulation results.

4.2 Simulation Results

Simulation 1Figures 16(a)–(d) show the results of simulation 1.

Figure 16(a) shows that the packet transmission successrates of AODV, SSR, and SRP are lower than those of theother protocols. Since AODV only uses a single path, itis difficult for it to improve the packet transmission successrate even if the terminal density increases. Although thepacket transmission success rates of SSR and SRP improveas the terminal density increases, they do not exceed thoseof LFBL, PRIOR, or PRIOR-E. This is because they usean explicit ACK that indiscriminately cancels all packetforwarding within the ACK sender’s range. Thus, the explicitACK excessively cancels packet forwarding and impairs pathdiversity in a way that affects the packet transmission successrate. LFBL, PRIOR (n = 0), and PRIOR-E (n = 0) havehigher packet transmission success rates compared AODV,SSR, and SRP. In particular, LFBL and PRIOR (n = 0)have higher success rates than PRIOR-E (n = 0). LFBLand PRIOR do not rely on an explicit ACK in contrast toSSR and SRP and they restrict the implicit ACK conditionwhen terminals receive the same packet again. Hence, each

potential forwarder can get more opportunities to forwardpackets. By contrast, PRIOR-E (n = 0) slightly decreasesthe packet transmission success rate. As a result, theexplicit ACKs of PRIOR-E may cancel necessary packetforwarding even though they prevent excessive cancellationsfrom occurring by considering the hop count. PRIOR (n =1, 3) and PRIOR-E (n = 1, 3) achieve the highest packettransmission success rates among the protocols for anyterminal density. In a sparse environment, not everyterminal has enough neighbours within their communicationrange to gain forwarding path diversity. Nevertheless,PRIOR (n = 1, 3) and PRIOR-E (n = 1, 3) increasethe packet transmission success rate by improving thelink reliability using a retransmission control since theretransmission control behaves like conventional link-layerARQ to recover the lost packet even if nobody forwards thetransmitted packet. However, the hop-by-hop retransmissioncontrol fails to have its advantage in the extremely sparseenvironment such as the network with 20 terminals. Thisis because that the terminals are too few to establishforwarding path. Therefore, it is difficult to improvethe performance in such environment. In addition, thehop-by-hop retransmission control improves the packettransmission success rate as well in the dense environment.This is because that local sparse areas may be exist due tothe biases of the terminals’ position even if the networkis dense. Therefore, the retransmission control easesthe influence of the bottle-neck by assisting the packetforwarding in such area. PRIOR (n = 3) slightly decreasesthe packet transmission success rate when there are 200terminals. This is because that each terminal only cancels

38IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

packet forwarding by receiving the same packet once again,since PRIOR disables explicit ACKs. Thus, it increasesmisunderstandings in the handling of the received packetand increases unnecessary packet forwarding. Therefore, ina dense environment, PRIOR ends up decreasing the packettransmission success rate as it consumes network resources.On the other hand, PRIOR-E (n = 1, 3) does not degradethe performance in a dense environment since it cancelsunnecessary packet forwarding and decreases the networkload to use explicit ACKs.

Figure 16(b) shows that AODV has the lowest hopcount among the protocols. AODV forwards a packetalong a single path that is established the shortest pathfirst manner; thereby, it shortens the hop count more thanOR protocols do. SSR, SRP, and PRIOR-E also achieve alower hop count than LFBL and PRIOR do, since they cancancel unnecessary detours by using an explicit ACK. Inparticular, PRIOR-E significantly decreases the hop countcompared with PRIOR without there being a large impacton its packet transmission success rate. This is becauseit becomes easier to acknowledge packets accurately sinceit uses an explicit ACK based on the difference in hopcounts. Moreover, we can see that the increase in thehop count is slightly smaller when using the retransmissioncontrol. This also happens with an appropriate eliminationof unnecessary retransmissions. On the other hand, LFBLhas the highest hop count among the protocols in anysituation. As mentioned above, this is because it doesnot rely on an explicit ACK and restricts an implicit ACKcondition. Therefore, LFBL unnecessarily increases thehop count because it is difficult for it to cancel the packetforwarding appropriately. PRIOR (n = 3) has the highesthop count among the protocols except LFBL in the denseenvironment. PRIOR does not cancel packet forwardingand retransmissions appropriately in dense environmentsbecause it does not use explicit ACKs. Therefore, it mayincrease collisions and unnecessary packet forwarding dueto the larger number of hops count caused by the detoursaround the congested area.

Figure 16(c) shows that AODV has a stable transmissiondelay for any terminal density. AODV does not require oneto use a backoff time; thereby, it can suppress increasesin the delay as much as possible. However, the delay isrelatively larger when the number of terminals is 80 to 200terminals. This is because AODV requires a lost packet to beretransmitted after the backoff time of the link-layer ARQ.Moreover, when several packets get lost, it must re-establishthe path and this also increases the delay. On the other hand,OR protocols can forward packets autonomously withoutretransmission and route re-establishment. Therefore,the delay is relatively shorter than that of AODV. SSR,PRIOR (n = 0), and PRIOR-E (n = 0, 1, 3) clearly decreasethe transmission delay when the number of terminals is 60to 200 terminals. In particular, SSR has a slightly lowertransmission delay than PRIOR-E has. This is becauseSSR indiscriminately cancels packet forwarding by usingthe explicit ACK, and it gives a large backoff time to detour

terminals. Hence, SSR decreases the transmission delaysince the detour happens in a limited situation. PRIOR andPRIOR-E use PFs and a backoff time calculation that alwaysprioritizes a closest terminal to the destination. Hence,it decreases the transmission delay without decreasing thepacket transmission success rate as it improves the forwarderselection and decreases the delay on each hop caused by thebackoff time. However, the OR protocols has much longerdelay when the number of terminals is 20 terminals. Notethat we have excluded the results of the OR protocols thathave several hundred milliseconds delay when the numberof terminals is 20 terminals for improving the visibility ofthe result. As mentioned above, they have the lower packettransmission success rate than that of dense environment,and several packets sometimes reach the destination withlarge delay due to some temporary factors such as detouringwhen they establish an inappropriate forwarding path unlikeAODV that establishes shortest-path manner. Therefore, oneof the advantage of the OR protocols, namely path diversity,cannot perform the potentials of reliability improvement andshortening of delay. Thus, this fact increases the end-to-enddelay of the OR protocols compared with AODV especiallyin the extremely sparse environment.

Figure 16(d) shows that AODV (n = 3) has thesmallest number of transmitted packets in among theprotocols in a dense environment since AODV only usesa single forwarding path unlike the OR protocols. Onthe other hand, LFBL and PRIOR (n = 3) has thelargest number of transmitted packets. This is becausethat LFBL and PRIOR do not rely on an explicit ACK.Thus, they increase unnecessary packet forwarding sincethey increase misunderstandings in the handling of receivedpackets. Although PRIOR-E (n = 1, 3) has larger numberof transmitted packets than AODV, SSR, and SRP, it hasmuch smaller number of transmitted packets than LFBL andPRIOR (n = 1, 3). In addition, it has much higher packettransmission success rate than SSR, SRP, and AODV as canbe seen in Fig. 16(a). Therefore, PRIOR-E achieves boththe high packet transmission success rate and small numberof transmitted packets by using hop-by-hop retransmissioncontrol and an explicit ACK.

Simulation 2 Figures 17(a)–(d) show the results ofsimulation 2. Figure 17(a) shows that AODV fairly preventsthe degradation of the packet transmission success rateeven if the topology is changed. This is because AODVimmediately re-establishes the route by using neighbourswhen a forwarder fails the packet transmission in such amiddle density environment. Also, all of the OR protocolsare practically unaffected by the moving speed, because theycan adaptively change the forwarding path according to thetopology in terms of the packet transmission success rate. Inparticular, PRIOR (n = 1, 3) and PRIOR-E (n = 1, 3) achievethe highest packet transmission success rates among theprotocols at any moving speed. Therefore, it is consideredthat they can adapt to fast topological changes with adaptivePF selection during forwarding. Meanwhile, most of theprotocols decrease the packet transmission success rate in a

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING39

Fig. 17 Results of simulation 2: (a) packet transmission success rate, (b) average hop count, (c) averageend-to-end delay, and (d) total number of transmitted packets.

low mobility environment. This is because that the resultsof simulation 2 were strongly affected by the randomlygenerated topology in such an environment. Thereby, ifthe positions of the terminals are biased, the end-to-end pathmay include sparse areas where the protocols cannot performto their maximum potential in terms of path diversity.

Figure 17(b) shows that, as in simulation 1, AODVachieves the smallest hop count of all protocols. All of theOR protocols increase the hop count in the low mobilityenvironment. As mentioned above, their results are stronglyaffected by the topology in the low mobility environment.However, they can eliminate the biases of the terminalposition by using multiple detour paths. The hop countsof PRIOR and PRIOR-E are relatively higher than thoseof SSR and SRP in the high mobility environment. Thereason is that PFs become obsolete in a short time in such anenvironment, and this increases unnecessary detours.

Figure 17(c) shows that AODV (n = 0, 1) increasesthe end-to-end delay in the low mobility environment. Thisis because that AODV often re-establishes routes causedby transmission failures due to the low link reliabilitywhen the end-to-end distance is long. As mentionedabove, AODV uses the hop count for the metric of routeselection based on the shortest path first manner withoutconsidering each link reliability. Hence, although the hopcount becomes smaller, each link reliability becomes worsebecause each distance between forwarders might becomelonger. When the mobility is low, the end-to-end distancebetween the source and destination depends on an initialtopology since the topology will not change in a short time.Therefore, AODV happens to increase the delay by the route

re-establishment due to the transmission failures that arecaused by the low link reliability derived from the topologicalissue. However, in AODV (n = 3), the end-to-end delaydecreases since each link reliability becomes better. On theother hand, backoff-based OR protocols have lower delayto autonomously select the forwarding path time to timewithout the route re-establishment though they increase thehop count. SRP has the lower transmission delay in the highmobility environment. As SRP eliminates 2-hop detours andit repairs a route only when it becomes necessary, it decreasesthe transmission delay by suppressing long detours. Bycontrast, PRIOR and PRIOR-E have the lowest delay in thelow mobility environment since they reduce the backoff delayby using PFs. Moreover, they have lower delays than LFBLdoes even when mobility is high.

Figure 17(d) shows all of the protocols slightly increasethe total number of transmitted packets with the increaseof the moving speed. This is because they may sometimesfail to forward packets due to a mismatch between the costinformation of forwarders and the actual topology caused bythe topological changes. In AODV, the transmission failuresmay cause the route re-establishments and increase of theadditional packets. In OR protocols, due to above reason,forwarders may transmit unnecessary packets and increasesthe data packets.

5. Conclusion

We proposed a novel OR protocol called PRIOR thatuses a PF and considers the neighbours of the PF ina more efficient backoff time calculation based on a

40IEICE TRANS. COMMUN., VOL.E100–B, NO.1 JANUARY 2017

sigmoid function. Moreover, we integrated a hop-by-hopretransmission control into PRIOR in order to mitigate theeffect of terminal density. In addition, to solve the problemsof backoff-based OR protocols, we proposed an extension ofthe explicit ACK that is based on the difference in hop countsbetween the forwarder and its neighbours.

We evaluated the proposed method in computersimulations. The results indicated that PRIOR and PRIOR-Eare more efficient and flexible than existing alternativesat forwarder selection in fixed and mobile environments.They also show that the hop-by-hop retransmission controlcontributes to improving the end-to-end packet transmissionsuccess rate in most situations and mitigates the effect ofterminal density. We indicated that a suitable combinationof OR and hop-by-hop retransmission control can extend theapplication range of an OR in order to reduce the effect ofterminal density.

In this study, we evaluated the performance of theprotocols only by the primitive simulations. To simulatemore practical situation, the collisions among several flowsand the congestions must be considered. However, we cansee that PRIOR achieves both the high packet transmissionsuccess rate and the low network load comparing with theconventional protocols. Therefore, it is assumed that PRIORhas tolerance against the network congestions. Hence, theeffectiveness of PRIOR in the congested situations should bestudied. In addition, we chose the hop count as the metricand devised a flexible backoff time calculation. In the future,the potential of using other metrics should be studied.

Acknowledgements

This work was supported by JSPS KAKENHI Grant Number15K15978.

References

[1] D. Johnson, Y. Hu, and D. Maltz, “The dynamic source routingprotocol (DSR) for mobile ad hoc networks for IPv4,” IETF, RFC4728, Feb. 2007.

[2] C.E. Perkins and E.M. Royer, “Ad-hoc on-demand distance vectorrouting,” Proc. 2nd IEEE Workshop on Mobile Comput. Syst. andApplications (WMCSA 1999), New Orleans, USA, pp.90–100, Feb.1999.

[3] Y. Matsuzawa, Y. Yamao, K. Otake, and K. Ishibashi, “Multi-hoptransmission performance of integrated dynamic multi-hopping forwireless ad hoc networks,” Proc. 11th IEEE Consumer Commun.and Netw. Conf. (CCNC 2014), Las Vegas, USA, pp.635–640, Jan.2014.

[4] H. Liu, B. Zhang, H.T. Mouftah, X. Shen, and J. Ma, “Opportunisticrouting for wireless ad hoc and sensor networks: Present and futuredirections,” IEEE Commun. Mag., vol.47, no.12, pp.103–109, Dec.2009.

[5] S. Biswas and R. Morris, “Opportunistic routing in multi-hopwireless networks,” SIGCOMM Comput. Commun. Rev., vol.34,no.1, pp.69–74, Jan. 2004.

[6] S. Biswas and R. Morris, “ExOR: Opportunistic multi-hop routingfor wireless networks,” SIGCOMM Comput. Commun. Rev., vol.35,no.4, pp.133–144, Oct. 2005.

[7] S. Chachulski, M. Jennings, S. Katti, and D. Katabi, “Tradingstructure for randomness in wireless opportunistic routing,”

SIGCOMM Comput. Commun. Rev., vol.37, no.4, pp.169–180, Oct.2007.

[8] M. Zorzi and R.R. Rao, “Geographic random forwarding (GeRaF)for ad hoc and sensor networks: Multihop performance,” IEEE Trans.Mobile Comput., vol.2, no.4, pp.337–348, Oct.–Dec. 2003.

[9] M. Zorzi and R.R. Rao, “Geographic random forwarding (GeRaF)for ad hoc and sensor networks: Energy and latency performance,”IEEE Trans. Mobile Comput., vol.2, no.4, pp.349–365, Oct.–Dec.2003.

[10] G.G. Chen, J.W. Branch, and B.K. Szymanski, “Self-selectiverouting for wireless ad hoc networks,” Proc. IEEE Int. Conf. Wirelessand Mobile Coput., Netw. and Commun. (WiMob 2005), Montreal,Canada, pp.57–64, Aug. 2005.

[11] G.G. Chen, J.W. Branch, and B.K. Szymanski, “A self-selectiontechnique for flooding and routing in wireless ad-hoc networks,” J.Netw. Syst. Manag., vol.14, no.3, pp.359–380, Sept. 2006.

[12] E. Gelenbe, P. Liu, B.K. Szymanski, and C. Morrell, “Cognitive andself-selective routing for sensor networks,” Comput. Manag. Sci.,vol.8, no.3, pp.237–258, Aug. 2011.

[13] M. Meisel, V. Pappas, and L. Zhang, “Listen first, broadcast later:Topology-agnostic forwarding under high dynamics,” Proc. AnnualConf. Int. Tech. Alliance (ACITA 2010), London, UK, Sept. 2010.

[14] M. Meisel, V. Pappas, and L. Zhang, “Ad hoc networking via nameddata,” Proc. 5th ACM Int. Workshop on Mobility in the EvolvingInternet Architecture (MobiArch 2010), Chicago, USA, pp.3–8, Sept.2010.

[15] QualNet, website. http://web.scalable-networks.com/qualnet-network-simulator

[16] ANSI/IEEE Std. 802.11, “Wireless LAN medium access control(MAC) and physical layer (PHY) specification,” March 2012.

Taku Yamazaki received the B.E. and M.S.degrees in electronic information systems fromShibaura Institute of Technology, Tokyo, Japan,in 2012 and 2014, respectively. He is presently aresearch associate and doctoral course studentat the Department of Communications andComputer Engineering, Waseda University.

Ryo Yamamoto received the B.E. and M.E.degrees in electronic information systems fromShibaura Institute of Technology, Tokyo, Japan,in 2007 and 2009, respectively. He receivedD.S. in global telecommunication studies fromWaseda University, Tokyo, Japan, in 2013. Hewas a research associate at Graduate Schoolof Global Information and TelecommunicationStudies, Waseda University, from 2010 to 2014,and has been engaged in researching in wirelesscommunication networks. He is presently an

assistant professor at Graduate School of Informatics and Engineering, theUniversity of Electro-Communications.

YAMAZAKI et al.: PRIOR: PRIORITIZED FORWARDING FOR OPPORTUNISTIC ROUTING41

Takumi Miyoshi received the B.E., M.E.,and D.E. degrees in electronic engineering fromthe University of Tokyo, Tokyo, Japan, in1994, 1996, and 1999, respectively. He wasa visiting associate from 1994 to 1996 and anInternet technical staff from 1996 to 1997 at theInstitute for Monetary and Economic Studies,Bank of Japan. He was also a research associateat Global Information and TelecommunicationInstitute, Waseda University, from 1999 to 2001,and a research fellow at Telecommunications

Advancement Organization of Japan from 1998 to 2003. He was a visitingscholar at Laboratoire d’Informatique de Paris 6 (LIP6), UPMC SorbonneUniversités (Paris 06), Paris, France, from 2010 to 2011. He is presentlya professor at Department of Electronic Information Systems, Collegeof Systems Engineering and Science, Shibaura Institute of Technology,Saitama, Japan.

Takuya Asaka received his B.E. and M.E.degrees in industrial and management systemengineering from Waseda University in 1988and 1990, respectively, and Ph.D. degree inglobal information and telecommunication fromWaseda University in 2001. He joined NTTLaboratories in 1990. He was also a researchfellow at Telecommunications AdvancementOrganization of Japan and a visiting researcherat Global Information and TelecommunicationInstitute, Waseda University from 1998 to 2000.

His research interests include performance evaluation of communicationnetworks and traffic control. He was an associate professor at GraduateSchool of Informatics, Kyoto University. He is currently a professor atFacluty of System Design, Tokyo Metropolitan University. He is a memberof IEEE, IPSJ and the Operations Research Society of Japan.

Yoshiaki Tanaka received the B.E., M.E.,and D.E. degrees in electrical engineering fromthe University of Tokyo, Tokyo, Japan, in 1974,1976, and 1979, respectively. He became astaff at Department of Electrical Engineering,the University of Tokyo, in 1979, and hasbeen engaged in teaching and researching in thefields of telecommunication networks, switchingsystems, and network security. He was a guestprofessor at Department of CommunicationSystems, Lund Institute of Technology, Sweden,

from 1986 to 1987. He was also a visiting researcher at Institute for Postsand Telecommunications Policy, from 1988 to 1991, and at Institute forMonetary and Economic Studies, Bank of Japan, from 1994 to 1996. Heis presently a professor at Department of Communications and ComputerEngineering, Waseda University.