Subject: RE: [manet] Non-zero NAV frame transmission in 802.11

From: "Farrag, Osama" <[email-masked]>
Date: Wed, 29 Mar 2006 13:32:20 -0500

Ehsan;

Did node C receive the data packet before CTS is sent from node B to
node A? if yes then NAV value at C was zero and sending an ACK is normal
local behavior according to DCF rules; if CTS was transmitted by
B/received by C before data packet was received by C from D then C NAV
value is non zero and it should not send Ack to D. in fact, C should
experience interference if CTS was transmitted by B during reception of
data packet by C. Most likely; last bit of data packet was received by C
at same time last bit of RTS was received by B. Note: that node C is
unaware, NAV will remain zero, because node C would not be able to
receive the CTS when it is sending ACK. In the scenario you presented,
there is no interference yet, and non will occur unless node C is
involved in subsequent communication, and sends data during the time
node A is sending the data packet to B following the RTS.

Osama 

________________________________

From: Ehsan Hamadani [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 10:06 AM
To: [email-masked]
Subject: [manet] Non-zero NAV frame transmission in 802.11

Dear all.

As part of my simulation results with 802.11 in ad hoc networks, I have
come across the following scenario which looks odd regarding my
understanding of 802.11 DCF channel access algorithm.

Consider the following scenario where node A has a packet larger than
RTS_Threshold for B and node D has a packet smaller than RTS_Threshold
for C. 

A-->B-->C<--D 

In this case, node A first starts sending a RTS packet towards B, and
consequently receives a CTS back from node B. Once node A initiates its
data transmission, node D also starts its own data transmission towards
C (without any prior channel reservation). Despite the fact that node C
has been made silent for the duration of A-->B data transmission, node C
will issue an link layer ACK after it successfully receive the packet
from node D !! In other words, node C sends a link layer ACK regardless
of the its non-zero NAV value. 

Is this an expected 802.11 behavior in the case of link layer
acknowledgment? If so, what is the idea behind it considering the
collision it causes to A-->B transmission?

Thanks

Ehsan

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

---

From: "Ehsan Hamadani" <[email-masked]>
Date: Thu, 30 Mar 2006 16:40:25 +0100

Dear Osama,
 
Thanks for your descriptive response. 
 
>> Did node C receive the data packet before CTS is sent from node B to
node A?
The answer is No. Node C receives the data packet from node D after it
has already received a CTS from node B.
 
>> if CTS was transmitted by B/received by C before data packet was
received by C from D then C NAV value is non zero and it should not send
Ack to D.
Well, this is the part that makes the confusion for me as well.
According to the rules of 802.11 standard (section 9.2.8, paragraph 2),
when a STA receives a data frame successfully that requires an ACK, it
has to send an ACK back after SIFS time regardless of whether it senses
the medium idle or busy physically or virtually. So, in spite of its
updated NAV value, it still can transmit the link layer ACK which causes
collisions later on at node B.
 
What I do not understand quite well is the necessity of adding the above
phrase (sending ACK regardless of the value of NAV) to the 802.11
standard while it obviously makes lots of collisions.
 
Regards,
 
Ehsan
 
-----Original Message-----
From: Farrag, Osama [mailto:[email-masked]] 
Sent: 29 March 2006 19:32
To: Ehsan Hamadani; [email-masked]
Subject: RE: [manet] Non-zero NAV frame transmission in 802.11
 
Ehsan;

 
Osama 
 
  _____  

Dear all.

 
A-->B-->C<--D 

 
Thanks
 
Ehsan

---

From: Justin Yackoski <[email-masked]>
Date: Thu, 30 Mar 2006 11:13:44 -0500

> has already received a CTS from node B.

By the time Node C starts receiving the data packet from node D, node A 
has presumably heard B's CTS also and has started transmitting a data 
packet to B which would interfere with C hearing the data packet from D. 
  But since C successfully received D's data packet, enough time has 
passed since A should have heard the CTS that we can assume A did not 
(and will not) transmit any data because its channel is busy or it did 
not hear the CTS.  As Osama pointed out, the first bits of one of the 
transmissions will likely interfere with the other in most, if not all, 
cases like this.

Justin

> has to send an ACK back after SIFS time* regardless of whether it senses 
> the medium idle or busy physically or virtually*. So, in spite of its 
> *From:* Farrag, Osama [mailto:[email-masked]]
> *Sent:* 29 March 2006 19:32
> *To:* Ehsan Hamadani; [email-masked]
> *Subject:* RE: [manet] Non-zero NAV frame transmission in 802.11
> 
>  
> 
> Ehsan;
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Ehsan Hamadani [mailto:[email-masked]]
> *Sent:* Wednesday, March 29, 2006 10:06 AM
> *To:* [email-masked]
> *Subject:* [manet] Non-zero NAV frame transmission in 802.11
> 
>  
> 
> Dear all.
> 
>  
> 
> Consider the following scenario where node *A* has a packet larger than 
> RTS_Threshold for *B* and node *D* has a packet smaller than 
> RTS_Threshold for *C*.
> 
>  
> 
> *A**à**B**à**C**ß**D *
> 
>  
> 
> In this case, node *A* first starts sending a RTS packet towards *B*, 
> and consequently receives a CTS back from node *B*. Once node A 
> initiates its data transmission, node *D* also starts its own data 
> transmission towards *C* (without any prior channel reservation). 
> Despite the fact that node *C* has been made silent for the duration of 
> *A*à*B* data transmission, node *C* will issue an link layer ACK after 
> it successfully receive the packet from node *D* !! In other words, node 
> *C* sends a link layer ACK regardless of the its non-zero NAV value.
> 
>  
> 
> collision it causes to AàB transmission?
> 
>  
> 
> Thanks
> 
>  
> 
> Ehsan
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Justin Yackoski
DEGAS Networking Group
Dept. Of Computer and Info. Sciences
University of Delaware, Newark, DE 19711
http://degas.cis.udel.edu