CSMA/CA DCF WiFi ns-3.14.1

1,527 views
Skip to first unread message

Davide Piccione

unread,
Aug 2, 2012, 1:32:43 PM8/2/12
to ns-3-...@googlegroups.com
Hi,
I ran the example wifi-simple-adhoc.cc contained in ns-3.14.1 and I noted that Mac level don't consider the DIFS mechanism. Is it possible?

I ran the example with original parameter about 802.11b and I obtained the following results (analysing  receiver's pcap files with tcpdump):
reading from file wifi-simple-adhoc-0-0.pcap, link-type IEEE802_11_RADIO (802.11 plus radiotap header)
02:00:01.008704 1008704us tsft 1.0 Mb/s 2412 MHz (0x00a0) -80dB signal -101dB noise IP 10.1.1.2.49153 > 10.1.1.255.www: UDP, length 1000

Instead, I ran the same example but with modified parameters for 802.11b (in the wifi-mac.cc), precisally I modified SIFS from 10usec to 12usec and SLOT-TIME from 20usec to 21usec, the results contained in pcap files are:
reading from file wifi-simple-adhoc-0-0.pcap, link-type IEEE802_11_RADIO (802.11 plus radiotap header)
02:00:01.008704 1008704us tsft 1.0 Mb/s 2412 MHz (0x00a0) -80dB signal -101dB noise IP 10.1.1.2.49153 > 10.1.1.255.www: UDP, length 1000

In the modified case the frame would be received at 1008708usec instead 1008704usec, because DIFS in augmented to 4 usec.

Is it possible? Are there some parameter for enable DCF with DIFS? Why this happens?
Thanks.

p.s.: sorry for my english :)

Davide Piccione

unread,
Aug 3, 2012, 4:45:32 AM8/3/12
to ns-3-...@googlegroups.com
Sorry,
there are some problems in my question?
I'm newby in ns-3 and I would know if this is a bug or I'm in error.
I'm waiting answer, thanks.

Konstantinos

unread,
Aug 3, 2012, 5:15:26 AM8/3/12
to ns-3-...@googlegroups.com
Hi,

According to this poster from WNS-3 2012, the DCF model of WIFI in ns-3 is validated,so I guess it is something wrong with your code or how you interprate your results (for example I don't see anywhere the random backoff)

Validation of ns-3 WiFi Distributed Coordination Function Model
Guangyu Pei, Thomas Goff and Thomas R. Henderson


Davide Piccione

unread,
Aug 3, 2012, 6:49:15 AM8/3/12
to ns-3-...@googlegroups.com
Thanks Kostantinos, you were very useful!
I didn't consider the initial random backoff also at first broadcast transmission.
Moreover, I didn't consider that the sta's listen the channel forever and not only if they must transmit.
Could you tell me where i can obtain the document about "Validation of ns-3 WiFi Distributed Coordination Function Model"
Guangyu Pei, Thomas Goff and Thomas R. Henderson?

Regards,
DP

Konstantinos

unread,
Aug 3, 2012, 7:06:52 AM8/3/12
to ns-3-...@googlegroups.com
Hi,

I could find this report: Validation of 802.11b PHY model (http://www.nsnam.org/~pei/80211b.pdf) and Validation of OFDM error rate model (http://www.nsnam.org/~pei/80211ofdm.pdf). I guess you can contact the authors for the validation of DCF.

Davide Piccione

unread,
Aug 3, 2012, 1:47:07 PM8/3/12
to ns-3-...@googlegroups.com
Thank you very much.

Regards,
DP

phuchong kheawchaoom

unread,
Aug 3, 2012, 1:51:12 PM8/3/12
to ns-3-...@googlegroups.com
Did you see this  http://www2.engr.arizona.edu/~junseok/simple_wireless.html 
Regards
PK

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/QctTe06bRCsJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

Davide Piccione

unread,
Sep 17, 2012, 1:45:33 PM9/17/12
to ns-3-...@googlegroups.com
Hi,
I don't have an another about my question yet.
I need to verify 802.11 behaviour when the nodes haven't any packet to transmit. Actually, I noted that ns-3 implementation permits to nodes to listen the channel also if they have their queue of packet empty. So, if a node listen the channel as idle when its queue is empty, then it starts its backoff timer. Then, as soon as it have to transmit a packet, it transmit directly on channel, without re-listen the channel.
Unfortunately, I don't find more information about this, the standard IEEE 802.11 don't specify this behaviour. I wrote to the authors of document Validation of ns-3 WiFi Distributed Coordination Function Model - Guangyu Pei, Thomas Goff and Thomas R. Henderson and they told me that their study is about the behavior under saturated conditions (when all stations always have a packet to send).
Anyone have more information about this?

Thanks,
Regards.
DP



Ko LC

unread,
Feb 26, 2013, 9:20:05 PM2/26/13
to ns-3-...@googlegroups.com
Hi DP,
 
Please check the "9.3.3 Random backoff time" section in Std 802.11-2012, the spec does not explicitly request a STA to perform random backoff when medium is idle; it only requests a STA to perform random backoff when the medium is busy. I personally regard random backoff is not necessary when medium is idle.
 
Br,
LC

Davide Piccione於 2012年9月18日星期二UTC+8上午1時45分33秒寫道:

Tanuj Chauhan

unread,
Sep 3, 2013, 2:31:43 AM9/3/13
to ns-3-...@googlegroups.com
Hi Ko LC,

DP is right it should have some mechanism for relisten the channel before transmitting.
because if we use adhoc netwotk and every node in the network broadcasting packet at
same time will collide.
This is happening in my simulation.

is it expected behaviour?

LC Ko

unread,
Sep 3, 2013, 11:52:05 AM9/3/13
to ns-3-...@googlegroups.com, tanujs...@gmail.com
Hi Tanuj, 

This is because there is no ACK for broadcast packets so the nodes never know there are collisions thus they would never enter backoff stages. I guess you started all node at the same time and with the same broadcast packet generation periodicity in your simulation so they always collide together. You might want to randomize them a little bit because in reality it is almost impossible for a lot of nodes to generate broadcast packet at the same time. In addition, please remember broadcast in 802.11 network is not reliable in nature. (Ref: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/Robust.Broadcast.html)

Br,
LC


2013/9/3 Tanuj Chauhan <tanujs...@gmail.com>
--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/hgls9xm_u0A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.

To post to this group, send email to ns-3-...@googlegroups.com.

T Chauhan

unread,
Sep 4, 2013, 3:04:34 AM9/4/13
to ns-3-...@googlegroups.com
Hi Ko LC,

Thanks for the reply. but as per 802.11 mac standard before any transmission it should sense the medium and backoff till
backoff slots expire, after backoff expiry it will send the frame whether it is unicast or broadcast.

I started all nodes at the same time so it is colliding every time. So I m thinking of putting some mechanism to avoid
collision which nodes transmitting at same time.
Can you please suggest the solution.

If possible please give me your gmail id.


Thanks



On Thursday, August 2, 2012 11:02:43 PM UTC+5:30, Davide Piccione wrote:

Ko LC

unread,
Sep 12, 2013, 10:44:03 PM9/12/13
to ns-3-...@googlegroups.com
Hi Tanuj, 

As I mention in my previous post: 802.11 spec does not explicitly request a STA to perform random backoff "when medium is idle" and this is also the way how NS-3 was implemented. In your case, since medium is definitely idle before your simulation begins, CSMA/CA is not performed so all your broadcast packets collide together.

If in your case uni-cast packets were used, then the collision (due to no ACK was received) would result in re-transmission and CSMA/CA will be performed during re-transmissions due to the former collision. But in your case, broadcast packets were used and there is no way a broadcast packet collision can be detected because there were no ACK for them. Consequently CSMA/CA is never performed. I won't say this is a problem of 802.11 spec because in real world this case (a lot of nodes broadcast their packet at exactly the same time continuously) rare happens. Therefore, I suggest you to randomize the start points of your mobile nodes a little bit since you are using broadcast packets and then you shall see CSMA/CA is sometime performed due to medium busy caused by other nodes and the collision situation should be mitigated.

Br,
LC

T Chauhan於 2013年9月4日星期三UTC+8下午3時04分34秒寫道:

T Chauhan

unread,
Sep 13, 2013, 5:04:00 AM9/13/13
to ns-3-...@googlegroups.com
I got it , Thanks.

I randomize initial timestamp of all the nodes, so now collision reduced.
Now I want to develop some TDMA approach for multiple adhoc nodes in the network, so that
ideally there will not any collision.
Any one has any suggestion on this or any one had already worked on this?

Hi Ko LC can you please give me your gmail id?

Thanks

Yalda Edalat

unread,
Feb 8, 2016, 5:03:46 PM2/8/16
to ns-3-users
Hi,

I am a beginner too. Could you please tell me how you measured collision?

Tommaso Pecorella

unread,
Feb 8, 2016, 5:39:24 PM2/8/16
to ns-3-users
Hi,

since you're a beginner, I'd start by reading the posting guidelines. You'll find a lot of useful (necessary, I'd say) tips to increase the chances to have a successful and satisfactory help.

Thanks,

T.

Sudhir Pattanaik

unread,
May 25, 2016, 4:45:17 AM5/25/16
to ns-3-users
 Hello Tommaso Pecorella,
How Can we know the backoff value of individual node  using dcf/edca mechanism

zeng...@gmail.com

unread,
Feb 12, 2017, 4:54:28 PM2/12/17
to ns-3-users
How can I modify to perform random backoff when medium is idle for DCF.

在 2016年2月8日星期一 UTC-5下午5:39:24,Tommaso Pecorella写道:

Tommaso Pecorella

unread,
Feb 16, 2017, 10:13:04 AM2/16/17
to ns-3-users
Check the DcfManager class.

T.

inam

unread,
Apr 6, 2017, 1:21:14 AM4/6/17
to ns-3-users
Hi Tomasso Pecorella,
Yalda's question might be relevant at this point because the person wants to know how exactly the collisions are detected in NS3. 

As far as I understand, DcfManager::RequestAccess() reports collision and starts backoff when the medium is busy or is within the aifsn. The actual real world collision, ie when a station gets the medium free and starts its transmission and its signal gets garbled because of another tx on the air, is not captured. eg when two nodes start at exactly the same time. Please correct me if I am wrong.

PS. The collision detection is also difficult in real world because you don't get anything detectable when the signal destroys before the frame is received. It is later inferred from the lack of an ack.
Regards.
Inam
Reply all
Reply to author
Forward
0 new messages