ht-wifi-network.cc rates for MCS0 and MCS7

[Steve muni]

Hi

I am testing the rates values for MCS0 and MCS7 in ns-3.20 with the example ht-wifi-network.cc and I cant get the theoretical values. The simulator gives:

MCS0 6.5Mbps -->  5.2644 Mbps 

MCS7 65Mbps --> 22.7268

when using the default paramters in WifiMac::Configure80211n_2_4Ghz()

However I have noticed that the timeslot in 802.11n es 9ns so I have changed the parameters to:

SetSifs (MicroSeconds (10));  //should I change to 2 us, as same as RIFS?? 

SetSlot (MicroSeconds (9));

SetEifsNoDifs (MicroSeconds (10 + 79)); //Sifs + acktimeout

SetPifs (MicroSeconds (10 + 9)); //sifs + timeslot

SetRifs(MicroSeconds (2)); //replacing sifs?

SetCtsTimeout (MicroSeconds (10 + 45 + 20 + GetDefaultMaxPropagationDelay ().GetMicroSeconds () * 2)); 

SetAckTimeout (MicroSeconds (10 + 45 + 20 + GetDefaultMaxPropagationDelay ().GetMicroSeconds () * 2)); 

//SIFS+(timeslot+2*Txtimeack)+plpc+2xTprop

But the results are not good enough in my opinion

MCS0 6.5Mbps -->  5.54 Mbps 

MCS7 65Mbps --> 29.24 Mbps

Since the expected throughput is 5.67Mbps and for MCS7 is 36.8 Mbps I think that is quite far to the expected values. What is happening?Am I forgetting something? No frame aggregation and no block ack are being used, so which could I change to improve the values? 

What about AIFSN? I have checked with

PointerValue ptr2;

   Ptr<NetDevice> n2;

   Ptr<WifiNetDevice> wd2;

   n2 = apDevice.Get(0);

   wd2 = n2->GetObject<WifiNetDevice>();

   wd2->GetMac()->GetAttribute("DcaTxop", ptr2);

   Ptr<DcaTxop> dca2 = ptr2.Get<DcaTxop>();

   std::cout << "AIFSN " << dca2->GetAifsn() << std::endl;

and a AIFSN of is 2us being used. Should I be change it?Or should I look over in EdcaTxopN insead of DcaTxop?

Thanks

Kind regards

[Tommaso Pecorella]

Hi,

the goodput datarate is dependent on a number of elements. In particular you didn't mention what is the protocol stack level you are measuring. 
E.g., at IP level, you have the IP header overhead. At MAC you have a MAC header (and a trailer too).

Moreover, the goodput is affected by the ACK time, retransmissions and so on.

If you find some numbers that, according to the standard, are not set to the proper values, please let us know by opening a bug in Bugzilla (make sure to reference the exact standard pages with the correct value).

However, you'll never ever even get close to the MCS "raw" value, and the higher it is, the worse the difference. This isn't ns-3, this is Wi-Fi.

Cheers,

T.

[Steve muni]

Hi

This week I have been testing and now I undertand better all the protocol overhead (I was not considering LLC layer).

Now, for MCS0 I obtain very accurate results and acording the model (the bianchi one), however for MCS7 the results are not so good. I attach an image of both throughputs MCS0 and MCS7 regarding the distance (X axis in km) for simulations and model.

In MCS7 at km 35 there is an unexpected step and for small distances the difference between the model and the simulation are not despreciable. I do not know why is this happening, because I have only changed the PhyRate and the offered load in the link. The other parameters (MAC and Phy) are the same as in MCS0.

it could be possible that there is problem with the phy layer??Maybe the delays or the traces for MCS7 are not well implemented. Where could I look for a solution? Should I create a bug in nsnam?

Thanks

Kind regards

Steve

[Tommaso Pecorella]

Hi Steve,

I guess you changed some params in the Tx/Rx noise figures and power, as WiFi at 60 Km is a bit... unusual.

Nevertheless, the accordance with the theory is quite good.

About the MCS7 differences, all is possible. However, I can't see why there should be a step at a particular distance. I mean, there is a difference for sure, but I can't figure out why. I guess you locked the MCS to a fixed value, otherwise the AMC would be the responsible for that difference.

Anyway, without the simulation we can't investigate it further. I'd suggest to contact the WiFi module maintainer directly (he's quite fast in answering) and to check with him.

The maintainers are listed here:

https://www.nsnam.org/bugzilla/describecomponents.cgi?product=ns-3

Cheers,

T.

[Steve muni]

El lunes, 11 de agosto de 2014 17:45:41 UTC+1, Tommaso Pecorella escribió:

Hi Steve,

I guess you changed some params in the Tx/Rx noise figures and power, as WiFi at 60 Km is a bit... unusual.

Nevertheless, the accordance with the theory is quite good.

Yes, I used the FixedRssLossModel with a quite high value for the RSSI. Also I changed the Slotime and Acktimeout for in order to possibilite such a long distances

 

About the MCS7 differences, all is possible. However, I can't see why there should be a step at a particular distance. I mean, there is a difference for sure, but I can't figure out why. I guess you locked the MCS to a fixed value, otherwise the AMC would be the responsible for that difference.

Anyway, without the simulation we can't investigate it further. I'd suggest to contact the WiFi module maintainer directly (he's quite fast in answering) and to check with him.

The maintainers are listed here:

https://www.nsnam.org/bugzilla/describecomponents.cgi?product=ns-3

I will contact with Daniel L. Thank you

Kind regards

Steve

[Tanya Tian]

Hi,

May I ask how long does it take to send an ACK? Is MCS of ACK different from MCS of data in NS-3?

Thanks.

Regards,

Tanya

[Steve muni]

Hi Tanya

As far as I know, the ACK are always sent with the lowest and more robust MCS, this is MCS0. So changing the MCS for the data plane should not change the duration of sending an ACK.

Kind regards

Steve

[Steve muni]

Hi 

I forgot post that after checking the wifi theoretical model I obtained with the simulator the expected value for each MCS according the theoretical model. Also I tested same the same links with real equipment and resuts seems quite similar. If anybody is interested in I would be glad to help

Kind regards