How is SNR defined? And then, which is the mechanism that choose the MCS?

[dannoman1988]

Issue Description

I have enabled the printing of the metrics in srsue (by pressing "t") and I have seen that the EU detects a SNR of 40dBm in downlink; it also uses the MCS 2 and 16 respectively for the downlink and uplink. I would like to understand where the 40dBm SNR is defined (it's uncorrelated from the "real" SNR dependent by pathloss, rxpower and txpower in EMANE, right?) in the code and then where the MCS choice is implemented. Is it a task entrusted to srsLTE-emane or to EMANE LTE Model?

Setup Details

My configuration is the same of the demonstrations in this page: https://github.com/adjacentlink/emane-model-lte

Additional Information

I have tried to analyze the code of srsLTE-emane. I have found the variables metrics.phy.dl.sinr and metrics.phy.dl.mcs in metrics_stdout.cc; I think I understood that their values come out of the calculations in phch_common.cc. But then? I'm not able to understand the exact chain leading to the SNR and MCS values mentioned above.

Thank you! Andrea

[jgiovatto]

Currently this is being set statically in:

https://github.com/adjacentlink/srsLTE-emane/blob/master/srsue/src/phy/phch_worker.cc

 void phch_worker::update_measurements()

We are working on integrating the emane snr info into these parameters in a future release.

[dannoman1988]

Very clear, thank you! However, if I can, I should ask you for another help in analyzing the code. I understood how the SNR is managed, but the setting of the MCS is not clear to me. I have verified, as you said, that the values are static and do not change with the SNR. But how, in which area of the code, are MCS values set? Thanks!!

[eschreiber-alink]

Have a look at the alloc_tbs function in scheduler_ue.cc:

https://github.com/adjacentlink/srsLTE-emane/blob/master/srsenb/src/mac/scheduler_ue.cc#L1201

[dannoman1988]

I'm sorry, but I'm afraid I have to ask you another help. In these days I have tried to analyze the code, but I'm not so familiar with C++. As said, I have found the values of MCS and SNR at the level of srsLTE (2 for downlink, 16 for uplink, 40 dBm respectively by default): so, this means in downlink I'm using a QPSK modulation and a 16QAM in uplink. Then I have seen the pcrcurveuri parameter, and the file pcr.xml with por values with respect to different SINR for eNB and UE. I understood that a packet is discarded if its receiving power is below the receiver's sensitivity (and I have verified this: in the demonstrations, the receivers has a sensitivity of -107 dBm, if I set a pathloss higher than 107, packets are not received). Instead I have not understand which are the modulations used in Emane. I mean, are they the same indicated in srsLTE, ie QPSK in downlink and 16QAM in uplink? In this case, how could I verify for example that in downlink I'm experimenting a por of 50% with a SINR of 3.0 (as described in pcr.xml)? I have tried with rlcthruputtable of the eNodeB, expecting a number of NumPushFail equal to about half of NumPush, but NumPushFail remain to 0. Thank you very much for your help!!

[eschreiber-alink]

EMANE does not implement physical layer modulation processes. Instead, it uses PCR curves to statistically determine the probability of a packet reception based on the received SINR of the packet and physical layer modulation parameters particular to a given waveform. For LTE, the PCR curves describe the probability that a single resource block is received based on its receive SINR and the modulation type for the physical channel contained in that block - the modulation type is carried in a header and known to the receiver. Users provide the PCR values in configuration. An example file is provided in the release:

https://github.com/adjacentlink/emane-model-lte/blob/master/demo/templates/enb/pcr.xml

Packet reception is determined by performing a pass/fail test on each resource block that comprises a message and then determining if enough resource blocks were received to channel decode the message based on the relative size of the transport block and the number of message resource elements. On the UE the implementation is here:

https://github.com/adjacentlink/emane-model-lte/blob/master/src/uemessageprocessor.cc#L158

[dannoman1988]

Ok, thank you... so, if I have well understood: the UE receiver knows the number of resource blocks (numResourceBlocks of line 170), the modulation type (modType of line 178) and the number of bits of the message to decode (numberOfBits of line 180). Then the receiver makes the tests with the two for cycle of lines 252 and 342, each of them on a "slot column" frequency by frequency of a subframe, right?

This message that you are talking about, and of which you test the reception in line 419, is a RLC PDU?

And I have to ask your help for the variables rbParams.res and numberChannelCodeREs, that sincerely I'm not able to understand what do they stand for. I thought that rbParams.res would be the number of Resource Elements for each slot, but in this case should be equal to 6 or 7, instead of 20, 32 or 40 as I have seen in the log files.

Thank you!!

[dannoman1988]

To be precise, for "log files" I meant the emane.log file of the User Equipment, where i find lines like this one:

10:51:32.319071 DEBUG MACI 003 UEMessageProcessor::noiseTestChannelMessage: modType 2, sinr_dB 3.5, por 0.7, rand 0.3, rbParams.res_ 32

where rbParams.res_ assumes values that I did not expect.

Thank you very much for your help!