Bug 2770

Summary:	Simulation fails if multiple stations support different number of spatial streams
Product:	ns-3	Reporter:	Akin Soysal <akinsoysal>
Component:	wifi	Assignee:	sebastien.deronne
Status:	RESOLVED FIXED
Severity:	major	CC:	matis18, ns-bugs
Priority:	P2
Version:	ns-3-dev
Hardware:	All
OS:	All
Attachments:	test script proposed solution

Description Akin Soysal 2017-08-08 03:06:07 UTC

Hello,

I have encountered a problem and I summarized it also in ns-3-users group:

https://groups.google.com/forum/#!searchin/ns-3-users/txvector.SetPreambleType$20(WIFI_PREAMBLE_HT_MF)$3B%7Csort:relevance/ns-3-users/fD8zUS5QICI/g6GqZ0SDBAAJ

I had the problem that with 3 antenna AP and 3 antenna STA, the number of streams in good channel conditions was not going up to 3 streams. It used to stay constant at 2 streams. After long investigations I found out that the throughput calculated for 2 streams was higher than 3 streams. 

The problem has to do with the preamble type set in CalculateFirstMpduTxDuration.

txvector.SetPreambleType (WIFI_PREAMBLE_HT_MF);

I am using the 802.11ac standard, maybe this header is old. Changing it this line to txvector.SetPreambleType (WIFI_PREAMBLE_NONE); fixes the problem but maybe it should be the WIFI_PREAMBLE_VHT type?

I have not seen this preamble setting in ns-3.26 but it exists in ns-3-dev. Therefore, I have selected the version as 3.26.

Comment 1 sebastien.deronne 2017-09-13 13:39:12 UTC

Is this your proposed fix?

MinstrelHtWifiManager::CalculateFirstMpduTxDuration (Ptr<WifiPhy> phy, uint8_t s
   txvector.SetGuardInterval (sgi ? 400 : 800);
   txvector.SetChannelWidth (chWidth);
   txvector.SetNess (0);
   txvector.SetStbc (phy->GetStbc ());
   txvector.SetMode (mode);
-  txvector.SetPreambleType (WIFI_PREAMBLE_HT_MF);
+  txvector.SetPreambleType (WIFI_PREAMBLE_NONE);
   return phy->CalculateTxDuration (m_frameLength, txvector, phy->GetFrequency (), MPDU_IN_AGGREGATE, 0);
 }

I would like the view of Mathias before pushing this, because I do not see a link between the preamble type and your issue. Did you enabled Greenfield mode?

Comment 2 Matías Richart 2017-09-14 15:30:05 UTC

Hi.

I don't think that is a bug.
You have to consider the preamble when calculating the TX time.

Akin can you share a test case?
I have just tested MinstrelHt with wifi-manager-example and it uses 3 streams correctly.

Comment 3 Akin Soysal 2017-09-19 02:30:25 UTC

Back in the time, possibly around June, even though the SINR was high, it was not switching to 3 antennas. If it does with your most recent, then this bug is obsolete.

Comment 4 sebastien.deronne 2017-09-19 02:32:02 UTC

Akin,
Do you mind giving a try with the latest ns-3-dev so that this bug can be closed?
Thanks!

Comment 5 Akin Soysal 2017-09-19 03:28:59 UTC

Sebastien, I have new errors with the script I used to test. Not sure if it is because of substantially modified code.

run it with:

./waf --run 'scratch/vht_network_from_omer --nWifiAp=1 --nWifiSta=2 --udp=1 --ideal=2 --nssAp=3 --nssSta1=2 --nssSta2=1 --speed=0.0 --simulationTime=10.0 --fading=0 --distance=5'

and you get the following error:

msg="Reception ends in failure because of an unsupported number of spatial streams", file=../src/wifi/model/wifi-phy.cc, line=2399
terminate called without an active exception

Comment 6 Akin Soysal 2017-09-19 03:29:42 UTC

Created attachment 2920 [details]
test script

Comment 7 sebastien.deronne 2017-09-20 14:49:42 UTC

I think I got it. The assert is not correct: all stations receive the frame at PHY, it is only at MAC layer that it gets dropped if it is not the recipient. So, even the station with a single antenna received the frame sent with NSS=2. IMO, it should be dropped at PHY since it cannot decode it. I will work on a solution.

Comment 8 sebastien.deronne 2017-09-20 16:12:40 UTC

Created attachment 2921 [details]
proposed solution

Comment 9 sebastien.deronne 2017-09-24 04:57:49 UTC

Please confirm this solves the issue, so I can push the solution.

Comment 10 Akin Soysal 2017-09-25 08:26:42 UTC

OK, the simulation did not fail this time, so this bug is fixed.

Comment 11 sebastien.deronne 2017-09-25 14:27:51 UTC

Fixed in changeset 13079:a9e130d43da8