[ns] CTS EIFS NAV problem in ns-2.26 ns-2.27 802.11 protocol
implementation
Ahmad Al_Hanbali
Ahmad.Al_Hanbali at sophia.inria.fr
Tue Jan 20 03:17:45 PST 2004
Hello for all
I'm a Phd student, I'm working on ADhoc networks. I found these problems
in ns-2.26 implementation of 802.11 protocol.
The first problem is :
According to 802.11 protocol specification section 9.2.5.7, "a STA that
is addressed by an RTS frame shall transmit a CTS frame
after a SIFS period if the 'NAV' at the STA receiving the RTS frame
indicates that the medium is idle", so the sensing on sending a CTS is
'only' virtually. But in protocol implementation in ns-2.26 see file
../ns-2.26/mac/mac-802_11.cc function check_pktCTRL() the sensing is
virtually and physically using the function is_idle().
==================================================
int
Mac802_11::check_pktCTRL()
{
struct hdr_mac802_11 *mh;
double timeout;
if(pktCTRL_ == 0)
return -1;
if(tx_state_ == MAC_CTS || tx_state_ == MAC_ACK)
return -1;
mh = HDR_MAC802_11(pktCTRL_);
switch(mh->dh_fc.fc_subtype) {
/*
* If the medium is not IDLE, don't send the CTS.
*/
case MAC_Subtype_CTS:
if(!is_idle()) {
discard(pktCTRL_, DROP_MAC_BUSY); pktCTRL_ = 0;
return 0;
}
.
.
.
==================================================
The problem second is on receiving an erronoius frame by a node the
simulator set the NAV to eifs duration see file mac-802_11.cc function
recv_timer()
==================================================
if( ch->error() ) {
Packet::free(pktRx_);
set_nav(usec(eifs_));
goto done;
}
==================================================
So in case of receiving RTS in this eifs duration, i will not respond by
a CTS conforming CTS procedure section 9.2.5.7. And conforming to this i
will not stop
the EIFS period according to section 9.2.3.4.
Its pleasure to me hear your comments.
Ahmad
More information about the Ns-users
mailing list