[ns] CTS EIFS NAV problem in ns-2.26 ns-2.27 802.11 protocol implementation

[Ahmad Al_Hanbali]

Hi,

I'm sure that reseting NAV didn't exist in ns-2.26, when you receive an
RTS.
I used also the patch of Mike Moreton, i agree with you it is a very
good implementation. 
But i found also in this patch another bug:

When you receive an error free packet not addressed to you, you have to
call the backoff_.setIFStype(Backoff::DIFS); 
and if the ifsEvent_ of EIFS is scheduled you have to cancel this event
according to section 9.2.3.4. But these 2 actions
are not implemented in Mike patch.
There is also a small bug: according to section 9.2.3.4 the eifs
durstion shall begin after finding the medium 
idle "PHY" without regards to the NAV, but in Mike patch this eifs
duration begin after finding the medium idle 
PHY and virtually.

Thanks a lot for your reply
Ahmad 


Jeff Robinson wrote:
> 
> I really don't know the original 2.26 code that well.  For the last
> several months I have been working with the "Synad" EDCF code.  You can
> search the archives to find links to it, and I highly recommend it.  For
> starters, the timing is made a lot clearer, with special functions for
> setting the IFS and setting the NAV.  The code is much more modular and
> easier to understand and modify.
> 
>  On Wed, Jan 21, 2004 at
> 09:11:09AM
> +0100, Ahmad Al_Hanbali wrote: > Hi Jeff , thanks for your reply.
> >
> > Jeff Robinson wrote:
> > >
> > > It sounds like your first problem is real.
> > >  The second problem is not actually a problem.  EIFS terminates whenever a STA receives a correct
> > > transmission. So the STA that gets the RTS ends EIFS as soon as the RTS finishes and replies with a CTS.
> >
> > Can you tell me please where the reset nav is done on receiving the RTS
> > ??
> >
> >
> > What you say is true when i receive a partial part of the frame during
> > the EIFS duration.
> >
> > Let see this scenario:
> > let my time origin be when i completly receives an error frame, so at 0s
> > the EIFS~=1100us(micro seconds).
> > suppose that at 500us i completly receive an RTS addressed to me (when i
> > receive a packet addressed to me
> > i will not reset the nav see function timer_recv() of Mac802_11 class).
> > at 510us the nav will indicate busy
> > so i'm not able to transmit the CTS.  and here the problem.
> >
> > thanks a lot
> > Ahmad AL Hnabali
> >
> >
> > >
> > > Of course, there is still the major problem of ns using EIFS whenever it
> > > detects a collision, it should really make sure that the PLCP header is
> > > correct before deciding to use EIFS.
> > >
> > > Jeff
> > >
> > >  On Tue, Jan 20, 2004 at 12:17:45PM +0100, Ahmad Al_Hanbali
> > > wrote: >
> > > > 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
> > >
> > > --
> > > Jeff Robinson
> > > jeffr at sfu.ca
> > > MASc Student - Simon Fraser University
> 
> --
> Jeff Robinson
> jeffr at sfu.ca
> MASc Student - Simon Fraser University