F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fixed bug 1437 - LTE documentation missing figures and references

Browse Source
This commit is contained in:
Nicola Baldo
2012-05-30 14:33:29 +02:00
parent aece093628
commit fa87f19478
9 changed files with 66 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/models/Makefile
View File

@@ -135,6 +135,16 @@ SOURCEFIGS = \
$(SRC)/lte/doc/source/figures/MCS_17_20.png \
$(SRC)/lte/doc/source/figures/MCS_21_24.pdf \
$(SRC)/lte/doc/source/figures/MCS_21_24.png \
$(SRC)/lte/doc/source/figures/MCS_25_28.pdf \
$(SRC)/lte/doc/source/figures/MCS_25_28.png \
$(SRC)/lte/doc/source/figures/MCS_29_29.pdf \
$(SRC)/lte/doc/source/figures/MCS_29_29.png \
$(SRC)/lte/doc/source/figures/MCS_2_test.png \
$(SRC)/lte/doc/source/figures/MCS_2_test.pdf \
$(SRC)/lte/doc/source/figures/MCS_12_test.png \
$(SRC)/lte/doc/source/figures/MCS_12_test.pdf \
$(SRC)/lte/doc/source/figures/MCS_16_test.png \
$(SRC)/lte/doc/source/figures/MCS_16_test.pdf \
$(SRC)/lte/doc/source/figures/lte-phy-interference.png \
$(SRC)/lte/doc/source/figures/lte-phy-interference.pdf \
$(SRC)/lte/doc/source/figures/helpers.png \

2
src/antenna/doc/source/antenna-design.rst
View File

@@ -61,7 +61,7 @@ for all direction.
CosineAntennaModel
++++++++++++++++++
This is the cosine model described in [Chunjan]_: the antenna gain is
This is the cosine model described in [Chunjian]_: the antenna gain is
determined as:
.. math::

2
src/buildings/doc/source/buildings-testing.rst
View File

@@ -63,7 +63,7 @@ This test is aimed at validating the COST231 model. The test is similar to the O
Test #3 2.6 GHz model
---------------------
This test validates the 2.6 empirical model [pl26ghz]_. The test is similar to Okumura Hata one except that the frequency is the EUTRA band #7 (2620 MHz) and the test can be performed only in urban scenario.
This test validates the 2.6 GHz Kun model. The test is similar to Okumura Hata one except that the frequency is the EUTRA band #7 (2620 MHz) and the test can be performed only in urban scenario.
Test #4 ITU1411 LoS model
-------------------------

1
src/lte/doc/Makefile
View File

@@ -94,6 +94,7 @@ IMAGES_NOBUILD = $(FIGURES)/fading_pedestrian.png \
$(FIGURES)/MCS_21_24.pdf \
$(FIGURES)/MCS_21_24.png \
$(FIGURES)/MCS_25_28.pdf \
$(FIGURES)/MCS_25_28.png \
$(FIGURES)/MCS_29_29.pdf \
$(FIGURES)/MCS_29_29.png \
$(FIGURES)/MCS_2_test.png \

24
src/lte/doc/source/lte-design.rst
View File

@@ -84,7 +84,7 @@ have been considered:
so that they use different carrier frequencies and system bandwidths. The
bandwidth used by different cells should be allowed to overlap, in order to
support dynamic spectrum licensing solutions such as those described
in [Ofcom2.6GHz]_ and [RealWireless]_. The calculation of interference should
in [Ofcom2600MHz]_ and [RealWireless]_. The calculation of interference should
handle appropriately this case.
#. To be more representative of the LTE standard, as well as to be as
close as possible to real-world implementations, the simulator
@@ -525,7 +525,7 @@ hence in a given subframe each RB is always allocated to the same user in both
slots.
The allocation bitmap can be coded in
different formats; in this implementation, we considered the *Allocation
Type 0* defined in [TS36.213]_, according to which the RBs are grouped in
Type 0* defined in [TS36213]_, according to which the RBs are grouped in
Resource Block Groups (RBG) of different size determined as a function of the
Transmission Bandwidth Configuration in use.
@@ -567,14 +567,14 @@ scheme.
Finally, we note that there are some discrepancies between the MCS index
in [R1-081483]_
and that indicated by the standard: [TS36.213]_ Table
and that indicated by the standard: [TS36213]_ Table
7.1.7.1-1 says that the MCS index goes from 0 to 31, and 0 appears to be a valid
MCS scheme (TB size is not 0) but in [R1-081483]_ the first useful MCS
index
is 1. Hence to get the value as intended by the standard we need to subtract 1
from the index reported in [R1-081483]_.
The alternative model is based on the physical error model developed for this simulator and explained in the following subsections. This scheme is able to adapt the MCS selection to the actual PHY layer performance according to the specific CQI report. According to their definition, a CQI index is assigned when a single PDSCH TB with the modulation coding scheme and code rate correspondent to that CQI index in table 7.2.3-1 of [TS36.213]_ can be received with an error probability less than 0.1. In case of wideband CQIs, the reference TB includes all the RBGs available in order to have a reference based on the whole available resources; while, for subband CQIs, the reference TB is sized as the RBGs.
The alternative model is based on the physical error model developed for this simulator and explained in the following subsections. This scheme is able to adapt the MCS selection to the actual PHY layer performance according to the specific CQI report. According to their definition, a CQI index is assigned when a single PDSCH TB with the modulation coding scheme and code rate correspondent to that CQI index in table 7.2.3-1 of [TS36213]_ can be received with an error probability less than 0.1. In case of wideband CQIs, the reference TB includes all the RBGs available in order to have a reference based on the whole available resources; while, for subband CQIs, the reference TB is sized as the RBGs.
Round Robin (RR) Scheduler
@@ -594,7 +594,7 @@ condition over time. Let :math:`i,j` denote generic users; let :math:`t` be the
subframe index, and :math:`k` be the resource block index; let :math:`M_{i,k}(t)` be MCS
usable by user :math:`i` on resource block :math:`k` according to what reported by the AMC
model (see `Adaptive Modulation and Coding`_); finally, let :math:`S(M, B)` be the TB
size in bits as defined in [TS36.213]_ for the case where a number :math:`B` of
size in bits as defined in [TS36213]_ for the case where a number :math:`B` of
resource blocks is used. The achievable rate :math:`R_{i}(k,t)` in bit/s for user :math:`i`
on resource block :math:`k` at subframe :math:`t` is defined as
@@ -1131,7 +1131,7 @@ LTE Spectrum Model
^^^^^^^^^^^^^^^^^^
The usage of the radio spectrum by eNBs and UEs in LTE is described in
[TS36.101]_. In the simulator, radio spectrum usage is modeled as follows.
[TS36101]_. In the simulator, radio spectrum usage is modeled as follows.
Let :math:`f_c` denote the LTE Absolute Radio Frequency Channel Number, which
identifies the carrier frequency on a 100 kHz raster; furthermore, let :math:`B` be
the Transmission Bandwidth Configuration in number of Resource Blocks. For every
@@ -1144,7 +1144,7 @@ the MultiModelSpectrumChannel described in [Baldo2009]_, the interference
among eNBs that use different spectrum models is properly accounted for.
This allows to simulate dynamic spectrum access policies, such as for
example the spectrum licensing policies that are
discussed in [Ofcom2.6GHz]_.
discussed in [Ofcom2600MHz]_.
@@ -1153,7 +1153,7 @@ PHY Error Model
The simulator includes an error model of the data plane (i.e., PDSCH) according to the standard link-to-system mapping (LSM) techniques. The choice is aligned with the standard system simulation methodology of OFDMA radio transmission technology. Thanks to LSM we are able to maintain a good level of accuracy and at the same time limiting the computational complexity increase. It is based on the mapping of single link layer performance obtained by means of link level simulators to system (in our case network) simulators. In particular link the layer simulator is used for generating the performance of a single link from a PHY layer perspective, usually in terms of code block error rate (BLER), under specific static conditions. LSM allows the usage of these parameters in more complex scenarios, typical of system/network simulators, where we have more links, interference and "colored" channel propagation phenomena (e.g., frequency selective fading).
To do this the Vienna LTE Simulator [Vienna]_ has been used for what concerns the extraction of link layer performance and the Mutual Information Based Effective SINR (MIESM) as LSM mapping function using part of the work recently published by the Signet Group of University of Padua [PaduaPEM]_.
To do this the Vienna LTE Simulator [ViennaLteSim]_ has been used for what concerns the extraction of link layer performance and the Mutual Information Based Effective SINR (MIESM) as LSM mapping function using part of the work recently published by the Signet Group of University of Padua [PaduaPEM]_.
MIESM
@@ -1169,7 +1169,7 @@ Moreover, from an HARQ perspective, the MIESM has more flexibility in managing t
MIESM computational procedure diagram
The mutual information (MI) is dependent on the constellation mapping and can be calculated per transport block (TB) basis, by evaluating the MI over the symbols and the subcarrier. However, this would be too complex for a network simulator. Hence, in our implementation a flat channel response within the RB has been considered; therefore the overall MI of a TB is calculated averaging the MI evaluated per each RB used in the TB. In detail, the implemented scheme is depicted in Figure :ref:`fig-miesm-architecture`, where we see that the model starts by evaluating the MI value for each RB, represented in the figure by the SINR samples. Then the equivalent MI is evaluated per TB basis by averaging the MI values. Finally, a further step has to be done since the link level simulator returns the performance of the link in terms of block error rate (BLER) in a addive white guassian noise (AWGN) channel, where the blocks are the code blocks (CBs) independently encoded/decoded by the turbo encoder. On this matter the standard 3GPP segmentation scheme has been used for estimating the actual CB size (described in section 5.1.2 of [TS36.212]_). This scheme divides the the TB in :math:`N_{K_-}` blocks of size :math:`K_-` and :math:`N_{K+}` blocks of size :math:`K_+`. Therefore the overall TB BLER (TBLER) can be expressed as
The mutual information (MI) is dependent on the constellation mapping and can be calculated per transport block (TB) basis, by evaluating the MI over the symbols and the subcarrier. However, this would be too complex for a network simulator. Hence, in our implementation a flat channel response within the RB has been considered; therefore the overall MI of a TB is calculated averaging the MI evaluated per each RB used in the TB. In detail, the implemented scheme is depicted in Figure :ref:`fig-miesm-architecture`, where we see that the model starts by evaluating the MI value for each RB, represented in the figure by the SINR samples. Then the equivalent MI is evaluated per TB basis by averaging the MI values. Finally, a further step has to be done since the link level simulator returns the performance of the link in terms of block error rate (BLER) in a addive white guassian noise (AWGN) channel, where the blocks are the code blocks (CBs) independently encoded/decoded by the turbo encoder. On this matter the standard 3GPP segmentation scheme has been used for estimating the actual CB size (described in section 5.1.2 of [TS36212]_). This scheme divides the the TB in :math:`N_{K_-}` blocks of size :math:`K_-` and :math:`N_{K+}` blocks of size :math:`K_+`. Therefore the overall TB BLER (TBLER) can be expressed as
.. math::
@@ -1394,7 +1394,7 @@ With respect to the mathematical channel propagation model, we suggest the one p
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]_):
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 [TS36104]_):
* users' speed: typically only a few discrete values are considered, i.e.:
@@ -1402,7 +1402,7 @@ Since the number of variable it is pretty high, generate traces considering all
* 30 and 60 kmph for vehicular scenarios
* 0, 3, 30 and 60 for urban scenarios
* 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 [TS36.104]_.
* 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 [TS36104]_.
* 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.
@@ -1413,7 +1413,7 @@ According to the parameters we considered, the following formula express in deta
.. math::
S_{traces} = S_{sample} \times N_{RB} \times \frac{T_{trace}}{T_{sample}} \times N_{scenarios} \mbox{ [bytes]}
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 3 different scenarios one for each taps configuration defined in Annex B.2 of [TS36.104]_:
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 3 different scenarios one for each taps configuration defined in Annex B.2 of [TS36104]_:
* Pedestrian: with nodes' speed of 3 kmph.
* Vehicular: with nodes' speed of 60 kmph.

65
src/lte/doc/source/lte-references.rst
View File

@@ -1,6 +1,32 @@
.. include:: replace.txt
.. [TS25814] 3GPP TS 25.814 "Physical layer aspect for evolved Universal Terrestrial Radio Access"
.. [TS36101] 3GPP TS 36.101 "E-UTRA User Equipment (UE) radio transmission and reception"
.. [TS36104] 3GPP TS 36.104 "E-UTRA Base Station (BS) radio transmission and reception"
.. [TS36211] 3GPP TS 36.211 "E-UTRA Physical Channels and Modulation"
.. [TS36212] 3GPP TS 36.212 "E-UTRA Multiplexing and channel coding"
.. [TS36213] 3GPP TS 36.213 "E-UTRA Physical layer procedures"
.. [TS36321] 3GPP TS 36.321 "E-UTRA Medium Access Control (MAC) protocol specification"
.. [TS36322] 3GPP TS 36.322 "E-UTRA Radio Link Control (RLC) protocol specification"
.. [TS36323] 3GPP TS 36.323 "E-UTRA Packet Data Convergence Protocol (PDCP) specification"
.. [R1-081483] 3GPP R1-081483 `Conveying MCS and TB size via PDCCH <http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip>`_
.. [FFAPI] `FemtoForum LTE MAC Scheduler Interface Specification v1.11 <http://www.femtoforum.org/femto/technical.php>`_
.. [ns3tutorial] `The ns-3 Tutorial <http://www.nsnam.org/docs/tutorial/singlehtml/index.html>`_
.. [ns3manual] `The ns-3 Manual <http://www.nsnam.org/docs/manual/singlehtml/index.html>`_
.. [Sesia2009] S. Sesia, I. Toufik and M. Baker, "LTE - The UMTS Long Term Evolution - from theory to practice",
Wiley, 2009
@@ -20,53 +46,26 @@
.. [Seo2004] H. Seo, B. G. Lee. "A proportional-fair power allocation scheme for fair and efficient multiuser OFDM systems",
in Proc. of IEEE GLOBECOM, December 2004. Dallas (USA)
.. [Ofcom2.6GHz] Ofcom, "Consultation on assessment of future mobile
.. [Ofcom2600MHz] Ofcom, "Consultation on assessment of future mobile
competition and proposals for the award of 800 MHz and 2.6 GHz
spectrum and related issues", March 2011
.. [TS36322] 3GPP TS 36.322 "E-UTRA Radio Link Control (RLC) protocol specification"
.. [TS36323] 3GPP TS 36.323 "E-UTRA Packet Data Convergence Protocol (PDCP) specification"
.. [TS36.101] 3GPP TS 36.101 "E-UTRA User Equipment (UE) radio transmission and reception"
.. [TS36.213] 3GPP TS 36.213 "E-UTRA Physical layer procedures"
.. [TS25.814] 3GPP TS 25.814 "Physical layer aspect for evolved Universal Terrestrial Radio Access"
.. [TS36.104] 3GPP TS 36.104 "E-UTRA Base Station (BS) radio transmission and reception"
.. [R1-081483] 3GPP R1-081483 `Conveying MCS and TB size via PDCCH <http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip>`_
.. [FFAPI] `FemtoForum LTE MAC Scheduler Interface Specification v1.11 <http://www.femtoforum.org/femto/technical.php>`_
.. [ns3tutorial] `The ns-3 Tutorial <http://www.nsnam.org/docs/tutorial/singlehtml/index.html>`_
.. [ns3manual] `The ns-3 Manual <http://www.nsnam.org/docs/manual/singlehtml/index.html>`_
.. [RealWireless] RealWireless, Low-power shared access to spectrum
for mobile broadband, Final Report, Ofcom Project MC/073, 18th
March 2011
.. [PaduaPEM] http://mailman.isi.edu/pipermail/ns-developers/2011-November/009559.html
.. [Vienna] The Vienna LTE Simulators http://www.nt.tuwien.ac.at/about-us/staff/josep-colom-ikuno/lte-simulators/
.. [ViennaLteSim] The Vienna LTE Simulators http://www.nt.tuwien.ac.at/about-us/staff/josep-colom-ikuno/lte-simulators/
.. [LozanoCost] Joan Olmos, Silvia Ruiz, Mario García-Lozano and David Martín-Sacristán, "Link Abstraction Models Based on Mutual Information for LTE Downlink", COST 2100 TD(10)11052 Report
.. [wimaxEmd] WiMAX Forum White Paper, WiMAX System Evaluation Methodology, July 2008.
.. [TS36.212] 3GPP TS 36.212 "E-UTRA Multiplexing and channel coding"
.. [mathworks] Matlab R2011b Documentation Communications System Toolbox, `Methodology for Simulating Multipath Fading Channels <http://www.mathworks.es/help/toolbox/comm/ug/a1069449399.html#bq5zk36>`_
.. [PaduaPEM] http://mailman.isi.edu/pipermail/ns-developers/2011-November/009559.html
.. [Vienna] The Vienna LTE Simulators http://www.nt.tuwien.ac.at/about-us/staff/josep-colom-ikuno/lte-simulators/
.. [LozanoCost] Joan Olmos, Silvia Ruiz, Mario García-Lozano and David Martín-Sacristán, "Link Abstraction Models Based on Mutual Information for LTE Downlink", COST 2100 TD(10)11052 Report
.. [CatreuxMIMO] S. Catreux, L.J. Greenstein, V. Erceg, "Some results and insights on the performance gains of MIMO systems," Selected Areas in Communications, IEEE Journal on , vol.21, no.5, pp. 839- 847, June 2003
.. [ViennaPaper] J.C. Ikuno, M. Wrulich, M. Rupp, "System Level Simulation of LTE Networks," Vehicular Technology Conference (VTC 2010-Spring), 2010 IEEE 71st , vol., no., pp.1-5, 16-19 May 2010
.. [Ikuno2010] J.C. Ikuno, M. Wrulich, M. Rupp, "System Level Simulation of LTE Networks," Vehicular Technology Conference (VTC 2010-Spring), 2010 IEEE 71st , vol., no., pp.1-5, 16-19 May 2010
.. [TS36.211] 3GPP TS 36.211 "E-UTRA Physical Channels and Modulation"

12
src/lte/doc/source/lte-testing.rst
View File

@@ -103,11 +103,11 @@ E-UTRA Absolute Radio Frequency Channel Number (EARFCN)
The test suite ``lte-earfcn`` checks that the carrier frequency used
by the LteSpectrumValueHelper class (which implements the LTE spectrum
model) is done in compliance with [TS36.101]_, where the E-UTRA
model) is done in compliance with [TS36101]_, where the E-UTRA
Absolute Radio Frequency Channel Number (EARFCN) is defined. The test
vector for this test suite comprises a set of EARFCN values and the
corresponding carrier frequency calculated by hand following the
specification of [TS36.101]_. The test passes if the carrier frequency
specification of [TS36101]_. The test passes if the carrier frequency
returned by LteSpectrumValueHelper is the same as the known value for
each element in the test vector.
@@ -207,10 +207,10 @@ matches a reference throughput value obtained according to the SINR perceived
within a given tolerance.
The test vector is obtained according to the values of transport block
size reported in table 7.1.7.2.1-1 of [TS36.213]_, considering an
size reported in table 7.1.7.2.1-1 of [TS36213]_, considering an
equal distribution of the physical resource block among the users
using Resource Allocation Type 0 as defined in Section 7.1.6.1 of
[TS36.213]_. Let :math:`\tau` be the TTI duration, :math:`N` be the
[TS36213]_. Let :math:`\tau` be the TTI duration, :math:`N` be the
number of UEs, :math:`B` the transmission bandwidth configuration in
number of RBs, :math:`G` the RBG size, :math:`M` the modulation and
coding scheme in use at the given SINR and :math:`S(M, B)` be the
@@ -273,7 +273,7 @@ at the given SNR by the total number of UEs.
Let :math:`\tau` be the TTI duration, :math:`B` the transmission
bandwidth configuration in number of RBs, :math:`M` the modulation and
coding scheme in use at the given SINR and :math:`S(M, B)` be the
transport block size as defined in [TS36.213]_. The reference
transport block size as defined in [TS36213]_. The reference
throughput :math:`T` in bit/s achieved by each UE is calculated as
.. math::
@@ -410,7 +410,7 @@ MIMO Model
----------
The test suite ``lte-mimo`` aims at verifying both the effect of the gain considered for each Transmission Mode on the system performance and the Transmission Mode switching through the scheduler interface. The test consists on checking whether the amount of bytes received during a certain window of time (0.1 seconds in our case) corresponds to the expected ones according to the values of transport block
size reported in table 7.1.7.2.1-1 of [TS36.213]_, similarly to what done for the tests of the schedulers.
size reported in table 7.1.7.2.1-1 of [TS36213]_, similarly to what done for the tests of the schedulers.
The test is performed both for Round Robin and Proportional Fair schedulers. The test passes if the measured throughput matches with the reference throughput within a relative tolerance of 0.1. This tolerance is needed to account for the
transient behavior at the beginning of the simulation and the transition phase between the Transmission Modes.

4
src/lte/doc/source/lte-user.rst
View File

@@ -299,7 +299,7 @@ Fading Traces Generation
************************
It is possible to generate fading traces by using a dedicated matlab script provided with the code (``/lte/model/fading-traces/fading-trace-generator.m``). This script already includes the typical taps configurations for three 3GPP scenarios (i.e., pedestrian, vehicular and urban as defined in Annex B.2 of [TS36.104]_); however users can also introduce their specific configurations. The list of the configurable parameters is provided in the following:
It is possible to generate fading traces by using a dedicated matlab script provided with the code (``/lte/model/fading-traces/fading-trace-generator.m``). This script already includes the typical taps configurations for three 3GPP scenarios (i.e., pedestrian, vehicular and urban as defined in Annex B.2 of [TS36104]_); however users can also introduce their specific configurations. The list of the configurable parameters is provided in the following:
* ``fc`` : the frequency in use (it affects the computation of the doppler speed).
* ``v_km_h`` : the speed of the users
@@ -341,7 +341,7 @@ And for setting the parameters::
It has to be noted that, ``TraceFilename`` does not have a default value, therefore is has to be always set explicitly.
The simulator provide natively three fading traces generated according to the configurations defined in in Annex B.2 of [TS36.104]_. These traces are available in the folder ``src/lte/model/fading-traces/``). An excerpt from these traces is represented in the following figures.
The simulator provide natively three fading traces generated according to the configurations defined in in Annex B.2 of [TS36104]_. These traces are available in the folder ``src/lte/model/fading-traces/``). An excerpt from these traces is represented in the following figures.
.. _fig-fadingPedestrianTrace:

2
src/propagation/doc/propagation.rst
View File

@@ -60,7 +60,7 @@ RangePropagationLossModel
OkumuraHataPropagationLossModel
+++++++++++++++++++++++++++++++
This model is used to model open area pathloss for long distance (i.e., > 1 Km). In order to include all the possible frequencies usable by LTE we need to consider several variants of the well known Okumura Hata model. In fact, the original Okumura Hata model [hata]_ is designed for frequencies ranging from 150 MHz to 1500 MHz, the COST231 [cost231]_ extends it for the frequency range from 1500 MHz to 2000 MHz, and [pl26ghz]_ further extends it up to 2.6G Hz. Another important aspect is the scenarios considered by the models, in fact the all models are originally designed for urban scenario and then only the standard one and the COST231 are extended to suburban, while only the standard one has been extended to open areas. Therefore, the model cannot cover all scenarios at all frequencies. In the following we detail the models adopted.
This model is used to model open area pathloss for long distance (i.e., > 1 Km). In order to include all the possible frequencies usable by LTE we need to consider several variants of the well known Okumura Hata model. In fact, the original Okumura Hata model [hata]_ is designed for frequencies ranging from 150 MHz to 1500 MHz, the COST231 [cost231]_ extends it for the frequency range from 1500 MHz to 2000 MHz. Another important aspect is the scenarios considered by the models, in fact the all models are originally designed for urban scenario and then only the standard one and the COST231 are extended to suburban, while only the standard one has been extended to open areas. Therefore, the model cannot cover all scenarios at all frequencies. In the following we detail the models adopted.