Peer-to-Peer Netw. Appl.
DOI 10.1007/s12083-016-0533-5
CTMR-collaborative time-stamp based multicast routing
for delay tolerant networks in post disaster scenario
Amit Kumar Gupta 1 & Jyotsna Kumar Mandal 2 & Indrajit Bhattacharya 1 &
Tamal Mondal 1 & Sourav Sanu Shaw 1
Received: 15 March 2016 / Accepted: 26 October 2016
# Springer Science+Business Media New York 2016
Abstract Due to high chances of loss in connectivity, a Delay
Tolerant Network (DTN) can be used to communicate between
nodes without having any fixed connection between the source
and destination. A Post Disaster Scenario presents a very chal-
lenging environment to communicate in and to analyze those
situations is even a harder task to accomplish. It necessitates
very efficient co-ordination to successfully accomplish situation
analysis and resource management. Efficient co-ordination be-
tween relief and rescue teams in such situations can be achieved
through multicasting, since it allows sending single packet to
multiple destinations. Though multicasting in MANET has
been studied extensively, but the implementation of efficient
multicasting in DTN is a very challenging task due to its fre-
quent partitioning characteristic. In this work a Collaborative
Time-Stamp based Multicast Routing (CTMR) Protocol has
been proposed. The messages have been implemented using
customized bundles, where the destination of a multicast bundle
consists of a group of nodes. Node grouping mechanism has
* Amit Kumar Gupta
amitgupta.kgec@gmail.com
Jyotsna Kumar Mandal
jkm.cse@gmail.com
Indrajit Bhattacharya
indra51276@gmail.com
Tamal Mondal
tamalkalyanigov@gmail.com
Sourav Sanu Shaw
souravshw@gmail.com
1
Kalyani Government Engineering College, Kalyani, West Bengal,
India
2
University of Kalyani, Kalyani, West Bengal, India
been adopted to suit a post disaster condition. Collaborative
bundle creation and selection mechanism has been utilized so
that localized redundant information flow is minimized.
Suitable time and space limits have been selected to further
reduce redundancy. The group forwarding strategy is based
on probabilistic measures calculated using historical encounter
records, and on a multiple parameter priority queue. This pro-
tocol has been implemented in the ONE simulator and is com-
pared with other existing unicast and multicast routing proto-
cols on important routing parameters like delivery ratio and
delivery delay. Comparison results show that CTMR can be a
novel efficient solution to multicasting in a DTN.
Keywords Opportunistic network . Delay tolerant networks .
Post disaster scenario . Multicast . Collaborative . ONE
simulator
1 Introduction
In the context of networking, multicasting is the process of
communication between one to many as well as many to many
groups of entities. It differs from unicasting and broadcasting
with respect to the number of destinations a message has been
assigned to. A unicast message has a single destination; a
broadcast message has all the possible entities as destinations
whereas a multicast message has multiple numbers of selective
destinations. Multicast offers many advantages over both
unicast and broadcast mode of communication. It offers quick
and increased probability for message deliveries for well-
known multicast destinations as compared to unicast. On the
other hand, it reduces overhead by not overwhelming the sys-
tem with messages as in a broadcast mode. DTN [1] is a wire-
less networking approach that can be used in situations where
end-to-end connectivity cannot be guaranteed, and where

networks suffer huge disruptions because of external factors
like wireless radio range limitation, sparse and mobile nodes,
energy constraints, etc. In any post-disaster scenario DTN net-
works are preferred. Working of any existing communication
infrastructure such as Internet or any cellular network cannot be
guaranteed in those challenging situations. This results in im-
proper communication infrastructure, where it cannot be en-
sured when a message reaches the destination. Since TCP/IP
and other communication protocols cannot work in DTN,
hence the DTN Research Group has proposed architecture ca-
pable of communicating in challenging scenarios like DTN [2].
DTN has wide applications in terrestrial environment, and post-
disaster scenario that lack continuous connectivity. Previous
studies have shown that in some DTN networks (e.g. Pocket
Switched Networks, PSN) DTN routing approach in not an
appropriate solution [3]. It has been suggested that some
forwarding mechanisms can be an alternate approach in these
situations. In Internet architecture routing and forwarding are
distinguishable. In DTN, routing algorithm is executed for com-
putation of paths for message delivery to achieve routing ob-
jectives. On the other hand, forwarding signifies moving bun-
dles between two DTN nodes. Some DTN routing algorithms
provide forwarding mechanisms, but these approaches are not
appropriate for most DTN scenarios as much of this mobility
pattern is unpredictable [4]. Hence, bundle forwarding based on
some network behavior aspects can be an alternate solution.
Again, only forwarding cannot be a good solution when there
are multiple receivers of a bundle. In DTN, the choice of wheth-
er to select a routing or a forwarding strategy depends on the
implementers [5].
It has been observed that some forwarding strategies like the
Bubble Rap [3] perform better as compared to some unicast
DTN routing protocols in terms of certain network parameters.
But, these forwarding strategies are applicable only when there
is a single destination for a message. In real DTN scenarios
there can be multiple receivers of any message. As multicasting
supports efficient distribution of data to group members [6],
there should be a focus on group formation. As mentioned
earlier, multicasting in MANET is not a challenging issue as
the receivers or group members of a multicast packet are well
defined. As the data transfer delay in a MANET is too short,
group membership changes during data transfer can be ignored
[6]. But due to frequent partitioning in DTN, large amount of
delay in data transfer can happen and membership changes can
be frequent rather than exception. So an efficient multicasting
and group formation mechanism is needed so that multicast
packets can be delivered to the members.
The bundle layer protocol [7] defines a series of adjoining
data blocks as bundles, where each bundle has enough infor-
mation to allow applications to make decisive progress.
Bundles are generally routed in a store-carry-and-forward man-
ner between participating nodes over the network. Two nodes
are called neighbors if they are within their connection range. A
Peer-to-Peer Netw. Appl.
DTN may consist of several paths in multiple hops. Hops are
the mobile nodes moving from one place to another. The topol-
ogy of the DTN layer often changes dynamically due to fre-
quent link ups and downs. As mentioned in [6], data transfer in
DTNs occurs in data units called messages or bundles. Hence,
the term message/ bundle can be used alternatively. There are
number of ways in which a node sends a bundle to single
destination, such as Epidemic [8], Prophet [9], Max-prop
[10], Spray and Wait [11], RAPID [12], MBRP [13], Bubble
Rap [3], Delegation Forwarding [14], etc. These strategies are
developed to communicate in DTN in one to one mode. These
protocols are not adequate in emergency response scenarios, as
there are multiple group of members (e.g. doctors, nurse, police,
and army) present in a relief/rescue team and they are scattered
at different places. For such group communication, there can be
separate unicast operations to each members of a group. But
due to limitations in path availability, power and storage restric-
tion in DTN environment, it is not a promising solution [15].
Efficient routing using multicasting can be constructed by using
partial knowledge of unicast routing protocols [16]. In the pro-
posed work, as mentioned earlier we have taken such partial
knowledge i.e. forwarding strategy from Prophet unicast
routing protocol and on top of that developed a novel multicast
routing strategy applicable for post disaster scenarios.
Multicast helps disconnected rural areas to utilize the oppor-
tunities in exchanging information effectively and efficiently,
for applications like data circulation, file sharing, etc. Many
multicast protocols have been proposed in Adhoc wireless net-
works. These include Multicast Extensions to Open Shortest-
Path First (MOSPF) [17], Distance Vector Multicast Routing
Protocol (DVMRP) [18], Ad hoc Multicast Routing protocol
(AMRoute) [19] and the On-Demand Multicast Routing
Protocol in multi hop wireless networks (ODMRP) [20].
These MANET routing protocols are not suitable for DTN,
due to the challenge of frequent network partitions. The main
objective of this work is to implement a routing protocol that
transmits information to multiple destinations via multiple paths
to achieve better delivery of messages over a DTN.
A Post-disaster recovery area is divided into number of dif-
ferent sites, as the affected area can be huge and scattered in a
large scale disaster. In each of these sites, relief work is per-
formed. Government organizations work together with a num-
ber of NGO’s. It has been observed that non-government relief
organizations choose a site for their relief operations for a par-
ticular period of time [21]. The main purpose of such relief
work is to provide help to the needy by providing immediate
rescue and emergency resources. The term ‘resource’ in this
context refers to the emergency requirements of any affected
area after any large scale disaster. These emergency require-
ments can be generally categorized as Rescuers, Medical,
Food, Water, Clothes. As it is a very challenging task to com-
municate and analyze the requirement of particular needs and
the volume, hence, there is necessity to device an efficient
Peer-to-Peer Netw. Appl.
routing algorithm to deliver packets to different members of a
relief/rescue team in a post-disaster situation. Without knowing
the actual needs of various sites, it is not possible to coordinate
the relief operation efficiently. There should be an efficient
mechanism of information exchange that takes care of the relief
operation. This information exchange is performed using smart
phones carried by the relief workers. Every relief worker or any
affected person in the disaster area is considered as a node in the
proposed protocol. Smart phones are used to create bundles that
incorporate messages created by the relief workers or affected
people. These smart phones are capable of receiving and send-
ing bundles. Multicasting is a preferred communication mode
in these cases as the destination is not a single node in most of
the cases. A single bundle is sent to multiple nodes which are
assigned as the destination group or DTN endpoints. A bundle
is considered to have been successfully delivered to a destina-
tion group when at least a predefined subset of the nodes of
destination group has received the bundle successfully. These
destination groups are statically fixed before the field
deployment.
The number of groups constructed in a disaster area depends
on their responsibilities. We have considered various groups like
a group of Police, Doctors, Nurses, Ambulances, etc. There might
besub-groupsunderagroup.Asforexample,underDoctorgroup
there may be many sub-groups depending upon their specializa-
tions or expertise. Information about destination groups includes
the number of members in the group, member identification,
name of each member, etc. This information helps the sender
node to decide what bundles need to be sent to which group.
In the present work a collaborative time-stamp based
multicast routing protocol is designed for a DTN. Each node,
before sending data to a particular destination group, scans its
neighborhood to find out the neighbors with similar type of
interest. Nodes are said to have similar types of interest if they
have similar messages destined to the same group. Among all
such nodes, the most promising node takes the responsibility to
create the bundle and forward it towards the destination. All
necessary information regarding the destination group members
like the number of resource instances (e.g. doctors, ambulance,
nurses, and food) required for the sites, etc. are padded with the
message. As the bundle is received at the destination group, it is
decoded to get necessary content like the need of a site from
where the bundle was sent. This eases need assessment and
resource management for entities in the destination groups.
The remaining paper is organized as follows. Section 2
shows the related work in the field of routing protocols in
DTN. Section 3 presents the proposed DTN multicast routing
protocol followed by details about the bundle creation tech-
nique, forwarding techniques, and bundle priority. Section 4
describes the experimental setup required for performing our
simulations in the ONE simulator. Simulation results are pre-
sented and discussed in Section 5. Section 6 ends the paper
with a conclusion.
2 Related work
A number of works have been reported in the field of routing
in DTN. Most of the existing DTN routing protocols focus on
unicast mode of transmission, such as Epidemic [8], Prophet
[9], Max-prop [10], Spray and Wait [11], RAPID [12], MBRP
[13] that transmit a bundle to a single destination. As men-
tioned earlier, these protocols are not suitable for emergency
response scenarios including a post-disaster scenario. When
multiple destination nodes are present, a multicast routing
protocol is preferable over others. Very limited work has been
performed in the area of multicasting and group membership
mechanisms that define constraints applied on group member-
ships in multicasting in DTN. In this section, different seman-
tic models that explicitly specify constraints on group mem-
bership are discussed first. Then it has been shown that the
proposed multicast routing technique supports one of these
semantic models. Recent multicast routing strategies that in-
clude Unicast Based Multicast, Static Tree Based Multicast,
Dynamic Tree Based Multicast, OS-Multicast, Non-Custodial
Multicast over Prophet, Scalable Multicasting, Mobility based
routing algorithm in DTNs, Directional routing and schedul-
ing for green vehicular DTNs, Quota Based Multicast Routing
in DTNs, Social Profile based Multicast Routing for DTNs,
and A Novel Mobility Based Routing Protocol for Semi
Predictable DTNs are discussed and critically reviewed after-
wards. We also discuss two of the most recent forwarding
strategies in DTN that include Bubble Rap (BR) and
Delegation Forwarding (DF). A comparative study of existing
recent DTN multicast routing methods and DTN forwarding
strategies has been presented in Table 1. A brief discussion of
these is presented next.
2.1 Multicast semantics model
In the multicast semantics model [6], authors have described
three semantic models to implement group formation in DTN
multicasting. Different semantic models [6] include- a)
Temporal Membership model (TM), b) Temporal Delivery
model (TD) and c) Current Member Delivery model (CMD).
In TM model the intended receivers of the bundle are
defined at the time of bundle creation. The actual receivers
can be a subset of the set of intended receivers. Similarly,
they define the group id of the receiver. Here, a member-
ship interval specifies that the group members are defined
within that time period. In TD model the bundle specifies
an extra constraint of delivery interval which indicates the
time period within which the bundle should be delivered to
the intended receivers. In CMD Model, they have specified
a CMD flag which shows whether the receiver is the mem-
ber of the group at the time of receiving the bundle. When
the CMD flag is set the intended receivers of the bundle
should be the group members at the time of delivery. If the
 Peer-to-Peer Netw. Appl.

Table 1 DTN multicast routing and forwarding strategies

DTN multicast routing strategies

1. Unicast based multicast [4]
Protocol Strategy Remarks
It is based on the concept of doing a one-to-many data communication by This technique is not adequate for DTN where efficient data transfer is very
multiple one-to-one source-to-destination unicast data transfers. If a challenging due to frequent network partitioning, limited power, limited
node creates a multicast bundle for n destinations then that bundle is bandwidth, limited storage. It does not provide promising solution in
replicated n times, as shown in Fig. 1. The sender queries the underlying emergency situations like post disaster scenario, military battlefield, etc.
network to collect all the discovered historical end-to-end paths to that where efficient data transfer is of utmost need.
destination. If the source finds any established link, then a copy of the
multicast bundle is forwarded to the next hop.
2. Static tree based routing (STBR) [4]
Here, nodes construct a tree starting from source to intended receivers. The If the tree is not available, sender just keeps the bundle in buffer and waits
nodes between sender and the receiver are selected as intermediate hops for next availability of the tree to send the bundle towards the
for the bundle using Dijkstra’s algorithm. As the route is static, if a node destination. This protocol is suitable for scenarios where network
misses the contact then it has to wait for the next contact. Use of partitions occur in a scheduled manner (like satellite communication).
multicast tree reduces redundant traffic. When communication starts, the But in an emergency situation where network partitions occur frequently,
source queries its underlying network to find out historical end to end this protocol is not promising. There should not be full dependence on a
paths to all group members, as presented in Fig. 2. It then builds up a multicast tree. STBR also suffers from large buffer overheads.
shortest path tree based on this information and keeps sending bundles
along the tree.
3. Dynamic tree based routing (DTBR) [4]
Here, routes are dynamic and use explicit addressing approach. Nodes This protocol suffers from lack of coordination between multicast group
determine next hop through current or newly derived contact members as it is not the responsibility of any multicast group member to
information. Each bundle has a unique multicast tree that may change transfer bundles to other members. In a DTN scenario due to non- esti-
hop-by-hop to adopt changes in link up and down. Each node has the mated delay in data transfer the group members may frequently join or
capability to extend its own tree, as has been shown in Fig. 3. It com- leave the group. Some mechanism is needed where the destination itself
putes the smallest cost tree based on its current local view of DTN layer. can send the bundle to other destinations, if opportunity arises.
It forwards the bundle using its own discovered multicast tree. If there is
a newly available path to a destination which is not discovered by the
upstream nodes, this node may immediately take advantage of that in-
formation for sending bundles.
4. On demand situation aware multicast protocol (OS-multicast) [22]
It is based on the demand of path discovery and situation awareness of It does not eliminate redundant bundle created from same proximity for
connection availability. Situation request and reply system bundles gain same destination. A strategy is required that shares bundle’s contents of
availability of the network. DTN nodes create a situation request bundle neighboring nodes. Also, this protocol does not rely on global
into entire neighborhood to know the paths to destinations. The knowledge of the network. A post disaster scenario requires some past
neighbors create a situation reply bundle based on historic encounters to knowledge about neighboring nodes initially. An efficient method must
the receivers of the multicast bundles. The node combines all paths to take care of this from initial level by calculating delivery probability of
form a static mesh. When bundle is forwarded, the hop generates a new each neighbor who wants to create similar bundles for same destination
dynamic mesh over which the bundle is transferred to next hop. group.
5. Non-custodial multicast over the DTN-prophet protocol [23]
Here, PRoPHET model is used for probabilistic calculations along with This protocol may be reasonable for DTN scenario but it is not efficient in
little mobility information. Nodes share delivery predictions along with post disaster scenario because the duration for handling critical situations
the node’s moving directions. A pseudo multicast tree is implemented lasts for hours or days. Authors have tested for a maximum of 4600 s
that comprises of one source, a set of destinations and a set of which is not confident enough for implementing in a real scenario.
intermediate nodes. Using these information, nodes transfer bundles via
multiple hop to the destination.
6. Scalable multicasting [24]
Here, a DTN multicast protocol called RelayCast is presented whose A relay node plays a vital role in transferring packets, yet no mechanism
operation is based on 2-hop relay DTN routing which is performed in has been proposed to select a relay node. The multicast source simply
two phases. In phase 1, the multicast source sends a packet to a relay sends the packet to a relay node if it is in the vicinity of that source.
node (could be multicast receiver). In phase 2, if there remains any
multicast receiver who has not yet received the packet, the relay node
delivers the packet.
7. Mobility based routing algorithm in DTNs [25]
It is based on the information about the mobility of nodes and their contacts.
Authors have considered the node mobility as schematic where mobility of
Authors in this work assume that greater mobility of nodes results in nodes can be predicted by getting information from daily activity of
better contacts. This is basically a unicast routing protocol that achieves
people who carry smart phones. But in a post disaster scenario the
high delivery probability with low message overhead compared to other mobility pattern is not so easily predictable. Also, lack of proper support
unicast routing scheme. for multicasting renders it inefficient.
8. Directional routing and scheduling for green vehicular DTNs (DRSS) [26]
Peer-to-Peer Netw. Appl.

Table 1 (continued)
It presents a direction based routing scheme for green vehicles that can Authors have designed this technique for varying mobility patterns (traffic
optimize energy efficiency with the considerations of congestion, buffer patterns). The proposed technique can be applicable in a post disaster
and delay. The proposed technique learns from traffic patterns and selects situation where vehicle routes are intact after any disaster. It fails to perform
optimal route for packet delivery towards the destination. otherwise.
9. Quota based multicast routing in DTNs (QBMR) [27]
Here, a multicast routing scheme has been designed by giving extra This approach is highly prone to unnecessary bandwidth utilization.
attention on group membership maintenance. Authors in this work adapt a However, in a DTN efficient utilization of network parameters (bandwidth,
quota replication scheme to increase delivery rate and decrease message power, etc.) is of utmost importance. Unbounded replication of messages
relay cost. It uses a quota based multicasting where a quota >1 means that can’t be afforded in a resource scarce DTN environment.
the message can be duplicated and forwarded to another node (may or may
not belonging to the multicast group).
10. Social profile based multicast routing for DTNs (SPM) [28]
This paper proposes a multicast scheme based on exploration of some The dataset is not equally suitable for a post disaster situation as in a
social features of DTN. The social features have been obtained from disaster scenario, node mobility is much more unstable and unpredictable.
infocom6 data trace. Authors have adapted efficient affiliation and So, its applicability in a post-disaster scenario is uncertain.
language based group formation technique for message delivery purpose in
a multicast scenario.
11. A novel mobility based routing protocol for semi predictable DTNs (MBPR) [29]
This protocol proposes mobility based routing using space-time graph from Such a routing strategy is not suitable for emergency response scenario as
known mobility patterns of nodes. When the space-time graph is incom- there might be multiple group members in a relief/ rescue team and they are
plete, this technique relies on previous encounters to estimate future con- scattered at different places. No test for support of multicasting has been
tacts. It achieves better performance in terms of delivery probability, delay performed.
and hop count compared to other unicast routing schemes.
DTN forwarding techniques
1. Bubble rap [3]
It is a social based forwarding strategy that exploits two social and It used datasets gathered by Haggle Project over 2 years from Infocom05,
structural metrics namely community and centrality. It is designed for Hong Kong, etc. These datasets are not applicable in post disaster situations
pocket switched networks, a type of DTN where repeated disconnection where node mobility is unpredictable. We require techniques that suit
and re-wiring of network can be possible. This technique evaluates the specific requirements of a post-disaster situation.
impact of above mentioned metrics on forwarding and proposes a hybrid
algorithm that selects high centrality (within a community some node are
more popular and interact with more nodes than others) nodes and com-
munity members of destination as relays. In this work authors have used
utility of two community detection algorithms together for getting rich
information about human social clustering for useful design of a forwarding
strategy.
2. Delegation forwarding [14]
It is another novel forwarding approach where authors have shown that the Authors here assume buffer space of each node to be unlimited and that the
network cost is proportional to the square root of population size. Authors buffer will hold all replicated messages till delivery. In real DTN
assume that a set of mobile nodes Ni € M where |M| = N. Each generated environment there are limitations on storage, bandwidth, etc. Strategies are
message has a particular source S € M and a destination D € M. Generated required that meet real scenarios more precisely.
messages are transmitted from one node to another based on quality metric
associated with each node and message. Main goal of this work is to reduce
the number of replicas generated for each message by choosing the best
node or highest quality nodes for eventual delivery to the destination.

CMD flag is not set the bundle would be delivered during
the delivery interval like the Temporal Delivery Model.
When the flag is set the intended receivers must belong
to that group at the time of delivery. These three models
provide efficient grouping mechanism in DTN for
multicast routing. In our proposed routing protocol
(Collaborative Time-Stamp based Multicast Routing,
CTMR), TM model for group formation has been taken
as the group members in TM model are defined during
bundle creation. The grouping mechanism has been
discussed later in Section 3.1.

K R1
S S M

S R2 R3
R1, R2, R3 R1 R1 R1
J
Fig. 1 Unicast based multicast replicating a multicast bundle to multiple
unicast bundles Fig. 2 Tree formation in STBR

M creating a bundle CTMR forwards it to the right node based on
S K
M ority queue. Important features in CTMR are discussed in the
R1
R3
K
R2 R2
Fig. 3 Route discovery as in DTBR
Table 1 presents a brief discussion and critical review of the
existing DTN multicast routing strategies and some DTN
forwarding strategies. The discussions about DTN multicast
routing strategies in Table 1 show that none of the existing
routing strategies have been built by taking into account the
specific constraints posed by a DTN network that include
sparse resources, limited buffer size, very rare communication
opportunities, precious bandwidth, etc. We require a DTN
routing strategy that overcomes these constraints, at the same
time perform efficiently for important parameters.
In the next section we discuss our proposed DTN multicast
routing protocol CTMR in details.
3 Collaborative time-stamp based multicast routing
protocol (CTMR)
Collaborative Time-Stamp based Multicast Routing (CTMR)
is the proposed DTN multicast routing protocol designed es-
pecially for a post-disaster scenario. In a large scale disaster
there can be multiple affected sites. Number of governmental
or non-governmental relief /rescue organizations work in
these affected areas. As timely information about those affect-
ed areas are necessary for efficient serving of affected people,
there is a requirement of efficient coordination between the
team members of rescue and relief organizations. In proposed
CTMR technique, nodes belonging to any affected site create
bundles specifying the requirement of that particular area. It
may so happen that in an area a number of nodes create same
type of bundle due to similar requirements. This creates re-
dundancy in the network. The CTMR technique takes care of
this by minimizing bundle redundancy during bundle crea-
tion. Nodes have the facility to create a multicast bundle in
collaboration with their neighboring nodes which helps to
improve the performance of CTMR technique along with re-
ducing the hop count. The most promising node among its
neighborhood is given the responsibility to create and deliver
the bundle. CTMR also employs efficient grouping mecha-
nism to bind nodes into destination groups judicially that helps
the nodes to know correct destinations for their bundles.
CTMR defines proper bundle format that has been customized
to suit requirements in the post-disaster DTN scenario. After
Peer-to-Peer Netw. Appl.
the proposed forwarding strategy used to prepare bundle pri-
following sections.
3.1 Grouping mechanism in CTMR
As mentioned in Section 2.1, several semantic models have
been proposed which explicitly put constraints on the group-
ing mechanism. The models unambiguously define the re-
ceivers of a multicast packet. In the proposed scenario, we
have considered the members of the relief organization
(Doctors, Nurse, Ambulance etc.) and the team members of
rescue teams (Police, Army etc.) as the receivers of the
multicast bundles. The source and intermediate nodes of the
multicast bundle can be normal people of affected sites or any
member of the above mentioned teams. It has been considered
that relief organizations and rescue teams are divided into
groups. For example, in any relief or rescue team there are
several doctors, nurses, volunteers or police. We can think of
these as separate groups as they are distinguishable based on
their role within any organization. In CTMR, these groups are
named using specific identification. For example, D, N, RW
are the group names of Doctors, Nurses, Relief Workers re-
spectively. Again, a composite group involving users of dif-
ferent types are named using combined group names of all
such types. For example, a group involving some doctors as
well as some nurses is called as DN group. As there might be
several such group combinations the number of groups to
form and their members has been customized before deploy-
ment in the proposed work. Each and every node is aware of
this group information. Group members decide the final des-
tinations of multicast bundles. In our work, TM semantic
model has been used to draw constraints on the groups due
to frequent joining or leaving of the group members. At the
time of bundle creation, along with other parameters the
group-id and the membership interval [t1, t2] has been pro-
vided to the bundles, so that they become aware of the nodes
belonging to the destination group. A membership interval is
the interval included in the bundle at the time of bundle crea-
tion. For a bundle with group id G and membership interval
[t1, t2], the intended receivers of the bundle are the nodes that
are members of group G at time during the period [t1, t2]. The
intended receivers of a group are defined at the time of bundle
creation by including the membership interval to the bundle.
Due to frequent join or leave, there is a subset of intended
receivers, called the actual receivers, which actually receive
the bundle. A node may belong to multiple groups but would
only receive bundles if it belongs to the destination group
assigned to that bundle. If a node is acting as an intermediate
hop, then it temporarily receives all bundles to transmit to the
next forwarding node.
Peer-to-Peer Netw. Appl.
3.2 Bundle format
CTMR follows a customized bundle format, as shown in
Table 2, to create effective bundles prior to sending them. It
defines the header information regarding bundle.
Fields used in the bundle format are explained in the fol-
lowing part.
Bdl_ID: The unique id of the bundle to uniquely identify
it among all the bundles.
TTL (Time to Live): The time limit for which the bundle
would survive after creation.
Bdl Criticality: It is the criticality factor provided by the
node itself that ranges from 1 to 5. Nodes assign a criti-
cality factor to their created bundles, based on their
choice. A criticality factor of 1 means least critical while
5 means highly critical.
Sen ID: The id of the creator who creates the bundle.
Grp Id: The destination group ID of the intended
receivers.
Bdl Type: It specifies the type of bundle based on the type
of node this bundle belongs to. It helps the nodes to de-
termine which bundle is destined to which destination
nodes.
BdlLoc: It is the location of the node that created the
bundle at the time of creating it. At the time of bundle
creation GPS co-ordinates are included into the bundles
as bundle locations. These co-ordinates comprise of lati-
tude and longitude of the location of the sender node at
the time of creating the bundle.
Bdl Created Time: It is the time at which the bundle has
been created.
3.3 Creating a bundle
Bundle creation is an important phase of the proposed CTMR
protocol, where collaboration is used extensively to reduce
redundancy for creating multicast bundles. Since the protocol
is defined over DTN, special emphasis is given for reduction
in redundancy and hop count. As affected people of any par-
ticular region or relief/rescue workers of any affected region
may report similar messages regarding the requirement of that
region, so it is obvious that more than one user lying in very
close proximity may create bundles of same type. This is
because nodes in a small area continuously monitor their
neighborhood. Same type of bundles from neighboring nodes
thus increases the redundancy and overhead thereafter.
Table 2 Bundle format for bundles in CTMR
Bdl_ ID TTL Bdl Criticality Sen ID
Therefore, a patience limit has been introduced. It defines a
time limit that a node must wait before creating a new bundle.
If any node wants to create a bundle then it defers its decision
until patience limit is elapsed and waits for reply from its
neighboring nodes. Suppose at a time instance t, node A wants
to create a bundle and B, C are its neighbors, as shown in
Fig. 4.
Node A broadcasts this information as a temporary mes-
sage constituting its bundle type named as BR_Bdl_Type to
nodes B and C and waits for reply till patience limit (Fig. 5).
The purpose of this temporary message is to inquire its
neighborhood if any other node wants to create similar type
of bundle or not. After receiving the broadcast message, the
neighboring nodes are prohibited from sending any broadcast
message till that patience limit expires. They can send or re-
ceive the bundles but they cannot broadcast any other tempo-
rary message. B and C, after getting the broadcast message,
decide whether they want to create that type of bundle or not.
If one or more nodes want to create same type of bundle, they
incorporate this information along with maximum delivery
probability as the reply of the broadcast message and send it
back to A.
The delivery for a single multicast bundle is calculated on
the basis of the number of receivers who received the bundle
divided by the number of nodes belonging to that group of
receivers (the destination group size). The delivery probability
of bundle i, termed BDPi, is calculated as in formula (1).
Total Group Members who received the Bundle
BDPi ¼ ð1Þ
Total Number of Group Members
Using (1), the delivery probability of CTMR routing pro-
tocol (of all the bundles), termed BDP, is calculated as in
formula (2).
Xn
BDP ¼ 1 BDPi ð2Þ
n j ¼1
Here n represents the total number of bundles created and i
denotes each bundle.
Suppose C wishes to create a similar bundle of same type
as that of A. So it replies affirmatively along with its maxi-
mum delivery probability and its bundle contents to A.
Figure 6 shows that C replies back to A along with its maxi-
mum delivery probability with an affirmative answer.
Node A incorporates all information from the neighboring
nodes to its message content and decides, based on the max-
imum delivery probability, which node must create the bundle
Grp ID Bdl Type Bdl Loc Bdl Created Time

B C
C
A
Fig. 4 Nodes B, C are in range of A
for further forwarding. If Node A itself has the highest deliv-
ery probability, then A simply creates the bundle. If any other
node within A’s neighborhood has maximum delivery proba-
bility, then that node is instructed by node A to create the
bundle. Node A sends the entire appended message to that
node. The patience limit has been used here to reduce dupli-
cate bundles and hence redundancy. It must be noted here that
the patience limit not only reduces bundle replication but it
also helps to reduce the number of bundles for same type of
destination groups. This contributes in saving of storage, min-
imizing congestion and bandwidth utilization which are very
important issues in DTN. Suppose Node A finds that C has
better delivery probability for the destination, hence A in-
structs C to create the bundle along with final appended bun-
dle contents of all other nodes as shown in Fig. 7.
To verify the efficiency obtained by incorporating such
collaboration, we use an example to explain how this strategy
efficiently decreases hop count and data redundancy. Suppose
two nodes C and A are lying at a close proximity to each other.
We imagine that there are few injured persons and they need
immediate medical attention. Both nodes C and A create a
doctor type bundle. The Doctor type bundle is destined to
nodes R1, R2, and R3. It can be observed from Fig. 8a that
node C creates the bundle and passes it to M, node M passes it
to J, node J delivers it to R1and R3. Finally, R3 delivers it to
R2.
Similarly, as can be seen from Fig. 8b, node A also creates
the bundle and passes it to Z, node Z passes it to L, node L
delivers it to R1, and finally R1 delivers it to R3 and R2. In the
above case, total hop count is 8 for two bundles. Following the
strategy as used in CTMR let us assume that node C has a
better delivery probability than node A for the selected desti-
nations. Node C creates the bundle utilizing the initial collab-
oration. The created bundle follows the same path from C to
all the destination nodes of the bundle as in Fig. 8a. It results in
a hop count of 4 for the bundle. This shows how CTMR helps
to minimize message redundancy and hop count substantially
C B
BR_Bdl_Type BR_Bdl_Type
A Bundle Content
Fig. 5 Node A is broadcasting temporary message
Peer-to-Peer Netw. Appl.
B
Yes + 0.73 +
Bundle Content
A 0.64
Fig. 6 Node C replies with a BYes^ along with its Max DP
for similar bundles created from nearby locations. Nodes col-
laborate among themselves to create a multicast bundle which
is delivered in a more efficient way in the disaster affected
area. Figure 9 shows the step by step procedure to create a
bundle collaboratively at each node as used in CTMR.
As presented in Fig. 9, the nodes first select the type of
bundle such as Doctor or Police type. Nodes then write the
message content and initiate send message. Rest of the work is
carried out with the CTMR routing protocol. Initializing a
send operation does not mean that the node has created the
bundle. It means that the node has just participated in bundle
creation. The bundle is created by the most probable node
among the neighborhood of the initiator node. This strategy
is responsible for collaborating among neighboring nodes to
decide which node creates the bundle. Rest of the processes,
as shown in the form of an algorithm in Fig. 9, is self-
explanatory.
3.4 Metadata of the bundles
Once a bundle is created the sender node stores it in its buffer.
Nodes maintain a metadata of every bundle at the time of its
creation or after receiving other bundles. The fields defined in
the metadata are used to identify the bundles that need to be
forwarded in the next available opportunity.
The metadata of the bundles contain the following fields:
1. Bdl Location
2. Bdl Type
3. Bdl ID
4. Group ID
Details about these fields are similar to that explained in
Section 3.2. This metadata is used by the nodes to select bun-
dles in appropriate order, to be forwarded to next hop on
available opportunity.
C B
Create Bundle +
A
Fig. 7 Node A instructs C to create bundle
Peer-to-Peer Netw. Appl.
M J R3
M 2.1: Select BdlType
C J R1 R2
(a)
L R3
A R1
Z Z L R2
(b)
Fig. 8 Analysis of nodes A and C of creating the bundle separately
3.5 Time-stamp based next hop communication
Selection of appropriate forwarding node is performed
through a proposed Time-stamp based criteria in CTMR.
This check is performed whenever any node comes in the
range of another node. CTMR employs a strategy that is
used to determine that if a pair of nodes has communicat-
ed recently, then for a certain period of time those two
nodes would be refrained from communication. This pe-
riod of time is the proposed time-stamp. The idea behind
this is that it is very unlikely that these two nodes will
have fresh bundles to exchange within that time period,
since they have already communicated recently. In a di-
saster affected area, relief workers work at a particular site
for a long period of time. Nodes belonging to a particular
site are within communication ranges for long periods. In
the absence of a time-stamp, nodes keep trying to com-
municate with each other. Considering energy as a price-
less constraint, it is important to focus on saving the en-
ergy. The proposed time-stamp based strategy effectively
reduces energy consumption of the nodes by putting a
limit on communication attempts. The time interval for
the time-stamp is fixed before deployment. A node always
maintains a list where the id of the node and its last con-
tact time is stored. Whenever a node comes in contact
with another node, this list is checked to find out whether
that node had contacted within the time-stamp period. If
the condition is true, then the connection is no more en-
couraged. For example, if node A has made a contact with
node B at time t. If time stamp period is 10 min, within
10 min, node B is supposed not to have much fresh bun-
dles to send to node A and vice-versa. Therefore, they are
not allowed to communicate within the next 10 min. The
threshold for the time-stamp period is defined before field
deployment so that all nodes are aware of this value. The
timestamp threshold has been set to 10 min in our simu-
lations as it has been observed that for the threshold value
of 10 min, CTMR achieves optimal value for average
bundle latency, increased average bundle delivery proba-
bility and reduced average bundle overhead as explained
later in Section 5. The message generation interval has
been kept between 5 and 10 s. The corresponding results
have been shown in Section 5.
Step1: Start
Step2: [Creating Multicast Bundle]
2.2: Assign BR_Bdl_Type = BdlType
2.3: Assign Patience Limit
[Check If any neighboring node is present in the node’s range]
2.4: If any Node is Present in its range or patience limit does not
expire
2.5: Broadcast temporary message BR_Bdl_Type to all Nodes in its
range.
[Wait for reply against BR_Bdl_Type]
2.6: If (any Broadcast Bundle arrives) and patience limit does not
expire.
2.6.1: Check BdlType from BR_Bdl_Type
2.6.2: If (BR_Bdl_Type = BdlType)
2.6.2.1: Send My Max Delivery Probability according to the
Destination List with "Yes” as the reply.
[Wait for the reply]
2.7: If (reply = Create Bundle)
2.7.1: Create Bundle (Bdl ID) incorporating all bundle contents
2.8: If any reply arrives and patience limit has not expired.
2.8.1: If Reply is Yes with message content, max delivery
predictions and patience limit has not expired.
2.8.2: Store all received message content.
2.8.3: Select the host whose Delivery probability is highest.
2.8.4: If the Selected host is other than this host
Then
2.8.5: Reply to that host with "Create Bundle” instruction with all
the bundle contents.
[Abort Multicast Bundle creation]
2.9: Go to Step 3
2.10: Else if Selected Host is this host
2.10.1: Select Bdl ID
2.10.2: Select TTL
2.10.3: Assign Group Id
2.10.4: Assign Sender = This Host
2.10.5: Add (This node) to List of Hops Travelled
2.10.6: BdlType = MyBdlType
2.10.7: BdlLoc = My Current GPS co-ordinates.
2.10.8: CreateBundle (Bdl ID) incorporating all bundle
content;
2.10.9: Calculate the Size of the Bundle
2.10.10: If (Size <= Current Buffer Space)
2.10.11: Decrease MyBufferSpace by the size of the bundle
2.10.12 Else if (Size > Current Buffer Space)
Drop bundles in FIFO to make space for newly
created bundles.
Step 3: Exit
Fig. 9 Collaborative strategy to create a bundle at a node
3.6 Bundle forwarding
Once appropriate next hop nodes are selected, the bundles
need to be forwarded to them. The metadata is first exchanged
whenever any node comes in contact with another node that is
ready to accept the bundles. The sender, after receiving the
metadata from the receiver, decides upon bundles to be sent.
The receiver, ready to accept the bundles, would reply affir-
matively along with all of the delivery predictions of the nodes
it contacted. This prediction technique is based on a well-
known DTN routing protocol namely Probabilistic Routing
Protocol using History of Encounters and Transitivity
(PRoPHET) [9] protocol. This delivery probability calculation
employs an algorithm that attempts to take advantage of actual
encounters by maintaining a set of probabilities for successful
deliveries to known destinations. Whenever two nodes meet,
they exchange additional information called delivery predict-
ability after expiry of the time-stamp period. The sender, after
receiving the delivery predictions for all encountered nodes by

Desnaon/
Sender Next Hop
Sending Beacon
Sending Metadata
ACK
Delivery Predicons
ACK
Time Time
Sender preparing
Final Priority Queue
Sending Bundles according
to Final Priority Queue
Fig. 10 Time activity diagram of communication between sender and
receiver nodes
the receiver, creates a bundle priority queue. Bundles are
forwarded to next hop according to the bundle priority queue.
The task of intermediate hops is to forward bundles opportu-
nistically to other hops or to the destination. The selection of
the next forwarding node, and also the order of the bundles to
be transferred, depends on certain forwarding parameters like
location, aging, criticality etc. These are discussed in details
next.
Location: Whenever two nodes want to communicate,
they exchange their bundle metadata with each other.
CTMR protocol checks the location difference of two or
more similar type of bundles from these two nodes.
Nodes are encouraged to send only those bundles that
have been created from different locations rather than
the bundles from same or nearby close locations. The
Sender calculates the location difference of similar type
of bundles from within itself and the receiver node. It is
checked whether the location difference between two
bundles from the two communicating node is greater than
the threshold limit defined for location difference or not.
The threshold is a portion of the max size of the disaster
area region. If the location difference is less than the
threshold limit, then it is enquired whether the destina-
tions of the two bundles are same or not. If yes, then that
bundle is aborted. The location difference between two
GPS co-ordinates is calculated using the Haversine for-
mula. This formula has been used to calculate the dis-
tance between two GPS co-ordinate locations as in [30].
Bundles are transferred from one node to another only if
their location difference is above the threshold location
difference that has been calculated empirically, as pre-
sented in Section 5.
Peer-to-Peer Netw. Appl.
Table 3 Bundle priority queue of node S communicating with node R
Bdl ID μ Age δ Max DP Priority values
M1 5 423 0 0.31 1.81
M2 4 45 −378 0.42 1.6515
M3 2 36 −387 0.65 5
M1: A bundle with its destination as the Group of Doctors, D1
M2: A bundle with its destination as the Group of Supplier, S1
M3: A bundle with its destination as the Group of Police, P1
Aging: CTMR considers most recent bundles to be more
important as new bundles are more likely to bring recent
and valued information that need to be transmitted.
CTMR gives higher preference to the bundles that are
recently created. The time-to-live (in minutes) for a bun-
dle in a DTN varies from hours to days. When a bundle
reaches the destination then also it remains alive inside
the buffer of many intermediate nodes till its TTL expires.
Longer the age of a bundle, more it is replicated thus
occupying more buffer space at nodes. This results in
fewer chances for delivering newly created bundles that
contain important and relevant information. Aging pa-
rameter is used as a solution, in the preparation of
Priority Queue of bundles, as explained in section 3.7.1.
Criticality of Bundle: Criticality factor has been intro-
duced in CTMR through which a node determines the
importance of its bundles. If a node is carrying a bundle
with higher criticality, then it is treated with higher im-
portance. The criticality of bundles varies from 1 to 5. For
example, in a post-disaster scenario emergency bundles
are given the highest priority i.e., 5 and any update or
status bundle is given the lowest priority i.e., 1. All inter-
mediate criticality values fall within this range. The crit-
icality is used in the preparation of the priority queue as
explained next in section 3.7.1.
3.6.1 Construction of priority queue
CTMR employs a bundle priority queue for arranging the
bundles in order by using an additional queue. It is created
by the sender for all targeted receivers separately. In the pri-
ority queue those bundles are placed first whose destination is
the current receiver. The remaining bundles are ordered
through formula (3).
 . 
PBi ¼ μ*0:3‐ δ 60 *0:005 þ DPðMax ðGroupId ÞÞ ð3Þ
Here, PBi represents the priority value of the ith bundle.
In (3), μ is the criticality of the bundle which was assigned
by the creator node at the time of its creation. δ is the
aging factor, calculated as the difference between current
Peer-to-Peer Netw. Appl.

Step1: Send Beacon Messages Table 4 The ONE simulator parameters

1.1 Wait for Reply
1.2 If the Reply is affirmative Simulation time 12 Hours
Step 2: [Exchange Metadata of Bundles] Transmit range 60 Meters to 90 Meters
2.1 Send this node’s Metadata Buffer size 200 MB
2.2 After getting the Meta Data Of the other Node
Wait time 10 Seconds to 240 Seconds
Step 3: Select bundles first whose one of the destination is that
Speed 0.5 to 1.5 m/sec
neighboring node, with which this communication has been
established World size 4500 m × 3400 m
3.1 Assign priority value to 5 to those bundles. Bundle interval 5 sec to 10 Sec
3.2 [Check the bundles of the same type from both nodes] Bundle size 5 KB to 2 MB
If (Same_Type) Then 1st Doctor group (D1) 25,7,29,11,13,68,95,99
3.3 If (location Difference is more than or equal to predefined 1st Police group (P1) 4,28,13,22,1,86,55,47
threshold limit)
1st Relief worker group (RW1) 8,6,17,20,25,7,107,88
Then
1st Army group (A1) 2,12,14,27,3,112,42,63
3.4 [Add those bundles to the next index of the priority list
according to the final priority formula.] 1st Nurse group (N1) 9,1,10,24,19,97,113,110
PBi = μ * 0.3 + (δ / 60) * 0.005 + DP(Max(Group Id)) Management group (M1) 0,19,23,26,11,13,83,109
Else if location difference is less than the threshold Supplier group (S1) 29,13,17,19,2,118,53,56
3.5 Ignore those bundles 2nd Doctor group (D2) 28,35,20,4,9,100,93,115
Step 4: [Add bundles that do not belong to same BdlType according 2nd Police group (P2) 7,13,8,23,17,48,58,84
to the priority queue formula.]
2nd Relief worker group (RW2) 14,25,29,0,9,22,54,102
PBi = μ * 0.3 + (δ / 60) * 0.005 + DP(Max(Group Id))
Step 5: [After The Bundle List is generated]
2nd Army group (A2) 57,50,82,103,66,46,44,92
5.1 Send the Bundles one by one from the priority queue 2nd Nurse group (N2) 49,117,11,98,101,85,18,90
5.2 End Connection Fire fighter group (F1) 67,59,60,94,64,80,69,52
Step 6: Simultaneously while receiving bundles
6.1 Send affirmative acknowledgement (ready to receive
bundles)
Table 3 presents an example showing the calculation of the
Step 7: Reply my delivery probability along with Metadata to the
sending node priority queue of bundles prepared by a node S (sender) for
Step 8: Receive & Store bundles in buffer another node R (receiver) belonging to the Police group. Once
Step 9: Decrease the priority of the bundles which have this node as the priority values are calculated, the bundles are ordered ac-
the destination. cordingly to be transferred to the next hop.
Step 10: Exit According to the strategy to construct the priority queue, M3
Fig. 11 Bundle forwarding and priority queue construction at nodes is given the highest priority 5 as node R is its immediate desti-
nation. M2’s age is 45 s. The eldest bundle is M1 with an age of
423 s. Hence δ value for M2 is (45–423 = −378). Similarly M1
bundle age and the age of the eldest bundle at the sender. has a δ value of 0. For M1, node R gives the Max DP of 0.31
δ is divided by 60 to convert seconds into minutes and which means that node R has contacted members of Doctors
then multiplied by 0.005 to normalize the final priority Group and the maximum delivery probability among them for
value to the range of [0,5]. δ is subtracted because greater node R was 0.31. Also the criticality value μ, as assigned by the
the age of the bundle, the lesser is its priority value. It creator node to the bundles are 5, 4, and 2 respectively. Final
helps to increase the priority of those bundles which are priority values of these bundles are calculated using (3). Based
recently received. This is how the aging constraint is tak- on these priority values, the bundles are forwarded to the re-
en care of in CTMR. The queue is constructed whenever a ceiver node in the order {M3, M1, M2}. Figure 11 shows the
sender node comes in contact with a receiver. DP in (3) bundle forwarding strategy presented as an algorithm.
represents the delivery probability calculated by receiver
for the bundles’ destinations, using PRoPHET. If the
sender has a bundle with its destination as the current
receiver then that bundle is given the highest priority 4 Experimental setup
5 at the priority queue. This is because it is important to
send those bundles first whose destination is the current To evaluate the performance of our proposed strategy and to
receiver. Otherwise unnecessary delay creeps in. The validate our claims, we have performed simulations. Based on
steps involved in construction of final priority queue have the parameters described in Table 4, simulations have been
been shown in Fig. 10 as a time activity diagram of com- perf ormed in the ONE (Opp ortunistic Networks
munication between the sender and the receiver. Environment) simulator [31]. The ONE is a DTN specific
 Peer-to-Peer Netw. Appl.

Fig. 12 Snapshot of ONE simulator executing CTMR routing protocol, after 2458 s

simulation environment capable of routing bundles between
various nodes that move by following certain mobility rules.
Each simulation has been executed for 12 h. The transmit
range denotes the communication range of the wireless de-
vices. The range has been varied from 60 m to 90 m. Wait
Time denotes waiting period when the node arrives at a par-
ticular location. The node may choose it randomly from 0 to
240 s. The bundle interval denotes the interval in which new
bundles are created. At every 5 to 10 s, a new bundle is cre-
ated. Bundle size varies from 5 KB to 2 MB. We have created
the destination groups in our Simulation by grouping certain
similar nodes together. The groups in this simulation have
been selected as Doctor, Police, Relief Worker, Army,
Nurse, Management and Supplier. Each node in ONE simu-
lator is identified using a unique node address. The numbers
after each group denote the node numbers of nodes belonging
to that group. A node can belong to more than one group. It
may so happen that some nodes do not belong to any group
(affected people, say). Such nodes can generate as well as can
be a forwarder of a bundle. However, nodes that belong to a
group can forward a bundle to another node only if that bundle
does not belong to that group. In Each Simulation, 210 nodes
are considered which are numbered from node 0 to node 210.
Out of these, 0 to 118 nodes belong to some group or groups
and the rest do not belong to any group. A snapshot of the
ONE simulator executing the proposed CTMR routing proto-
col has been obtained and reproduced here, as shown in
Fig. 12. Figure 12 presents the status of the simulation after
2458 s of continuous execution of the CTMR routing based on
simulation parameters as described in Table 4. The results
obtained, as presented in section 5, are the results of average
runs of ten simulations each.

0.676

0.674 3150
Bundle Delivery Probability

0.672 3100
Average Bundle Delivery Delay

0.670 3050
(in seconds)

0.668 3000

0.666 2950

0.664 2900

0.662 2850

0.660 2800
60 70 80 90 60 70 80 90
Wireless Communication Range (in meters) Wireless Communication Range (in meters)

Fig. 13 Bundle delivery probability of CTMR with varying wireless Fig. 14 Average bundle delivery delay of CTMR with varying wireless
communication range for each node range for each node
Peer-to-Peer Netw. Appl.

120 different multicast strategies and forwarding strategies has

been shown in Figs. 23, 24, 25, 26 and 27.
100
Bundle Overhead Ratio

Multiple results have been obtained by varying wireless

80
60
40
20
0
60 70 80
Wireless Communication Range (in meters)
Fig. 15 Bundle overhead ratio of CTMR with varying wireless range for
each node
5 Results and discussion
The proposed multicast routing protocol CTMR has been
measured on the basis of three performance metrics. These
are bundle delivery probability, average bundle delivery delay
and average hop count. To obtain graphs for the same, average
result of ten runs of simulation with a 95 % confidence inter-
val has been considered. For our simulations, we have consid-
ered a real DTN scenario where DTN links may be up for a
very short period of time [32]. We have also compared the
forwarding strategy used in CTMR which is based on
PRoPHET with Bubble Rap and Delegation Forwarding,
two popular forwarding techniques in terms of hop count,
bundle delivery ratio and average delay. Empirical test has
been performed to obtain the optimal wireless communication
range for the communicating nodes (Figs. 13, 14 and 15),
since it shows a large impact on overall performance.
Similar empirical tests have been performed to yield optimal
values for other forwarding parameter values such as the lo-
cation difference (Figs. 16, 17 and 18) and patience limit time
period (Figs. 19, 20, 21 and 22). The comparison with
communication ranges for the nodes as shown in Figs. 13,
14 and 15. In real scenario the outdoor communication range
of IEEE 802.11, i.e. Wi-Fi technology is 90 m (approx.).
Beyond that range nodes are not able to communicate. In
simulation we have varied the range between 60 and 90 m.
It is found that the delivery probability of CTMR is highest
when the wireless range for the nodes is set at 70 m. At 60 m
90 wireless range, bundles are delivered at a satisfactory rate. As
the contact opportunity increases at the range of 70 m, bundle
delivery probability also increases. It can be observed from
Fig. 13 that as the communication range increased to 80 m the
delivery probability had decreased because of an increased
interference of other wireless signals and the probable chance
of buffer overflow. When the wireless range is increased to
90 m the buffer overflow problem is increased which results in
increased dropping of bundles thus reducing delivery proba-
bility. At 90 m the delivery probability improves slightly but is
found best at 70 m. Connection between nodes (smart phones)
ceases after 90 m. Figure 14 shows the Average Delay of the
bundles that have been delivered. Here it is observed that the
delay at 70 m range is the minimum among all other ranges. It
has increased when the communication range of the nodes
increased above 70 m. This is due to the interference of wire-
less links of nearby nodes, and there is wastage of time re-
quired for switching from one node to other. Due to this it
results in higher delays. Figure 15 demonstrates bundle over-
head ratio as the wireless range is increased. It can be observed
that wireless range of 70 m for the nodes has more overhead
than 60 m but lesser than 80 and 90 m. Basically, bundle
overhead is gradually increasing because each simulation that
runs on the particular wireless range suffers from number of
dropped bundles. This is due to the overflow of buffer space
with the increase of wireless range of nodes as more nodes

Fig. 16 Bundle delivery 0.681

probability with varying location
differences and time-stamp 0.680
Bundle Delivery Probability

periods
0.679

0.678
Time Stamp
0.677 Period (mins)
0
0.676 10
20
0.675 30
40
0.674

0 1 2 3 4

Location Difference (in %)

 Peer-to-Peer Netw. Appl.

Fig. 17 Average bundle delivery 2950

latency with varying location

differences and time-stamp 2940
periods

Bundle Latency
2930
Time Stamp
Period (mins)
2920
0
10
2910 20
30
40
2900

2890
0 1 2 3 4
Location Difference (in %)

(and thus more bundles) get involved in communication.
Wireless range of 70 m has best delivery probability and la-
tency is least among all wireless ranges. Thus, it has been
observed that a wireless range of 70 m is optimum for each
node to deliver the bundles as delivery probability is notably
the most important parameter that needs to be considered in
post disaster scenarios. Hence the value of 70 m has been set
as a standard wireless communication range for testing the
CTMR routing protocol’s performance in the considered sim-
ulation environment.
Empirical test has been performed using multiple simula-
tion to calculate optimum values for location difference and
time-stamp periods by varying these values, as presented in
Figs. 16, 17 and 18. This test is performed because these
parameters need to be set before deployment, as depending
on these parameters the relief management team sets its pref-
erences. Since the most important parameter in a post-disaster
scenario is the successful delivery of bundles, the delivery
probability has been given highest importance. Figure 16
shows the performance of proposed CTMR protocol in terms
of delivery probability. It has been found that bundles under a
time-stamp period of 10 min and location difference of 2 to
3 % are more probable to reach the destination than other
values for these parameters. This claim is further supported
from Fig. 17 where it is observed that the delivery latency of a
bundle with a time-stamp of 10 min and location difference of
3 % is good but that with a location difference of 2 % is having
highest latency for the same time-stamp period. Though mes-
sage bundles with a location difference of 3 and having time
stamp of 30 min give the smallest latency, such bundles suffer
from low delivery ratio as in Fig. 16. Figure 18 shows the
bundle overhead ratio, where it can be observed that location
difference of 2 % and time stamp period of 10 min has lowest
overhead among all. Location difference of 3 % is having high
overhead for time-stamp period of 10 min. Message bundles
with time-stamp period of 10 min and location difference of
2 % have the best performance as compared to other values for
these parameter values. This suggests the use these values as
standard in our experiments and so the time stamp period has
been fixed as 10 min and the location difference has been set

Fig. 18 Bundle overhead ratio

90.4
with varying location differences
and time-stamp periods
90.2

90.0
Bundle Overhead

Time Stamp
Period (mins)
89.8
0
89.6 10
20
30
89.4
40

89.2

89.0
0 1 2 3 4

Location Difference (in %)

Peer-to-Peer Netw. Appl.

0.696

0.694

Average Bundle Delivery Delay

2960
Bundle Delivery Probability

0.692

0.690

(in seconds)
0.688 2950

0.686

0.684 2940
0.682

0.680
2930
0.678

0.676
60 120 180 240 300 60 120 180 240 300
Patience Limit (in seconds) Patience Limit (in seconds)
Fig. 19 Bundle delivery ratio with different patience limit Fig. 21 Average bundle delay with different patience limits

to 2 %. After getting optimum location difference and time-
stamp values, simulations for different values of patience limit
have been performed to obtain optimum value as in Figs. 19,
20, 21 and 22.
From Fig. 19 it can be observed that the bundle delivery
probability gradually increases till the patience limit is in-
creased to 240 s. Bundle delivery probability is highest at
the patience limit of 240 s. Beyond this, it has decreased.
Figure 20 suggests the use of 240 s as the desired patience
limit. This is because at this limit the bundle overhead ratio is
the least. From Fig. 21 it is further observed that the average
bundle delivery delay increases gradually with increasing pa-
tience limit. This is attributed to the fact that the more we
invest time for collaboration (required by the patience limit)
the more a bundle is waited, thus increasing the average de-
livery delay. The discarded bundles’ contents are added to
those bundles which have been created after collaboration.
This in turn increases the size of bundles. As the patience limit
increases the number of created bundles decreases as has been
shown in Fig. 22. From these observations it is suggested to
set a patience limit of 240 s as standard value for our further
experiments.
Figure 23 shows the comparison between the proposed
multicast routing protocols CTMR with other existing DTN
multicast routing protocols in terms of bundle delivery prob-
ability. Here we have set the parameters values such that the
nodes carry a wireless communication range of 70 m. System
values contain the location difference of 2 %, time-stamp pe-
riod of 10 min and a patience limit of 240 s (these values have
been empirically measured, as mentioned previously). The
graphs in Fig. 23 prove that the performance of CTMR is
better than other existing multicast routing protocols. The
main novelty in CTMR is that it does not allow creating re-
dundant bundles from neighboring nodes lying in close prox-
imity. Also, whenever two nodes meet for communication,
CTMR ensures that multiple copies of similar types of bundles
are filtered out and not further transmitted into the network for
the same destination group. These improvements and advan-
tages are ensured by our judicious selection of important pa-
rameter values. CTMR also encourages a node to transfer
bundles that are recently created with higher priority.
Unicast based multicast has minimum bundle delivery delay
compared to other DTN multicast routing protocols including
CTMR as shown in Fig. 24. But this routing protocol in not
6200

91.0
6150
Bundle Overhead Ratio

Total Bundles Created

90.5 6100

6050
90.0

6000

89.5
5950

5900
60 120 180 240 300 0 60 120 180 240 300
Patience Limit (in seconds) Patience Limit (in seconds)
Fig. 20 Bundle overhead ratio using different patience limit Fig. 22 Number of created bundles with different patience limits
 Peer-to-Peer Netw. Appl.

Fig. 23 CTMR verses other

multicast routing protocols for 0.7
bundle delivery probability

Bundle Delivery Probability

0.6

0.5

0.4

0.3

0.2

0.1

0.0
Non-Custodial Prophet CTMR OS Multicast STBR DTBR U-Multicasting

Different Multicast Routing Strategies including CTMR

appropriate for a post disaster scenario as there remains other
network issues with it, as mentioned earlier. Except unicast
based multicasting, CTMR has lowest bundle delivery delay
among all other multicast routing protocols, as can be seen
from Fig. 24. This is because it gives higher priority to those
bundles which are recently created, and two bundles from
nearby locations having same destinations are also ignored.
CTMR encourages relaying those bundles which are created
from locations having large enough location difference, to
ensure no redundancy is present, as far as bundles are
concerned.
Next, we have compared the forwarding strategy based on
time-stamp constrained Prophet as used in our proposed
scheme CTMR with the Bubble Rap and Delegation
Forwarding schemes, as shown in Figs. 25, 26 and 27. The
proposed algorithm CTMR is conceptually identical to the
above mentioned forwarding techniques as in all of the cases
it might be observed that we are considering fittest nodes for
message/bundle transfer. Besides, in all three cases the main
goal is to reduce the number of replication in the network.
Though in above mentioned two forwarding techniques, the
authors claimed that the mobile nodes are not using any prior
knowledge of the network but while considering the best or
fittest nodes they are fetching information from mobility
traces offline or quality metric associated with each node. In
DTN scenario, to judge whether a node is a good candidate or
not, we must have to analyze some priory knowledge of that
node. In CTMR we have considered that by calculating the
delivery probability (DP) of each node with respect to the
destination group for each bundle.
As can be seen from Fig. 25, we have compared CTMR
forwarding based on time-stamp constrained Prophet with
Bubble Rap and Delegation Forwarding in terms of average
bundle delivery probability. CTMR forwarding performs

Fig. 24 CTMR verses other 4500

multicast routing protocols for
average bundle delivery delay (in 4000
Average Bundle Delivery Delay

seconds)
3500

3000
(in seconds)

2500

2000

1500

1000

500

0
Non-Custodial Prophet CTMR OS Multicast STBR DTBR U-Multicasting

Different Multicast Routing Strategies including CTMR

Peer-to-Peer Netw. Appl.
0.40
Average Bundle Delivery Probability
0.35
0.30
0.25
0.20
0.15
0.10
0.05
0.00
CTMR Forwarding
Fig. 25 CTMR forwarding based on time-stamp constrained Prophet vs.
Bubble Rap and delegation forwarding in terms of average bundle deliv-
ery probability
much better than both bubble rap and delegation forwarding
as at each step in bundle forwarding it is selecting the most
eligible candidate i.e. the fittest node for data transfer. The lack
of far-sightedness capability in bubble rap and delegation
forwarding reduce their capability to estimate good future
values. This takes its toll in the long run, thus reducing their
delivery probability to a large extent. Forwarding based on
Prophet provides good future estimates based on past perfor-
mances. As far as average bundle delivery delay is concerned,
as presented in Fig. 26, CTMR performs almost at par with
bubble rap and much better than delegation forwarding. The
introduction of time-stamp based criteria in forwarding mech-
anism in CTMR, though helps in increasing delivery ratio, it
also increases delivery delay to some extent. This is because
forwarding to next hops is halted temporarily until the pre-set
time-stamp period is exhausted. This increases the delivery
delay of CTMR forwarding slightly. Though BubbleRap
scheme takes minimum number of hops for bundle delivery,
as in Fig. 27, it is not a good candidate in terms of Delivery
Ratio as shown in Fig. 25. CTMR forwarding takes the max-
imum number of hops, on an average, to deliver its messages
14000
Average Bundle Delivery Delay
12000
10000
(in seconds)
8000
6000
4000
2000
0 parameters have been introduced in CTMR like optimal wireless
CTMR Forwarding
Fig. 26 CTMR forwarding based on time-stamp constrained Prophet vs.
Bubble Rap and delegation forwarding in terms of average bundle deliv-
ery delay
7.8
7.6
7.4
Average Hop Count
7.2
7.0
6.8
6.6
6.4
6.2
6.0
Bubble Rap Delegation Forwarding
5.8
CTMR Forwarding Bubble Rap Delegation Forwarding
Fig. 27 CTMR forwarding based on time-stamp constrained Prophet vs.
Bubble Rap and delegation forwarding in terms of average hop count
from source to destination. This is attributed to the fact that
Prophet calculations in CTMR force a carrier to transfer bun-
dles to immediate neighbors even if they appear to only mi-
nutely improve delivery probability. This results in a large
number of intermediate nodes in the path from a source to a
destination. From the above results and discussions, we con-
clude that CTMR is a good routing scheme for considered
DTN scenario.
6 Conclusion
The area of Post Disaster Situation Analysis and Resource
Management needs more focus because of increased severity
and losses accompanied with disasters. A DTN presents a good
alternative to create fast network architecture in case the existing
communication network is crippled after a disaster strikes. In a
DTN, communication channels may connect and disconnect
continuously. Longer periods of disconnection are not rare in
DTN. Specialized routing protocols need to be developed for
communication to be made possible in a DTN. Unicast DTN
routing protocols have limitations in the context of performance
in a post-disaster situation where most of the tasks are performed
using collaboration and are group-based. In the current work, we
have proposed a multicast DTN routing protocol named
Collaborative Time-stamp based Multicast routing (CTMR) pro-
tocol that is developed for efficiently handling post-disaster relief
work and resource management. A multicast protocol is capable
of reducing bundle redundancy and overhead to a large extent. In
the proposed strategy, bundles are created collaboratively among
a certain neighborhood of a node such that redundant bundles of
similar type and same destination are avoided. Several important
Bubble Rap Delegation Forwarding
communication range for each communicating node, optimal
location difference & time-stamp period values, and optimal pa-
tience limit values. These parameter values, along with the

probabilistic calculations of potentiality for a node to deliver to
another node based on the well-known PRoPHET model, have
been used in combination to generate a bundle priority queue.
This queue decides the order in which the bundles at a node are
to be transmitted to the next hop in communication. CTMR has
been implemented in the ONE simulator and its performance has
been compared with other existing multicast routing protocols in
DTN. Simulation results, with a 95 % confidence interval, have
shown that under the considered scenario of a post-disaster en-
vironment, CTMR performs best as far as the overall bundle
delivery probability and the average bundle delivery delays are
concerned.
7 Future work
There are different kinds of nodes in a disaster scenario which
could be selfish node or malicious nodes. It is an important
concern that if a node is malicious or selfish then it can destroy
the entire team work. Detecting and handling such malicious
nodes would be beneficial for an effective communication. In
our future work, we would like to incorporate measures to detect
and handle such malicious nodes that might be present in the
network.
Acknowledgments This research work is an outcome of the
Government of India Project titled DiSARM funded by Information
Technology Research Academy, Media Lab. Asia, Department of
Electronics & Information Technology, Ministry of Communications
and Information Technology.
References
1. Farrell S, Cahill V (2006) Delay and disruption tolerant networking.
Artech House, Inc
2. Cerf V, Burleigh S, Hooke A, Torgerson L, Durst R, Scott K, Fall K,
Weiss H (2007) Delay-tolerant networking architecture. RFC4838
3. Hui P, Crowcroft J, Yoneki E (2011) Bubble rap: social-based
forwarding in delay-tolerant networks. IEEE Trans Mob Comput
10(11):1576–1589
4. Ye Q, Cheng L, Chuah MC, Davison BD (2009) Performance com-
parison of different multicast routing strategies in disruption toler-
ant networks. Comput Commun 32(16):1731–1741
5. Fall K, Scott KL, Burleigh SC, Torgerson L, Hooke AJ, Weiss HS,
Durst RC, Cerf V (2007) Delay-tolerant networking architecture.
http://tools.ietf.org/html/rfc4838
6. Zhao W, Ammar M, Zegura E (2005) Multicasting in delay tolerant
networks: semantic models and routing algorithms. Proceedings of
the 2005 ACM SIGCOMM Workshop on Delay-Tolerant
Networking. ACM.
7. Scott K, Burleigh S (2007) Bundle protocol specification. IETF,
RFC 5050
8. Vahdat A, Becker D (2000) Epidemic routing for partially connect-
ed Ad hoc network. Duke University Technical Report Cs-200006,
April 2000
Peer-to-Peer Netw. Appl.
9. Lindgren A, Doria A (2006) Probabilistic routing protocol for in-
termittently connected networks. IETF, draft-lindgren-dtnrg-proph-
et-02.txt, March 2006
10. Burgess J, Gallagher B, Jensen D, Levine BN (2006) MaxProp:
routing for vehicle-based disruption- tolerant networks. In Proc.
IEEE Infocom, April 2006
11. Spyropoulos T, Psounis K, Raghavendra CS (2005) Spray and wait:
an efficient routing scheme for intermittently connected mobile net-
works. In Proc. ACM SIGCOMM Workshop Delay-tolerant net-
working, pp 252–259
12. Balasubramanian A, Levine BN, Venkataramani A (2007) DTN
routing as a resource allocation problem. In: Proc. ACM
SIGCOMM, August 2007
13. Erramilli V, Crovella M, Chaintreau A, Diot C (2008) Delegation
forwarding. In Proceedings of the 9th ACM International
Symposium on Mobile Ad Hoc Networking and Computing 2008
May 26, ACM, pp 251–260
14. Iranmanesh S, Wu-Chin K (2015) A novel mobility-based routing
protocol for semi predictable disruption tolerant network. Int J
Wireless Inf Networks 138–146
15. Abdulla M, Simon R (2006) A simulation analysis of multicasting
in delay tolerant networks. In: Simulation Conference, 2006. WSC
06. Proceedings of the Winter. IEEE, pp. 2234–2241
16. Del Duca Almeida V, Oliveira AB, Macedo DF, Nogueira J (2012)
Performance evaluation of MANET and DTN routing protocols. In:
Wireless Days (WD), 2012 IFIP. IEEE, pp 1–6
17. Moy J (1994) Multicast Extensions to OSPF. RFC 1584,
March 1994
18. Waitzman D, Partridge C, Deering S (1988) Distance vector
multicast routing protocol. RFC 1075, November 1988
19. Xie J, Talpade RR, Mcauley A, Liu MY (2002) AMRoute: ad hoc
multicast routing protocol. Mobile Netw Appl 7(6):429–439
20. Bae SH, Lee SJ, Wouldiam S, Gerla M (2000) The design, imple-
mentation, and performance evaluation of the on-demand multicast
routing protocol in multihop wireless networks. IEEE Network,
January 2000, pp 70–77
21. http://www.ndma.gov.in/en/. Accessed 12/01/16
22. Ye Q, Cheng L, Chuah MC, Davison BD (2006) OS-multicast: on-
demand situation-aware multicasting in disruption tolerant net-
works. In Vehicular Technology Conference, 2006. VTC 2006-
Spring. IEEE 63rd, vol 1, pp 96–100. IEEE
23. Santiago J, Casaca A, Pereira PR (2008) Non-custodial multicast
over the dtn-prophet protocol. In: Wireless Sensor and Actor
Networks II 2008. Springer US, pp 197–208
24. Lee U, Oh SY, Lee KW, Gerla M (2008) Relaycast: scalable
multicast routing in delay tolerant networks. InNetwork Protocols,
2008. ICNP 2008. IEEE International Conference on 2008 Oct 19,
pp 218–227. IEEE
25. Kawecki M, Schoeneich RO (2016) Mobility-based routing algo-
rithm in delay tolerant networks. EURASIP J Wirel Commun Netw
2016(1):1–9
26. Zeng Y et al (2013) Directional routing and scheduling for green
vehicular delay tolerant networks. Wirel Netw 19(2):161–173
27. Lo SC, Luo NW, Gao JS, Tseng CC (2014) Quota-based multicast
routing in delay-tolerant networks. Wirel Pers Commun 74(4):
1329–1344
28. Deng X, Chang L, Tao J, Pan J, Wang J (2013) Social profile-based
multicast routing scheme for delay-tolerant networks. In: 2013 I.E.
International Conference on Communications (ICC), pp 1857–
1861. IEEE
29. Iranmanesh S, Chin KW (2015) A novel mobility-based routing
protocol for semi-predictable disruption tolerant networks. Int J
Wireless Inf Networks 22(2):138–146
30. Gupta AK, Bhattacharya I, Banerjee PS, Mandal JK, Mukherjee A
(2015) DirMove: direction of movement based routing in DTN
Peer-to-Peer Netw. Appl.

Indrajit Bhattacharya is an
architecture for post-disaster scenario. Wireless Networks (Springer
Assistant Professor at Kalyani
US), June 2015
Government Engineering
31. Kernen A, Ott J, Karkkainen T (2009) The ONE simulator for DTN College (KGEC) in West Bengal,
protocol evaluation. Proc. Int. Conf. Simul. Tools Tech., pp 55 India. He has completed his PhD
32. Lindgren A, Phase KS (2006) Evaluation of queuing policies and from Jadavpur University in West
forwarding strategies for routing in intermittently connected net- Bengal, India in 2014. He obtain-
works. In: Communication System Software and Middleware, ed his Master in Computer
2006. Comsware 2006. First International Conference on 2006 Science from the University of
Jan 6, pp 1–10. IEEE Calcutta, West Bengal. He has a
teaching and research experience
of more than 14 years in different
institutes of repute. He is the
Amit Kumar Gupta is a Ph.D.
Principal Investigator of the
research scholar from the
Project titled DiSARM (Post
University of Kalyani, West
Disaster Situation Analysis and Resource Management using Delay
Bengal, India. His areas of interest
Tolerant Peer-to-Peer Opportunistic Networks) at KGEC, funded by
include delay tolerant networks,
Information Technology Research Academy, Media Lab. Asia, Govt. of
wireless networks, sensor net-
India. His research interests include delay tolerant networks, wireless
works, security in wireless net-
networks, sensor networks, and radio frequency identification.
works, social networks data anal-
ysis, and data management in
wireless transmission. He has
c o m p l e t e d h i s M a s t e r ’s i n
Computer Applications and in
Information Technology from Tamal Mondal is a research
theUniversity of Calcutta. He scholar from the Kalyani
carries a teaching experience of Government Engineering
four years of teaching Master’s students. College (KGEC), West Bengal,
India. His areas of interest include
delay tolerant networks, wireless
networks, sensor networks, social
networks data analysis, and other
related fields. He has completed
Jyotsna Kumar Mandal is a h i s M a s t e r ’s i n C o m p u t e r
Professor at the Computer Applications from KGEC.
Science and Engineering
Department of The University of
Kalyani, West Bengal, India. He
has been an ex-Dean to the
Faculty of Engineering,
Technology & Management at
the University of Kalyani. He
has an active academic carrier
with more than 30 years of teach- Sourav Sanu Shaw is a master’s
ing and research activities in vari- student at Kalyani Government
ous reputed institutes and Engineering College (KGEC),
Universities. He is an active mem- West Bengal, India. His areas of
ber of more than ten professional interest include delay tolerant net-
bodies like IEEE, ACM, to name a few. He has frequent involvement with works, wireless networks, social
organizing international and national seminars in different areas of com- networks data analysis, and other
puter science and allied subjects. His fields of interests include coding related fields.
theory, data and network security, remote sensing and GIS based appli-
cations, data compression error corrections, watermarking, steganogra-
phy and document authentication, image processing, visual cryptography,
MANET, wireless and mobile computing, unified computing, chaos the-
ory and applications. He leads various government and non-government
projects in his computing laboratory.