Beacon-less geographic multicast routing in a real-world wirelesssensor network testbed

Juan A. Sanchez • Rafael Marin-Perez •

Pedro M. Ruiz

Published online: 15 February 2012

� Springer Science+Business Media, LLC 2012

Abstract We study the problem of geographic multicast

routing (GMR) in a wireless sensor network. In particular,

we are interested in geographic routing solutions with a

very limited control overhead and overall bandwidth con-

sumption. Existing GMR protocols require nodes to peri-

odically exchange beacon messages to gather information

about the position of their neighbors. These beacons

represent a waste of resources, specially in areas of the

network with no active communications. Beacons also

induce significant problems in real deployments such as

interferences and collisions that cause inconsistencies in

neighboring tables. In this paper we propose a new beacon-

less geographic multicast routing protocol called BRUMA.

Unlike previous solutions, BRUMA uses the propagation

of data packets to opportunistically select next hops among

those that are reachable from the sending node. In addition,

we contribute a novel next hop selection function by which

candidate next hops schedule their responses based on their

progress along each of the branches of the multicast tree.

This allows the protocol to overcome most of the issues of

beacon-based solutions in real deployments such as colli-

sions, low-quality links, etc. The results of our empirical

tests in a real testbed as well as in simulations show that

BRUMA achieves a higher packet delivery ratio and a

lower overall bandwidth consumption than GMR, which is

the protocol performing best among existing geographic

multicast solutions.

Keywords Beacon-less � Multicast � Geographic �Localized � Routing

1 Introduction

A wireless sensor network (WSN) consists of a set of

autonomous devices commonly known as sensor nodes.

They are equipped with short-range wireless interfaces and

hardware for monitoring environmental parameters such

as humidity, pressure, temperature, etc. WSNs use multihop

communications to enable the delivery of data packets

among nodes which are not within radio range. The appli-

cations of WSNs are endless, including among others

monitoring, distributed control, etc. Most WSN applications

make extensive use of one-to-many ore many-to-one com-

munications. Therefore, the design of efficient multicast

routing protocols is of paramount importance to support the

distributed operation of WSNs.

It is now widely accepted that routing protocols used in

MANETs are not appropriate for WSNs [12] whereas the

localized operation of geographic routing algorithms [8]

perfectly suits the requirements of WSNs. Most geographic

multicast routing (GMR) protocols in the literature are

based on extensions of greedy-face-greedy [2] (GFG), a

very well-known geographic unicast routing algorithm.

Position based multicast (PBM) [13] was the first geo-

graphic multicast protocol proposed, then GMR [17] solved

some scalability problems of PBM while achieving better

results in terms of bandwidth consumption.

Most geographic unicast routing protocols and all of the

geographic multicast ones assume that nodes get to know

J. A. Sanchez (&) � R. Marin-Perez � P. M. Ruiz

DIIC, Facultad de Informatica, University of Murcia,

Campus de Espinardo s/n, 30100 Murcia, Spain

e-mail: jlaguna@dif.um.es

R. Marin-Perez

e-mail: rafael81@dif.um.es

P. M. Ruiz

e-mail: pedrom@dif.um.es

123

Wireless Netw (2012) 18:565–578

DOI 10.1007/s11276-012-0419-2

their neighbor’s positions by using beacon messages.

Beacons are short messages periodically broadcast by

sensor nodes to advertise their position and identifier to

neighboring nodes.

However, the use of beacons can introduce a number

of severe problems when protocols are deployed in real

testbeds: collisions, imprecision in neighborhood tables,

unnecessary waste of resources, etc. The effect of these

problems cannot be underestimated as confirmed by several

studies [10, 21, 22]. To avoid these problems, some beacon-

less unicast routing solutions have been proposed in the

literature.

The general idea of beacon-less geographic routing is

to reactively discover the information about neighbors’

positions. Examples of these protocols are implicit geo-

graphic forwarding [1] (IGF), geographic random

forwarding [23] (GeRAF), beacon-less routing [9] (BLR),

contention-based forwarding [7] (CBF), Beacon less Posi-

tion Based Routing with Guaranteed Delivery [3] and

beacon-less on-demand strategy for sensor networks [15]

(BOSS). These solutions are specific to geographic unicast

routing. Additionally, there are some works about beacon-

less broadcasting such as the area based beacon-less reliable

broadcasting [14].

In this paper we study the problem of beacon-less GMR.

This problem is even more challenging than the unicast

counterpart. The reason is that at each hop, nodes need to

select not only a next hop, but a subset of neighbors.

Selecting more than a single neighbor creates branches in

the multicast distribution tree, and it has a direct impact on

the overall bandwidth consumption. However, in some

cases it is better to have more branches consisting of good

quality links than few of them with very low quality.

Finding a good multicast tree with a good balance between

cost and reliability using only local information is very

difficult. Our proposed solution (BRUMA), tries to achive

such a trade-off by selecting next hops at each intermediate

node oportunistically. The current node routing the mes-

sage sends the data packet first, and selects next hops

among those that successfully received the data packet. In

addition, the protocol incorporates efficient mechanisms to

reduce the number of control messages required to make

the selection and the probability of collisions. Our simu-

lation and testbed results show that the idea of beacon-less

multicast routing is very efficient and effective compared

to the best performing GMR protocol in the literate.

The results of our empirical tests confirm what we have

previously devised by doing simulations. BRUMA is able

to outperform the best bandwidth-efficient solution in the

literature (GMR [17]) in terms of packet delivery ratio

and overall bandwidth consumption. So, we can see that

working without beacons not only reduces control over-

head, but also improves the performance of the protocol,

specially in real scenarios with interferences, collisions,

etc.

The reminder of the paper is organized as follows. In

Sect. 2, we give an overview of the operation of geographic

routing and its adaptation to the multicast case. We describe

the operation of BRUMA in Sect. 3. Section 4 provides a

performance evaluation of BRUMA and compares it against

GMR. In Sect. 6 we overview some related works, and Sect.

7 concludes the paper and provides some ideas for future

work.

2 Geographic multicast routing

The general operation of geographic unicast routing is very

simple. A node currently holding a message addressed to a

destination node located outside its radio range selects one

of its neighbors as next relay and passes it the message. The

selection is done solely based on the positions of the current

node, its neighbors and the position of the destination.

Whenever possible, geographic routing chooses neighbors

which are closer to the destination than the current node.

This is called greedy mode. When no neighbor node is

closer to the destination than the current one, perimeter

mode (also called face routing) is used to escape from the

local minimum until greedy mode can be resumed. The best

example of this operation is the GFG [2] algorithm.

In the case of GMR, the problem becomes more chal-

lenging for a number of reasons. First of all, messages can

potentially be addressed to several destinations. That is, the

routing task consists of creating a distribution tree which is

much more complex than a simple path. Therefore, a node

holding a message has to determine whether to create dif-

ferent branches in the tree or to continue the same one.

Secondly, it must select which neighbors should act as next

relays, and the selection of relays requires not only selecting

next hops, but deciding which next hops shall take care of

routing toward which branch. That is, assigning a different

subset of destinations to different neighbors. Additionally,

data delivery is also harder than in the unicast case. For the

multicast case, the protocol should be able to reliably

deliver messages to all the selected next hops. Otherwise, a

single packet loss may cause multiple destinations to loss

the data packet.

The whole process is obviously more complicated than

in the unicast case. The number of possible options grows

exponentially with the number of neighbors and receivers,

and the decision of selecting one or multiple next hops (i.e.

whether to create a branch or not) has a crucial influence on

the overall cost of the multicast tree. Furthermore, the

adaptation of the perimeter mode for the case of multiple

destinations requires a careful design to handle situations in

which part of the destinations can be routed in greedy

566 Wireless Netw (2012) 18:565–578

123

mode, and the rest in perimeter. Finally, the delivery phase

must be designed to deal with errors and losses which are

common in real scenarios.

In the next section we illustrate how our proposed pro-

tocol deals with all these issues.

3 Beacon-less multicast routing with BRUMA

In this section we describe the operation of BRUMA and

show how it solves all the issues mentioned above. We first

give an overview of the overall operation and then, we

describe the detailed routing process.

Similar to geographic routing protocols in the literature,

our protocol assumes that there is a location service by

which the source can know the position of the destinations.

Given that our work focuses on the way multicast data is

delivered, we do not impose any such service in the

remainder of the paper. We just assume that the source

knows the positions of the destinations.

Another important aspect to consider is how the position

of the destinations are included in data messages. If there

are a large number of destinations, that alone can represent

a lot of overhead. So, some kind of header compression or

position hierarchy would be desired. Given that this is

common to all GMR protocols, we just use a list of des-

tinations. However, any improvement in that regard can be

introduced into our protocol as well.

Below we describe the overall operation of the protocol,

and we will go into details in the next subsections.

3.1 Overview

As in most geographic routing protocols, we assume that

nodes know their own position either via GPS, or by using

localization algorithms [18]. We also assume the existence

of a location service available to the source node for

locating the destinations such as, for example, the grid

location service (GLS) [12]. The source node includes the

location of the destinations in the header of every data

message. So that, every node forwarding the message can

know the position of the destinations. Additionally, being a

beacon-less protocol means that neighbors’ positions are

reactively discovered by using a 1-hop query-answer

mechanism. Therefore, we can say that, in BRUMA, nodes

only use local information to forward messages. Concretely,

each node forwarding a message in BRUMA follows the

following three steps:

1. Decide whether to branch or not The key for multicast

routing protocols to produce efficient trees, is to select

branching points in an appropriate way. That is, nodes

where the data packet must be replicated in order to

reach different sets of destinations. In BRUMA, nodes

determine when and how to branch following the same

approach used by LEMA [16] and MSTEAM [6]. That

is, using as a guide the position of the receivers.

Concretely, using just local information, the node

currently having the message applies the Kruskal’s

algorithm to build a minimum spanning tree (MST) of a

complete graph containing only the receivers and the

current node as vertices. In that graph, edges are labeled

with the Euclidean distance between vertices. The

resulting tree is a very efficient multicasting backbone.

Thus, the node currently holding the message knows

the number of branches that required to span all the

receivers, and the subset of receivers spanned by each

branch 1(b).

2. Locate candidate neighbors to next relay BRUMA is a

beacon-less protocol. So, the information about avail-

able next hops is gathered by forwarding nodes in a

reactive way. Concretely, they send a query message

including also the data payload (Data). Therefore, only

those neighbors that successfully receive the data

message are able to answer with a response message

(Response) indicating that they can act as next relays.

Then, a neighbor is assigned to every branch obtained

in the previous step among the set of discovered nodes.

Obviously, the same node can be the next relay for

different branches if it is the best candidate for all of

them.

This process can generate a big number of response

messages, therefore, we also include a sophisticated

timer assignment scheme to prioritize the answers

from good candidates. Additionally, the number of

responses is also reduced, so that, the bandwidth

consumption and the probability of collisions among

responses are condierably decreased. This results in an

crease of BRUMA’S reliability.

3. Deliver the message Neighbors selected as next relays

already have the data payload because it was trans-

mitted in the query message used to locate them. Thus,

in BRUMA, this final step consists only in announcing

the assignment of routing subtasks. This is done

by means of a single selection message (Selection)

including a list of assignments. Each routing subtask

consists of the identifier of the neighbor selected as

next relay and the subset of destinations assigned to it.

The current node might not have any neighbor closer

to some receivers than itself, that is, a dead end might

be reached. In this case a recovery mechanism needs to

be started for reaching those particular destinations.

Typical recovery mechanisms for geographic routing

require knowing the position of almost the complete

set of neighbors to determine the next relay. Next

section describes how we manage to obtain these

Wireless Netw (2012) 18:565–578 567

123

information without resorting to a new query message

and avoiding collisions as much as possible.

All the messages used in BRUMA are carefully sched-

uled in order to reduce the number of messages required for

the selection process to complete. Next subsections address

these and others operational details explaining how BRU-

MA’s protocol work either in greedy and in perimeter

mode, and the optimizations we have designed to reduce

the bandwidth used wile increasing the reliability of the

protocol.

3.2 Details of greedy mode

Figure 1(a) shows an example network in which node s is

the source node and has a message addressed to a set of 10

destinations: fr1; . . .; r10g. Notice that destination r1 is out

of the radio range of node s, and s has no neighbors pro-

viding advance towards that destination, so that, there is a

network void in the path towards r1 and perimeter mode

will be necessary.

3.2.1 Step 1

Figure 1(b) shows the resulting tree obtained by applying

the Kruskal’s algorithm over the complete graph contain-

ing only the receivers and the s as vertices. Then, node

s determines the three outgoing edges in the resulting MST,

so that, it decides that the message must be split in three

branches, one dedicated to reach {r1}, a second one for

{r2, r3, r4, r5} and a third one for {r6, r7, r8, r10}.

The direct descendants of s in the MST are the multicast

destinations through which messages will pass in their path

towards other destinations. We call these sub set of

receivers the first level receivers (FLR). Delivering the

message to the set of FLR is enough to deliver the message

to the whole set of receivers. Therefore, s only has to find,

among its 1-hop neighbors, a sub set of nodes to act as

next relays to reach the set of FLR. In our example

FLR = {r1, r4, r6}.

3.2.2 Step 2

After determining the set of FLR, s broadcasts a Data

message which also includes the full payload and, in the

header, the set of intended FLRs. Then, 1-hop neighbors

that successfully received the Data message report their

position to s using Response messages. Node s waits for

responses just for a short pre-established period of TGreedy

seconds.

The Data message is received by the neighbors whose

received signal is strong enough to successfully decode the

message. The protocol is designed so that only the best

candidates will answer as we shall explain later. Based on

the received reports, s selects the neighbor providing the

most advance towards every FLR as next relay for the

branch that node represents.

The benefit of sending the payload in the first message is

that only relevant neighbors which successfully managed

to receive the data packet are discovered. This limits very

much the number of retransmissions that may be required

in the advent of propagation errors. Additionally, it does

not incur in any extra cost as long as s has to broadcast the

data packet anyway.

Figure 2 shows that, in the example, there are neigh-

bors providing advance just towards two FLRs (r4 and r6).

In fact, n2 provides advance towards both of them. Node

s selects n3 to be the next relay for r4 and their descen-

dants in the MST because that node provides the largest

advance towards that receiver. Neighbors n1 and n2 pro-

vide almost the same progress towards r6, so that, n2 is

randomly selected to be the next relay for r6 and their

descendants.

10

9

8

76

5

4

3

2

1

s

r

r

r

rr

r

r

r

rr

(a)

10

9

8

76

5

4

3

2

1

s

r

r

r

rr

r

r

r

rr

(b)

Fig. 1 In a we can see a

network in which s is the source

node and there are ten receivers

spread all over the network area.

Notice that r1 is out of the radio

range of s which is illustrated in

the picture by a circle. In b the

MST of the receivers plus s is

used to decide that the source

must split the message in three

branches, one for {r1}, a second

one for {r2, r3, r4, r5} and a

third one for {r6, r7, r8, r10}

568 Wireless Netw (2012) 18:565–578

123

3.2.3 Step 3

Finally, node s notifies the selected neighbors that they are

the chosen ones by transmitting a Selection message that

includes the new routing assignments. Then, it waits for

overhearing the Data messages forwarded by every next

relay, n2 and n3.

Each greedy routing assignment consists of the identi-

fier of the neighbor selected as next relay and the list of

receivers it must be responsible for. Some neighbors can be

the best candidate relay for two or more subsets of receiv-

ers. In that case, they are merged into a single assignment.

3.3 Dealing with voids

TGreedy is the amount of time that s schedules for receiving

all responses in greedy mode. Thus, FLR for which s did

not received any response during that period of time must

be reached in perimeter mode because, presumably, there

are no neighbors providing advance towards them.

In BRUMA, we use the recovery mechanism defined in

GFG [2] to individually determine the next relay in

perimeter mode for each one of those FLRs. However, to

do that we need to know the position of all the 1-hop

neighbors in order to build a planar graph and then apply

GFG.

Therefore, continuing with the same example, after

waiting for the first TGreedy seconds and not having received

any response from a neighbor suitable of becoming the

next relay for r1, the Selection message is not transmitted,

and s continues waiting for a pre-established interval of

TPerimeter seconds. During this time interval, given that no

Selection message has been received, every neighbor that

has not answered yet, transmits its Response message.

Thus, s can now apply GFG to determine the next relay for

every FLR not reachable in greedy mode. As a conse-

quence, n4 is chosen as next relay for r1.

The Selection message in this case includes not only

greedy, but also perimeter routing assignments. Perimeter

routing assignments differ from greedy routing assignments

because the later contains additional information which is

required for perimeter routing such as the node where

perimeter mode started. That information is used to return to

greedy mode as soon as a node which is closer to the des-

tination than the position where perimeter started is found.

3.4 Reducing the number of responses

In scenarios where the mean number of neighbors per node

is low only a few responses are transmitted. However, in

real deployments the mean density may be high. Thus, the

number of responses grows and increases the bandwidth

consumption to undesirable levels. Moreover, wireless

links are far from being perfect because errors, losses and

collisions are common in real deployments. So, we incor-

porate in BRUMA a mechanism based on timed responses

to achieve a high performance while reducing the number

of responses and bandwidth usage.

In BRUMA, responses are ordered in time so that

neighbors providing more advance answer first. This allows

other neighbors to cancel their responses after overhearing

previous ones. In this way, we reduce the number of

responses and collisions resulting in a high reliability.

Additionally, given that there may be multiple branches,

and that the same neighbor can be candidate to next relay

for more than one branch, neighbors must know when to

send the response related to each branch (i.e. FLR). Thus,

we also establish the order in which responses for every

FLR must be sent by neighbors.

To do that, we have designed a function that each

neighbor can use to determine the timeout value it must

wait before sending its own Response message. This

function assigns lower delays to neighbors providing the

most advance towards a certain FLR.

As we may have multiple FLRs, this function also

prevents responses related to different FLRs from being

transmitted within the same time interval. Concretely,

being F the list of FLRs. We uniformly distribute the

TGreedy seconds in |F| time intervals ofTGreedy

jFj seconds that

we call TBranch. Thus, all neighbors providing advance

towards a the ith FLR should answer during the ith period

of TBranch seconds.

Moreover, we establish an order between time intervals

for different FLRs by simply using the arbitrary order in

which they are listed in the Data message. As this message

is received by all neighbors, all candidate relays share the

same information about how to establish time intervals.

2 r6

4

31

nr4

1r

s

nn

n

Fig. 2 This figure shows just the 1-hop neighbors of s. Nodes n2, n3,

and n4 provide advance towards the FLR r4, nodes n1 and n2 are the

candidate relays for the FLR r6, and no node provides advance

towards r1

Wireless Netw (2012) 18:565–578 569

123

Neighbors providing a large advance towards a certain

FLR should answer first. That is, the amount of time every

node has to wait is inversely proportional to the progress it

provides. The maximum progress possible is equal to the

radio range, but the problem with this approach is that,

being the progress a continuous value, really small differ-

ences in the location of two nodes imply very subtle

differences in the delay each node must wait, resulting in

possible collisions.

To address this issue, we divide the coverage area in a

fixed number of sub areas providing the same range of

progress and all neighbors in the same area share the same

delay. Obviously, to avoid collisions we introduce some

randomness to the resulting delay. Figure 3 shows what we

call the common sub areas (CSA). As it can be seen, each

FLR define a different set of CSAs. Then, to determine the

amount of time each neighbor has to wait for each FLR we

proceed as follows.

First, given a maximum radio range R, the current relay

s and a certain FLR f 2 F, we define the positive progress

area for f (PPAf) as the section of s’s coverage area whose

points are closer to f than s. Then, each neighbor n in the

PPAf computes its own greedy progress towards f (Pg)

using the following equation.

Pgðn; f ; sÞ ¼ distðs; f Þ � distðn; f Þ ð1Þ

where s and f are the current relay and the FLR respec-

tively, and dist(a, b) is the Euclidean distance between the

positions of the nodes a and b. Obviously, the greedy

progress varies between 0 and R.

Additionally, for a given f 2 F we divide its PPAf in sets

of neighbors providing a similar greedy progress (see Fig. 3)

and we assign smaller delay times to subsets of neighbors

providing more progress toward f. Concretely, fixing the

number of subareas (NSA) in which we want to uniformly

divide the PPAf, each neighbor can determine in which

Common Subareas (CSA) it is located using the following

equation for each FLR f included in the Data message:

CSAf ¼ NSA� R� Pgðn; f ; sÞR

� �ð2Þ

here, the value of CSAf falls between 0 and NSA - 1

corresponding 0 to the area located closest to f and NSA - 1

to the farthest one. Finally, given the CSAf, each neighbor

computes its delay time for f according to the following

equation:

tf ¼ fi � TBranch þ CSAf �TBranch

NSA

� �

þ randomTBranch

NSA

� � ð3Þ

here, fi represents the index that f has in F and random(x)

is a function obtaining a random value between 0 and x. This

function combines a uniformly distributed value that

depends on the progress with a random value. This means

that responses from different subareas cannot collide.

Additionally, the fi factor guarantees that all responses for a

given branch are transmitted before the ones of the next

branch following a certain order known by all neighbors.

Assuming the following order among the FLRs:

({r1, r4, r6}), and according to the distance between neigh-

bors and FLRs, no neighbor answers during the time interval

dedicated for r1 because none of them provides advance.

Then, n3 answers for r4 canceling the answers from n4 and n2.

Finally, during the last time interval dedicated for r6, either

n1 or n2 answers canceling the other neighbor’s answer.

On the other hand, when perimeter mode must be applied

for one or more FLRs, the current relay needs the position of

every neighbor. Concretely, the position of neighbors that

have not answered yet. As those neighbors can be spread all

over the coverage area the notion of positive progress area is

not valid here. Therefore, we define a different function to

compute the progress according to the distance from s. This

function is called Pp and it is used to divide the whole cov-

erage area in circular subareas. Finally, we compute tp, the

time each neighbor must wait before answering in perimeter

mode. Obviously, that time must be greater than TGreedy.

Ppðn; sÞ ¼ distðs; nÞ ð4Þ

CSAp ¼ NSA� Ppðn; sÞR

� �ð5Þ

tp ¼ TGreedy þ CSAp �TBranch

NSA

� �

þ randomTBranch

NSA

� � ð6Þ

As in the previous case, here we also try to avoid

collisions by delaying the transmission of responses a

First CSA

PPA r6

4

3

2

1

r6

1

n

n

4

s

r

n

n

rPPA4

Last CSA

FirstCSA

r

Fig. 3 Neighbors answer after their timer expires. Timers are set

according to the closeness each neighbor has for each FLR

{r1, r4, r6}. The positive progress areas (PPA) and the location of

the first and last common sub areas (CSA) are also shown

570 Wireless Netw (2012) 18:565–578

123

variable amount of time. Concretely, neighbors schedule

their answers according to their distance from s following

Eq. 6. As it can be seen, we also use sub areas but, in this

case, we create sub sets of neighbors located at a similar

distance from s. The number of sub areas and the time

interval assigned to each one are the same as in the

previous case. For clarity we call the maximum time to

wait for this kind of responses TPerimeter, but it is the same

as TGreedy.

By letting neighbors located closest to s answering in the

first place we can take advantage of an optimization pro-

posed by Chawla et al. [3]. Concretely, farther neighbors

can cancel their responses after hearing the response of

other neighbors, because they determine they are not part

of the planar graph of the current relay node. Notice that

this optimization makes sense because usually plannarizing

a graph means eliminating longer edges.

The example in Fig. 4 shows the subareas defined as

concentric circles around the current relay. In this case,

only neighbors n4 and the one that did not answer yet

among n2 and n1 must answer after the TGreedy time inter-

val. Thus, assuming that n2 transmitted its response for r6

during the first TGreedy seconds, only n4 and n3 send their

responses. Then, s uses the position of its neighbors to

determine that n4 is the next relay for r1 in perimeter mode,

n3 is the next greedy relay for r4 and their descendants

({r3, r2, r5}), and finally that n2 is responsible for

fr6; r7; . . .; r10g also in greedy mode.

3.5 Dealing with packet losses

In very sparse networks where a node only has a few

neighbors, there is a probability of loosing all Response

messages. Therefore, it is necessary to define some kind

of retransmission mechanism. In BRUMA, if TGreedy ?

TPerimeter seconds have elapsed and the current relay has

not received any response, the protocol retransmits the

Data message up to MAX_RETRIES times.

Besides, Selection messages are smaller in size than

Data ones, thus if a Data message arrived correctly to a

neighbor, and its response also arrived correctly, the

probability for that neighbor to successfully receive the

Selection message is high [15]. Nevertheless, the original

message is not deleted immediately after sending the

Selection message. Instead, it is stored until being sure that

all the next relays successfully received their routing

assignments. To do that, the current relay overhears the

transmission of Data messages by next relays selected.

That is, we use a kind of passive acknowledgment (PACK).

Additionally, BRUMA also supports the use of explicit

ACK messages. This is specially useful when the selected

next relay is in fact the final destination because there

will not be any posterior retransmission confirming the

successful reception of the message.

Finally, to avoid all next relays to send their Data

packets simultaneously, next hop relays wait a small ran-

dom amount of time after they received the Selection

message. This reduces the probability of collisions.

4 Simulation results

In this section, we compare our proposed beacon-less

multicast geographic routing algorithm (BRUMA) against

the GMR algorithm [17], which is the most bandwidth-

efficient geographic multicast algorithm in the literature.

For our simulations, we use the TOSSIM [11] simulator

which considers collisions and uses a realistic MAC layer.

Additionally, we model transmission errors using a table

derived from some recent empirical results [15]. In this

previous work we presented a detailed study of the relation

between the distance among sender and receiver, the

packet size and the packet reception ratio (PRR).

4.1 Simulation setup

We evaluate the performance of BRUMA and GMR at

varying mean densities of nodes. We measure density as

the mean number of neighbors per node. Both algorithms

were run in the same set of scenarios. Concretely, we fix

the maximum radio range to R = 150 m, MAX_SELECT

and MAX_RETRIES to 5 and the simulation area to

2,000 9 2,000 m2. We simulate 50 different scenarios for

each of the 6 different mean densities (10, 15, 20, 25, 30

and 35) considered. The scenarios are generated by ran-

domly placing a number of nodes varying between 300 and

2,000 nodes to achieve the different desired densities.

In our experiments, randomly select 15 different sour-

ces, sending 5 multicast packets to 10 random destinations

3

4

2

1

1

s

n

n

n

n

First CSA

Last CSA

r

Fig. 4 As no neighbor provides advance towards r1, s waits for

responses of the neighbors that did not answered during the TGreedy

period

Wireless Netw (2012) 18:565–578 571

123

in the network. So, for each of the 50 scenarios, and each of

the 6 different densities, a total of 45 data messages are

being routed.

Regarding the configuration of the algorithms being

tested, GMR’s authors did not consider the problems

caused by lossy links. So, GMR does not include any

mechanism to check the correct reception of a message by

a neighbor. To guarantee a fair comparison we add the use

of ACK messages to the base GMR protocol. They are used

to acknowledge the reception of the only packet defined by

GMR, the Selection message. GMR’s Selection messages

include the payload and the routing assignments for the

next relays selected by the current one. On the other hand,

BRUMA has four different messages: Data, Response,

Selection and ACK. The first one is the data packet,

responses are used to know candidate relays, selection

messages just select a subset of those candidates and finally

ACK is used by leaf nodes to acknowledge the reception of

the selection message. Intermediate nodes use passive

ACK just to confirm retransmissions.

Given that IEEE 802.15.4 limits packets to 120 bytes,

from which 10 bytes are used by tinyOS to implement its

MAC layer, we only have 110 bytes for coding packets.

Data packets include a header with the type of message,

sequence number, etc. This header has a fixed size of 12

bytes. In addition, for each destination in the list we use 2

extra bytes to code its position as (x, y). So, the total

available payload is 98 - 2*d being d the number of

destinations. Responses have a fixed length of 10 bytes.

ACKs have a fixed length of 8 bytes and finally Select

messages have a fixed length of 7 ? 2*b, being b the

number of branches. If permimeter information to escape

from a void is required, then Select messages include

another fixed-lenght 12 bytes.

As we explained in the previous section we assume that

the sender knows the positions of the destinations when

evaluating both protocols. This avoids introducing any bias

in the performance evaluation by considering the effects

incorporating a location service or a particular protocol for

that.

4.2 Analysis of results

The main goal of BRUMA is the construction of efficient

multicast trees by reducing the bandwidth used by the

protocol while still achieving a high packet delivery ratio.

Figure 5 compares the packet delivery ratio for both pro-

tocols. We can see that BRUMA clearly outperforms GMR

regardless of the density because BRUMA’s opportunistic

selection of next hops is able to choose those neighbors

which have a very high probability of reception. GMR has

a lower delivery ratio because in some cases a node

receives beacons from neighboring nodes whose link

quality is not very good. Thus, even though small beacon

messages can be transmitted reliably on that link, data

packets may not be able to traverse the link because their

large size makes them more prone to errors. The best result

for GMR is close to 90% whereas BRUMA achieves more

than 98% for all the densities considered.

Regarding the overall bandwidth consumption, Fig. 6

shows that, in addition to achieving a higher packet

delivery ratio, BRUMA also consumes much less total

bandwidth than GMR. In fact GMR transmits almost 4

times more bytes than BRUMA when the mean density is

above 18 which, in many WSN scenarios is not a really

high value. Again only a few good neighbors answer to

Data packets thanks to BRUMA’s opportunistic neighbor

selection. Therefore, many collisions and interferences due

to beacons can be avoided, which means that a lower

number of retransmissions are required. In the case of

GMR we can clearly see that higher densities make the

protocol to worsen its performance. The reason is that the

denser the network, the higher the interference caused by

50

60

70

80

90

100

110

10 15 20 25 30 35 40

Pac

ket D

eliv

ery

Rat

io

Density

GMR BRUMA

Fig. 5 Packet delivery ratio for GMR and BRUMA

10000

100000

10 15 20 25 30 35 40

Tota

l Byt

es T

rans

mitt

ed

Density

GMR BRUMA

Fig. 6 Total number of bytes transmitted

572 Wireless Netw (2012) 18:565–578

123

beacons. However, the density does not affect the scala-

bility of BRUMA.

As expected, both protocols experience the lowest per-

formance in the very low density scenarios. The reason is

that the number of existing paths is much limited, and in

some cases low-quality links cannot be avoided. That is,

given that BRUMA only chooses next hops among nodes

that sucessfully received the data message, it implicitly

takes into account the quality of links. However, when

there is a very low density in some cases the only option to

continue routing is using those links, which means that the

performance of the protocol worsens. Also, lower density

means a higher probability of voids in the network, which

may require nodes to use the less-efficient perimeter mode.

The results obtained in the simulations show that perimeter

mode is more intensively used in those sparse scenarios.

Both protocols use similar recovery strategies, therefore,

there are not big differences between both protocols

regarding their performance in perimeter mode.

To analyze in more detail the bandwidth consumption of

both protocols we study the bytes transmitted per hop.

Figure 7 shows the mean number of bytes transmitted per

hop by each algorithm grouped by message types. Clearly,

BRUMA needs less total bytes per hop than GMR in

almost all tested scenarios.

The beacon-less nature of BRUMA makes it scale with

the number of nodes in the network. As Figs. 6 and 7 show,

BRUMA’s total bandwidth consumption and the propor-

tion of bytes of each type of message is almost independent

of the size of the network. However, GMR does increases

its bandwidth per hop as the mean density of neighbors

grows up. We can also see in Fig. 7 that the bandwidth

consumption due to Response, ACK and Selection mes-

sages is not very high. They increase the number of bytes

per hop of the protocol, but they provide more reliability

(see Fig. 5). Also, this overhead is not very huge because

those messages are only sent out by nodes participating in

the routing unlike beacon messages which must be sent by

all nodes. Also, we can see how even with these extra

messages BRUMA outperforms GMR in the total number

of bytes per hop.

When the density is high the probability of loosing

messages due to interferences and collisions caused by

beacons is high. To prevent the decrease of the delivery

ratio GMR resorts to retransmitting Selection and ACK

messages, but this can lead to introduce unnecessary

duplicated packets in the network, as Fig. 8 confirms.

Duplicated messages are those messages arriving to the

destination more than a single time. For example, if the

ACK message of the selected next hop is repeatedly lost, a

different next hop can be chosen. Thus, two different next

hops might forward the same message making it reaching

the destination twice. As we see in Fig. 8 from the 45

messages being sent in each simulation, GMR produces

routes around the double of those messages unecessarily as

duplicastes towards the destinations. However, BRUMA is

below 5 duplicates for all tested densities.

5 Experimental results

To further demonstrate that BRUMA is capable of offering

a good performance in networks with realistic wireless

links, we perform some experiments in a real sensor net-

work testbed consisting of 35 Tmote-sky motes. The motes

are distributed within the first floor of the Computer Sci-

ence building at the University of Murcia as shown in

Fig. 9. To be able to achieve relevant statistics, the motes

log every network event via USB to a gateway, which

places the logs into a central server via Ethernet. Logging

via ethernet is implemented so that these messages do not

interfere with the traffic of the experiment. Log entiresFig. 7 Total bytes transmitted per hop

0

10

20

30

40

50

60

70

80

90

10 15 20 25 30 35 40

Del

iver

y D

uplic

ate

Pac

kets

Density

GMR BRUMA

Fig. 8 Number of duplicate data packets at the destinations

Wireless Netw (2012) 18:565–578 573

123

include the sending and reception of any message via radio.

We log for each message the source, destination, time of

the event, size of the packet, type of packet, etc. After the

experiment is completed we run a script to process all

traces and generate the results that we present below.

The size of the different packet types is the same as in

the simulation section above.

For the experiments, we choose a source and 10 desti-

nations spread all over the scenario. After booting all

motes, the source sends 1,000 messages to the destinations,

which are used to obtain cumulative probability density

functions (CDF) for the different performance metrics

used. The interval between data messages generated by the

source has been fixed to 5 s, and the size of those messages

is 120 bytes.

For all the experiments, we considered a maximum

response time (Tmax) equal to 300 ms. We also considered

5 positive progress areas, a maximum number of selection

retries of 10 and a maximum number of retries for the

whole selection process of 3.

As we show in Fig. 10 the proposed protocol achieves a

very high delivery ratio which is nearly perfect in most of

the experiments. In fact, only in 2% of the experiments the

packet delivery ratio of our proposed scheme is below

99%. On the other hand, the packet delivery ratio obtained

by GMR is always below 80%, and only in the 20% of the

experiments is over 70%. The reason for these results is

that the proposed beacon-less forwarding strategy of

BRUMA certainly manages to reliably deliver multicast

messages to the intended next hops.

Moreover, this reliability is not obtained at the expense

of a large control overhead. As we show in Fig. 11, the

number of required transmissions at each hop to send a

message to the next relays in the case of BRUMA is cer-

tainly lower than in the case of GMR. That is, key to the

high packet delivery ratio of BRUMA is the fact that the

next hop selection and delivery function manages to select

good next hops, avoiding thus having a large number of

retransmissions. For instance, we can see in the figure that

in 90% of the experiments BRUMA can forward the data to

next hops with less than 5 transmitted messages. This is a

low value considering that without transmission errors the

minimum that BRUMA requires is 3 messages. Contrary to

that, GMR requires in the best case only 2 messages per

hop, however due to bad next hop selections, it requires

more than 5 messages per hop in nearly half of the

experiments.

Figure 12 shows that the superiority of BRUMA over

GMR in its hop-by-hop operation also translates into an

overall higher efficiency in the testbed. As we show in the

figure, BRUMA’s network consumption in 80% of the

experiments less than 200 bytes per reached destination, to

deliver the 120-bytes data message. On the other hand,

GMR is below 200 bytes per reached destination only in

the 20% of the experiments. For the rest of the tests,

BRUMA is in most of the experiments below 400 bytes per

reached destination whereas GMR is well beyond 400

bytes per reached destination in more than 50% of the

experiments.

Summing it up, our experiments in the real testbed

confirm that our proposed solution is very effective and

0

21

3

4

5

67

8

9

10

11

12

13

14

1516

17 18

19

20

2122 23

2425

26

27

2829

1303

32

33

34

35

36

100−80 %70−40 %30−0 %

Fig. 9 Deployment in first floor of Computer Science building. Colors represent measured link qualities over a 24 h period (Color figure online)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

40 50 60 70 80 90 100

CD

F o

f Pac

ket D

eliv

ery

Rat

io

Packet Delivery Ratio

BRUMA GMR

Fig. 10 CDF of the delivery ratio

574 Wireless Netw (2012) 18:565–578

123

practical for real deployments whereas the most competi-

tive solution in the literature is not designed to cope with

realistic wireless links.

6 Related work

There are several multicast protocols [4, 19] designed to

operate in Mobile Ad Hoc Networks (MANETs). These

protocols follow two main routing strategies: tree-based and

mesh-based. Tree-based protocols create spanning trees

between the source and the set of destinations. Additionally,

recovery mechanisms are introduced in order to cope with

topological changes. In mesh-based protocols, nodes build a

graph of virtual links creating an over-dimensioned distri-

bution network. Their goal is to achieve a greater robustness

against topology changes than tree-based protocols. Nev-

ertheless, the overhead of these protocols tends to increase

with the number of nodes. It has been shown [12] that these

protocols do not scale well with the size of the network, so

they are not appropriate for WSNs.

Therefore, our work is mainly based in two different

approaches: geographic routing, and beacon-less routing.

6.1 Geographic multicast routing

PBM [13] was the first GMR protocol proposed in the lit-

erature. In PBM, the goal of the routing decisions is to

simultaneously optimize two opposite criteria: the progress

of the message towards the destinations, and the bandwidth

usage of the multicast tree being build. To do that, nodes

consider all possible subsets of its neighbors, and for each

one they assign each destination to the closest neighbor in

the subset. For every option, the objective function is eval-

uated, and the subset achieving the lowest value is chosen.

The exploration of all the possibles subset makes PBM

to be computationally expensive and not scalable with the

number of neighbors. Additionally, the objective function

has a parameter called k which determines the weight of

each criterion (progress/bandwidth). Therefore, the selec-

tion of this parameter is not a trivial problem.

In GMR [17] authors exploits the wireless multicast

advantage by applying the cost over progress metric. That

is, selecting the alternative set of neighbors which mini-

mizes the number of relays (cost) needed, and at the same

time, maximizes the progress towards the destination. In an

effort to reduce the computational cost of PBM, GMR

nodes does not test all possible subsets of neighbors.

Instead, an interactive algorithm discards some presumably

bad combinations reducing the complexity from exponen-

tial to polynomial. Experimental results show that GMR

outperforms the one of PBM in terms of bandwidth con-

sumption, and obviously in delay and computational cost.

LEMA [16] proposes a fully distributed heuristic approach

to build the multicast tree, and a strategy to reduce energy

consumption in the delivery phase. Given a set of destina-

tions, the transmitting node first constructs an spanning tree

rooted at itself and including the destinations. Based on this

locally computed tree and the location of its neighbors, the

transmitting node then splits the destinations in different

groups and calculates the next hop for each of these groups.

After that, a single message is issued containing the list of

next hops selected and the set of destinations each one must

take care of. To build the spanning tree that guides the rest of

the operation, each node locally uses Kruskal’s algorithm over

a fully-connected virtual graph consisting of the transmitting

node and the set of destinations it is in charge, and using as

edge’s weights, the Euclidean distance among nodes.

Additionally, the transmission of the message is carefully

planned by the transmitting node. The node determines

among its neighbors the energy efficient path for the mes-

sage to reach its intended next hop. Thus, LEMA’s authors

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9 9.5CD

F o

f Num

ber

of P

acke

ts p

er H

op

Number of Packets per Hop

BRUMA GMR

Fig. 11 CDF of the total number of transmitted packets per hop

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 200 400 600 800 1000 1200 1400

CD

F o

f Byt

es T

x pe

r D

estin

atio

n

Total Bytes Tx per Reached Destination

BRUMA GMR

Fig. 12 CDF of the total number of bytes transmitted per reached

destination

Wireless Netw (2012) 18:565–578 575

123

assume nodes know the position of all their neighbors by

using some sort of beaconing mechanism.

Another recent solution which is very similar to LEMA

was proposed by Feng et al. [5]. The proposed protocol

called RBMulticast distributes the area of the network into

broadcast regions, and the current node sends the packet

towards a virtual position (called virtual node) which is

computed based on the positions of the destinations within

that broadcast region. Authors assume that voids are avoi-

ded at the MAC layer, so they just focus on the selection of

virtual nodes and sending the packets towards them.

Unfortunately, by choosing the next relay as the node being

closer to the virtual node, they do not account for possible

effects of low quality links, etc. Also, the paper is not

completely beaconless because to escape from void areas,

the proposed water flow model requires some memory and

knowledge of neighbors.

6.2 Beacon-less routing

The general idea of beacon-less routing is to reactively

discover the information about neighbors’ positions just

when routing data packets. Hence, the overhead and inter-

ferences caused by beacon transmissions can be avoided. In

the literature we can find two different approaches: totally

distributed, and directed by the transmitting node.

BLR [9] and blind geographic routing [20] (BGR) are

examples of the totally distributed approach. Nodes running

these protocols forward the message and leave the selection

of the next forwarder to be done in a distributed contention

process based on timers. That is, using the same function,

each node sleeps for a certain amount of time computed

using the same function. Then, the first candidate that

awakes becomes the next relay for the message and imme-

diately forwards it. The forwarding of the message informs

the other candidates that the next relay has been already

selected, so that, they do not have to forward the message.

These protocols use different delay functions to avoid

collisions and reduce the number of responses. They also

differ in the definition of candidate neighbors to next hop to

duplicates due to candidates not hearing answers from

other nodes.

On the other hand, the IGF [1], GeRAF [23] , CBF [7] , and

BOSS [15] are examples of the second approach. In these

protocols, the node holding the message is the one in charge of

selecting the next hop. To do that, variations of a three way

handshaking protocol (RTS/CTS/ACK) are used. While these

protocols have more control overhead than the previously

mentioned, the control of the forwarding process is bigger and

the probability of generating duplicate messages is low.

These protocols also need to use timers to reduce the

number of responses and collisions. Besides, they empha-

sizes the definition of ‘‘forwarding areas’’. That is, the areas

whose nodes participate in the process. Among them, BOSS

is the only one taking care about the errors and losses typical

from real wireless networks.

For the particular problem of beaconless geographic

routing we are not aware of any previous soution. Our

proposed protocol (BRUMA) can be seen as a mixture

between the high level ramification strategy followed by

LEMA and the beacon-less strategy used in BOSS. From

LEMA, we adopt a way to determine when and how to split

the message creating new branches of the multicast tree.

From BOSS we adopt the idea of sending the payload data

first, and using it to find good next hop candidates. This

helps BRUMA perform well in real scenarios.

7 Conclusions and future work

We propose and evaluate BRUMA, a new beacon-less

multicast geographic routing algorithm for WSNs. BRU-

MA’s main goal is to reduce the bandwidth consumption

due to control overhead. This is achieved with three dif-

ferent properties. Firstly, the beacon-less nature of the

protocol significantly reduces the bandwidth used by the

whole network. Secondly, BRUMA combines an opportu-

nistic data delivery with a dynamic neighborhood discov-

ery function that reduces the number of candidate

neighbors and therefore the number of response messages.

Finally, the retransmission mechanism incorporated in

BRUMA allows it to achieve a very high delivery ratio

while reducing the overall bandwidth consumption.

Our experimental results comparing BRUMA against

GMR, which is the protocol performing best among

existing solutions, confirms that the goal of reducing the

bandwidth consumption has been achieved. BRUMA out-

performs GMR not only in terms of bandwidth consump-

tion, but also in delivery ratio. Moreover, this result is

supported not only by simulations but also by our experi-

mental results in a real testbed.

Finally, taking into account that unlike BRUMA, GMR

is a beacon-based algorithm, the simulations results are

even better because we have not accounted for the addi-

tional overhead introduced by beacon messages when

plotting GMR results. Had we counted them, then the

bandwidth consumption of GMR would have been even

higher than shown.

Regarding future work, we are considering the extension

of BRUMA to be able to select next hops with the goal of not

only reducing bandwidth but the overall energy consumption.

While BRUMA saves energy indirectly by avoiding message

retransmissions, supporting sleeping sensors, reducing

bandwith, etc., being able to save more energy by adjusting

Tx power in motes requires changes to the protocol. This is

the reason why we consider this as future work.

576 Wireless Netw (2012) 18:565–578

123

Acknowledgment This work has been partially funded by the

MOTEGRID (PII1C09-0101-9476) project.

References

1. Blum, B., He, T., Son, S., & Stankovic, J. (2003). IGF: A state-free robust communication protocol for wireless sensor networks.

Technical report CS-2003-11, Department of Computer Science,

University of Virginia, USA.

2. Bose, P., Morin, P., Stojmenovic, I., & Urrutia, J. (2001). Routing

with guaranteed delivery in ad hoc wireless networks. WirelessNetworks, 7(6), 609–616.

3. Chawla, M., Goel, N., Kalaichelvan, K., Nayak, A., & Stojme-

novic, I. (2006). Beaconless position based routing with guaranteed

delivery for wireless ad-hoc and sensor networks. In Proceedingsof the 19th IFIP world computer congress, August 2006.

4. De Morais Cordeiro, C., Gossain, H., & Agrawal, D. P. (2003).

Multicast over wireless mobile ad hoc networks: Present and

future directions. IEEE Network, 17(1), 52–59.

5. Feng, C.-H., Zhang, Y., Demirkol, I., & Heinzelman, W. B.

(2011). Stateless multicast protocol for ad-hoc networks. IEEETransactions on Mobile Computing (accepted for publication).

6. Frey, H., Ingelrest, F., & Simplot-Ryl, D. (2003). Localizedminimum spanning tree based multicast routing with energy-efficient guaranteed delivery in ad hoc and sensor networks.

Technical report RT-0337, INRIA, June 2003.

7. Fußler, H., Widmer, J., Kasemann, M., Mauve, M., & Harten-

stein, H. (2003). Contention-based forwarding for mobile ad hoc

networks. Ad Hoc Networks, 1(4), 351–369.

8. Giordano, S., Stojmenovic, I., & Blazevic, L. (2001). Position

based routing algorithms for ad hoc networks: A taxonomy. In X.

Cheng, X. Huang, & D.Z. Du (Eds.), Ad hoc wireless networking(pp. 103-136). Kluwer.

9. Heissenbuttel, M., & Braun, T. (2003). A novel position-based and

beacon-less routing algorithm for mobile ad-hoc networks. In Pro-ceedings of the of the 3rd IEEE workshop on applications and ser-vices in wireless networks, (ASWN’ 03) (pp. 197–210), July 2003.

10. Heissenbuttel, M., Braun, T., Walchli, M., & Bernoulli, T.

(2007). Evaluating the limitations of and alternatives in beacon-

ing. Ad Hoc Networks, 5(5), 558–578.

11. Levis, P., Lee, N., Welsh, M., & Culler, D. (2003). TOSSIM:

Accurate and scalable simulation of entire TinyOS applications.

In Proceedings of the of the first ACM conference on embeddednetworked sensor systems, (SenSys 2003), November 2003.

12. Li, J., Jannotti, J., De Couto, D. S. J., Karger, D. R., & Morris, R.

(2000). A scalable location service for geographic ad hoc rout-ing. New York, NY: ACM Press.

13. Mauve, M., Fußler, H., Widmer, J., & Lang, T. (2003). Position-

based multicast routing for mobile ad-hoc networks. ACM SIG-MOBILE Mobile Computing and Communications Review, 7(3),

53–55.

14. Ovalle-martınez, F., Nayak, A., Stojmenovic, I., Carle, J., &

Simplot-Ryl, D. (2006). Area based beaconless reliable broad-

casting in ad hoc and sensor networks. International Journal ofSensor Networks, 2(2), 147–159.

15. Sanchez, J. A., Marın-Perez, R., & Ruiz, P. M. (2007). BOSS:

Beaconless on-demand strategy for geographic routing in wire-

less sensor networks. In Proceedings of the 4th IEEE interna-tional conference on mobile ad-hoc and sensor systems (MASS’07), October 2007.

16. Sanchez, J. A. & Ruiz, P. M. (2006). Lema: Localized energy-

efficient multicast algorithm based on geographic routing. In

Proceedings of the 31st IEEE conference on local computernetworks (LCN ’06) (pp. 3–12), November 2006.

17. Sanchez, J. A., Ruiz, P. M., Liu, J., & Stojmenovic, I. (2007)

Bandwidth-efficient geographic multicast routing protocol for

wireless sensor networks. IEEE Sensors Journal, 7, 627–636.

18. Stojmenovic, I. (2002). Position based routing in ad hoc wireless

networks. IEEE Communications Magazine, 7(40), 128–134.

19. Viswanath, K., & Tsudik, G. (2006). Exploring mesh and tree-

based multicast routing protocols for manets. IEEE Transactionson Mobile Computing, 5(1), 28–42.

20. Witt, M., & Turau, V. (2005). BGR: Blind geographic routing

for sensor networks. In Proceedings of the of the third workshopon intelligent solutions in embedded systems (WISES’05) (pp.

51–61), Hamburg, Germany, May 2005.

21. Woo, A., Tong, T., & Culler, D. (2003). Taming the underlying

challenges of reliable multihop routing in sensor networks. In

Proceedings of the first international conference on embedded net-worked sensor systems (SenSys ’03) (pp. 14–27), November 2003.

22. Zhao, J., & Govindan, R. (2003). Understanding packet delivery

performance in dense wireless sensor networks. In Proceedings ofthe first international conference on embedded networked sensorsystems (SenSys ’03) (pp. 1–13), November 2003.

23. Zorzi, M., & Rao, R. R. (2003). Geographic random forwarding

(GeRaF) for ad hoc and sensor networks: energy and latency

performance. IEEE Transactions on Mobile Computing, 2(4),

349–365.

Author Biographies

Juan A. Sanchez received his

B.Sc. (1999), M.Sc. (2004) and

Ph.D. (2006) degree in Com-

puter Science from the Univer-

sity of Murcia, Spain. For over

4 years he was involved in

several national and interna-

tional R&D projects in the field

of wireless and mobile net-

works, multimedia applications

and next generation networks as

member of the R&D department

of Agora Systems S.A. Cur-

rently, he is Associate Professor

at the Department of Commu-

nications and Information Engineering (DIIC), at the University of

Murcia (UMU).

Rafael Marin-Perez received

his B.Sc. (2006) and M.Sc.

(2007) degree in Computer

Science from the University of

Murcia, Spain. He is a

researcher in the Department of

Information and Communica-

tion Engineering (DIIC) at the

University of Murcia (UMU),

and he has worked in several

national and international R&D

projects in the field of wireless

sensor networks and multimedia

applications.

Wireless Netw (2012) 18:565–578 577

123

Pedro M. Ruiz received his

B.Sc. (1999) and M.Sc. (2001)

and Ph.D. (2002) degrees in

Computer Science from the

University of Murcia, Spain. He

is a Ramon y Cajal Researcher

in the Department of Informa-

tion and Communication Engi-

neering (DIIC) at the University

of Murcia (UMU), and he has

also held Post-doctoral research

positions at ICSI in Berkeley,

King’s College London and

University of California at Santa

Cruz. During these years he has

acted as Principal Investigator in several projects mainly funded by

the European Union, Spanish government and private companies, and

has published over 60 refereed papers in international journals and

conferences. Dr. Ruiz is in the editorial board for the International

Journal on Parallel, Emergent, and Distributed Systems, he partici-

pates in the Technical Committee of several conferences, and he has

served as a reviewer for major IEEE journals and conferences. His

main research interests include sensor networks, mobile and ad hoc

wireless networks and distributed systems. He is a member of the

IEEE Communications Society.

578 Wireless Netw (2012) 18:565–578

123