Bugzilla – Bug 3011
MIMO error rate model is incorrect
Last modified: 2020-04-12 09:07:18 EDT
In commit https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.28 InterferenceHelper::CalculateChunkSuccessRate was modified to support MIMO. Besides the fact that SINR gain is an obvious overestimation (exactly 4 for 2x2 MIMO, even with 2 spatial streams), I do not understand the reason for dividing the number of bits by the number of spatial streams (nbits /= txVector.GetNss ()). As I understand it, bits from both spatial streams must be delivered in order for the whole chunk to be delivered successfully. Should we at least remove the line https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.30 ?
(In reply to Alexander Krotov from comment #0) > In commit https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.28 > InterferenceHelper::CalculateChunkSuccessRate was modified to support MIMO. > > Besides the fact that SINR gain is an obvious overestimation (exactly 4 for > 2x2 MIMO, even with 2 spatial streams), How did you check that? maybe we should add tests for this. I agree that if SDM is used, then no gain should be applied (so i.e. 2x2:2 = no gain), but otherwise a rough approximation is a 3dB gain per redundant radio chain (e.g. 2x2:1 = 6dB gain) It seems that here a gain is always applied, without considering whether SDM is used. And that could be the problem for me. I do not understand the reason for > dividing the number of bits by the number of spatial streams (nbits /= > txVector.GetNss ()). As I understand it, bits from both spatial streams must > be delivered in order for the whole chunk to be delivered successfully. > > Should we at least remove the line > https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.30 ? I have to further check this, maybe Tom still remembers well why we did that (I think I started from a patch from him).
(In reply to sebastien.deronne from comment #1) > (In reply to Alexander Krotov from comment #0) > > In commit https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.28 > > InterferenceHelper::CalculateChunkSuccessRate was modified to support MIMO. > > > > Besides the fact that SINR gain is an obvious overestimation (exactly 4 for > > 2x2 MIMO, even with 2 spatial streams), > > How did you check that? maybe we should add tests for this. > > I agree that if SDM is used, then no gain should be applied (so i.e. 2x2:2 = > no gain), but otherwise a rough approximation is a 3dB gain per redundant > radio chain (e.g. 2x2:1 = 6dB gain) In 2x2:1 case there is only one redundant radio chain. Shouldn't the gain be 3dB? > It seems that here a gain is always applied, without considering whether SDM > is used. And that could be the problem for me. I get range increase in 2x2:2 case in NS-3 indeed. > > I do not understand the reason for > > dividing the number of bits by the number of spatial streams (nbits /= > > txVector.GetNss ()). As I understand it, bits from both spatial streams must > > be delivered in order for the whole chunk to be delivered successfully. > > > > Should we at least remove the line > > https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.30 ? > > I have to further check this, maybe Tom still remembers well why we did that > (I think I started from a patch from him). This seems like a mistake, because even if we model each of the, for example two, spatial streams separately, we need to square success probability in the end, because both streams have to be delivered successfully.
Created attachment 3213 [details] Proposed patch Here is a proposed patch based on the discussion above.
(In reply to Alexander Krotov from comment #2) > (In reply to sebastien.deronne from comment #1) > > (In reply to Alexander Krotov from comment #0) > > > In commit https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.28 > > > InterferenceHelper::CalculateChunkSuccessRate was modified to support MIMO. > > > > > > Besides the fact that SINR gain is an obvious overestimation (exactly 4 for > > > 2x2 MIMO, even with 2 spatial streams), > > > > How did you check that? maybe we should add tests for this. > > > > I agree that if SDM is used, then no gain should be applied (so i.e. 2x2:2 = > > no gain), but otherwise a rough approximation is a 3dB gain per redundant > > radio chain (e.g. 2x2:1 = 6dB gain) > > In 2x2:1 case there is only one redundant radio chain. Shouldn't the gain be > 3dB? My mistake, there are 2 redundant radio chains if we count both TX and RX. The patch takes this into account.
Could you add a test case to test all possible combinations? We can easily miss something.
Where does "3dB per redundant radio chain" estimation comes from? It results in 6dB gain for 1x3:1. OSTBC gain should be 3 in this case, not 4 (6dB). See slide 31 in https://gtas.unican.es/files/docencia/TAC/apuntes/ostbcswp_0.pdf
(In reply to Alexander Krotov from comment #0) > In commit https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.28 > InterferenceHelper::CalculateChunkSuccessRate was modified to support MIMO. > > Besides the fact that SINR gain is an obvious overestimation (exactly 4 for > 2x2 MIMO, even with 2 spatial streams), I do not understand the reason for > dividing the number of bits by the number of spatial streams (nbits /= > txVector.GetNss ()). As I understand it, bits from both spatial streams must > be delivered in order for the whole chunk to be delivered successfully. The intent of the abstraction was to allow idealized support for either diversity gain or spatial multiplexing gain; either * idealized diversity gain is N*N for N transmit and N receive antennas, or * spatial multiplexing gain improves data rate by N without improving SNR. However, other details of how, for example, STBC would be applied are not considered. > > Should we at least remove the line > https://code.nsnam.org/index.cgi/ns-3-dev/rev/f379a30efa16#l17.30 ? I will have a look with some tests.
Created attachment 3221 [details] patch plus tests I agree with Alexander's patch; here is his patch plus an initial few test cases to confirm it.
Created attachment 3222 [details] Proposed patch (In reply to Tom Henderson from comment #8) > Created attachment 3221 [details] > patch plus tests > > I agree with Alexander's patch; here is his patch plus an initial few test > cases to confirm it. As I said above, my patch is wrong in 3x1 and 1x3 case. Here is updated patch with your test suite extended to 3x1:1 and 1x3:1 cases.
I do not agree with this in the if: txVector.GetNss () == 1 In case we have 3x3:2, we can have gain as well here, even though getNss returns 2.
(In reply to sebastien.deronne from comment #10) > I do not agree with this in the if: > > txVector.GetNss () == 1 > > In case we have 3x3:2, we can have gain as well here, even though getNss > returns 2. See above: "The intent of the abstraction was to allow idealized support for either diversity gain or spatial multiplexing gain". Combining them is out of scope, I just want to make existing model correct. We can have gain in 3x3:2 case, but calculating it is not that simple, because the gain applies only to one spatial stream. Calculating overall gain requires dividing the number of bits in 2 and calculating error rate for each stream separately.
OK then we should make documentation clear on that point.
(In reply to sebastien.deronne from comment #12) > OK then we should make documentation clear on that point. Let's also prevent usage by causing a fatal error for unsupported combinations. A couple of other points. - I made CalculateChunkSuccessRate() temporarily public to run the tests, but we could possibly clean this aspect up by making the test a friend class. - do we check that Nss() <= 4 for 11n rates, and <= 8 for 11ac rates? Do we limit Nss() to 4 even for 11ac since Wave2 products seem to have that limit?
(In reply to Tom Henderson from comment #13) > (In reply to sebastien.deronne from comment #12) > > OK then we should make documentation clear on that point. > > Let's also prevent usage by causing a fatal error for unsupported > combinations. We cannot prevent this, users can still use MIMO but they won't know whether a gain is applied or not (unless they read the updated documentation). > > A couple of other points. > > - I made CalculateChunkSuccessRate() temporarily public to run the tests, > but we could possibly clean this aspect up by making the test a friend class. > > - do we check that Nss() <= 4 for 11n rates, and <= 8 for 11ac rates? Do we > limit Nss() to 4 even for 11ac since Wave2 products seem to have that limit? In my opinion there are checks for that, but I am not sure whether we limit to 4 or 8 for 11ac. If you want I can have a look.
I discussed with Leonardo Lanante and he suggested the following model. If STBC is not used, gain should be 10*log (# Rx antennas / # spatial streams). Having more Tx antennas can be safely ignored for AWGN. The resulting gain would be: antennas NSS gain 2 x 1 1 0 dB 1 x 2 1 3 dB 2 x 2 1 3 dB 3 x 3 1 4.8 dB (10 log 3) 3 x 3 2 1.8 dB (10 log 3/2) 3 x 3 3 0 dB 4 x 4 1 6 dB (10 log 4) 4 x 4 2 3 dB 4 x 4 3 1.2 dB (10 log 4/3) 4 x 4 4 0 dB and so on If STBC is used, the gain could be additive to the above, with a term of 10 log (NSTS/NSS). NSTS: number of space time streams. Comments on this proposed model?
Sounds good, but I would be interested to know where this model comes from (and so it could be added in comments or in the documentation).
(In reply to sebastien.deronne from comment #16) > Sounds good, but I would be interested to know where this model comes from > (and so it could be added in comments or in the documentation). It came from Leonardo Lanante, who couldn't provide a standard reference but told me that he just based it on the level of redundancy in the spatial streams.
> If STBC is not used, gain should be 10*log (# Rx antennas / # spatial streams). The model seems to be the same as slide 18 here: https://www.cs.princeton.edu/courses/archive/spring18/cos463/lectures/L16-mimo.pdf With MRC, spatial stream SNR is increased by factor of number of antennas.
Bug moved to https://gitlab.com/nsnam/ns-3-dev/-/issues/172