Subject: [manet] Question on 802.11DCF

From: Peter Pham <[email-masked]>
Date: Mon, 10 Nov 2003 10:43:34 +1030

Hi all

I read the standard of 802.11 and it is confusing on how you interpret 
the standard.
If the channel is  already idle for a long-long time (low data rate), 
and the mobile node has a packet for transmission, will the mobile nodes 
send the packet after a DIFS  or DIFS + Deferal time ?
 From the standard it said that "if the medium is busy, it will sense 
the channel until  the channel is idle for a DIFS and it performs a 
additional deferal time". It does not state what to do when the medium 
is idle. Do the node need to do a deferal backoff in this case ? does 
the node alway have to to defer after a DIFS ?

Can you please provide some insight here.

Best regards
Peter Pham

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Joon Yoo" <[email-masked]>
Date: Mon, 10 Nov 2003 09:40:07 +0900

----- Original Message ----- 
From: "Peter Pham" <[email-masked]>
To: "MANET" <[email-masked]>
Sent: Monday, November 10, 2003 9:13 AM
Subject: [manet] Question on 802.11DCF

> is idle. Do the node need to do a deferal backoff in this case ? does 

In this case, where the node has been sensing the channel as idle before the packet arrival, the node will wait for a DIFS period and transmit the packet without any backoff procedures (equivalent to backoff value=0). This is called "Immediate Access".  In other words, when no on-going backoff and over DIFS idle time, a frame can be transmitted immediatley.

> the node alway have to to defer after a DIFS ?

In case of DCF, yes. 

> Can you please provide some insight here.
	šëfj)bž	b²Ùšëbz×è®m¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ùšë

---

From: Peter Pham <[email-masked]>
Date: Mon, 10 Nov 2003 15:10:08 +1030

Hi
There are two terms that must be distinguished here. Defer and Backoff.

Is it true that after every DIFS we perform a Defer ?
How Defer and Backoff interact  ?

Let discuss in this scenario. After a successful transmission, the 
sender receive and ACK. It will perform a backoff  (this one should be 
called backoff ? right)... After this backoff, there are two cases here
1) if there is no packet for transmission and the channel is idle. The 
node goes to idle right ?....Once the node in idle state and the channel 
is idle and there is a packet arrival ? the node performs a DIFS + defer 
or just DIFS  before sending the packet ???
2) if there is a packet for transmission and the channel is idle, it 
performs are DIFS + defer or just a DIFS ???

This is where I find the standard confused here ...

Cheers
Peter Pham

---

From: Dong Zheng <[email-masked]>
Date: Sun, 09 Nov 2003 22:04:40 -0700

On Sun, 2003-11-09 at 21:40, Peter Pham wrote:
> called backoff ? right)... 
No need if there is no packet in the output queue and the BO (backoff)
is simply left as 0. However, if the queue is not empty, the BO will be
set and it will compete for the channel again.

If somehow later it has a packet to deliver, it will first check if the
channel is idle and NAV ?= 0. If not, it will wait for the channel to
become idle again, set the BO and compete for the channel after DIFS.
Otherwise, it will just wait for DIFS, and if no one else transmits
before the DIFS period expires, it will transmit the packet immediately
after the DIFS period.

Hope this can help you, correct me if I am wrong.

-Dong

After this backoff, there are two cases here
> node goes to idle right ?.... Once the node in idle state and the channel

---

From: bjkwak <[email-masked]>
Date: Mon, 10 Nov 2003 12:33:51 -0500

[My apologies, if you have received multiple copies of this e-mail!]

Hi Dong,

> set and it will compete for the channel again.

In 5th paragraph, Section 9.2.5.2, IEEE 802.11 specification, it says

"A backoff procedure shall be performed immediately after the end of 
every transmission [ ... ] even if no additional transmissions are 
currently queued."

> before the DIFS period expires, it will transmit the packet immediately

My understanding is, if a packet arrives, a node checks if the channel 
has been idle for DIFS, instead of checking if the channel is idle for
DIFS after the arrival of the packet.

Thanks!

Byung-Jae Kwak

-- 
 Anyone can be passionate,
 but it takes real lovers to be silly.  - Rose Franklin

---

From: Dong Zheng <[email-masked]>
Date: Mon, 10 Nov 2003 14:42:08 -0700

> every transmission [ ... ] even if no additional transmissions are 
Yes, you are right. But does this backoff mean that you have to set up
the Backoff Timer? My understanding is since you don't have any packets
in the queue, then definitely you have to be silent (backoff) for a
while. ;-)

BTW, I also read the code from GlomoSim, here is the code:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void Mac802_11CheckForOutgoingPacket(GlomoNode *node, GlomoMac802_11
*M802)
{
   if
(!NetworkIpOutputQueueIsEmpty(node,M802->myGlomoMac->interfaceIndex))
   {
      Mac802_11SetBackoffIfZero(node, M802);
      AttemptToGoIntoWaitForDifsOrEifsState(node, M802);
   }
   else
   {
      assert(M802->BO == 0);
      Mac802_11SetState(node, M802, M802_11_S_IDLE);
      Mac802_11CancelTimer(node, M802);
   }
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This function is called after a successful ACK has been received. As you
can see, if there is no packet in the queue, it will simply leave BO
(the Backoff Timer) as zero.

> DIFS after the arrival of the packet.
But does that mean if the channel has been idle for DIFS, it will
transmit the packet immediately?

Thanks!

-Dong

---

From: bjkwak <[email-masked]>
Date: Mon, 10 Nov 2003 18:34:37 -0500

Hi Dong,

> BTW, I also read the code from GlomoSim, here is the code:

I see!  But, I believe we have to follow the published STANDARD 
if there is a disagreement between the standard and an 
implementation.

A while ago, our group was working on performance analysis of
the IEEE 802.11 DCF and we used OPNET for the simulation.
At first the simulation result (OPNET 7) was quite different
from our analysis result.  We decided to investigate the OPNET 
WLAN model and later found out there were some bugs in the OPNET
model.  We reported the bugs to OPNET company and they fixed
the bugs in a very timely manner.  OPNET 9 has all the bugs
we reported fixed and it implements the 802.11 standards quite
accurately.  (There were still some areas that needed some
work when OPNET 9 was released though.)
I am sure GlomoSim has a lot of bugs, too.

> transmit the packet immediately?

Actually, that is where the standard is very confusing.
What I understand is as follows:

Node A Tx a packet;
Node A receives an ACK;
Node A starts a backoff procedure:
  choose random backoff and count down;
If the queue was not empty at the time of reception of ACK
  then
    Enter normal backoff procedure;
  else // Queue was empty
    If a packet arrives before the backoff counter expires
      Then
        Wait until the timer expire;
        Tx the packet after DIFS idle time;
      else // A packet arrives after the timer expires
        If channel has been idle for more than DIFS
          then
            Tx the packet right away;
          else
            Enter normal backoff procedure;
        endif
    endif
endif

Thanks!

Byung-Jae Kwak
------------------------------------------
Wireless Communication Technologies Group
Advanced Network Technologies Division
NIST, MD

---

From: Dong Zheng <[email-masked]>
Date: Mon, 10 Nov 2003 16:24:51 -0700

Hi, Byung,

It seems that our understanding bifurcates from the clause "In general,
a STA may transmit ..., when the STA determines that the  medium is idle
for greater than or equal to a DIFS period ..." In my understanding, the
STA determines that the medium will be idle for DIFS, however, your
understanding is that the STA determines that the medium has been idle
for more than DIFS. But a closer look at Fig. 51 tells that the STA will
wait for DIFS instead of checking the channel has been idle for DIFS.

Can sb. else help us clarify this confusion? ;-)

>   choose random backoff and count down;
If the average of this backoff time is less than DIFS ...

>     Enter normal backoff procedure;
then it will give priority to this node cause other nodes will wait for
DIFS before they can enter the backoff procedure.

---

From: bjkwak <[email-masked]>
Date: Tue, 11 Nov 2003 12:35:54 -0500

Hi Dong,

> Hi, Byung,

It is Byung-Jae :)

> >             Enter normal backoff procedure;

I guess I was not clear enough in my description.
Below is an improved version.  

Note: In my original description, the "normal backoff
procedure" was meant to be:

 waiting DIFS + choosing random number + counting down.

In the new description below, it does not include the
DIFS to be clearer.

STA A Tx a packet;
STA A receives an ACK;
STA A waits for DIFS;
STA A choose a random number for backoff and counts down to zero;
If (STA A has a packet in the queue)
  then
    STA A Tx the packet;
  else
    STA A waits until a packet arrives;
    switch (channel idle time)
        case (the channel has been idle for more than DIFS):
          STA A Tx the packet right away;
        case (the channel has been idle for T_idle < DIFS):
          STA A waits for DIFS - T_idle;
          STA A enters a normal backoff procedure;
        case (the channel is busy)
          STA A waits until the channel becomes idle;
          STA A waits DIFS;
          STA A enters a normal backoff procedure;
    endswitch
endif 

I hope that it makes sense now!

Thanks!

Byung-Jae Kwak

---

From: Peter Pham <[email-masked]>
Date: Wed, 12 Nov 2003 11:28:26 +1030

Hi all

There are two concerns here
Firstly,  this is the ns2 code when receiving a packet from the upper 
layer. Focusing on the first case of the switch on what Byung-Jae said , 
in this case backoff is already performed therefore it will go to the 
true part of the if statement.
The defer is also not busy, therefore it start defering a DIFS + random 
slot time of the windows. It only Tx the packet after finishing the defer.
If what Byung-Jae stated is true, ns2 code is false which casts doubts 
on simulations results from ns2.

     */
    if(mhBackoff_.busy() == 0) {
        if(is_idle()) {
            /*
             * If we are already deferring, there is no
             * need to reset the Defer timer.
             */
            if(mhDefer_.busy() == 0) {
                rTime = (Random::random() % cw_) * (phymib_->SlotTime);
                mhDefer_.start(difs_ + rTime);
            }
           
        }
    /*
     * If the medium is NOT IDLE, then we start
     * the backoff timer.
     */
        else {
            mhBackoff_.start(cw_, is_idle());
        }
    }

Secondly, please correct me if I am wrong...
If it is like what you said then the node will have to wait 2 DIFS in 
the second and third case of the switch ?
Please look at the comment with the #

******************************************************
normal packoff procedure:
waiting DIFS + choosing random number + counting down.
******************************************************
STA A Tx a packet;
STA A receives an ACK;
STA A waits for DIFS;
STA A choose a random number for backoff and counts down to zero;
If (STA A has a packet in the queue)
  then
    STA A Tx the packet;
  else
    STA A waits until a packet arrives;
    switch (channel idle time)
        case (the channel has been idle for more than DIFS):
          STA A Tx the packet right away;
        case (the channel has been idle for T_idle < DIFS):
          STA A waits for DIFS - T_idle; // -> therefore wait totally one DIFS here 
          STA A enters a normal backoff procedure; //wait another DIFS + random number of slot time here
        case (the channel is busy)
          STA A waits until the channel becomes idle;
          STA A waits DIFS; // one DIFS 
          STA A enters a normal backoff procedure; //wait another DIFS + random slot time here 
    endswitch
endif

---

From: bjkwak <[email-masked]>
Date: Wed, 12 Nov 2003 20:54:48 -0500

Hi Peter,

No!  In the NEW description:

 normal backoff = choosing random number + chounting down

Byung-Jae

---

From: Mineo Takai <[email-masked]>
Date: Tue, 25 Nov 2003 22:53:41 -0800

Hello Byung-Jae and Dong,

I could not join the discussion in a timely manner even though the 
GloMoSim code was cited. Now that I had a chance to look into the 
standard, and can comment on a few issues.

<snip>

> if there is a disagreement between the standard and an 

I acknowledge this as a GloMoSim bug, although I think its effect is 
minimal (at least for many MANET studies in which the network is loaded 
with a lot of traffic). With this bug, STA may transmit a packet (aCWmin 
* aSlotTime) sooner than defined in the standard in the worst case (half 
the time on average). But this happens only when (a) an application 
somehow requests MAC to send a packet right after MAC sees that the 
queue is empty, and (b) other STAs do not transmit any packet after DIFS 
because none of their backoff timers expires on that time slot. If these 
two conditions are met, fairness among multiple STAs can be incorrectly 
simulated. Again, it is very difficult to create such conditions though.

I (or our students) will fix it and try updating the distribution. 
Thanks for pointing this out.

<snip>

> Actually, that is where the standard is very confusing.

Yes, it is very confusing, so I took a look at the formal description of 
MAC operation (Annex C) towards the end of the standard. According to 
that description, STA waits for DIFS after the arrival of the packet, 
instead of examining if the channel has been idle for DIFS. Here are 
several places to look at:

"Process Tx_Coordination_sta: sta_tx_idle_2d(10)," on page 345 includes 
an input symbol "Pdu_Request(fsdu)." This is the request of packet 
transmission given by the higher layer. If we trace down the flow, STA 
performs "Backoff(0, 0)" before going to "send_rts" or "send_mpdu" in 
the next page.

Backoff(cw, cnt) is defined in "Process Backoff_Procedure" on pages 356 
and 357. If Backoff(cw, cnt) gets called with arguments (0, 0), it exits 
the process with value -2 if the channel is idle for DIFS since 
Pdu_Request(fsdu).

Let's go back to the flow after Backoff(0, 0). "Process 
Tx_Coordination_sta: sta_tx_dcf_3d(10)" on page 346 checks the return 
value of the backoff procedure (bstat). If bstat == -2, it requests PHY 
to transmit an RTS or MPDU immediately, otherwise it calls Backoff(ccw, 
-1) in which case a new random backoff value is chosen.

(I only have the latest standard "1999 Edition (R2003)" so the page 
number may be slightly off.)

I think no one can follow what I am talking about without the standard 
handy :-) but I am certain that STA waits for DIFS after receiving the 
packet from the higher layer.

>       else // A packet arrives after the timer expires
!!!       Wait for DIFS; if channel is idle during the DIFS period
!!!         then
!!!           Tx the packet
>             Enter normal backoff procedure;

Hope this helps,

Mineo

---

From: Dong Zheng <[email-masked]>
Date: Wed, 26 Nov 2003 00:38:22 -0700

Hi, Mineo,

Thanks for your comments.

> simulated. Again, it is very difficult to create such conditions though.
Suppose that you have a CBR traffic with inter-arrival time slightly
bigger than the transmission time of the packet and other CBR flows have
larger interval time, or suppose there is a high traffic load, then this
situation should happen more frequently. 

> I (or our students) will fix it and try updating the distribution. 
GloMoSim or Qualnet? ;-)

Anyway, I have another question which I posted on the mailing list of
GloMoSim.  I guess the Rayleigh fading implementation has a bug (if you
plot the values that it generates for the fading_dB, it is actually
Rayleigh distributed, not exponentially distributed), the correct code
should be:
*fading_dB = 10.0 * log10(-2.0 * RAYLEIGH_VARIANCE *
log(pc_erand(seed)));

Also RAYLEIGH_VARIANCE should be given a value of 0.5, thus not
introducing any energy into the channel.

Thanks,
-Dong

---

From: Mineo Takai <[email-masked]>
Date: Wed, 26 Nov 2003 00:31:33 -0800

Dong:

My comments are in line.

> situation should happen more frequently. 

Well, sure. If you create a scenario intentionally to expose this bug, 
it is not difficult. But again, I think typical manet scenarios with xx 
pps CBR flows would hardly create this situation. Also, I don't know any 
real application that would generate such traffic patterns. Even if 
there is one, the delay (jitters) caused by host-NIC communications is 
more than a few hundred microseconds, so it is hard to hit this spot 
every time.

> introducing any energy into the channel.

I will look into the model and get back to you in the glomosim mailing 
list. Please don't post a GloMoSim bug report here to make me respond to 
defend ;-) It's outside the scope of this mailing list.

Mineo

---

From: Mineo Takai <[email-masked]>
Date: Wed, 26 Nov 2003 16:51:25 -0800

Dong:

I decided to copy this message to [email-masked] just because I don't want 
people on this mailing list to unconsciously think the current GloMoSim fading 
models (and studies that used the models) are inaccurate.

I see no problem with the GloMoSim Rayleigh fading model. It does produce a 
Rayleigh distribution, and I don't know why we need to use an exponential 
distribution which is the cdf of Rayleigh. Is there a rational behind it?

As for RAYLEIGH_VARIANCE, the default value gives the mean value of 1.0 (or 0 
dB) such that the fading model does not have an effect on the average rx power.

Regards,

Mineo

---

From: Dong Zheng <[email-masked]>
Date: Wed, 26 Nov 2003 22:58:25 -0700

Hi, Mineo,

Please correct me if I am wrong. 

The Rayleigh distribution has the cdf as:
F = 1 - exp(-r^2/(2*sigma^2))

So we generate r using inverse transform method as:
r = sqrt(-2*sigma^2*log(u)),
where u is a uniform random number between 0 and 1.

To compute the channel gain, we need to compute:
fading_gain = 10*log10(r^2) = 10*log10(-2*sigma^2*log(u)).
However, the original code is 5*log10(-2*sigma^2*log(u)). 

For the Rayleigh variance, the expected value of r^2 is:
E(r^2) = 2*sigma^2, 
we want this value to be 1, thus sigma^2 has to be 1/2.

Thanks,
-Dong

---

From: Mineo Takai <[email-masked]>
Date: Thu, 27 Nov 2003 00:14:52 -0800

Dong:

Ok, I now see your point. Since the Rayleigh fading describes gain/loss 
of the signal amplitude, the fading gain (power) should be the square of 
the Rayleigh variable. The fading code in GloMoSim uses the Rayleigh 
variable directly, thus it becomes halved (10*log10(sqrt(f)) == 
5*log10(f)) and its variance needs to be sigma^2 == 2/PI.

Let me know if my understanding is correct.

Mineo

---

From: Dong Zheng <[email-masked]>
Date: Thu, 27 Nov 2003 01:50:43 -0700

> Let me know if my understanding is correct.
Yes, correct. ;-)

-Dong