Interpretation of noise variance in GaussianPriorSource

[gc1905]

There is an inconsistency in interpretation of the noise variance parameter among different classes. Please consider the following code example:

import sionna
import tensorflow as tf
import matplotlib.pyplot as plt

no = 0.01
shape = [1000]

# Generate LLR with Gaussian Prior Source 
gps = sionna.phy.fec.utils.GaussianPriorSource()

llr_gps = gps(output_shape=shape, no=no)

# Generate LLR with Mapper -> AWGN -> Demapper
src = sionna.phy.mapping.BinarySource()
mapper = sionna.phy.mapping.Mapper(constellation_type='pam', num_bits_per_symbol=1)
demapper = sionna.phy.mapping.Demapper(demapping_method='app', constellation_type='pam', num_bits_per_symbol=1)
channel = sionna.phy.channel.AWGN()

b = src(shape)
x = mapper(b)
y = channel(x, no)
llr_demap = demapper(y, no)

# Plot hiostograms of  LLR magnitudes
plt.hist(tf.math.abs(llr_demap), bins=30, label='demap')
plt.hist(tf.math.abs(llr_gps), bins=30, label='gps')
plt.legend()
plt.show()

As you can see, the code implements two alternative methods to generate LLRs for BiAWGN channel:

• use GaussianPriorSource to generate zero-CW LLRs,
• use a concatenation of BinarySource -> Mapper -> AWGN -> Demapper configured with BPSK.

The output of the code provided above is as follows:

A user may expect to obtain exactly the same distribution of LLR magnitudes with both methods when configured with the same noise variance, so they can be used interchangeably. However, the distributions are not matching due to different assumptions on noise variance taken by different blocks. It seems that the discrepancy results from the fact that GaussianPriorSource assumes real-valued AWGN channel, when AWGN assumes (obviously) complex-valued AWGN.

Is this an intended behavior? Please comment.

[jhoydis]

Hi @gc1905,

This is because no is indeed the variance of the real-valued AWGN channel in the GaussianPriorSource. We should probably rename no to sigma2_chn or something like this to avoid confusion. We'll keep it in mind for a future release. In the meantime, just use no/2 as input and it should work.