How to change duration of RTS,CTS,ACK,BACKRESP

[Dang Tai Tan]

Dear experts

I want to compare scenario between ns2 and ns3. In ns2 duration of rts = 52us, cts = 44us,block ack = 68us

in ns3, i checked, and the default value of rts = 64us, cts = 60us, blockack = 80us(are these correct??) 

and now i want to change these values are same as in ns3. 

How can I change it, can anyone give me some advise ? 

I also tried by modifying by change the size of those. from file mac-low.cc --> jump to wifi-mac-header.cc  ->>in function

 uint32_t

WifiMacHeader::GetSize (void) const

  uint32_t size = 0;

  switch (m_ctrlType)

    {

    case TYPE_MGT:

      size = 2 + 2 + 6 + 6 + 6 + 2;

      break;

    case TYPE_CTL:

      switch (m_ctrlSubtype)

        {

        case SUBTYPE_CTL_RTS:

          size = 2 + 2 + 6 + 6;         //change here

          break;

        case SUBTYPE_CTL_CTS:

        case SUBTYPE_CTL_ACK:

          size = 2 + 2 + 6;                    //change here

          break;

        case SUBTYPE_CTL_BACKREQ:

        case SUBTYPE_CTL_BACKRESP:

          size = 2 + 2 + 6 + 6;                 //change here

          break;

        case SUBTYPE_CTL_CTLWRAPPER:

          size = 2 +2 +6 +2 +4;

          break;

        }

      break;

....

I changed value here but , it got errors. i don't know is it correct way

I appriciate your help

Thank you

[Konstantinos]

Dear Dang,

I think that the duration of those frames is related to the data rate as their size (bytes) should be the same according to the IEEE standard.
So please check if you have used the same configuration between ns2 and ns3.
In addition, you should also check if NS-2 implementation is correct before changing NS-3.

Regards,
K.

[Sebastien Deronne]

Konstantinos is right, frame length should be identical (if not, something is wrong) and the duration will thus depend on the bitrate used to transmit those frames.
You should first have a look at how the bitrate for those frames is selected, there are also some rules in the standard.

Please use the latest version of ns-3, since the way the bitrate is selected for those frames has been changed in order to follow the standard rules.
Note that I have also some doubt that ns-2 has a correct implementation, since it is no longer really maintained.

[Dang Tai Tan]

Thank you, Konstantinos and Sebastien Deronne. I understand that

in this scenario i use mcs = 0 and i don't want to change mcs. In Ns2, i also change the duration of RTS,CTS,ACK with values above, and it built successful. Now I change to Ns3, and I want to do same thing to compare the throughput

=> is there any other way to change these value?

thank you so much! 

Vào 20:58:05 UTC+9 Thứ Ba, ngày 16 tháng 6 năm 2015, Sebastien Deronne đã viết:

[Sebastien Deronne]

Sorry but IMO you are going in the wrong direction:

1/ I guess you are referring to 802.11n, but as far as I know 802.11n is very "experimental" in ns-2, so I do not see any sense to compare ns-2 and ns-3.
I even don't see any interest to compare results of an outdated simulator with ns-3. If you want to validate ns-3 models a bit further, then you should compare to experimental results, theoretical models, reference published results, ...

2/ "i also change the duration of RTS,CTS,ACK with values above, and it built successful"
    => what the hell have you changed exactly? The bitrate or the size? If you changed the bitrate, you might not be standard compliant, and if you changed the size then you totally broke the standard.

[Matteo Danieletto]

Hi all,

why is he going in wrong direction?

IMO, Dang is trying to break the standard on purpose.

What is it not clear for me is: 

why most of the time when someone wrote how to change the parameters as RTC, CTS, ACK 

the answer is: "it is wrong because you are breaking the standard".

Then my question is: where is the problem if I am breaking the standard? 

Sometimes it is easer to modify the ns3 code than the Linux Kernel to test some network features.

An example you can do the something modifying the Atheros Driver (ath9k) in Linux but:

you have to find/buy the right chipset,  modify the right file inside the driver, compile the kernel and hope.

Thank you

Matteo

[Sebastien Deronne]

Matteo, there is nothing wrong in changing the standard, I did it myself in both ns-3 and Linux, and I never disapproved that someone acts this way!

What is wrong here, is to try to tune the parameters "a bit randomly" to have both ns-2 and ns-3 results similar.