This commit is contained in:
Marco Miozzo
2011-11-02 13:33:20 +01:00
2 changed files with 19 additions and 22 deletions

View File

@@ -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.

View File

@@ -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