Skip to main content

Controlling Transmission Range from within the Simulation

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 = Double.valueOf(
   (Double) comBus

// If the radio was made OFF, restore the radio
double range = (Double) comBus.getProperty(NetworkInterface.RANGE_ID);

// Some related logic here ... skipped

if (range == 0.0) {
Here, the original radio range (set in the settings file) is stored the first time the code is executed. Next, the NetworkInterface.RANGE_ID property is used to retrieve/update the current transmission range. Use this code along with your logic to change the transmission range.

Update (06 June 2014):

The above code snippet is unlikely to be written in the NetworkInterface class. One can incorporate this into his/her own routing/application module. However, this should not be written inside any constructor or any method invoked by the constructor. A suitable candidate would be the update() method with some checks.

Update (23 December 2016):

The method described above would not work for nodes that have more than one network interface.


  1. I want to create two interfaces:
    1. for cars . it has lower range , say 30m
    2. for special type of nodes which can take message from car and send it to other car or to same special node. it would have higher range say 200m.

    How can i implement it. Please help.

    1. You can create two different types of network interfaces in simulation scenario. However, they would be incompatible. Alternatively, reduce/increase the transmission range of the relevant nodes dynamically once the simulation begins as discussed above.

    2. In which .java file i have to implement it. Please explain more about implementation and how can i achieve my objective. i am confused.

  2. How can i obtain contact time at first node using ONE simulator

  3. Hi Barun,
    I want to create my own message event generator. Do I have to register this class with the simualtor? If yes, then how? Please help me with this.


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.


% 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…

SeeR: Simulated Annealing-based Routing in Opportunistic Mobile Networks

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 many other protocols. We evaluated the …