Rayleigh fading

[dragos-bth]

Hi,

I am looking into the source code for computing Rayleigh fading in INET/INETMANET https://github.com/inet-framework/inet/blob/d93b7bc29def3ead5727f4de880a02be19810a44/src/inet/physicallayer/wireless/common/pathloss/RayleighFading.cc#L32-L39

double RayleighFading::computePathLoss(mps propagationSpeed, Hz frequency, m distance) const
{
    m waveLength = propagationSpeed / frequency;
    double freeSpacePathLoss = computeFreeSpacePathLoss(waveLength, distance, alpha, systemLoss);
    double x = normal(0, 1);
    double y = normal(0, 1);
    return freeSpacePathLoss * 0.5 * (x * x + y * y);
}

I would like to understand where 0.5 term comes from on the line with the return statement. As far as I know, $\sqrt{x^2 + y^2}$ has a Rayleigh density when $x$ and $y$ are normal and independent random variables with zero mean and equal variance. Therefore I was expecting that line to look like

return freeSpacePathLoss * sqrt((x * x + y * y));

[rhornig]

I will try to track down the origin of the code, but most likely this is a bug. Would you mind copy/pasting this neat issue report to the INET issue tracker (as we cannot move issues accross organization boundaries).

[dragos-bth]

Done that. See inet-framework/inet#956 I am also trying to understand the computations for Rician fading where only x is getting shifted by sqrt(2 * k), but I will give it one more shot before starting a new discussion thread. If you already know the answer, I would appreciate it if you can post a comment about it so I can stop banging my head against the wall.

…

On 6 Mar 2024, at 19:43, Rudolf Hornig ***@***.***> wrote: I will try to track down the origin of the code, but most likely this is a bug. Would you mind copy/pasting this neat issue report to the INET issue tracker (as we cannot move issues accross organization boundaries). — Reply to this email directly, view it on GitHub <#1119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJMNMFKB5ODHH6N2TRMKEQ3YW5PVLAVCNFSM6AAAAABEIYWIHOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMOJXG43TO>. You are receiving this because you authored the thread.

[dragos-bth]

@rhornig Yes, intuitively your explanation makes sense, but it would be nice to have some more formal arguments to put forward when I discuss it with other people.

[rhornig]

probably a comparing the codebase with NS3 would give some insight.

[dragos-bth]

Already checked against MATLAB and is what I expected (for scale factor b=1)

function r = raylrnd(b,varargin)
%RAYLRND Random arrays from the Rayleigh distribution.
%   R = RAYLRND(B) returns an array of random numbers chosen from the
%   Rayleigh distribution with parameter B.  The size of R is the size of
%   B.
%
%   R = RAYLRND(B,M,N,...) or R = RAYLRND(B,[M,N,...]) returns an
%   M-by-N-by-... array.
%
%   See also RAYLCDF, RAYLINV, RAYLPDF, RAYLSTAT, RANDOM.

%   RAYLRND uses a transformation method, expressing a Rayleigh
%   random variable in terms of a chi-square random variable.

%   Reference:
%      [1] Evans, M., Hastings, N., and Peacock, B. (1993) Statistical
%          Distributions, 2nd ed., Wiley, 170pp.

%   Copyright 1993-2018 The MathWorks, Inc. 


if nargin < 1
    error(message('stats:raylrnd:TooFewInputs')); 
end

[err, sizeOut] = internal.stats.statsizechk(1,b,varargin{:});
if err > 0
    error(message('stats:raylrnd:InputSizeMismatch'));
end

% Return NaN for elements corresponding to illegal parameter values.
b(b < 0) = NaN;

% Generate chi-squared 2 d.f. random values and take their sqrt.
r = sqrt(randn(sizeOut,'like',b).^2 + randn(sizeOut,'like',b).^2) .* b;

[rhornig]

I guess, it is pretty much settled that this is a bug and will be fixed in INET. I'm still unsure about the Rician fading code.

[dragos-bth]

Unfortunately, MATLAB uses a different approach to generate Rician random variables and therefore I can't check against it.

Rician fading with Rician factor $\kappa$ can be modeled with a complex Gaussian random variable $r \sim \mathcal{CN}(\sqrt{\kappa/(1+\kappa)}, 1/(1+\kappa))$. I assume the $x$ and $y$ variables in the code correspond to the real and imaginary part of $r$, respectively.

I think the use of the $c$ variable is to rescale $x,y$ from $\mathcal{N}(0,1)$ to $\mathcal{N}(0,1/2(1+\kappa))$, to yield a total variance of $1/(1+\kappa)$, which is what we want for $r$. If that is the case, then I would expect the mean of $x$ and $y$ to be scaled similarly, that is by adding $\sqrt{\kappa/(1+\kappa)}$ to each, but that is not what is done in the code.