paper managing disconnected mobile nodes in a …borcea/papers/ieice13-e.pdfmobile devices highlight...

Copyright © 20XX The Institute of Electronics, Information and Communication Engineers

Paper Special Section on Internet Architectures, Protocols, and Management Methods that Enable Sustainable Development

Managing disconnected mobile nodes in a Delay Tolerant Network

with HALF routing protocol Anika Aziz, Md. Enamul Haque

††, Cristian Borcea

†††, Yasser Kamal Hassan

††††, and Shigeki Yamada

††, Member

SUMMARY Delay and Disruption Tolerant Networks (DTN) can

provide an underlying base to support mobility environments. DTN is

equipped with advance features such as custody transfer and hop by

hop routing which can tackle the frequent disconnections of mobile

devices by buffering bundles and dynamically making hop-by-hop

routing decisions under intermittent connectivity environment. In this

paper, we have proposed a DTN routing protocol HALF (Handoff-

based And Limited Flooding) which can manage and improve

performance of disrupted and challenging communication between

mobile nodes in the presence of an infrastructure network consisting of

fixed interconnected nodes (routers). HALF makes use of the general

handoff mechanisms intended for the IP network, in a DTN way and

also integrates a limited flooding technique to it. Simulation results

show that HALF attains better performance than other existing DTN

routing protocols under diverse network conditions. As the traffic

intensity changes from low to high, delivery ratio of other DTN routing

protocols decreased by 50% to 75% whereas in HALF such ratio is

reduced by less than 5%. HALF can deliver about 3 times more

messages than the other protocols when the disrupted network has to

deal with larger size of messages. If we calculate the overhead ratio in

terms of „how many extra (successful) transfer‟ is needed for each

delivery, HALF gives less than 20% overhead ratio while providing a

good delivery ratio.

Key words: DTN, custody transfer, hop-by-hop routing, HALF.

1. Introduction

Recent advances in computing and networking

technologies have led to a proliferation of mobile devices

with wireless networking capabilities. These wireless

mobile devices highlight the need for flexible, efficient

and robust support of mobility services in the future

Internet [1].To support mobile environments,

mechanisms such as Mobile IP [2], TCP modifications

(eg. I-TCP [3]) are added to the original Internet

architecture. But even with the modifications, they do not

operate well under the challenges of the current Internet

and are often inefficient in the presence of mobility of

the devices. Mobility can induce fluctuation in the

connectivity and high mobility can lead to complete

disconnections. Different approaches have been

developed to mitigate (short-term) disconnections while

at least partly preserving the end-to-end notion. In this

regard, DTN takes a different approach by relying

exclusively on asynchronous communications which

means that messages are transmitted through the network

asynchronously, depending upon whether an opportunity

is available to communicate to the next node (a mobile

device ) or not.

DTN is featured by two advanced capabilities:

custody transfer and hop-by-hop routing. The custody

transfer capability allows messages or „bundles‟ to be

buffered in DTN nodes until bundles are forwarded to the

next hop DTN node or found to be unnecessary [4]. The

hop-by-hop routing capability enables routing decisions

to be made dynamically during each hop. These unique

features of DTN are very promising to handle the

mobility associated problems in current network

architecture. Many research projects are currently

working on resolving the future Internet issues [5], [6]

considering DTN for managing the challenged network

conditions. Storage-aware (generalized DTN) routing

that exploits in-network storage to deal with varying link

quality and disconnection, has already been proposed in

routing protocol design [7].Considering advantageous

aspects, we believe that DTN can better cope with the

disruption situation caused by node mobility. Some of the

existing routing protocols in DTN take forwarding

decision based on local knowledge [8], [9] given by next

hop node and bundles are forwarded opportunistically

fulfilling some pre-conditions. These protocols work on

the principle of spreading unlimited or limited number of

copies of messages in the network so that any one of

those copies will be lucky enough to make its way to the

destination. These encounter-based DTN routing

protocols are not enough to cope with disruptions toward

higher message delivery ratio and smaller end-to-end

delay. We wanted to devise a routing protocol which will

eliminate the opportunistic waiting as much as possible,

will gather routing information from nodes other than the

next hop node and if possible, will minimize the flooding

in the network. Therefore, we have envisioned utilizing

the fixed infrastructure where many fixed interconnected

nodes (referred as „fixed routers‟ subsequently) are

ubiquitously located in some geographical areas. In [10]

and [11] fixed nodes play a passive role in opportunistic

forwarding strategy by simply acting as information

sinks. In [12] [13] and [14] fixed routers are used to

create either a greater number of opportunities or ferries

Manuscript received xx, 20xx. Manuscript revised xx, 20xx. † The author is with the University of Dhaka, Dhaka,

Bangladesh †† The authors are with National Institute of Informatics,

Tokyo, 101-8430 Japan. ††† The author is with New Jersey Institute of Technology, NJ

07102, USA. †††† The author is with South Valley University, Egypt.

IEICE TRANS. ELECTRON., VOL.XX-X, NO.X XXXX XXXX

2

are used as relays to other mobile nodes. On the contrary,

we have used the interconnected fixed infrastructure to

manage and improve disconnections among the mobile

nodes in a DTN which is induced by mobility in the

network. A network having fixed nodes and mobile

nodes undergoes handoff phenomena as a consequence

of the mobility of nodes and routing of data takes place

through the new route as a part of this handoff process.

Our intention was to utilize this handoff process and to

employ a back propagation mechanism with caching of

routing information in the routers of already traversed

route (subsequently referred as „experienced route‟) of a

mobile node.

With above observations‚ we are introducing HALF

(Handoff-based And Limited Flooding) routing protocol.

HALF makes best use of the general handoff

mechanisms intended for IP networks but uses the DTN

features like hop-by-hop routing and custody transfer. In

existing DTN routing protocols, mobility is exploited to

deliver a message to the destination resulting in

improvement of capacity [15] and overcoming of the

lack of end-to-end connectivity [16]. We have used a

consequence of the mobility that is‚ the handoff

mechanism to route data through the network. As the

mobile node keeps changing its position, handoff takes

place repeatedly. During each handoff, the information

about which DTN fixed router the mobile node is

currently registered with (subsequently referred as

„location information‟) travels back to every fixed router

in its experienced route and to be cached there. Thus a

forwarding path is established through the already

traversed routers of the mobile node. If any of these fixed

routers receives a bundle for the mobile node, it can

quickly forward that bundle through the already

established forwarding path. Otherwise (when a fixed

router has received a bundle to deliver to the mobile node

but has no information about the route to follow) a fixed

node floods the bundle throughout the network to reach

the destination. On this purpose, a limited flooding

technique is integrated with the handoff mechanism of

our routing protocol. To implement handoff and routing

in the DTN layer/Bundle Protocol layer, we have

proposed extension of few fields in the Bundle block

format of Bundle Protocol (BP) specification given by

the IRTF‟s Delay Tolerant Network Research Group

(DTNRG) [17]. This ensures HALF protocol‟s

compliance with the DTNRG‟s current advancements.

In summary‚ our contributions include the

following:

• We have designed HALF in such a way that it gives

satisfactory performance in a networking environment

of different ratio of fixed nodes and mobile nodes. So,

we believe that HALF can be used in a disaster

scenario where the infrastructure is partly destroyed

causing only partial availability of fixed routers. Or,

for the purpose of better performance/ cost

communication: the preposition of inter-connected

nodes are considered realistic especially in urban areas

in the world because these urban areas have been

ubiquitously deploying WiFi access points that are

interconnected backward with each other like via fixed

local area networks, and finally connected to internet

fixed backbone networks. Keeping these applications

in mind, in our simulation work, we have varied the

number of mobile nodes and fixed routers over a wide

range. Most existing DTN routing protocols deal with

the environment of fewer fixed nodes so, we even

varied the numbers to be only10 and 6 for a city map.

• When HALF is implemented between a mobile node

and a fixed node, the handoff works effectively for

better routing by updating location information.

Between fixed nodes, the back propagation and route

caching work effectively for better routing.

Furthermore between fixed nodes, the previous hop

fixed node does not need any opportunistic waiting but

can immediately forward bundles to the next hop fixed

node without waiting in whatever way, whether it is

based on the updated location information, route

caching information or limited flooding.

• HALF is implemented in such a way that it can use a

non-localized routing information to route the data

through the network: In HALF the cached information

at the fixed routers are back propagated may be from a

distant router and any fixed router in the experienced

path may utilize such information to route the data

through the best possible way towards the destination.

These accounts for higher delivery ratio and this type

of mechanism is absent in other DTN routing protocols.

• Evaluation of HALF is done under different network

conditions: variation in the number of fixed nodes and

mobile nodes, radio ranges, message and buffer sizes

at the nodes, mobility models & speeds. Performance

of HALF is also compared with existing DTN

protocols which utilize fixed infrastructure such as

ThrowBox [12]. Overhead ratio is calculated taking

into account the number of excess transfer for every

successful delivery in the network.

The rest of the paper is organized as follows: Section 2

discusses the related work on different technologies such

as handoff-based technology in TCP/IP, work that handle

mobility with DTN, and DTN routing protocols. Section

3 discusses the protocol description. Section 4

demonstrates the performance evaluation and analysis. In

section 5, we propose how HALF can handle the inter-

region communication. Section 6 concludes the paper.

3

2. Related Works

2.1 Related Works on Handoff Technologies in TCP/IP

Protocol

The technologies in HALF are similar to some of the

existing Internet architecture extensions in TCP (such as

I-TCP [3], M-TCP [18]) and IP layers (Mobile IP [2]).

However HALF handover is simply carried out in the

hop-by-hop routing scheme without establishing an end-

to-end route. If we consider a large number of mobile

nodes changing networks quite frequently, a high load on

the home agents as well as on the networks is generated

in Mobile IP by registration and binding update

messages. The update message usually has to travel a

long distance from the mobile node to the Home Agent

(HA) and the latency increases dramatically depending

on this distance. On the other hand, Bundle delivery in

HALF does not involve going through any HA. Instead

the Bundle delivery is accomplished through the handoff

process which involves the immediate Previous Master

(PM) and Current Master (CM) of the mobile node. As a

result HALF mitigates scalability problem by having

lower handoff latency and overall latency than Mobile IP

protocol. Furthermore, when the route is changed by the

Mobile IP, some packets transferred during a switchover

from an old route to a new route may be lost and packet

retransmission may occur over the new route in TCP

layer. This may also incur large latency. The custody

transfer capability of each DTN node assures to keep any

Bundle received during the handoff in the node until it is

forwarded to the next hop, resulting in no Bundle loss

during the handoff.

In IP micro-mobility protocols like Cellular IP [19,

20] all nodes collect and cache routing information for

accessing destination mobile nodes to allow

simultaneous forwarding of packets destined for a mobile

node along multiple paths and achieve local handover

from an old router to a new router. This routing

information caching is similar to HALF‟s caching.

However, Cellular IP may sometimes cause packet loss

due to transient packet transfers to the old route without

explicit packet buffering. On the other hand, in HALF all

transient bundles are explicitly kept in the large buffers

of old router following the custody transfer mechanism

and this leads to no bundle loss.

2.2 Related Works that Handle Mobility with DTN

Many projects which are working in resolving the future

Internet issues [5], [6] consider DTN for managing the

challenged network conditions. MobilityFirst is designed

around the principle that mobile devices, and their

associated applications, must be treated as first-class

Internet citizens [1]. There are many challenges

associated with integrating wireless mobile

communication as a core element of the Internet

architecture. MobilityFirst has considered mobility as the

norm for the future Internet and has used DTN routing in

its design. We have proposed a DTN routing protocol

which can be used to manage the mobility of the

disconnected nodes. So, „mobility‟ and „DTN‟ are the

common factors between the MobilityFirst and HALF.

MobilityFirst is a clean slate project working with the

architecture, protocol stack, routing and many other

network conditions for the future Internet. We envision

that the handoff mechanism is a novel idea to be used in

a DTN routing protocol. More works have been proposed

which are consistent with the lines of research on

generalizing the DTN-related technologies for the future

Internet [21] and [22].

2.3 Related Works on DTN routing protocols

Existing protocols in DTN are designed to handle

challenging and opportunistic situations of sparsely

connected mobile nodes in a network. Epidemic routing

protocol is solely based on the information exchanges

between two encountering mobile nodes and thus

distributing messages throughout the network to reach

the destination [8]. The PRoPHET is devised to be more

selective by being probabilistic while forwarding to the

next node [9]. Updated version of this protocol called

PRoPHETv2 with some minor modifications to the

routing metric calculations has improved the

performance of this protocol [23]. The Spray and Wait

(SW) protocol adds limited copy flooding feature to the

mobile nodes while routing to the destination [16]. The

Spray and Focus scheme distributes even a small number

of copies to few relays [24]. Each relay can then forward

its copy further using a single-copy utility-based scheme,

instead of naively waiting to deliver it to the destination

by itself as happened in SW. These flooding based

routing protocols make use of only localized knowledge

and hence suffer from reduced delivery ratio and large

latencies. MaxProp prioritizes the scheduling of packets

for transmission and take the resource limitation into

account [25]. HALF assumes simple FIFO for scheduling

the packets. Another DTN routing protocol, RAPID,

deals with the problem of routing in DTN as a resource

allocation problem and tries to solve it by calculating a

routing metric per packet on the basis of available

resources and then replicates the packet accordingly [26].

HALF does not involve calculating the routing metric on

the basis of how much resources are available. Another

DTN routing protocol makes use of isolated fixed nodes

(Throwbox) to increase the contact opportunity during

routing [12]. Specialized mobile nodes like Message

Ferries (MF) have also been used to improve the

performance [13]. The MF design exploits mobility to

improve data delivery performance. HALF design

involves infrastructure of fixed nodes to improve


4

delivery ration of data. The Message Ferry scheme

addresses the disconnection problem by introducing non

randomness to node mobility and exploiting such non

randomness to provide connectivity. Using the cached

information HALF provides deterministic nature to its

routing strategy. MF is proactive on the other hand

HALF is reactive.

3. Protocol Description

We assume our network model having fixed

interconnected nodes (routers) and mobile nodes

(routers) as shown in Figure1. The fixed routers are inter-

Fig. 1 A general network model with fixed routers and mobile nodes

connected with each other through communication links

and provide a communication infrastructure in the

network.Two mobile routers can communicate directly

(when they are within each others range) or using the

communication infrastructure of the network. Although

links among the fixed routers are defined, the links

between the mobile routers or between the fixed and

mobile routers are opportunistic. The DTN nodes

communicate using the Bundle Protocol (BP) [17]. The

standardized message format of BP that is, the bundle

can be used to implement various network functionalities

including routing function.

The sequence of events and messages that takes

place during a typical handoff process, in the BP layer, is

illustrated in Figure 2. The vertical lines represent mobile

node M0‚ fixed router R1‚ mobile node M1 and fixed

router R2 respectively, and the arrows represent bundles

sent from one machine to another. Each fixed router is

broadcasting beacon messages and whenever a mobile

node is within the wireless range of a fixed router, it

responds with a registration request, REG message. In a

normal case‚ a successful bundle transmission from one

node to another is followed by a Status Report (SR).

Special SRs have been used in HALF to introduce new

functionalities to the bundle protocol. The content and

purpose of these special SRs during registration and

handoff are described in Table 1. As the events take

place‚ we proceed from the left towards the right side of

the diagram. Initially mobile node M0 and M1 are

registered to router R1 and communicating through R1.

After a while‚ M1 moves out of R1‟s range and comes

within the communication range of R2. R1 detects it and

in the meantime, if R1 receive any bundle to be delivered

to M1‚ R1 buffers it by custody transfer mechanism until

next opportunity to deliver it to the next hop is available.

In its new location‚ as soon as M1 receives a

beacon from R2‚ the handoff process starts. M1 sends a

registration request, REG, to the new router‚ R2. This

REG is a special SR message of the bundle protocol and

carries [M1‚R1] information so that R2 get informed

about the previous fixed router (termed as Previous

Master, PM) of M1. In response to this REG message‚

R2 sends a handoff message (through a special SR

message) carrying [M1‚R2] information to the PM‚ R1.

This Handoff message informs R1 about the present

location of the departed mobile node, M1. Handoff

message [M1‚R2] means that R2 is the Current Master

(CM) of M1 and instigates to deliver the buffered

bundle(s) for M1 to it. So‚ R1 forwards bundle(s) to the

CM of M1 (in this case R2) and bundle(s) are delivered

finally to the destination‚ M1 as depicted in Figure 2.

Every fixed router maintains two lists: a Back List (BL)

and a Proxy List (PL) as shown in the Figure 2. The Back

List consists of the id of a mobile node and its PM‟s id

whereas a Proxy List consists the id of a mobile node and

its CM, as shown in Table 1.

With further mobility, node M1 moves to a new

location as depicted on the right side of Figure 2. In

Fig. 2 HALF protocol sequence during handoff in Bundle Protocol

layer

the new location, M1 registers with a new fixed router,

R3. When R3 receives the REG message‚ it sends the

handoff message to R2. Now‚ R2 updates its PL with

[M1‚ R3] instead of [M1‚R2]. This is termed as ’route

5

update’ process. The route update information is said to

be cached in each router of the experienced route of the

mobile node. Here the experienced route consists of fixed

router R1 and R2. So R2 consults its BL to choose other

fixed router to propagate back this update information.

Table 1 Content and purpose of special SR messages during

HALF operation.

Special

Status Report

During registration During handoff

Content [mobile node‚

Previous Master (PM)]

[mobile node‚

Current Master (CM)]

Origin and

destination

From mobile node to

new fixed router

(Current Master)

From Current Master to

Previous Master (both

fixed routers)

Added to Back List (BL) of CM Proxy List (PL) of all

PMs

Purpose

To determine to whom

the handoff message

has to be sent

To inform current

location of registered

mobile node

As R1 is associated with the concerning mobile node in

R2‟s BL, it forwards the latest location information of the

mobile node to R1. This process is known as ’back

propagation’. Thus, repetitive handoff process takes

place through the fixed routers of the infrastructure as a

mobile node keeps changing its location and moves from

one router to another. As a consequence the back

propagation and route update also take place. The back

propagation is shown in Figure 2 using arrows above the

routers in the backward direction. Now, if it happens that

after some time, R2 receives a message which is destined

for M1, it at first consults its PL to search the latest

updated location information about M1 and finds who

has propagated this latest update to it. Then the message

for M1 is forwarded to the sender fixed router who lastly

updated that route information about M1. Thus, making

use of the cached info at the PL, any router can send

bundles destined to a mobile node through the already

established path quickly. We have termed this process as

the ’proxy method’ since sender of the latest updated

information works as a proxy to the destination.

An efficient flooding technique, named as Limited

Flooding (LF) has been integrated with HALF‟s basic

handoff mechanism and it takes place under two

conditions:

(a) Whenever a fixed router does not have any

information about the destination in its PL. This

may happen if the cached information has

expired and no update has reached yet

(b) When a mobile node is never within the range

of any fixed router of the infrastructure.

Initially, LF starts spreading message copies in a manner

similar to Epidemic routing [8]. When specified numbers

of copies have been spread to guarantee that at least one

of them finds the destination quickly (with high

probability), it stops flooding and expects that at least a

single copy of the message is delivered by direct contact.

While flooding, if any of the branch nodes (we assume

that the flooding is taking place following a tree) has

information in its PL about the destination or CM of the

destination, flooding is stopped. Instead, that node

forwards the bundle to the proxy found in the PL. This is

how the Limited Flooding (LF) method works.

Definition: As a mobile node continues to change its

position, repetitive handoff process takes place between

the fixed routers. The PL constitutes the updated location

information of the mobile node and the BL keeps track of

the already traversed route of the mobile node. With the

help of the PL, any router of the traversed path can

effectively route to the mobile node which is termed as

proxy method. If PL information is not available or the

mobile node is out of range of any fixed router, HALF

switches to a limited flooding technique.

The following example shows how the bundles are

transmitted through a network by selecting a proxy or a

limited flooding method depending upon the situation. As

Fig. 3 Message transmission from source to destination by PX and LF

method

Figure 3 shows, the message 5 (M5) was created at the

mobile node, W49, at 22nd instant of time and was

destined for the mobile node, W79. After the creation of

M5, there was no information available to reach the

destination. So, M5 was delivered to P5 by flooding

method at 25.5th sec. For the same reason, M5 was

delivered to the fixed routers @116 and @115 by

flooding method. Fixed router @115 found a proxy to the

destination which is @80 in its PL. So, M5 was delivered

from @115 to @107, by proxy method. On the other

hand, @107 has a BL which contains the information

that once W79 visited it and that the Previous Master

(PM) of W79 was @115. So, @107 had back propagated

any location information about W79 to @115.

Forwarding of M5 to the next two hops- @106 and

@103 are done in a similar way. Finally the CM @80

send M5 to the final destination W79, by direct

transmission.

Now the pseudo code of the HALF routing

algorithm is presented through Figure 4 to 8:

WHILE a connection state is changed

PROCEDURE connectionChanged ( ) INITIATE createRegistration ( )

ENDWHILE


6

WHILE a message is created by user action PROCEDURE createNewMessage ( )

ENDWHILE WHILE a connection is available

PROCEDURE sendAllMessages ( ) ENDWHILE WHILE a message is received and classified

PROCEDURE messageTransferred ( ) ENDWHILE

Fig 4. Main Procedures( ) of HALF

The main Procedures of HALF routing algorithm are

shown in Figure 4. When the connection between a

mobile node and a fixed router is changed that is

available, the connection is established and the

Registration Procedure is initiated. HALF deals with five

types of messages: REG, Data, Status Report,

HANDOFF and BACKPROPAGATION. Before any of

these types is created, a connection should be available.

That is why we put connectionChanged( ) Procedure at

first. After a message is created, Procedures

sendAllMessages( ) and messageTransferred( ) come into

action. Each of these Procedures is presented in detail in

Figure 5.

BEGIN PROCEDURE connectionChanged( ) IF masterConnection found THEN

con:= masterConection createRegistration (masterConnection) ELSE IF con is down

masterConnection:= sbCon createRegistration (sbCon)

Message REG = new message PUT REG in the sending queue for sending

END IF END PROCEDURE //NOTE 1: sbCon is the strongest beacon Connection. //NOTE 2: REG bundle created for handoff initiation and ready PROCEDURE createNewMessage M [no_of_copy = X] PUT M in the sending queue END PROCEDURE PROCEDURE sendAllMessages( ) IF the receiver is connected

send the data messages to receiver ELSE IF proxy of the receiver is connected send the data messages to the proxy

ELSE IF M.no_of_copy > 0 or M.TYPE is other than data send each message M from the queue

END IF END PROCEDURE PROCEDURE messageTransferred (Message M, Host sender) ADD to deliveredMessage (M) IF M = DATA (src, dest, id)

ADD (new SR (self, sender, srid, id)) ADD(DATA(src, dest, id)) ELSE IF M = SR (src, dest, srid, id)

IF dest is not self then ADD(SR(src,dest,srid,id)) IF dest is self then REMOVE <id, src> from lsentmsg ELSE IF M= REG or HANDOFF or BACKPROPAGATION

RcvmsgnClassify ( ) END IF

END IF END IF END PROCEDURE

Fig. 5 Details of the main Procedures

Since we have integrated the Spray and Wait

protocol‟s flooding method with our basic handoff

mechanism, a certain number of copies of a message

have to be generated every time a message is created. For

example, we have used X copies in Figure 5. A message

is sent form the queue, whether a connection to the

receiver or the proxy of a receiver is connected until no.

of copy the message is greater than zero or the message

is of other type than Data.

The Status Report (SR) is generated as an

acknowledgement of the data. As a result, a receiver can

receive a SR as well as other type of Data. When a mess-

BEGIN PROCEDURE createRegistration(connection) SET newMaster = other node connected with connection CREATE new registration message, msg[TYPE:reg, SOURCE:self, DESTINATION:newMaster, PREV_MASTER:master] SET master = newMaster PUT msg in sending queue SET isMasterUp = true END PROCEDURE //NOTE 1: master is the last master node of this host and it is global to this procedure //NOTE 2. isMasterUp is a flag that indicates whether the host has a master at this instant and it is global too to this procedure PROCEDURE getStrongestBeacon:RETURNS strongestConnection LET connections be the list of available connections of this host SET minDistance = Infinity SET strongestConnection = null FOR each connection in connections, con IF con is up then con[i].getOtherNode(getHost()).getRouter();

SET dist = getDist( other node connected with con, this node)

IF dist < minDistance then SET minDistance = dist SET strongestConnection = con END IF END IF END FOR RETURN strongestConnection END PROCEDURE BEGIN PROCEDURE getDistotherNode,: host) SET x_dist = (x coordinate of otherNode - x coordinate of host)^2 SET y_dist = (y coordinate of otherNode - y coordinate of host)^2 SET dist = square root ( x_dist + y_dist) RETURN dist END PROCEDURE

Fig. 6 Procedures associated with the Registration

age is sent from the queue, it is added to the list of sent

message (lsentmsg).

The createRegistration( ) in Figure 5 accompanies

how the mobile node detects the strongest beacon from

any fixed router and calculating the distances when two

7

fixed routers are sending strong beacon to it. Detail of

these createRegistration( ) and associated Procedures

are illustrated below in Figure 6. RcvmsgnClassify( ) is

explained detail in Figure 8.

BEGIN PROCEDURE sendAllMessages (Message M, Connection) SORT messages according to the receive time GROUP messages according to the type For all Message M of type DATA, GET direct, proxy or an available R2R connection IF connection is found THEN Start transmission IF transmission result is Denied_old, Denied_TTL or

RCV_OK REMOVE the message from the queue ADD message to lsentmsg ELSE ADD (M, connection) to SecondaryBuffer END IF END IF IF direct or proxy connection not found

For all R2R connections C except the available one, ADD (M, C) to SecondaryBuffer

For all <Message M, Connection C> in SecondaryBuffer SEND M through C IF transmission result is Denied_old, Denied_TTL or RCV_OK

REMOVE (M, C) from SecondaryBuffer For all Message M of Type HANDOFF or SR, SEND M through direct or proxy connection IF transmission result is Denied_old, Denied_TTL

or RCV_OK REMOVE from the queue IF END IF END IF END END PROCEDURE //NOTE 1: R2R is the connection between 2 Fixed Routers

Fig. 7 Detail of the sendAllMessages ( )

When a message is received successfully (RCV_OK) or, it

is denied for being obsolete (Denied_old) or the TTL is over

(Denied_TTL), it is removed from the queue where it is

normally kept for sending to a connect ion. If any message

IF N.TYPE is registration, then CREATE a handoff message M [TYPE:handoff, HANDOFF_TO:N.LAST_MASTER, HANDOFF_FOR:N.sender, CURRENT_MASTER:this node] ADD (N.sender, N.LAST_MASTER) to Backpropagation List ELSE IF N.TYPE is handoff or backpropagation, THEN ADD(N.HANDOFF_FOR, N.CURRENT_MASTER) To Proxy List IF Backpropagation List contains backPropagateFor

SET backPropagateTo = the LAST_MASTERcorresponds to N.HANDOFF_FOR in Backpropagation List CREATE a backpropagation message M [BP_FROM:this host, BP_TO:backPropagateTo, BP_FOR:N.HANDOFF_FOR, CURRENT_MASTER:currentMaster]

ELSE IF N.TYPE is Data SET N.NO_OF_COPY= Ceiling(N.NO_OF_COPY / 2) SET M = N PUT M in sending queue.

END IF

END IF

Fig. 8 RcvmsgnClassify( )

cannot be sent successfully then it is kept in the Secondary

buffer to try to send it in future.

The messageTransferred( ) Procedure not only deals

with DATA and its SR, it also handles with other types of

messages– each in a different way. Figure 8 represents

each of these cases. Binary Spray and Wait [16] routing

scheme‟s technique is applied for decreasing the no. of

copies of the Data.

HALF is implemented in the Bundle Protocol layer.

The routing operation of HALF is effective through the

handoff mechanism which is accomplished with the DTN

technology and hence implemented in the BP layer. HALF

maintains the Proxy List and Back List with the latest

location update of the mobile node and propagating this

information backwards to the already traversed routers and

caching there, respectively. All these tasks are modeled in

the Bundle Protocol layer. The protocol stack of HALF is

given in Figure 9.

Fig.9 Bundle Protocol Stack

There is a cross layer information (signal strength) flow

from link layer to the BP layer as bundles are processed at

each node/router up to the BP layer. It can be mentioned

here that BP is an overlay protocol on top of the transport

layer. Interaction of BP with lower layers is defined in the

RFCs (4838 & 5050) [27] [17].

4. Performance Evaluation and Analysis

4.1 Network Simulation Model

We implemented HALF in ONE simulator [28], [29]

through some major modifications and necessary

extensions. The Helsinki City map of ONE was used

which included actual roads and streets for mobile nodes,

such as walkers, pedestrians, trams and cars. We used a


8

realistic movement model called SPMBM (Shortest Path

Map Based Movement) of ONE simulator, where instead

of a completely random walk, mobile nodes chose a

random point on the map and then follow the shortest

route to that point from their current locations. These

points were chosen randomly or from a specified list of

Point Of Interest (POI) given in ONE simulator. These

POIs included real world destinations such as tourist

attractions‚ shops and restaurants. To increase further

reality, velocity of mobile nodes and pause times at POIs

were adjusted to match pedestrians‚ vehicles or other

node types [28]. Moreover, we have located

interconnected fixed routers along appropriate streets.

These general parameter settings may be typical and

similar for many other cities. Such settings assured that

mobile nodes were able to send and receive relay bundles

easily to the destination nodes. In real world, the network

traffic may change, depending on locations (cities,

countries), and dates/times (rush hours/holidays),

occasions (normal/disaster situations). Therefore, we set

(at least) three types of traffic intensity parameter

settings from light traffic to heavy traffic (Traffic

intensity: 0.2, 0.5 and 0.7).

To implement the handoff mechanism of HALF,

Active Router module of ONE simulator was extended

and fields and methods were created which were not

included in any DTN routing algorithm in ONE before.

Handoff reports (output files) have been generated by

extending the Report module. For every simulation case,

we chose five runs using different random seeds and

produced reports with average values.

As a performance metrics for evaluation we have

used delivery ratio and average latency. The delivery

ratio is defined as the fraction of generated messages that

are correctly delivered to the final destination within a

given time period. The average latency is defined as the

time between when a message is generated and when it is

received. This metric is important since many

applications can benefit from a short delivery latency,

even though they will tolerate long waits. Table 2 shows the parameters used in the simulation.

The reasons behind choosing each of these parameters

are explained in the table.

Table 2 Simulation parameters

Parameters Description (values)

Node type

Fixed routers and mobile nodes (Walkers,

pedestrians, cars and trams)

Walkers and pedestrian‟s speed: (0.5, 1.5)

m/sec; car‟s: (2.7, 13.9) m/sec and tram‟s:

(7,10) m/sec where minimum and

maximum speeds (m/s) are shown when

moving on a path

Total number of

nodes

100

Node ratio (Fixed:

Mobile)

65: 35, 50:50,35:65, 10:90 and 6:94

Connections &

movement model

250 kBps,

ShortestPathMapBasedMovement

(SPMBM) model [29]

Simulation Area 4500 x 3400 meters

Transmitting 10m(Blue tooth )and 100 m(Wireless

range of the nodes LAN)

Message size 500KB ~ 1MB (random selection)

Message

generation

intervals

[1~ 29] sec., [1~11] sec. and [1~ 7]sec.

corresponds to Traffic intensity (ρ) value

of low (0.2), medium (0.5) and high (0.75)

respectively

Buffer size 5MB for walkers & cars; 50MB for the

trams. We varied it from10MB ~ 300MB

to study the effect of buffer size variation

Simulation time 12 hours

Message lifetime 40 min. (for discarding messages)

Alive time/ cache

time

5 sec, 30 sec, 160 sec, 600 sec and 3000

sec

4.2 Simulation Results

Performance of HALF is compared with Epidemic,

PRoPHET and SW, under the same networking

environment as mentioned in Table 2. To make our

comparison fair, we have applied the Epidemic,

PRoPHET and SW protocol to the fixed interconnected

routers and to the mobile nodes around them, in a similar

way as HALF. Two mobile nodes can communicate

when they are within each others‟ communication range

that is, when the communication opportunity is available

between them. In our network model, the communication

opportunity between the fixed interconnected nodes is

always available. So, we can consider that the exchange

of messages takes place in a similar way when two

mobile nodes or a fixed node and a mobile node meet or,

in a case when two fixed nodes are connected with each

other. After a mobile node exchanges its message list

with a fixed router and both of them is updated with the

list, the fixed router sends this updated list to the rest of

the fixed routers it is connected with. Consequently, all

the fixed interconnected routers get flooded by this

updated information. Since there is no opportunistic

waiting between the fixed routers, the spreading of the

messages will be faster than when it takes place among

mobile nodes only. In a similar way, when PRoPHET is

applied, the message is flooded in all the interconnected

fixed routers with probability 1. For Spray and Wait, the

specific number of message copies will be flooded within

the fixed interconnected routers.

4.2.1 Traffic Load Conditions

We kept the total number of nodes constant (100) but

varied the number of fixed and mobile nodes separately

to investigate how the different traffic load condition

influences the presence of the different ratio of fixed and

we are going to discuss about our obtained results, we

should mention about the general tendency of the routing

protocols as shown in Figure 10 below. As the mobile

9

Fig. 10 General characteristics of the DTN routing protocols

nodes. The speeds of the mobile nodes are chosen as

specified in Table 2. We also considered two radio

ranges: the Bluetooth range of 10m and the WLAN range

of 100m.

Before bundle transmission in a network increases,

the delivery rate increases but this continues until a

certain time- after this time the delivery rate starts

decreasing. This happens as a consequence of the

congestion which is developed in the network and bundle

drops due to the buffer overflow. As a result, if we want

to calculate the delivery rate/ delivery ratio of any

protocol within a specific time duration we will find the

position of the protocol as shown in the curve of Figure

10. Here the delivery is HALF>PRoPHET>Epidemic

while SW needs a different explanation. We know that

SW has minimum number of transmission in the

network than the other routing protocols. SW is placed at

the other side (rising side) of the curve presenting almost

same number of delivery as HALF but with less number

of bundle transmission. We received almost similar

behavior of the protocols from the simulation results.

From Fig. 11(a) to 11 (e), we can see that with

increased traffic load or intensity, the delivery ratio of

each of the protocol is decreased. This is because nodes

could not deliver the increased traffic due to overburden

causes. With the change of traffic intensity from low to

high, delivery ratio of other DTN routing protocols

decreased by, 50% to 75% whereas in HALF such ratio is

reduced by less than 5%.

The location information about the mobile node can

travel from a distant node and thus in HALF, we can

make use of the routing information which is not only

found from the next hop node, as used in other routing

protocols. As a result, with the increases of the traffic

load condition HALF can still deliver a good amount of

bundles to the destination.

The improved performance of HALF is due to the

delivery contributed by the handoff-based mechanism

with the support of the fixed infrastructure. As a result,

when the network scenario is changed from the mostly

fixed to mostly mobile, the value of the delivery ratio

falls because of less contribution from the interconnected

fixed nodes. For other protocols, the delivery ratio

increases as the number of mobile nodes increases.

As we found in the following Figure from 12 (a) to

12 (e), when the traffic intensity grows from low to high,

the end-to end latency of the network is increased.

Because nodes become overburden with the excess

traffic and the average time to reach the destination for

the messages is increased due to the increased waiting

time. As the network scenario was changed from the

mostly fixed to mostly mobile, the latency increased

because in the latter case, bundles can reach to their

destination only by the movement of mobile nodes. The

lowest latency was achieved by the HALF protocol

compare to all other protocols under the mostly fixed

scenario.

(a)

(b)

(c)

0

10

20

30

40

50

60

Del

iver

y ra

tio

(%

)

Traffic interval, radio range (m)

F65, M35Epidemic PRoPHET SW HALF

0

10

20

30

40

50

60

Del

iver

y ra

tio

(%

)


F50, M50Epidemic PRoPHET SW HALF

0

10

20

30

40

50

60

Del

iver

y ra

tio

(%

)


F35M65

Epidemic PRoPHET SW HALF

PRo

bundle transmission

Epi

Deliv

ery

ratio SW HALF


10

(d)

(e)

Fig.11 Delivery ratio at different traffic intensity

(a)

(b)

(c)

(d)

(e)

Fig. 12 Latency at different traffic intensity

4.2.2 Overhead Ratio for the Delivery

We have studied the overhead ratio along with the

delivery ratio of the bundles in the network. We

considered the case when the traffic intensity of the

network is [1, 29] and the radio range used is 100m for

the Mostly Fixed network scenario. The overhead ratio

was calculated in the following way:

(No of messages relayed-no. of messages delivered)/ no.

of messages delivered. That is, how many "extra"

(successful) transfers were needed for each delivery. This

is one measure of bandwidth efficiency of the protocol.

0102030405060

Del

iver

y ra

tio

(%)


F10M90Epidemic PRoPHET SW HALF

0

10

20

30

40

50

60

Del

iver

y ra

tio

(%

)



0

500

1000

1500

2000

2500

Late

ncy

(se

c.)


F65M35


0

500

1000

1500

2000

2500

Late

ncy

(se

c.)



0

500

1000

1500

2000

2500

Late

ncy

(se

c.)



0

500

1000

1500

2000

2500

Late

ncy

(se

c.)


F10M90


0

500

1000

1500

2000

2500

Late

ncy

(se

c.)


F6M94


11

Fig. 13 Overhead ratio with the delivery ratio

As it is found from Fig. 13, although Epidemic has

highest delivery under the given network condition, it is

also accompanied by larger overhead. On the other hand,

SW has the lowest overhead ratio but its delivery is

lower than the HALF. Considering both the

performances, HALF performs best because it gives

higher delivery but with very low overhead ratio SW has

a bit low overhead than HALF because for each

successful delivery SW takes less number of transfers in

the network.

The cost as another overhead for the use of

infrastructure could be calculated to build up the

infrastructure for additional node (DTN fixed router) cost

and link cost. The node cost is now and could be reduced

to small in the near future just like ubiquitous WiFi

access points. On the other hand, the fixed link cost may

be much larger if it is newly installed, depending on the

distance between fixed nodes because it may need not

only cable cost but also much human labors and time to

physically connect wired links between fixed nodes.

That‟s why we assume the use case of HALF in modern

urban areas because urban areas may have already

deployed many cables throughout the areas and we can

easily deploy low cost fixed DTN nodes. Thus, the small

additional investment into the infrastructure would make

the DTN performance much better.

4.2.3 Message Sizes and Buffer size Variation at the

Nodes

We evaluated HALF and the three other protocols for

different message sizes. Here we consider the mostly

fixed scenario. The Pedestrians, Walkers and Cars had

buffer size of 5 MB, the fixed router had 20MB and the

trams had 50MB. Our observations from the results

(shown Fig. 14) are that-

(a) Because of the opportunistic contacts, larger

messages cannot be always successfully delivered.

So, delivery ratio decreased as message size was

increased from the 100k~2M to 1M~100M size, for

all the protocols.

(b) With the increase of message size, the latency

decreased because less number of bundles took less

time to be delivered to their destinations.

(c) In spite of the decrease in delivery and increase in

latency HALF comparatively performs better than

others.

We have excluded the Epidemic here since this protocol

is restricted by the resource (mainly buffer) consumption

issue due to its message copy flooding in the network. To

Fig. 14 Performances for different message sizes

study how the buffer sizes of the infrastructure influence

the performances of the network, we increased buffers

at the nodes (in the same order as mentioned previously)

to 10MB, 100MB and 100MB respectively. We took the

scenario of a particular message size between [500k~

1M] and for low traffic interval [1~ 29]sec and high

traffic interval [1, 7] sec conditions under the mostly

fixed scenario.

(a) As shown in Fig. 15, the increased buffer size at

each node caused the delivery ratio to be increased

by 50%. Because more bundles can be buffered at

the nodes to wait for next delivery opportunity

instead of getting dropped.

(b) At the same time, the bundles took longer time to get

delivered to their destinations because of increased

buffering time and this leads to increased value of

overall latency.

4.2.4 Handoff Performances

In HALF, routing is done by a handoff- based mechanism

and hence handoff latency should also be studied. We

know that the handoff latency is set around several tens

0

50

100

150

200

250

300

350

0

10

20

30

40

50

Epidemic PRophet SW HALF

ove

rhea

d r

atio

del

iver

y ra

tio

(%

)

delivery ratio

overhead ratio

0

10

20

30

40

100K-2M 500k-4M 500k-8M 1M-100M

Del

iver

y ra

tio

(%)

Message sizes

Message size variation

PRoPHET SW HALF

0

200

400

600

800

100K-2M 500k-4M 500k-8M 1M-100M

Late

ncy

(se

c.)

Message sizes

Message size variationPRoPHET SW HALF


12

Fig. 15 Performance for different buffer sizes at nodes.

of milliseconds to several seconds at maximum. We take

the scenario of mostly fixed, with 100m radio range and

again study the result of the end-to end latency for

different traffic condition: as it is found, HALF shows

lowest end-to-end latency of the range of 200 sec in Fig.

16 (a). For the same parameter values, now we consider

HALF only and run simulation for approximately 3 hrs.

We recorded the value of the handoff latency in the mean

time and found that most of them have the value within

2~8 secs. Here we have plotted the number of messages

delivered within this handoff latency times. The graph of

Fig. 16 (b) presents that most of the messages are

delivered to their destinations with this short value of

handoff latency. So, the handoff latency contributes a

small amount to the performance of the HALF protocol .

4.2.5 Mobility Model

To study how the Mobility models can affect different

protocol performances for the all mobile network

environment, we evaluated with one random model like

Random Way Point (RWP) and another more realistic

(a)

Fig.16 Handoff performance.

model like Shortest Path Map Based Mobility Model

(SPMBM). Here we have considered SW and Epidemic

with HALF to see how one limited and another unlimited

type of flooding routing protocol work in comparison to

HALF. As shown in Fig. 17, with SPMBM the delivery

ratio is higher than with RWP. In terms of latency, HALF

performed best compared to other protocols. We also

observed the performances by varying the number of

different type of mobile nodes. The number of cars

influences the delivery performances very much because

of the increased contact frequency. The number of trams

has less influence on this as we found that with no trams

but 40 cars the delivery ratio is better than with no Cars

(but trams and others). In summary, SPMBM mobility

model with high speed vehicle improves the performance

of the protocol.

0

5

10

15

20

25

5M-50M[1,29] 10M-100M[1,29] 5M-50M[1,7] 10M-100M[1,7]

De

live

ry r

atio

(%

)

Buffer size, traffic intensity

Buffer size variation

PRoPHET SW HALF

0

500

1000

1500

5M-50M[1,29] 10M-100M[1,29] 5M-50M[1,7] 10M-100M[1,7]

Late

ncy (

sec.)

Buffer size variation

PRoPHET SW HALF

0

200

400

600

800

1000

1200

[1,29] [1,11] [1,7]

end

-to

-en

d la

ten

cy (

sec.

)

Traffic interval

Handoff perfromances

Epidemic ProPHET SnW HALF

0

20

40

60

80

100

1 10 100 1000 10000

Nu

mb

er o

f ar

rive

d

mes

sage

s

Handoff Latency ( Fibonacci scale)

0

5

10

15

20

25

Deli

very

rati

o(%

)

PedestriansOnly NoTrams NoCars 30Cars 60Cars

(b)

13

Fig.17 Performance of different mobility models.

4.2.6 Mobility Speed

To evaluate how the mobility speed affects our protocol

and others, we chose different values of mobility speed,

M by varying the speed of each type of mobile nodes

(pedestrians, cars, trams etc.), as explained in Table 1.

For example, M1= [(.5, 1.5) x40+ (2.7, 13.9) x40+ (7,

10) x2+ (7, 10) x2]/84=4.833. Here the pedestrians speed

had the distribution of (.5, 1.5), number of pedestrians

was 40; speed distribution for the cars were (2.7, 13.9),

no. of cars was also 40; trams1 and trams 2 both had the

distribution as (7, 10) and the total number of mobile

nodes were 84. Finally, the total speed was divided bythe

total number of nodes that is 84 and we get the M1 value

as 4.833.We varied the speed range of the different type

of mobile nodes and calculated the M2, M3 and M4

respectively.

Fig.18 Performance of different mobility speeds.

When the mobility speed increases, the delivery of each

of the protocol is increased but HALF achieves the

highest delivery among them, as shown in Fig. 18. The

latency of HALF is decreased to about 60% of its value

at M4 than at M1, because due to mobility of the nodes

more bundles reached their destinations faster than

before. On the other hand, PRoPHET protocol depends

on the probability of meeting a suitable node and as a

result, the increased mobility speed could not affect on

delivery ratio that much. However, the latency decreased

due to the faster moving mobile nodes. For Epidemic, the

increased mobility helped more bundles to be distributed

over the network quickly which increased the delivery

ratio and decreased the latency.

4.2.7 Protocols Utilizing Infrastructure Elements

In [12], [30] and [31] use of Throwboxes has been proposed to improve the performances (specially the delivery ratio) while applying the MaxProp protocol to route the traffic through the network. For evaluation, we placed Throwboxes at places where most of the mobile nodes of the city passed by and applied the MaxProp for routing. In our original HALF protocol, we used interconnected fixed routers (HALF_ C). This time for simulation, we used scenarios such as HALF Connected (HALF_C), HALF Not Connected (HALF_NC), HALF No Fixed node (HALF_NF), MaxProp with Throwbox (MaxProp_ThB). Figure 19 shows the performance at two different traffic intensities [10, 20] and [1, 7]. Here we have used 35 fixed routers for the HALF protocol and 35 Throwboxes with the MaxProp. Simulation time was 2.7

Fig. 19 Comparison between infrastructure-based protocols

0

500

1000

1500

2000

Late

ncy

(sec

.)

PedestrianOnly NoTrams NoCars 30Cars 60Cars

0

20

40

60

80

100

120

M1 (4.833) M2 (7.8809) M3 (18.2142) M4 (27.261)

Del

iver

y ra

tio

(%

)

Mobility speed (m/sec.)

Effect of Mobility speedHALF SW PRoPHET Epidemic

0

100

200

300

400

500

600

700

800

M1 (4.833) M2 (7.8809) M3 (18.2142) M4 (27.261)

Late

ncy

(se

c.)

Mobility speed (m/sec.)

HALF SW PROPHET Epidemic

0

10

20

30

40

50

60

70

80

[1,7] [10,20]

deliv

ery

ratio

(%

)

Traffic interval (sec.)

Infrastructure-based protocols

HALF_C HALF_NC HALF_NF MaxProp_ThB

0

100

200

300

400

500

600

700

[1,7] [10,20]

Late

ncy (

sec.)

Traffic interval (sec.)

Infrastructure-based protocols

HALF_C HALF_NC HALF_NF MaxProp_ThB


14

hrs. Transmit speed, transmit range and the Buffer size of the Throwboxes were taken as 1M, 250m and 75M respectively from [12], [30] and [31]. HALF performed better when the fixed routers were interconnected than the cases when they were not interconnected or, there was no Fixed Nodes (only Mobile Nodes) and also better than the MaxProp with the same number of Throwboxes.

5. HALF as an Inter-region DTN routing protocol

5.1 Basic Principle

Our main concept of managing disconnected mobile

nodes with a DTN routing protocol named HALF can be

extended to route data for the inter-region

communication [32]. We considered communication

between distant regions connected by a backbone region

consisting of number of Gateways. To send a packet

destined for a different region, home agent establish link

with the nearest GW. This GW then set up path with the

GW on the other end – preferably near to the destination

region.It is to be mentioned here that the DTN

architecture includes the concept of regions and DTN

gateways [4]. We have considered the inter-region

connectivity issues using i) HALF protocol within each

region and also in the connecting region and ii) HALF

protocol within each region but TCP/ mobile IP in the

connecting region. We have considered two operational

situations to find out the most suitable one for the inter-

region communication, as shown in the Fig. 15 (a) and

(b).

5.2 Destination Mobile host Resides in Home Network

If we consider HALF-Mobile IP model as shown in

Fig.20 (a), then the generated bundles is forwarded from

the home agent to the destination mobile host through the

gateways in between the region after the TCP connection

establishes. In case of all HALF models, all gateways

register information about the destination in the

respective lists. Then each gateway can communicate

with each other using hop by hop path. If any node

receives a bundle, it can make use of PL to route that

bundle to the destination quickly. Otherwise if the

gateways don‟t have route information about the

destination in the list, it proceeds with the flooding

mechanism.

5.3 Destination Mobile host Moves to a Foreign Network

While considering the HALF-Mobile IP model, the home

agent finds the CoA of the destination mobile host, and

forwards the bundle to another region as shown in the

Fig. 20 (b). This forwarding is enabled by Mobile IP that

is the bundle is forwarded from the sender region, via

home network to foreign network region and takes much

overhead. But if we consider all HALF model, GWs in

the connecting region follow HALF‟s handoff

mechanism: the new location information of the mobile

node is conveyed back to the old router by the new router

so that the old router can quickly forward the data

destined for that particular mobile node through the new

router.

5.4 Routing Cache Sequence Scheme

A route caching scheme for hop-by-hop routing is to

make the best use of an already experienced route

between a sender and a receiver. We assume that each

node caches the following tuple information in its routing

table. [Previous node ID, Next node ID, Source ID,

Destination ID, Arrival time, Bundle ID]. When a first

bundle from the source node to the destination node

arrives at the target node that has no associated tuple

information, the target node determines the next hop

node, based on Epidemic flooding, and then the

associated tuple information is cached in the target node.

These flooding based forwarding and route caching are

repeated in every traversed node until the first bundle

reaches the destination node. Once the destination node ¥

(a)

(b)

Fig.20 Destination host (a) resides in home network (region 1 and 2)

(b) moves to a foreign network (region 1 and 3).

receives the first bundle, the destination node sends back

a returning bundle to the source node.

As only one copy of the same bundle may have

reached the destination node through different routes, we

choose a single route leading to the source node among

different routes. In order to do it, the destination node

first finds the first arriving bundle and forwards the

15

bundle over the route which the first arriving bundle

experienced in a reversed direction. The second

forwarding bundle should also follow the route which the

first arriving bundle experienced in a forwarding

direction. Where each routers and gateways are already

established its routing table information for first and

previous node to the destination. As regional connectivity

promotes different kind of applications of DTN, we

compared possible combination of these two protocols to

pursue a suitable solution. Modeling and simulation

using ONE protocol is been left as the future work.

6. Conclusion

In this paper, we have showed how the presence of the

interconnected fixed routers influence the performance of

a DTN routing protocol, HALF. This new routing

scheme of HALF fully utilizes some knowledge on

destination nodes (handoff mechanism) and some

knowledge on topological information (proxy list/back

list). We found that HALF performs better than the other

routing protocols in most of the cases. Our observation

also focuses on the consideration of gateway routers

between the different regions and how these gateways

routers between the two regions can resolve the problem

of mapping routes of different regions with only HALF

protocol and/or HALF–Mobile/IP combination. In future

we will implement this protocol in ONE simulator.

References

[1] S. Nelson, G. Bhanage, D. Raychaudhuri, “GSTAR: Generalized

Storage-Aware Routing for Mobility First in the Future Mobile

Internet,” ACM MobiArch, pp.19-24, 2011.

[2] Jochen Schiller, Mobile communication, 2nd edition, Addison-

Wesley, 2003.

[3] A. V. Bakre and B. R. Badrinath, “Implementation and

Performance Evaluation of Indirect TCP”, IEEE Tran.on

Computer,vol.46, no.3, March 1997.

[4] K. Fall, “A Delay-Tolerant Network Architecture for Challenged

Internets,” ACM SIGCOMM‟03, pp.27-34, August 2003.

[5] NSF‟s FIND: http://www.nets-find.net/

[6] NSF GENI: http://www.geni.net/

[7] MobilityFirst: http:// mobilityfirst.winlab.rutgers.edu/

[8] A. Vahdat and D. Becker, “Epidemic routing for partially

connected ad hoc networks,” Technical Report CS-200006, Duke

University, April 2000.

[9] A. Lindgren, A. Doria, and O. Schelen, “Probabilistic routing in

intermittently connected networks,” SIGMOBILE Mobile

Computing and Communications Review, pp.19-20, July 2003.

[10] T. Small and Z.J. Hass, “The Shares Wireless Infostation Model-

A new Ad-hoc networking paradigm (or While there is a Whale,

there is a way),” ACM MobiHoc‟03, pp.233-244, June 2003.

[11] D. Goodman, J. Borras, N. Mandayam, and R. Yates,

“INFOSTATIONS: A New system model for data and messaging

services,” IEEE VTC‟97, vol.2, pp. 969-973, May 1997.

[12] N. Banerjee, M. D. Corner, and B. N. Levine, “An energy-

efficient architecture for DTN throwboxes,” IEEE INFOCOM‟07,

pp. 776-784, May 2007.

[13] W. Zhao, M. Ammar, and E. Zegura, “A message ferrying

approach for data delivery in sparse mobile ad hoc networks,”

MobiHoc 2004, pp.187-198.

[14] F. Yasmeen, N. Huda, C. Borcea, and S. Yamada, “Ferry access

points and sticky transfers: Improving communication in ferry-

assisted DTNs,” IEEE WoWMoM AOC‟12, pp.1-7, June 2012.

[15] M. Grossglauser and D.N.C. Tse, “Mobility increases the

capacity of wireless ad-hoc networks,” IEEE/ACM Tran.on

Networking, vol.10, no.4, August 2002.

[16] T. Spyropoulos, K. Psounis, and C. S. Raghavendra, ”Spray and

Wait: An efficient routing scheme for intermittently connected

mobile networks,” SIGCOMM‟05, pp. 252-259, August 2005.

[17] RFC 5050: http://tools.ietf.org/html/rfc5050/

[18] K. Brown and S. Singh, “M-TCP: TCP for mobile cellular

networks,” Computer Communication Review, vol.27, no.5, pp.

19–43, October 1997.

[19] A. Campbell, and J. G. Castellanos, “IP micro mobility protocols,”

SIGMOBILE Mobile Computing and Communications Review,

2000.

[20] A. Campbell, J. Gomez, S. Kim, Andras G. Valko, and C.Y. Wan,

“Design, Implementation, and Evaluation of Cellular IP,” IEEE

Personal Communications, pp.42-49, August 2000.

[21] S. Yamamura, A. Nagata, and M. Tsuru, “Towards the trustable

global information logistic infrastructure,” ACM CHANTS‟11,

pp.75-76, 2011.

[22] S. Yamamura, Akira Nagata, and Masato Tsuru, “Store-Carry-

Forward Based Networking Infrastructure: Vision and Potential,”

INCoS‟11, pp.594-599, December 2011.

[23] S. Gracis, E. Davies, A. Lindgren, and A. Doria, “The Evolution

of a DTN Routing Protocol-PRoPHETv2,” ACM CHANTS‟11,

pp.37-30, September 2011.

[24] T. Spyropoulos, K. Psounis, and C. S. Raghavendra, “Spray and

Focus: Efficient Mobility-Assisted Routing for Heterogeneous

and Correlated Mobility,” PerComW'07, pp.79-85, 2007.

[25] J. Burgess, B. Gallagher, D. Jensen and B. N. Levine, “MaxProp:

Routing for Vehicle-Based Disruption-Tolerant Networks,” IEEE

INFOCOM‟06, pp. 1-11, April 2006.

[26] A. Balasubramanian, B. N. Levine, and A. Venkataramani, “DTN

Routing as a Resource Allocation Problem,” ACM

SIGCOMM‟07, pp.1-12, August 2007.

[27] https://tools.ietf.org/html/rfc4838

[28] A. Keränen, J. Ott, and T. Kärkkäinen, “The ONE Simulator for

DTN Protocol Evaluation,” SIMUTools'09, March 2009.

[29] The ONE: http://www.netlab.tkk.fi/tutkimus/dtn/theone/.

[30] W. Zhao, Y. Chen, M. Ammar, M. Corner, B. Levine, and E.

Zegura, “Capacity Enhancement using Throwboxes in DTNs,”

IEEE MASS‟06, pp.31-40, Oct 2006.

[31] N. Banerjee, M. D. Corner, and B. N. Levine,“Design and Field

Experimentation of an Energy-Efficient Architecture for DTN

Throwboxes,” IEEE/ACM Transactions on Networking, vol.18,

N. 2, April 2010.

[32] Y. K. Hassan, A. Aziz, M. E. Haque, and S. Yamada,

“Comparison of Inter-region routing protocols in Delay Tolerant

Networks,” IEICE General Conference, March 2012

http://www.netlab.tkk.fi/tutkimus/dtn/theone/

paper managing disconnected mobile nodes in a …borcea/papers/ieice13-e.pdfmobile devices highlight...

Documents