Skip to main content

Effects of Buffer Size on Delay Tolerant Routing

In this post, we look at how buffer size affects, if at all, the performance of the routing protocols in DTNs. For this purpose, we will consider the following five routing protocols:
  • Epidemic
  • PROPHET
  • Spray-and-Wait (SnW)
  • First Contact (FC)
  • Direct Delivery (DD)
 Detailed discussion of these protocols is scoped out here. We just note that in case of Epidemic, there is unlimited replication of the messages. In PROPHET, however, the replication is usually less than that of Epidemic. On the other hand, SnW has a fixed limit (L) on possible number of replications of a message. Finally, FC and DD involve message forwarding -- not replication. So, in the latter cases, there is always a single copy of any message in the DTN.

We will consider the buffer sizes from 20 MB to 180 MB, both inclusive, in steps of 20 MB so that we have total 9 different buffer sizes. We will use the real-life connection traces from Infocom'06. Therefore, we will need to simulate 5 * 9 = 45 scenarios to get the relevant results. The contents of the default_settings.txt file are as shown below.

#
# Different routing protocols with 78 nodes using connection traces from
# Infocom'06.
#
# 
# Group.router: 5
# Group2.bufferSize: 9
# Total scenarios = 5 * 9 = 45
#

## Scenario settings
Scenario.name = %%Group.router%%_%%Group.bufferSize%%

Scenario.simulateConnections = false
Scenario.updateInterval = 5.0

# 43200s == 12h
Scenario.endTime = 43200
Scenario.nrofHostGroups = 1
Scenario.nrofHosts = 78


## Interface-specific settings:
# type : which interface class the interface belongs to
# For different types, the sub-parameters are interface-specific
# For SimpleBroadcastInterface, the parameters are:
# transmitSpeed : transmit speed of the interface (bytes per second)
# transmitRange : range of the interface (meters)

# "Bluetooth" interface for all nodes
btInterface.type = SimpleBroadcastInterface
# Transmit speed of 2 Mbps = 250kBps
btInterface.transmitSpeed = 250k
btInterface.transmitRange = 10


## Group-specific settings:

# Common settings for all groups
Group.movementModel = StationaryMovement
Group.nodeLocation = 10, 10

Group.bufferSize = [20M; 40M; 60M; 80M; 100M; 120M; 140M; 160M; 180M;]


# All nodes have the bluetooth interface
Group.nrofInterfaces = 1
Group.interface1 = btInterface
# Walking speeds
Group.speed = 0.5, 3
# Message TTL of 300 minutes (5 hours)
Group.msgTtl = 3000

Group.router = [EpidemicRouter; ProphetRouter; SprayAndWaitRouter; FirstContactRouter; DirectDeliveryRouter;]

SprayAndWaitRouter.nrofCopies = 16
SprayAndWaitRouter.binaryMode = true

ProphetRouter.secondsInTimeUnit = 30

Group.groupID = n
Group1.nrofHosts = 78



## Movement model settings
# seed for movement models' pseudo random number generator (default = 0)
MovementModel.rngSeed = 0
# World's size for Movement Models without implicit size (width, height; meters)
MovementModel.worldSize = 50, 50


# How many event generators
Events.nrof = 2

## Connection trace information
Events1.class = ExternalEventsQueue
Events1.filePath = my_scenarios/infocom-78n-24hr.tr

## Message creation events
Events2.class = MessageEventGenerator
Events2.hosts = 0,78
Events2.prefix = M
Events2.interval = 30,60
Events2.size = 50k,1M
Events2.time = 0,18000



## Reports - all report names have to be valid report classes
# how many reports to load
Report.nrofReports = 1
Report.reportDir = my_reports/buffer_size/
# Report classes to load
Report.report1 = MessageStatsReport


## Optimization settings -- these affect the speed of the simulation
## see World class for details.
Optimization.cellSizeMult = 5
Optimization.randomizeUpdateOrder = true

Now, let us take a look at some results. Figure 1 shows the delivery ratio of the messages obtained when these routing protocols were used together with the different buffer sizes.

Figure 1: Effects of buffer size on the delivery ratio.
 There are three clear trends in this Figure:
  1. The delivery ratio steadily increased with the increasing buffer sizes in the case of Epidemic and PROPHET routing protocols.
  2. For First Contact and Direct Delivery routing, the delivery ratio was invariant of the buffer sizes.
  3. In case of SnW, the delivery ratio exhibited increasing trend upto a certain extent, beyond which it saturated.
Why?

The nature of the routing protocols provide some hints here. Unlimited replication-based benefit from the increasing buffer size since, more buffer space implies more nodes can carry with them more message copies. On the other hand, in case of single copy-based message forwarding, the same does not hold  true.

So, how does SnW behave with increasing buffer sizes for different values of L? You can verify it yourself. For different L, the increasing size of buffer helps improving the delivery ratio upto different extents beyond which the performance do not vary.

Check out the article Effects of Heterogeneity on the Performance of Pocket Switched Networks for a detailed discussion and many more interesting scenarios.

Comments

  1. the scrip can't run...
    where we can get "Events1.filePath = my_scenarios/infocom-78n-24hr.tr"??

    thx u atention


    ReplyDelete
    Replies
    1. Ians,

      The trace file referred to above is the Infocom'06 connection trace that you can download from the CRAWDAD repository (http://crawdad.cs.dartmouth.edu/) and pre-process for use with the ONE simulator.

      Otherwise, you can simply use some synthetic mobility model.

      Delete
  2. Hello sir... i am unable to see ur blog...
    "you dont have permission to access this blog.. change your email id".

    how can i access your blog??

    ReplyDelete

Post a Comment

Popular posts from this blog

Text Highlighting in Latex

While preparing a manuscript with Latex, it is often useful to highlight the changes made in the current revision with a different color. This can be achieved using the\textcolor command provided by Latex. For example,\textcolor{red}{Hello World}would display the string "Hello World" in red color.

However, the final/published copy of the manuscript does not contain any highlighted text. Therefore, if a large volume of changes were made, it becomes tiresome at the end to find and remove all the individual portions of highlighted text.

This can be circumvented by defining a utility command to switch highlighting on and off as desired. In the following, we define a new Latex command, highlighttext, for this purpose. The command takes only a single argument -- the text that it should highlight.

    \usepackage{color}

% For highlighting changes in this version with red color
    \newcommand{\highlighttext}[1] {\textcolor{red}{#1}}
    % Remove all text highlighting
    % Useful to gener…

Specifying Source and Destination of Messages

One of the frequently asked questions in the community is how to specify which particular nodes would act as source(s) and destination(s) of the messages created in the ONE simulator. The simulator, in fact, provides a pair of settings (shown below in bold face) aimed for this particular purpose.

Let us consider that there are $n + 1$ nodes in an OMN.  Further, let the nodes with addresses from $x$ to $y$, both inclusive, would create messages. The nodes in the range $w$ to $z$, both inclusive, would be the destinations of those messages, where $0 \le x \le y \le n$, and $0 \le w \le z \le n$. Then, the corresponding simulation scenario can be configured as follows.

## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (Following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25,35 # Me…

IllegalArgumentException in Simulations

At times, users have reported of runtime exceptions while running a simulation that uses PRoPHET. The error signature looks like the following.

Exception in thread "main" java.lang.IllegalArgumentException: Comparison method violates its general contract! at java.util.TimSort.mergeHi(Unknown Source) at java.util.TimSort.mergeAt(Unknown Source) at java.util.TimSort.mergeCollapse(Unknown Source) at java.util.TimSort.sort(Unknown Source) at java.util.Arrays.sort(Unknown Source) at java.util.ArrayList.sort(Unknown Source) at java.util.Collections.sort(Unknown Source)
It may be noted that the default sorting algorithm has changed since Java 7 — rather than Merge sort, Tim sort is now used by default. However, it seems like it is possible to override the default sorting algorithm in Java using the following argument to the JVM.
-Djava.util.Arrays.useLegacyMergeSort=true
The execution command in the one.sh (or one.bat) file should be updated with the above argument to something like this:

j…