Barun Saha's blog on AI and Networks

Given a network (a set of nodes) and a set of traffic flows, a network flow allocation assigns network paths to these flows, so that data (for example, packets) can be sent from the respective source nodes to the corresponding destination nodes. In case of optimal network flow allocation, certain criteria, such as latency and utilization, need to be optimized. Moreover, in case of integral network flow allocation, all packets from a source node to a given destination node must travel via a single path or none at all. In other words, such a flow cannot be “split” across multiple paths. Optimal network flow allocation is a computationally hard problem, which not only requires a long time to solve, but also high level of skills. The problem becomes further challenging when unique business and industrial requirements are considered. In our recent work, we investigated this problem in the context of power grid networks, where the flows often require delay-symmetric upstream and ...

Conceptual architecture of SeeR Opportunistic Mobile Networks (OMNs) are characterized by intermittent connectivity among nodes. In many scenarios, the nodes attempt at local decision making based on greedy approaches, which can result in getting trapped at local optimum. Moreover, for efficient routing, the nodes often collect and exchange lot of information about others. To alleviate such issues, we present SeeR, a simulated annealing-based routing protocol for OMNs. In SeeR, each message is associated with a cost function, which is evaluated by considering its current hop-count and the average aggregated inter-contact time of the node. A node replicates a message to another node, when the latter offers a lower cost. Otherwise, the message is replicated with decreasing probability. Moreover, SeeR works based solely upon local observations. In particular, a node does not track information about other nodes, and, therefore, reduces the risk of privacy leaks unlike m...

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 up...

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 ...

The DTN blog recently reached a milestone — it crossed 50,000 page views! The journey of this blog — and that of mine with the ONE simulator — started in 2011. Back in those days, old-timers would recall, there were not much resources available on the ONE simulator. After spending some time with it, I was finally able to gain some understanding about its functionality and work flow. I realized that a short how-to document might benefit others. What started as a humble effort to provide a quick tutorial on the ONE simulator soon became a popular resource in the community over the years. I'm thankful to all the users of the ONE mailing list who continuously kept me motivated to enrich this blog. I took this opportunity to prepare an infographic on the usage of the DTN blog based on the statistics provided by Blogger. It has not been possible to include all statistics in the infographic. A few interesting observations are noted below. Undoubtedly, the ONE tutorial is the mos...

While simulating scenarios with the ONE simulator, one typically defines one or more network interfaces, and add them to the nodes as required. This use case prevails in most of the scenarios. However, a drawback here is that different network interfaces are mutually incompatible — an interface of type 1 can't communicate with any interface not of type 1. Under certain circumstances, it might be required to control the transmission range of one or more network interfaces dynamically from within the simulation. For example, in one of my works, " On emotional aspects in Mission-Oriented Opportunistic Networks ", I have considered the case where users occasionally turn off their device radios based on their contemporary emotions. In particular, the following shows how to set the radio range to 0: ModuleCommunicationBus comBus = host.getComBus(); // Store the original radio range the first time it is reset if (this.originalRadioRange == -1) { this.originalRadioRange = ...

The following metrics are commonly used when evaluating scenarios related to DTN protocols. Delivery ratio of the messages, Average message delivery latency Overhead ratio (of the underlying routing mechanism) Suppose that $M$ be the set of all messages created in the network and $M_d$ be the set of all messages delivered. Then, the delivery ratio is computed as $|M_d| / |M|$. Now let the $i^{th}$ delivered message was created at time $c_i$ and delivered at time $d_i$. Then the average message delivery latency is computed as $(\sum_{i = 1}^{|M_d|} (d_i - c_i)) / |M_d|$. Note that, in Statistics, mean, median and mode are all the measures of average. But "loosely speaking", unless otherwise specified, we refer to the "mean" value when we say "average." Nevertheless, the MessageStatsReport in the ONE simulator provides a measure of both the mean and median values wherever appropriate. One may refer the above metric as "end-to-end delay....

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...

The Virtual Labs project was launched a year ago.  Currently, these labs are undergoing user trials. I have been involved with the development of two virtual labs -- Software Engineering (cse08) and Advanced Network Technologies (cse28) . Interested users may visit these labs. It would be further useful if you could provide feedback on one or more experiments. The feedback link is available in the navigation bar at the top.