--- a/doc/models/Makefile Tue May 29 21:31:22 2012 -0700
+++ b/doc/models/Makefile Wed May 30 14:33:29 2012 +0200
@@ -135,6 +135,16 @@
$(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 \
--- a/src/antenna/doc/source/antenna-design.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/antenna/doc/source/antenna-design.rst Wed May 30 14:33:29 2012 +0200
@@ -61,7 +61,7 @@
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::
--- a/src/buildings/doc/source/buildings-testing.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/buildings/doc/source/buildings-testing.rst Wed May 30 14:33:29 2012 +0200
@@ -63,7 +63,7 @@
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
-------------------------
--- a/src/lte/doc/Makefile Tue May 29 21:31:22 2012 -0700
+++ b/src/lte/doc/Makefile Wed May 30 14:33:29 2012 +0200
@@ -94,6 +94,7 @@
$(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 \
--- a/src/lte/doc/source/lte-design.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/lte/doc/source/lte-design.rst Wed May 30 14:33:29 2012 +0200
@@ -84,7 +84,7 @@
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 @@
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 @@
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 @@
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 @@
^^^^^^^^^^^^^^^^^^
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 @@
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 @@
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 @@
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 @@
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 @@
* 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 @@
.. 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.
--- a/src/lte/doc/source/lte-references.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/lte/doc/source/lte-references.rst Wed May 30 14:33:29 2012 +0200
@@ -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"
--- a/src/lte/doc/source/lte-testing.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/lte/doc/source/lte-testing.rst Wed May 30 14:33:29 2012 +0200
@@ -103,11 +103,11 @@
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 @@
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 @@
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 @@
----------
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.
--- a/src/lte/doc/source/lte-user.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/lte/doc/source/lte-user.rst Wed May 30 14:33:29 2012 +0200
@@ -299,7 +299,7 @@
************************
-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 @@
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:
--- a/src/propagation/doc/propagation.rst Tue May 29 21:31:22 2012 -0700
+++ b/src/propagation/doc/propagation.rst Wed May 30 14:33:29 2012 +0200
@@ -60,7 +60,7 @@
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.