From 7cb42e536eb38dd9e1f7ad516c3bea2f961468ce Mon Sep 17 00:00:00 2001 From: Nicola Baldo Date: Thu, 5 Jan 2012 11:37:02 +0100 Subject: [PATCH] lte doc errata corrige by Luca Costantino --- src/lte/doc/source/lte-design.rst | 14 +++++++------- src/lte/doc/source/lte-user.rst | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/lte/doc/source/lte-design.rst b/src/lte/doc/source/lte-design.rst index 0140eae6e..f9eb0daf3 100644 --- a/src/lte/doc/source/lte-design.rst +++ b/src/lte/doc/source/lte-design.rst @@ -83,7 +83,7 @@ have been considered: #. It should be possible within the simulation to configure different cells 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 + support dynamic spectrum licensing solutions such as those described in [Ofcom2.6GHz]_ 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 @@ -361,7 +361,7 @@ the UE, which is the end point of the downlink communication. Data flow in the uplink between the UE and the internet -The case of the downlink is depicted in Figure :ref:`fig-epc-data-flow-dl`. +The case of the uplink is depicted in Figure :ref:`fig-epc-data-flow-ul`. Uplink IP packets are generated by a generic application inside the UE, and forwarded by the local TCP/IP stack to the LteUeNetDevice of the UE. The LteUeNetDevice then performs the following operations: @@ -373,7 +373,7 @@ UE. The LteUeNetDevice then performs the following operations: the entry point of the LTE Radio Protocol stack for this packet; #. it sends the packet to the eNB over the LTE Radio Protocol stack. -The eNB the receives the packet via its LteEnbNetDevice. Since there is a +The eNB receives the packet via its LteEnbNetDevice. Since there is a single PDCP and RLC protocol instance for each Radio Bearer, the LteEnbNetDevice is able to determine the RBID of the packet. This RBID is then recorded onto an LteRadioBearerTag, which is added to the @@ -515,7 +515,7 @@ in the downlink direction, the scheduler has to fill some specific fields of the DCI structure with all the information, such as: the Modulation and Coding Scheme (MCS) to be used, the MAC Transport Block (TB) size, and the allocation bitmap which identifies which RBs will contain the data -tranmitted by the eNB to each user. +transmitted by the eNB to each user. For the mapping of resources to physical RBs, we adopt a *localized mapping* approach @@ -563,7 +563,7 @@ the corresponding MCS scheme. The spectral efficiency is quantized based on the CQI (rounding to the lowest value) and is mapped to the corresponding MCS scheme. -Finally, wenote that there are some discrepancies between the MCS index +Finally, we note that there are some discrepancies between the MCS index in [R1-081483]_ and that indicated by the standard: [TS36.213]_ Table 7.1.7.1-1 says that the MCS index goes from 0 to 31, and 0 appears to be a valid @@ -1122,7 +1122,7 @@ 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 pair :math:`(f_c,B)` used in the simulation we define a corresponding spectrum -model using the Spectrum framework framework described +model using the Spectrum framework described in [Baldo2009]_. :math:`f_c` and :math:`B` can be configured for every eNB instantiated in the simulation; hence, each eNB can use a different spectrum model. Every UE will automatically use the spectrum model of the eNB it is attached to. Using @@ -1253,7 +1253,7 @@ Helpers ------- Two helper objects are use to setup simulations and configure the -variosu components. These objects are: +various components. These objects are: * LteHelper, which takes care of the configuration of the LTE radio diff --git a/src/lte/doc/source/lte-user.rst b/src/lte/doc/source/lte-user.rst index 80d5015e4..9ea7f75ea 100644 --- a/src/lte/doc/source/lte-user.rst +++ b/src/lte/doc/source/lte-user.rst @@ -301,7 +301,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: - * ``fc`` : the frequency in use (it affects the computation of the dopples speed). + * ``fc`` : the frequency in use (it affects the computation of the doppler speed). * ``v_km_h`` : the speed of the users * ``traceDuration`` : the duration in seconds of the total length of the trace. * ``numRBs`` : the number of the resource block to be evaluated. @@ -322,7 +322,7 @@ The parameters to be configured are: * ``SamplesNum`` : the number of samples; * ``WindowSize`` : the size of the fading sampling window in seconds; -It is important to highlight that the sampling interval of the fading trace has to me at most of 1 ms or greater and in the latter case it has to be an integer multiple of 1 ms in order to be correctly processed by the fading module. +It is important to highlight that the sampling interval of the fading trace has to be 1 ms or greater, and in the latter case it has to be an integer multiple of 1 ms in order to be correctly processed by the fading module. The default configuration of the matlab script provides a trace 10 seconds long, made of 10,000 samples (i.e., 1 sample per TTI=1ms) and used with a windows size of 0.5 seconds amplitude. These are also the default values of the parameters above used in the simulator; therefore their settage can be avoided in case the fading trace respects them.