Some Experiences with Implementing Simulation Support for Heterogeneous Multi-channel Wireless Networks in ns-2

(Documented by Vartika Bhandari in 2008)

I have recently worked on simulating multi-channel wireless networks with heterogenous interfaces in ns-2 (details are available in Chapter 6 of my Ph.D. dissertation). Doing so in a reasonable manner required a lot of changes in ns-2 at all levels. I have often benefited from information put up by others on various ns-2 issues encountered by them. Therefore, I decided to document some of my own experiences, in the hope that they may be useful to others. This is by no means a comprehensive list of all changes required, but provides an overview of one possible way of incorporating support for such simulations in ns-2. I will add to the description in the near future. I may also augment it with experiences from some work that I am currently doing. The ns-2 version I used is ns-2.31.

NOTE: Many of the choices I made were influenced by wanting to limit the number of changes I had to make to the existing ns-2 code structure. Thus, these are not the best or most elegant way of doing things.

Physical Layer

Support for Cumulative SINR-based reception, and multiple channels with different frequency/propagation characteristics:

Class modified: WirelessChannel

I added a propagation object handle to the WirelessChannel (this also requires changes in ns-lib.tcl). This is logically consistent with the fact that propagation is a characteristic of the channel and not the interface (by default ns2 gives a propagation handle to each WirelessPhy). Similarly, frequency and bandwidth are both now attributes of WirelessChannel. Further the WirelessChannel keeps a timer for each packet still on air, and provides a query/callback interface to interfaces that wish to know their total received signal power (the interface passes down its location/antenna information to allow WirelessChannel to do so).

Adding channels to simulator: ns2 by default does not have a clean way of adding multiple channels to a simulation (the channel handle is passed through the node-config command, which is quite convoluted and confusing). So I added a simple "create-new-channel { channeltype freq bandwidth propType }" function to ns-lib.tcl. Any channels that are to be used during simulation are created using this function. This must be done before nodes are created (for reasons that will become apparent later).

Class modified: PacketStamp

I have modified the PacketStamp class to include information about frequency of channel on which packet is sent, as well as the modulation that is used. The latter allows a receiving interface to determine whether or not it is capable of decoding the packet. This is relevant when we have 802.11b and 802.11g interfaces, and a 802.11g interface sends a packet using an OFDM modulation/rate.

Class created: MultiPhy

I created a new class to handle heterogeneous wireless interfaces with multi-channel ability. Currently, I have support for 802.11b, 802.11g, 802.11a, and 802.11ag. However support for additional types primarily requires updating modulation/datarate/SINR data, and changing some conditionals. Currently I have subclassed MultiPhy from WirelessPhy, primarily to avoid things breaking elsewhere. But it could be made a standalone class directly subclassed from Phy.

Channel-switching: The MultiPhy class has timer objects to model switching delay, and also to potentially defer switching if needed (e.g., if a packet transmission is ongoing, then as a policy one may decide to defer switching till the transmission is over). It is important to take care as to how/when one removes the phy object from the interface-list of one channel and puts it into that of another. Since propagation delay is non-zero, if this is not done correctly, then one or both of the following erroneous scenarios may arise:

An interface receives a copy of packet that was sent on the channel it just switched from (this may happen if the rx-start event was enqueued in Simulator's event-queue prior to removal from old-channel's list, and thereafter not cancelled or checked for)
An interface does not receive a copy of a packet whose tx at sending node started before it finished its switch to the new channel, but whose time of first detection (tx-start+prop-delay) is after the switch was successfully completed (this may happen if the rx-start events for that packet were processed and enqueued when the interface was not in the new channel's list, and after switching appropriate checks are not made).

While these may seem minor anomalies involving at most 1 packet at the time of switch, they may add up when simulating a system where interfaces switch channels frequently.

Adding new interfaces: I modified the "add-interface" function in ns-mobilenode.tcl, and added a new function "create-new-interface".

Class modified: Mac802_11

The MAC class needed modification to (1) handle Physical Carrier Sense correctly (2) temporarily store a packet received from IFQ if a channel switch is needed to send it. I also fixed a few bugs in the mac code.

Scripting Interface

I use the create-new-channel function described above to add channels to the simulation setup as required, and also provide the OTcl script a handle to each channel. I pass on one of these as a default channel to node-config using the -channel option solely to avoid having to change the node-config command. Before a new node is created, I use commands (added by me) setdefault-mphytype and setdefault-channel to set the defaults. When a new node is created, the default interface's phytype and initial channel is determined by these default values. Additional interfaces are added to the node using the create-new-interface command mentioned above.