Barun Saha's blog on AI and Networks

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

Opportunistic Mobile Networks: Advances and Applications is our forthcoming textbook to be published by Springer in 2016. This book is a result of our years of experience in research and development in this domain. #TheOMNBook, if you may say, deals with fundamental challenges in OMNs as well as contemporary research issues. These include, but not limited to, routing, mobility, cooperation, heterogeneity, and emotions. An entire chapter is dedicated to protocol development and testing using the ONE simulator. #TheOMNBook is shaped in a way to cater both beginning and advanced level readers. Contextual examples are provided to ensure better understanding of related topics. The chapters come with plenty of hands-on exercises. Several illustrations and other visual elements are used to make reading the book a pleasant experience. Whether you are a seasoned researcher looking for novel cross-dimensional ideas or a beginner to this field, give #TheOMNBook a try! Learn more about our...

Recently ns2web had suffered some downtime. However, it is up and running once again. Any inconvenience caused is regretted. If you are working with NS-2, you may try out the remote simulation and online analysis feature of ns2web . Also, read the article in IEEE Wireless Communications magazine on ns2web.

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