From 21d24bdc760af7296ef8497c6733b553e2ec290e Mon Sep 17 00:00:00 2001 From: Nicola Baldo Date: Tue, 1 Nov 2011 17:41:01 -0400 Subject: [PATCH] revised fading documentation --- src/lte/doc/source/lte-design.rst | 36 +++++++++++---------------- src/lte/doc/source/lte-references.rst | 5 +++- 2 files changed, 19 insertions(+), 22 deletions(-) diff --git a/src/lte/doc/source/lte-design.rst b/src/lte/doc/source/lte-design.rst index 1e5aa2c8e..3180b7321 100644 --- a/src/lte/doc/source/lte-design.rst +++ b/src/lte/doc/source/lte-design.rst @@ -385,43 +385,37 @@ The fading model is based on the one developed during the GSoC 2010 [Piro2011]_. * length of trace: ideally large as the simulation time, might be reduced by windowing mechanism. * number of users: number of independent traces to be used (ideally one trace per user). -Respect to the mathematical channel propagation model, we suggest the one provided by the ``rayleighchan`` function of Matlab since it provides a well accepted channel modelization both in time and frequency domain, more information following the link: - -http://www.mathworks.es/help/toolbox/comm/ug/a1069449399.html#bq5zk36 +With respect to the mathematical channel propagation model, we suggest the one provided by the ``rayleighchan`` function of Matlab, since it provides a well accepted channel modelization both in time and frequency domain. For more information, the reader is referred to [mathworks]_. The simulator provides a matlab script (``/lte/model/JakesTraces/fading-trace-generator.m``) for generating traces based on the format used by the simulator. In detail, the channel object created with the rayleighchan function is used for filtering a discrete-time impulse signal in order to obtain the channel impulse response. The filtering is repeated for different TTI, thus yielding subsequent time-correlated channel responses (one per TTI). The channel response is then processed with the ``pwelch`` function for obtaining its power spectral density values, which are then saved in a file with the proper format compatible with the simulator model. Since the number of variable it is pretty high, generate traces considering all of them might produce a high number of traces of huge size. On this matter, we considered the following assumptions of the parameters based on the 3GPP fading propagation conditions (see Annex B.2 of [TS36.104]_): - * users' speed: consider the most common typical value + * users' speed: typically only a few discrete values are considered, i.e.: * 0 and 3 kmph for pedestrian scenarios * 30 and 60 kmph for vehicular scenarios * 0, 3, 30 and 60 for urban scenarios - * number of taps: use the three models presented in Annex B.2 of TS 36.104. - * time granularity: 1 ms (as the simulator granularity in time). - * frequency granularity: per RB basis (which implies 100 RBs, as the simulator granularity in frequency). - * length of the trace: the simulator includes the windowing mechanism implemented during the GSoC 2011, which consists of picking up a window of the trace each window length in a random fashion. - * number of users: users share the same fading trace, but the windows are independent among users which randomly pick up their starting point. + * channel taps: only a limited number of sets of channel taps are normally considered, for example three models are mentioned in Annex B.2 of TS 36.104. + * time granularity: we need one fading value per TTI, i.e., every 1 ms (as this is the granularity in time of the ns-3 LTE PHY model). + * frequency granularity: we need one fading value per RB (which is the frequency granularity of the spectrum model used by the ns-3 LTE model). + * length of the trace: the simulator includes the windowing mechanism implemented during the GSoC 2011, which consists of picking up a window of the trace each window length in a random fashion. + * per-user fading process: users share the same fading trace, but for each user a different starting point in the trace is randomly picked up. This choice was made to avoid the need to provide one fading trace per user. -According to the parameters we considered, the following formula express in detail the dimension: +According to the parameters we considered, the following formula express in detail the total size :math:`S_{traces}` of the fading traces: .. math:: - T_{SIZE} = Sample_{size} \times RB_{NUM} \times \frac{T_{total}}{T_{sample}} \times Speed_{NUM} \times Scenarios_{NUM} \mbox{ [bytes]} + S_{traces} = S_{sample} \times N_{RB} \times \frac{T_{trace}}{T_{sample}} \times N_{scenarios} \mbox{ [bytes]} -where :math:`Sample_{size}` is the size in bytes of the sample (e.g., 8 in case of double precision, 4 in case of float precision), :math:`RB_{NUM}` is the number of RB or set of RBs to be considered, :math:`T_{total}` is the total length of the trace, :math:`T_{sample}` is the sampling period (1 ms for having a new sample each subframe), :math:`Speed_{NUM}` is the number of users relative speeds considered and :math:`Scenarios_{NUM}` is the number of scenarios (i.e., different taps configurations). -According to the formula we have that a typical single channel realization (i.e., independent RB traces at a given speed and given set of number of taps with one sample per ms/TTI)) implies the usage of 8,000,000 bytes (7.6294 MB) considering the precision of double (:math:`1\times10^{-308}` to :math:`1\times10^{308}`). +where :math:`S_{sample}` is the size in bytes of the sample (e.g., 8 in case of double precision, 4 in case of float precision), :math:`N_{RB}` is the number of RB or set of RBs to be considered, :math:`T_{trace}` is the total length of the trace, :math:`T_{sample}` is the time resolution of the trace (1 ms), and :math:`N_{scenarios}` is the number of fading scenarios that are desired (i.e., combinations of different sets of channel taps and user speed values). We provide traces for 4 different scenarios: -A typical set of traces for a simulation will result therefore in: + * describe scenario 1 (specifying speed and taps) + * describe scenario 2 (specifying speed and taps) + * describe scenario 3 (specifying speed and taps) + * describe scenario 4 (specifying speed and taps) - * :math:`RB_{NUM}`: 100 - * :math:`T_{total}`: 10 secs - * :math:`T_{sample}`: 0.001 secs (1 ms as a subframe) - * :math:`Speed_{NUM}`: 1 speed per scenarios (e.g. 3 kmph for pedestrian) - * :math:`Scenarios_{NUM}`: 1 (pedestrian) - -which results in 8,000,000 bytes (~8 MB) of traces with double precision. +hence :math:`N_{scenarios} = 4`. All traces have :math:`T_{trace} = 10` s (CHECK) and :math:`RB_{NUM} = 100` (CHECK). This results in a total XXX (CHECK) bytes of traces. diff --git a/src/lte/doc/source/lte-references.rst b/src/lte/doc/source/lte-references.rst index ff74f05ea..1169e6182 100644 --- a/src/lte/doc/source/lte-references.rst +++ b/src/lte/doc/source/lte-references.rst @@ -52,4 +52,7 @@ .. [ikegami] F.Ikegami, T.Takeuchi, and S.Yoshida, "Theoretical prediction of mean field strength for Urban Mobile Radio", in IEEE Trans. Antennas Propagat., Vol.39, No.3, 1991 -.. [cost231] “Digital Mobile Radio: COST 231 View on the Evolution Towards 3rd Generation Systems”, Commission of the European Communities, L-2920, Luxembourg, 1989 +.. [cost231] "Digital Mobile Radio: COST 231 View on the Evolution Towards 3rd Generation Systems", Commission of the European Communities, L-2920, Luxembourg, 1989 + +.. [mathworks] Matlab R2011b Documentation Communications System Toolbox, "Methodology for Simulating Multipath Fading Channels" http://www.mathworks.es/help/toolbox/comm/ug/a1069449399.html#bq5zk36 +