Bug 2533 - Provide a better 802.11n/ac PHY abstraction model for SIMO, MISO and MIMO
Provide a better 802.11n/ac PHY abstraction model for SIMO, MISO and MIMO
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
unspecified
All All
: P5 enhancement
Assigned To: sebastien.deronne
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-26 15:47 UTC by sebastien.deronne
Modified: 2016-11-16 15:40 UTC (History)
2 users (show)

See Also:


Attachments
new proposed model for MIMO, SIMO and MISO (36.62 KB, patch)
2016-10-26 15:47 UTC, sebastien.deronne
Details | Diff
802.11n MIMO throughput results with the old model (33.69 KB, application/postscript)
2016-10-26 15:49 UTC, sebastien.deronne
Details
802.11n MIMO throughput results with the new model (33.70 KB, application/postscript)
2016-10-26 15:49 UTC, sebastien.deronne
Details
Patch v2 (58.90 KB, patch)
2016-11-01 06:35 UTC, sebastien.deronne
Details | Diff
patch (60.26 KB, patch)
2016-11-07 17:51 UTC, sebastien.deronne
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sebastien.deronne 2016-10-26 15:47:38 UTC
Created attachment 2640 [details]
new proposed model for MIMO, SIMO and MISO

The current MIMO model (as well as MISO and SISO) relies on the existing SISO error rate models. For AWGN channel models, it has however been shown in several papers that  a correction factor applied to obtain a basic shift of the SISO curves can be used to model multiple spatial streams and/or antenna diversity.

Current abstraction in ns-3-lbt, 1x2 is modeled as follows:

     nbits /= txVector.GetNss (); // divide effective number of bits by NSS to achieve same chunk error rate as SISO for AWGN
     if (txVector.GetNss () == 1 && m_numRxAntennas == 2)
       {
         snir *= 2; // 3 dB increase for 1 Tx 2 Rx antenna receive diversity in AWGN
       }

I propose to go a bit further and consider every possibilities: MISO (i.e. 2x1), SIMO (i.e. 1x2) and MIMO (i.e. 2x2), where both the number of Tx antennas at the transmitter and the number of Rx antennas at the receiver matter.

From papers, I could conclude the correction factor corresponds to the product of nTx by nRx:

1x2: +3dB 
2x1: +3dB
2x2: +6dB
Comment 1 sebastien.deronne 2016-10-26 15:49:07 UTC
Created attachment 2641 [details]
802.11n MIMO throughput results with the old model
Comment 2 sebastien.deronne 2016-10-26 15:49:29 UTC
Created attachment 2642 [details]
802.11n MIMO throughput results with the new model
Comment 3 Tom Henderson 2016-10-26 22:21:13 UTC
Here are my general comments:

- I support the approach in general (have been doing this for 1x2 in the ns-3-lbt already)

- it seems to me that the number of Tx antennas should be encapsulated in the WifiTxVector, such as the number of spatial streams already is present there

- what about documentation on how users can set this up, and under what conditions does a 2x2 antenna configuration yield a single spatial stream with 6 dB diversity gain vs. 2 spatial streams using a higher MCS.  That is, how does rate control interact with this and select modes?  Also, if a node has 2 Tx antennas available, does it ever select to use only one of them (as is done in some STAs today) and how is that configured (e.g. 2x2 on downlink, 1x2 on uplink)?
Comment 4 sebastien.deronne 2016-10-27 06:29:36 UTC
(In reply to Tom Henderson from comment #3)
> Here are my general comments:
> 
> - I support the approach in general (have been doing this for 1x2 in the
> ns-3-lbt already)
> 
> - it seems to me that the number of Tx antennas should be encapsulated in
> the WifiTxVector, such as the number of spatial streams already is present
> there
> 

I agree it is the most straightforward approach, but the standard does not make room for that parameter. If we are fine with that, then I'll go for that because it is much less changes in our code.

> - what about documentation on how users can set this up, and under what
> conditions does a 2x2 antenna configuration yield a single spatial stream
> with 6 dB diversity gain vs. 2 spatial streams using a higher MCS.  That is,
> how does rate control interact with this and select modes?  Also, if a node
> has 2 Tx antennas available, does it ever select to use only one of them (as
> is done in some STAs today) and how is that configured (e.g. 2x2 on
> downlink, 1x2 on uplink)?

Tom, there is indeed still some work needed there, I will have a look.
Comment 5 sebastien.deronne 2016-11-01 06:35:33 UTC
Created attachment 2643 [details]
Patch v2

New patch that mainly addresses Tom's comments.

The number of antennas used by the transceiver is now part of the txVector, as defined in the standard (I was wrong about that in my previous comment).

It is now also possible to configure MIMO, MISO and SIMO in an easy way, and we can also define different configurations for uplink and downlink. 

We have 3 key parameters:
Antennas: set the number of antennas on the device;
MaxSupportedTxSpatialStreams: set the maximum number of supported TX spatial streams;
MaxSupportedRxSpatialStreams: set the maximum number of supported RX spatial streams.

Documentation has been updated as well.
Comment 6 Tom Henderson 2016-11-05 17:24:03 UTC
(In reply to sebastien.deronne from comment #5)
> Created attachment 2643 [details]
> Patch v2
> 
> New patch that mainly addresses Tom's comments.
> 
> The number of antennas used by the transceiver is now part of the txVector,
> as defined in the standard (I was wrong about that in my previous comment).
> 
> It is now also possible to configure MIMO, MISO and SIMO in an easy way, and
> we can also define different configurations for uplink and downlink. 
> 
> We have 3 key parameters:
> Antennas: set the number of antennas on the device;
> MaxSupportedTxSpatialStreams: set the maximum number of supported TX spatial
> streams;
> MaxSupportedRxSpatialStreams: set the maximum number of supported RX spatial
> streams.
> 
> Documentation has been updated as well.

Patch looks good; please deprecate the previous Attributes (see how Tommaso did it in bug 2513 patch).  Also please update CHANGES.html for changed API/behavior.
Comment 7 sebastien.deronne 2016-11-07 17:51:58 UTC
Created attachment 2666 [details]
patch

New patch that addresses Tom's comments: deprecated attributes and updated CHANGES.html
Comment 8 sebastien.deronne 2016-11-09 14:00:23 UTC
If it is ok with the latest patch, I propose to push this asap because it affects many files, so all upcoming patches will suffer merge conflicts.
Comment 9 Tom Henderson 2016-11-11 02:00:01 UTC
(In reply to sebastien.deronne from comment #8)
> If it is ok with the latest patch, I propose to push this asap because it
> affects many files, so all upcoming patches will suffer merge conflicts.

I have no further comments; thanks for handling my previous ones.
Comment 10 sebastien.deronne 2016-11-16 15:40:06 UTC
Pushed in changeset 12413:f379a30efa16