ieee 802.11 -----ns

TOMATOFAN

http://www.ict.csiro.au/staff/ren.liu/ns-2/simulate-802_11.htm 的翻译

当模拟 802.11无线连接，需要注意失真链路带来的问题：

Disable ad hoc routing:

在一个BSS中模拟的时候，可能要禁止da hoc路由功能

set val(rp) DumbAgent ;# ad-hoc routing protocol

否则，周期性的路由数据包将会打断 数据的传输

在模拟之前建立好ARP

ARP，即地址解析协议，实现通过IP地址得知其物理地址

任何数据传输之前，源和目的地址需要交换的ARP信息，以解决MAC的IP地址。 这可以是一个无线连接的问题：如果 你的链接是非常失真（例如，几乎100％），ARP协议无法解析的MAC - IP地址，将在整个模拟实验不间断的发送ARP请求。 这些ARP请求报文肯定会干扰你的 数据包。 此外，因为地址不解决，你的数据包不能正常传送的MAC层

为了解决这个问题，在我的模拟初始化阶段 ，设置了前10秒 。 在此期间，所有节点的初始设置在近距离（通信范围内）与对方。 每个源传输一个或多个虚拟数据包接收到其指定设立的ARP。 然后，节点移动到他们的实验场所，交通流的实际数据开始从实际数据在10秒来源。

802.11 xRetryLimit_实现不正确

对ShortRetryLimit_ 802.11实现和LongRetryLimit_不正确：如果您设置ShortRetryLimit_至7，你会期望在STA为7次（8传输的重试总 数）。 然而，2.33 STA中只转发6次（总人数的7转播）。 同样的情况，以LongRetryLimit_。 这不符合的IEEE 802.11标准规定STA中放弃“当SLRC达到aLongRetryLimit，或当达到dot11ShortRetryLim

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) ...}Recompile error for ns-2 in cygwin

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_                                                                                                                                                                                                                                                    Understand 802.11 PHY code in ns-2

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