NOTE: if you use any of these extensions for your scientific publication, please, cite our paper, which describes the extensions on higher level.
In order to measure the energy consumed by wireless interface, we measure the
times that the interface remains in each of its operational modes, i.e., sleeping,
idle, receiving, transmitting and sensing.
These times are accumulated by special statistics collector,
implemented as RadioModeStats class, and attached to the radio usually during its creation and initialization
(we considered to add such collector to any radio unconditionally, but preferred to avoid the burden
in simulations not requiring such information).
Thus, we intercept an event of the mode change in a radio in RadioNoise.setMode(mode) method recording the time of the change and the new
mode. At the subsequent mode change, we calculate the length of
the interval for the current mode and, again, record the time of
the change and the new mode. Thus, we accumulate the times during
which the radio was in each of the four modes. At any time during a
simulation, the consumed energy can be calculated by accessing appropriate method of RadioModeStats object
with values for the power consumed at each radio modes. Note that this simple model implicitly assumes the same
transmit (and receive) power as for every time unit.
Code examples:
RadioModeStats creation and attachment to RadioNoise instance:
RadioNoiseIndep radio = new RadioNoiseIndep(id, infoShared);
radio.setStats(new RadioModeStats(warmupTime, Constants.RADIO_MODE_IDLE));
RadioModeStats instance and calculating wasted energy:
RadioModeStats stats = field.getRadioData(id).getStats();
// calculates wasted energy based on the collected statistics, starting
// from the warm up time and assuming that power during sleep is 0 and
// power for sensing is equal to power for receiving.
double energy = stats.getWastedEnergy(powerTx, powerRx, powerIdle);
// calculates wasted energy based on the collected statistics, starting
// from the warm up
double energy2 = stats.getWastedEnergy(powerTx, powerRx, powerSense, powerIdle, powerSleep);
Supporting multiple radios at the same device.
The SWANS simulator features a very limited support for nodes with multiple radios, which
is summarized by an ability to add more than one radio and MAC
module to the same node. These radios, however, operate
independently from one another, which means that a movement of one
does not imply the movement of another. In our extension, we
eliminated this shortcoming by synchronizing the location of both
radios, i.e., under any mobility model, both radios are always
moved to a new location simultaneously.
This is done by introducing virtual notion of primary and secondary radios
(virtual in a sense that both radios are created the same, but added to the field differently).
The primary radio is the one on which Field.startMobility(radioID) method is invoked.
We extended Field class with a method for adding radios while
specifying the id of the primary radio on that node. Field saves a special mapping, thus
when a primary radio is moved, all secondary radios on the same node are moved altogether.
Another issue we addressed in our support for multiple radios is
interference. As opposite to the previous point, the handling of
the interference depends tightly on the types of radios as well as
on the system model assumptions. As mentioned above, in the base
version of SWANS radios behave independently, which results in
interference of a transmission by one radio with any other transmission
in the range (using a SINR based reception model), no matter which
radios transmit and even if both transmissions are emitted from
the same device. Moreover, the transmissions on one interface can
be received by the other interface (in fact, two interfaces on the
same device always receive transmissions one of the other).
We tackle this problem by very simple, yet effective way.
We introduce a possibility to set a name for each radio (BT, WiFi, etc.).
In more detail, the radio name is now a part of the shared radio properties,
i.e., RadioInfo.RadioInfoShared class.
When disseminating a signal over field, in Spatial.SpatialTransmitVisitor.visitTransmit(...) method, we
do not pass signal between radios having different names. Thus, without changing any original interface of the field or
the radio, we provide a flexible way to control whether interference occurs between different types of radios.
Certainly, such design will not provide for cases when partial interference is possible.
In such cases, more elaborated solution, requiring much more changes, is needed.
Code examples:
Creating two different objects of RadioInfo.RadioInfoShared for two radio types:
RadioInfo.RadioInfoShared wifiRadioInfoShared = RadioInfo.createShared(..., "WiFi");
RadioInfo.RadioInfoShared btRadioInfoShared = RadioInfo.createShared(..., "BT");
Creating radios and adding them to Field:
// radio1 is the primary radio and radio2 is the secondary one
RadioNoiseIndep radio1 = new RadioNoiseIndep(id1, wifiRadioInfoShared);
RadioNoiseIndep radio2 = new RadioNoiseIndep(id2, btRadioInfoShared);
// specify id of the primary radio when adding the secondary one to the field
field.addRadio(radio1.getRadioInfo(), radio1.getProxy(), nodeLocation);
field.addRadio(radio2.getRadioInfo(), radio2.getProxy(), nodeLocation, id1);
// start mobility on the primary radio only
field.startMobility(id1);
Another usage example: This extension can also be used to support multi-channel interfaces. Suppose you have an interface, e.g., WiFi, that can operate on X different channels. Then you need simply to create X radio interfaces, giving them X different names, like "WiFi_Chanel1", "WiFi_Chanel1", ..., and add all of them to each node. Note, though, that currently, all interfaces you define are able to receive packets sent on that interface. This means that if you decide to switch to channel 6 and some node Pi still transmits on channel 2, other nodes around will still receive Pi's packets on channel 2. To prevent this from happening, you might need to turn off interfaces (here, channels) which are not in use. If you need this feature, write me for further help.
An example of heartbeat application on multiple radios can be found here:
You can put testDriver.java in the driver directory of SWANS and modified
AppHeartbeat.java in the jist/swans/app directory, and try it.
The full changelog is available here.