postSINR

Dear Kharny,

sorry for the long delay - and a happy new year to you.

> I'm still asking myself, why the PhyMode pm should be set using postSINR instead of lqm inside
> SINRwithMIMO.cpp ( http://docs.openwns.org/api/SINRwithMIMO_8cpp-source.htm )
> 00077 wns::Ratio postSINR = lqm
> 00078 + friends.phyUser->getExpectedPostSINRFactor(numSS, numRx);

The lqm was either measured using the beacon or the fast link feedback
(wifimac, revision 83). In both cases, the frame which was used for the
measurement (beacon or RTS) has been transmitted with one stream;
furthermore, the SINR that is stored is the equivalent SINR of a single
receive antenna (see e.g.
http://bazaar.launchpad.net/~comnets/openwns-wifimac/wifimac--main--1.0/annotate/head%3A/src/draftn/FastLinkFeedback.cpp,
line 78).
Hence, the lqm is based on a 1x1 reception. If multiple streams are
used, the post-MIMO receiver SINR is different - this is expressed by
the addition of the expected post-processing SINR factor, so that the
expected post-processing SINR is used as the link quality measurement to
determine the used MCS.

The current MIMO-model in the openWNS is very simple (actually, it is
only a beta version that is only implemented in the convergence-FUN of
the wifimac). As a result, all spatial streams will have the same
post-processing SINR, which is not very realistic - but it allows to
have a very simple RA as implemented in SINRwithMIMO.

Soon (Maciej told me probably end of this week) we will release an
update that implements the MIMO-model in phy/ofdmaphy, where it should
be. This MIMO model can be extended by strategies to implement
different, more realistic/complex models. By default, two strategies are
provided:
* One very, very simple; even simpler than the current one.
* One for a ZF-receiver that takes into account Tx and Rx correlation
loss according to AoD, AoA, ASD, ASA.

> Another point would be the differences of the actual postSINR-formel and the one in my file-Version from August 2009
> wns::Ratio postSINR = lqm
> - friends.phyUser->getExpectedPostSINRFactor(1, numRx)
> + friends.phyUser->getExpectedPostSINRFactor(numSS, numRx);

Most likely, with your version the lqm was measured using a 1xNumRx
receiver. Thus, the substraction of
friends.phyUser->getExpectedPostSINRFactor(1, numRx) is needed.

BR,
Sebastian

--
Dipl.-Inform. Sebastian Max | mailto:<email address hidden>
Communication Networks | http://www.comnets.rwth-aachen.de/~smx
Faculty 6 (ET&IT) | Phone +49 241 802 0547
RWTH Aachen University | Fax +49 241 802 2242

Thank you Sebastian for your answer.
as far as i could check, all the spatial streams are used with exactly the same MCS and this one is set according to the MCS-Tabl inside
/home/cal/myOpenWNS/modules/dll/wifimac/PyConfig/wifimac/draftn
Am i right?
If so, regarding the Standard 802.11n, the MCS table should have more than 100 entries, did you reduce this till 8 entries, or is this just test-values? Is it really adequate for draftn?
By the way, how was thresholds for the db-values set? I mean, is there a way to know the reason, why you said, i.e. if postSINR = 9.1 dB, use QPSK-1/2 for the actual transmission?

Thanks
Kharny

>>as far as i could check, all the spatial streams are used with exactly the same MCS and this >>one is set according to the MCS-Tabl inside
>>/home/cal/myOpenWNS/modules/dll/wifimac/PyConfig/wifimac/draftn

I mean inside PhyMode.py

Dear Kharny,

> as far as i could check, all the spatial streams are used with
> exactly the same MCS and this one is set according to the MCS-Tabl
> inside
> /home/cal/myOpenWNS/modules/dll/wifimac/PyConfig/wifimac/draftn Am i
> right?

Correct.

> If so, regarding the Standard 802.11n, the MCS table should have more
> than 100 entries, did you reduce this till 8 entries, or is this just
> test-values? Is it really adequate for draftn?

Mmm... here we have a problem of terminology. For me (and thus in the
wifimac), a MCS is a "Modulation- and Coding Scheme". Thus, it does not
say anything about multiple spatial streams. This is in contrast to IEEE
802.11n, where a MCS consists of
* the number of subcarriers
* number of spatial streams
* modulation of each stream
* coding rate of each stream
In the wifimac, this would be called a "PhyMode" (if you add also the GI
length, because then the number of bits per second is determined).

Therefore, the MCS table in PhyModes.py contains 8 entries, and this is
absolutely adequate for draftn - the 100+ "draftn-MCSs" can be generated
by the rate adaptation strategy by selecting appropriate number of
streams and "wifimac-MCSs" for each stream (the only exemption is MCS
#32, because it cannot be generated in this way).

BUT, the SINRwithMIMO strategy does not make use of these possibilities:
 First, the number of subcarriers is fixed anyways in the PyConfig,
currently there is no option to have mixed 20/40 MHz simulations.
Second, the SINRwithMIMO applies only the same "wifimac-MCS" to each
stream. Hence, only (max num SS)*(MCSs) = 32 "draftn-MCS" are used,
instead 1SS*8MCS + 2SS*8MCS + 3SS*8MCS + 4SS*8MCS = 10*8 = 80 "draftn-MCSs".

With the current MIMO-postSINR model, this is fine - the SINR on each
stream is the same anyways, so no need to have different MCS. In a more
complex MIMO-postSINR model, different MCS on each stream might be
required, and the PhyMode-Interface supports this. Feel free to
implement a more realistic/complex MIMO-model, and a more
intelligent/complex rate adaptation.

> By the way, how was thresholds for the db-values set? I mean, is
> there a way to know the reason, why you said, i.e. if postSINR = 9.1 dB, use
> QPSK-1/2 for the actual transmission?

The threshold are set such that with the current error model (in the
convergence), a 1000B-frame ends up with a PER of < 10**(-5) (or -6?).
Feel free to check/change this.

Best regards,
Sebastian

Dear Sebastian,
sorry, i should have asked my question more precisely. Fortunately, you interpreted it the right way and gave me the informations i wanted to have.

Thanks, this solve my problem
Kharny