About getBlockErrorRate

Asked by Chiu

Dear Jan,

I notice that in BlockErrorModel::getBlockErrorRate

you wrote

perCBsuccessProb = 1.0 - getBlockErrorRate(sinr, modulation, codeRate, segmentedBlockSize);

The segmentedBlockSize you calculated seems already CRC-included, unlike the original "blockSize" which only contains information

But the check if (blockSize + 24 > 6144) always assume blockSize to be non-CRC-added as it was in the first segmentation

So when it calls getBlockErrorRate(sinr, modulation, codeRate, segmentedBlockSize) in the second recursive

It will do the check: segmentedBlockSize + 24 >? 6144, which add the CRC twice unwantedly and might segment the already segmented code block.

I guess I should delete

"
        double perCBsuccessProb = 1.0 - getBlockErrorRate(sinr, modulation, codeRate, segmentedBlockSize);
        bler = 1.0 - pow(perCBsuccessProb, static_cast<double>(numBlocks));
        return bler;
"

Use float blockLength = static_cast<float>(segmentedBlockSize); after the if

and write

        double perCBsuccessProb = 1.0 - tri.linear(lookupResult, lookForKeys);
        bler = 1.0 - pow(perCBsuccessProb, static_cast<double>(numBlocks));
        return bler;

at the last of this function

Is that so?

Sung-En Chiu

Question information

Language:
English Edit question
Status:
Solved
For:
IMTAphy Edit question
Assignee:
No assignee Edit question
Solved by:
Chiu
Solved:
Last query:
Last reply:
Revision history for this message
Jan (jan-ellenbeck) said :
#1

Hi Sung-En Chiu,

Thanks for your questions and for looking at this closely. I think the current implementation is indeed suboptimal and potentially wrong in corner cases. I tried your suggestion and I like it because it is much easier to understand than the recursive call I used before.

However, I think it hardly makes a difference on the results at least according to a before/after comparison I just ran. I will include this fix in a future update to the code.

Thanks and best regards
Jan

Revision history for this message
Chiu (qoocoolqoo) said :
#2

Jan,

Thank you for your check.

I agree with you that It is indeed probably a corner case since the segmented block length would hardly exceed 6120 before adding CRC.

And one more little matter to clear myself:

In your comment:
    // transport block size + 24 transport block CRC
    // bler curves already consider 24 bit CRC

Does this mean the input block size to BLER mapping should exclude CRC?

So a possible way would be

If(blockSize + 24 > 6144)
{
     ...
}
else
{
     segmentedBlockSize = blockSize + 24;
}

float blockLength = static_cast<float>(segmentedBlockSize - 24);
or other equivalent implementation such as do not include the CRC to the segmentedBlockSize.

Is my understanding correct?

-----------

And just a bit curious, do you know what block length did they use in Vienna's L2S BLER-SNR curves? (such as Fig.3 shown in they're paper "System level simulation of LTE networks") [Perhaps you ever check the curves with theirs?]

They didn't input any block size or do any TB segmentation in their system level simulator, I'm curious about what approximation did they make.

For instance if I understand it correctly, in certain case, say TB = 36696
with segmentation we will have, say C = 6 blocks.

Assume BLER of one block = 0.1
Using 6 blocks, we should have BLER = 1 - (1-0.1)^6 = 0.4686

But in Vienna's implementation, they directly map SNR to BLER without any segmentation. It would yield BLER = 0.1 and would quite deviate from 0.4686

Do you know what tricks or approximation on the BLER curves or the methodology they used to cover this problem?

or did they simply assume 0.1 =~ 0.4686 in such case?

Regards,
Sung-En Chiu

Revision history for this message
Jan (jan-ellenbeck) said :
#3

Hi,

I cannot speak for their system-level simulator and I haven't looked at their implementation. When I obtained the the SNR->BLER curves, I patched the link-level simulator to work with fixed block sizes. If I remember correctly, I controlled the size (i.e. number of PRBs) of a transport block to achieve a block size that was as close as possible to the one that I wanted to have. Note that this means that, for example, for higher MCS the smallest block sizes could actually not be simulated because a single PRB already holds too many bits. That should not be a problem for the L2S model because for such MCSs the smallest block sizes would never be used.

At the moment I cannot say whether the CRC should be included in the length for the lookup or not. But again, I really don't think it makes any tangible difference.

Best regards
Jan

Revision history for this message
Chiu (qoocoolqoo) said :
#4

I see. It just a bit confused me that how they assumed when getting their BLER-SNR curves since their usage of them is strange to me.

anyway, thanks!

Regards,

Sung-En