Routing Using Partition-Wide Informationin Wireless Delay Tolerant Networks

Anna SideraDepartment of Electrical and Computer Engineering

University of Cyprus, Cyprus

Stavros ToumpisDepartment of Informatics

Athens University of Economics and Business, Greece

Abstract—We present the Extended Minimum Estimated Ex-pected Delay (EMEED) protocol. EMEED is designed for usein wireless Delay Tolerant Networks (DTNs) that consist of alarge number of highly mobile nodes with non-uniform mobilitypatterns. Under the EMEED protocol, any two nodes that areoften in contact, either directly or through a multihop path,disseminate in the network the expected time they have to waituntil they come into contact. Nodes route packets according torouting tables created using these expected times. When its mainparameter, the contact radius, is equal to unity, the EMEEDprotocol operates similarly to the well known MEED protocol.However, using simulations, we show that for many mobilityscenarios, when the contact radius is greater than unity, theEMEED protocol performs far better than MEED, in terms ofthroughput and delay, with only a modest increase in the controloverhead.

I. INTRODUCTION

We present the Extended Minimum Estimated Expected

Delay (EMEED) protocol, a protocol for performing routing

in wireless Delay Tolerant Networks (DTNs). EMEED is

designed for use in networks where the number of nodes

is large and they exhibit non-uniform mobility patterns, for

example each node visits some locations more often than oth-

ers. There are many DTNs for which these assumptions hold,

for example, wildlife tracking networks [1], [2], Vehicular

DTNs [3], [4], and Unmanned Aerial Vehicle (UAV) DTNs [5].

Under the EMEED protocol, any two nodes that are in

contact often, either directly or through a local multihop path,

disseminate in the network the expected time they have to wait

until they come in contact. Nodes create routing tables such

that the cost of a link between two nodes is related to this

expected time, and they use these routing tables to forward

packets.

When its main parameter, the contact radius, is set to one,

the EMEED protocol approximates the well known MEED [6]

protocol that takes into account, when constructing the routing

table, only direct contacts between nodes. For values of the

contact radius larger than one, EMEED also takes into account

indirect contacts through multihop paths.Except from MEED, another protocol related to our own

is Bubble Rap [7]. Under this protocol, each node finds its

community, its global popularity, and its popularity within its

community, and a node A decides if it will give a copy of

a packet to another node B based on the popularities of Aand B and whether A and B are in the community of the

destination. The authors claim that Bubble Rap creates less

control overhead than MEED because nodes do not use routing

tables, however, under the protocol multiple copies are created

for each packet, and no comparison to MEED is offered via

simulation or analysis.

II. THE EMEED PROTOCOL

The main parameter of the EMEED protocol is the contactradius RC . When, according to the current topology, two

nodes i and j are separated by at most RC hops, we say

that i and j are in contact. The parameter RC can take the

following values: (a) RC = 1, 2, 3, . . ., (b) RC =∞, in whichcase two nodes are in contact if they are in the same partition.

As we show later on, when RC = 1, the EMEED protocol

operates similarly to the MEED protocol.

Estimation of Expected Delays: Every node j maintains,for every other node k, an estimate of the expected value

E[WT (j, k)] of the time it will have to wait until it comes incontact with node k. These estimates are calculated as follows:assume that from time 0 until time T node j is not in contactwith node k for m intervals of durations d1, d2, . . . , dm and

that for the rest of the time from time 0 to time T nodes jand k are in contact. Then j estimates E[WT (j, k)] using theformula

E[WT (j, k)] = (d21 + d22 + · · ·+ d2m)/(2T ).

This method for estimating E[WT (j, k)] was used in [6], andits use is justified there.

Creation of Expected Delay Routing Table: The nodesdisseminate the estimates of the expected delays in the network

and so each node i stores the estimates of E[WT (j, k)]for different pairs of nodes (j, k). Nodes forward packets

according to a routing table they create, called the expecteddelay routing table. Every node i creates its expected delayrouting table performing shortest path routing on a graph

called the expected delay graph of node i. This graph consistsof links of cost E[WT (j, k)] for each pair j and k for which ihas a value of E[WT (j, k)] in its memory, but we set to 0 thecosts of the links from node i to every node that is currentlywithin RC hops of node i.Dissemination of Expected Delays: At fixed time intervals,

every node j creates a new packet of estimates E[WT (j, k)],puts a timestamp on it, and sends it to all its direct neighbors.

Each node that receives this packet, and does not have a packet

978-1-4799-1004-5/13/$31.00 ©2013 IEEE

2013 12th Annual Mediterranean Ad Hoc Networking Workshop (MED-HOC-NET)

14

of estimates of node j with a newer timestamp, stores its

contents and then sends it to all its direct neighbors, also at

fixed time intervals. In order to keep a check on the amount of

routing overhead used for the dissemination of the expected

delays, the protocol uses two parameters, the routing tablecost threshold CT and the number of friends NF . When

the expected delay routing table of a node is created, only

paths of total cost CT or less are discovered. Furthermore,

nodes do not send in the network estimates of expected wait

times that are larger than CT . If a node estimates more than

NF expected wait times to be smaller than CT , it sends the

NF smaller ones.

III. PERFORMANCE EVALUATION

In order to evaluate our protocol, we have developed a

simulation tool, specifically designed for DTNs, and written in

C. We refrain from using off-the-shelf DTN simulation tools

like ONE [8] because we are interested in studying very large

networks, for which a lean, customized simulator based in C

is ideally suited.

A. Simulation Setting

Slotted Time: We divide time in slots of duration equal to15 minutes. The positions of the nodes are fixed during a slot.Mobility Model: We consider a square area in which we

have n1 = 1000 nodes, that we call persistent nodes, movingas follows: at the beginning of the simulation each node

selects, randomly and uniformly in the square area, a location

called home (H), a location called destination 1 (D1), and a

location called destination 2 (D2). At the beginning of each

day the node is at its H . It stays there for a number of slotschosen randomly between 0 and a maximum value. Then it

selects randomly either to go to its D1 or to its D2. It stays

there for a number of slots chosen randomly between 0 anda maximum value. Then it returns to its H . The maximumnumber of slots before it leaves H and the maximum number

of slots it stays at D1 or D2 are chosen such that the node

leaves H and returns to it during the same day.

We assume that when the node leaves H it appears im-

mediately at D1 or D2 and when the node leaves D1 or D2

it appears immediately at H . This approximation is made inorder to speed up the simulation. Indeed, it would take too long

to run a simulation that accurately simulates the movement of

the nodes in detail for a large number of days. We believe that

this approximation is reasonable, taking into account the topic

and the scope of this work.

Also, at each slot we have n2 = 1000 transient nodes,that exist in the network only for that slot, at positions

selected randomly and uniformly on the square area, and then

disappear. In a vehicular DTN scenario these nodes would

correspond to cars that are at a location that they do not visit

often, whereas persistent nodes would be cars that are parked

outside their owner’s home, or office, or any other location the

owner frequents.

Transmitter-Receiver Model: All nodes have the sametransmission range R. We assume that the nodes can only

PARAMETER NUMERICAL VALUENumber of persistent nodes n1 = 1000Number of transient nodes n2 = 1000Average node degree N = 1

Side of the grid in which the nodes move α = 100 kmSteady state time TS = 96000 slotsDuration of a day 96 slots

Maximum time before go to destination 56 slotsMaximum time stay at destination 32 slots

Packet TTL 480 slotsRouting table cost threshold CT = 960 slots

Number of friends NF = 200Buffer size B = ∞

TABLE IDEFAULT SIMULATION PARAMETERS.

communicate directly with each other if they are at a distance

R or less from each other. (We use as input parameter the

average node degree N and the simulation calculates R.)

Traffic: Initially, for some time that we term the steadystate time TS , we run the protocols without creating packets.This gives the nodes time to estimate the expected wait times

and disseminate them in the network. At time equal to TS ,every node creates one packet for every other node, then, the

simulation runs for time equal to the Time To Live (TTL) of

the packets, and then it stops.

Packet Forwarding: At each slot, each packet is forwardedfrom node to node, according to the expected delay routing

tables of its consecutive holders. The forwarding stops when

the packet reaches its destination or a node that cannot forward

the packet because the next hop is not in the same partition

with it.

Buffer Policy: All nodes have sufficiently large buffer

spaces so that packets are discarded only when their TTL

elapses.

PHY and MAC layers: We assume that transmissions arealways successful, and there is no contention. In other words,

if two nodes are in the same partition and the routing protocol

instructs them to exchange a packet, the packet exchange is

always successful.

B. Results

Unless otherwise stated, the parameters used in the simula-

tions are those of Table I.

Fig. 1 shows the delivery ratio versus the TTL. Various

values of RC are used. We observe that as we increase the

value of RC , the delivery ratio increases. However, by far the

greatest improvement appears when we go from the RC = 1case (i.e., the case of MEED) to the RC = 2 case. This impliesthat our protocol achieves impressive gains even with modest

increases of the control overhead.

Fig. 2 shows the delivery ratio versus the average node

degree. Observe that we are interested in node degrees close

to unity, as, for larger node degrees, our networks are totally

connected, whereas our protocol is focused on delay tolerant,

i.e., disconnected networks.

2013 12th Annual Mediterranean Ad Hoc Networking Workshop (MED-HOC-NET)

15

0 200 400 600 800 10000

0.2

0.4

0.6

0.8

1

Time to Live (timeslots)

Del

iver

y R

atio

MEEDRC=2

RC=3

RC=4

Fig. 1. Delivery Ratio versus Time To Live.

1 2 3 4 50

0.2

0.4

0.6

0.8

1

Average Node Degree

Del

iver

y R

atio

MEEDRC=2

RC=3

RC=4

Fig. 2. Delivery Ratio versus Average Node Degree.

Fig. 3 shows results for the delivery ratio versus the total

number of nodes, where at each point in the plot, half of the

nodes are persistent and half of the nodes are transient.

Using our standard input parameters set shown in Table I,

we also obtained results for the delivery ratio versus the

number of friends NF , for various values of the contact radius

RC . We do not show these results here due to lack of space.

We observe that we do not need a large value of NF to get

good results. For example, the delivery ratio for NF = 10 iswithin 1% of the delivery ratio for NF = 200. In our standardparameters set of Table I we choose NF = 200 because we

0 500 1000 1500 20000

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Total Number of Nodes

Del

iver

y R

atio

MEEDRC=2

RC=3

RC=4

Fig. 3. Delivery Ratio versus Total Number of Nodes.

want to use a large value of NF that gives good results not

only for N = 1 but also for larger values of N .We also obtained results for the delivery ratio versus the

number of transient nodes, where the number of persistent

nodes is fixed. We do not show these results here due to lack

of space. We observed that when there are no transient nodes,

our protocol does not perform much better than MEED. When

there are transient nodes, however, our protocol achieves much

higher delivery ratio. This shows that the main advantage

of our protocol over MEED is that our protocol makes

use of paths connecting a source and a destination that are

partially comprised of transient nodes. By its construction,

MEED ignores such paths, whereas our protocol utilizes them

extensively. This leads to notable improvements over MEED

when the number of transient nodes is substantial.

Finally, we obtained simulation results using the setting

described above, but in the mobility model, instead of having

n2 = 1000 transient nodes, we have n2 = 1000 nodes thatexist in the network for the whole duration of the simulation,

and at each slot select their positions randomly and uniformly.

The results are almost the same as when using the mobility

model in which we have transient nodes. This can be explained

as follows: Let i be one of these n2 = 1000 nodes. Nodei is not in contact with any other node often. Thus, the

E[WT (i, j)] is large for any node j. It follows that the linksfrom node i to other nodes are not used in the creation of theexpected delay routing table of any node.

IV. CONTROL OVERHEAD

A. Estimation of Expected Wait Times

As already discussed, at predefined time intervals, each node

i sends a control message to each node j that is at most RC

hops away from i, notifying it that i and j are in contact.

2013 12th Annual Mediterranean Ad Hoc Networking Workshop (MED-HOC-NET)

16

Node j uses this information to calculate E[WT (i, j)]. Thesecontrol messages must be sent often, for the expected delays

E[WT (i, j)] to be estimated accurately. These control mes-sages are also used so that the nodes know which links are up

at any time and so which costs to set to 0 in the creation oftheir expected delay routing table.

Observe that the volume of these messages per node remains

constant as the number of nodes in the network increases. For

this reason, unless the topology of the network changes very

fast, we expect that only a modest fraction of the bandwidth

will be consumed for their propagation.

B. Dissemination of Expected Wait Times

The control overhead needed for the dissemination of the

expected wait times increases with the network size, and hence

is expected to be more substantial.

However, in our simulations we observe that, for N = 1,we get good results even for small values of the number of

friends NF , i.e., disseminating only a few expected wait times

is enough to give good results.

Simulations show that when the value of RC increases, the

value of NF needed to get best results also increases. Thus,

comparing the protocols with RC > 1 to MEED, we see thatwe do not only need more control messages for the estimationof the expected wait times, but we also need larger control

messages for their dissemination, since when NF is larger,

these control messages contain more expected wait times and

corresponding node IDs.

The estimation of E[WT (i, j)] for two nodes i and j thatare often in indirect contact needs more control messages, and

thus more bandwidth, than the estimation of E[WT (i, j)] fortwo nodes i and j that are often in direct contact. It followsthat the increase in control overhead for the estimation of the

expected wait times when RC increases is both because the

protocol discovers more expected wait times that are smaller

than CT and because it is more costly (in bandwidth) to

discover the extra expected wait times. On the other hand,

the dissemination of E[WT (i, j)] in the network needs thesame bandwidth for two nodes i and j that are often in

direct contact and two nodes i and j that are often in indirectcontact. It follows that the increase in control overhead for the

dissemination of the expected wait times when RC increases is

only because the protocol discovers more expected wait times

that are smaller than CT and not because it is more costly (in

terms of bandwidth) to disseminate the extra expected wait

times.

The interval between control messages for the dissemination

of the expected wait times does not have to be very small

because each node needs to receive each expected wait time

only once before its value changes. The interval should be

such that the topology changes appreciably during the interval.

There are scenarios in which the expected wait times do not

change frequently. For example, most people live in the same

houses and work in the same offices for long periods of time.

In this case, the nodes can measure the expected wait times

constantly as explained above, but do not have to propagate

them further to other nodes continuously. In our future work,

we plan to implement the following algorithm to disseminate

the expected wait times. When a node sees that some expected

wait times it measures have changed significantly, it sends

them to other nodes, and these propagate the new values

further. Otherwise, the node creates no new control traffic.

V. CONCLUSIONS

We present the Extended Minimum Estimated Expected De-

lay (EMEED) protocol, a protocol designed for use in Wireless

Delay Tolerant Networks (DTNs) that consist of nodes with

non-uniform mobility patterns. Under EMEED, any two nodes

that are in contact often, either directly or through a multihop

path, disseminate in the network the expected time they have to

wait until they come into contact. Nodes create routing tables

where the cost of a link between two nodes depends on this

expected time and they use these routing tables to forward

packets. When its main parameter, the contact radius, is set to

unity, the EMEED protocol behaves similarly to the MEED [6]

protocol, which considers two nodes to be in contact only

when they can communicate directly. For other values of the

contact radius, EMEED considers two nodes to be in contact

when they can communicate directly or indirectly through a

multihop path. Using simulations, we show that, for important

mobility scenarios, the EMEED protocol performs far better

than MEED, in terms of throughput and delay, with only a

modest increase in the control overhead.

ACKNOWLEDGMENT

This research has been co-financed by the European Union

(European Social Fund - ESF) and Greek national funds

through the Operational Program ”Education and Lifelong

Learning” of the National Strategic Reference Framework

(NSRF) Research Funding Program “THALES Investing in

knowledge society through the European Social Fund”.

REFERENCES

[1] T. Small and Z. J. Haas, “The shared wireless infostation model – a newad hoc networking paradigm (or where there is a whale, there is a way),”in MobiHoc, Annapolis, MD, June 2003.

[2] P. Juang, H. Oki, Y. Wang, and M. Martonosi, “Energy-efficient com-puting for wildlife tracking: Design tradeoffs and early experiments withzebranet,” in ASPLOS-X, San Jose, CA, Oct. 2002.

[3] P.-C. Cheng, K.-C. Lee, M. Gerla, and J. Harri, “GeoDTN+Nav: Ge-ographic DTN routing with navigator prediction for urban vehicularenvironments,” Mobile Networks and Applications, vol. 15, no. 1, pp.61–82, 2010.

[4] A. Sidera and S. Toumpis, “Delay tolerant firework routing: A geographicrouting protocol for wireless delay tolerant networks,” EURASIP Journalon Wireless Communications and Networking, 2013.

[5] E. Kuiper and S. Nadjm-Tehrani, “Geographical routing with locationservice in intermittently connected MANETs,” IEEE Transactions onVehicular Technology, vol. 60, no. 2, pp. 592–604, 2011.

[6] E. Jones, L. Li, J. Schmidtke, and P. Ward, “Practical routing in delay-tolerant networks,” IEEE Transactions on Mobile Computing, vol. 6,no. 8, pp. 943–959, 2007.

[7] P. Hui, J. Crowcroft, and E. Yoneki, “BUBBLE rap: Social-based forward-ing in delay-tolerant networks,” IEEE Transactions on Mobile Computing,pp. 1576–1589, Nov. 2011.

[8] A. Karanen, J. Ott, and T. Karkkainen, “The ONE simulator for DTNprotocol evaluation,” in Proc. Simutools 2009, Rome, Italy, March 2009.

2013 12th Annual Mediterranean Ad Hoc Networking Workshop (MED-HOC-NET)

17