When simulating 802.11 wireless links, you need to take care of a few extra factors due to the lossy radio links:
You probably want to disable ad hoc routing if you only simulate one BSS:
set val(rp) DumbAgent ;# ad-hoc routing protocol
Otherwise, periodic route adv messages could interfere with your data packets.
Before any data transmissions, the sources and the sinks are required to exchange ARP messages to resolve MAC-IP addresses. This can be a problem for wireless links: if your link is very lossy (e.g. almost 100% drop in one of my experiment), ARP cannot resolve MAC-IP addresses, and the sources keep sending ARP requests periodically throughout the simulation experiments. These ARP request packets would certainly interfere with your data packets. Furthermore because addresses are not resolved, your data packets cannot be transmitted normally in the MAC layer.
To resolve this, I set the first 10 seconds to be initialisation period in my simulations. In this period, all nodes are initially set at close range (within communication range) with each other. Each source transmits one or more dummy packets to its designated sink to establish ARP. Then nodes are moved to their experimental locations, and real data traffic starts to flow from real data sources at 10 seconds.
The 802.11 implementations of ShortRetryLimit_ and LongRetryLimit_ are incorrect: if you set the ShortRetryLimit_ to 7, you would expect the STA to retry for 7 times (total number of transmissions of 8). However, ns-2.33 STA only retransmits 6 times (total number of transmissions of 7). The same happens to LongRetryLimit_. This doesn't conform to the IEEE 802.11 standard which specifies STA to give up "when SLRC reaches aLongRetryLimit, or when SSRC reaches dot11ShortRetryLimit." In the case of ns-2.33, STA give up before reaching the RetryLimit!
The problem is in mac-802_11.cc:
Mac802_11::RetransmitRTS() {... if(ssrc_ >= macmib_.getShortRetryLimit()) ...}
Mac802_11::RetransmitDATA() {... if(*rcount >= thresh) ...}
Corrections: The conditions should be “>” instead of “>=”, as follows:
Mac802_11::RetransmitRTS() {... if(ssrc_ > macmib_.getShortRetryLimit()) ...}
Mac802_11::RetransmitDATA() {... if(*rcount > thresh) ...}
I use ns-2.33 in cygwin on Windows XP. After changing some c++ code in ns2.33/mac/mac-802_11.cc, I run "make" in ns2.33/ to recompile the code. However there is an error in make: proxytrace2any.cc:112: error ...
Here is a solution suggested in http://sokoyo.csit.tw/~blog/2007-12-14/110: Modify file “ns-allinone-2.32/ns-2.32/indep-utils/webtrace-conv/dec/my-endian.h”: //#ifndef _ENDIAN_H_ //#define _ENDIAN_H_ #ifndef _MY_ENDIAN_H_ #define _MY_ENDIAN_H_
802.11 MAC code in NS-2 is an excellent guide on MAC code. Here I will extend it further to 802.11 PHY code in "ns2.33/mac/":
PHY::recv() - is the main handler of PHY interface. It can be called by Mac802_11::transmit() to send a packet via sendDown() with hdr->direction() DOWN. Or it can be scheduled by WirelessChannel::sendUP() to receive a packet via sendUP() with hdr->direction() UP.
WirelessPHY::sendDown() - called by Mac802_11::transmit() to put the packet into the PHY. It first check if the node is off the packet is discarded. If energy management is enabled "em()", transmission energy is deducted for this transmission action. Some parameters, e.g. antenna, transmit power, wavelength l, are stamped onto the node (for the calculation of reception in the receiving node). Then the packet is put onto channel_->recv(p, this).
Channel::recv() - simply calls Channel::sendUP(p, PhyHandler) to put the packet on the the channel.
WirelessChannel::sendUP() - it first change the hdr->direction() to UP. Then it goes through the list of all nodes sortLists() and pick a subset of nodes within communication range: getAffectedNodes(). Then it send a copy of the current packet (newp=p->copy()) to each affected node (rnode) by schedule a reception event to the receiving interface (rifp) of the affected node after a propagation delay (propdelay).
WirelessPHY::sendUP() - It first check if the node is off, sleep, or zero energy level. In these cases, the incoming packet is dropped. The receiving power Pr is calculated, via propagation_->Pr(), according to specified propagation model: such as free space, two-ray ground, and shadowing models (in ns-2.33/mobile/). If Pr is less than CSThresh_, the packet is undetected. If Pr is less than RXThresh_, the packet is received with error. There is a modulation_->BitError(Pr) facility trying to handle bit errors for various modulation mechanisms. However looking at the modulation.cc, it turns out to be a dummy: Pe=0 always! Next, if energy management is enabled "em()" receiving energy is deducted from the reception activity. I couldn't find how it send the packet up to MAC though...