--- a/doc/models/Makefile Thu May 19 17:29:28 2011 +0200
+++ b/doc/models/Makefile Thu May 19 17:40:40 2011 +0200
@@ -29,10 +29,10 @@
$(SRC)/emu/doc/emu.rst \
$(SRC)/tap-bridge/doc/tap.rst \
$(SRC)/mesh/doc/mesh.rst \
- $(SRC)/lte/doc/lte.rst \
- $(SRC)/lte/doc/lte-user.rst \
- $(SRC)/lte/doc/lte-design.rst \
- $(SRC)/lte/doc/lte-testing.rst \
+ $(SRC)/lte/doc/source/lte.rst \
+ $(SRC)/lte/doc/source/lte-user.rst \
+ $(SRC)/lte/doc/source/lte-design.rst \
+ $(SRC)/lte/doc/source/lte-testing.rst \
$(SRC)/propagation/doc/propagation.rst \
$(SRC)/network/doc/network-overview.rst \
$(SRC)/network/doc/packets.rst \
@@ -68,10 +68,10 @@
$(SRC)/wifi/doc/WifiArchitecture.dia \
$(SRC)/wifi/doc/snir.dia \
$(SRC)/wimax/doc/WimaxArchitecture.dia \
- $(SRC)/lte/doc/ff-mac-saps.dia \
- $(SRC)/lte/doc/ff-example.dia \
- $(SRC)/lte/doc/lte-enb-architecture.dia \
- $(SRC)/lte/doc/lte-ue-architecture.dia \
+ $(SRC)/lte/doc/source/figures/ff-mac-saps.dia \
+ $(SRC)/lte/doc/source/figures/ff-example.dia \
+ $(SRC)/lte/doc/source/figures/lte-enb-architecture.dia \
+ $(SRC)/lte/doc/source/figures/lte-ue-architecture.dia \
$(SRC)/uan/doc/auvmobility-classes.dia \
$(SRC)/netanim/doc/animation-dumbbell.png \
$(SRC)/netanim/doc/animation-dumbbell.pdf \
--- a/src/lte/doc/ff-api.rst Thu May 19 17:29:28 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,63 +0,0 @@
-.. include:: replace.txt
-
-.. _ff-mac-sched-api:
-
-FemtoForum MAC Scheduler Interface
-----------------------------------
-
-This section describes the ns-3 specific version of the `FemtoForum LTE MAC Scheduler Interface Specification v1.11 <http://www.femtoforum.org/femto/technical.php>`_
-
-The goals of the definition of this MAC scheduler API in the |ns3| network simulator are:
-
-* to let MAC's developers to implement its own MAC schedulers allowing these developers to provide the standard MAC scheduler API.
-* to let MAC's users to use different MAC schedulers using always the same standard MAC scheduler API.
-
-Design
-******
-
-The MAC Scheduler interface is **specified** or defined as **abstract classes**. The MAC Scheduler interface is **implemented** as **derived classes** from the abstract classes. We have splitted the MAC Scheduler interface into 4 abstract classes:
-
-* SCHED SAP API
-
- * Provider Side is specified in the ``FfMacSchedSapProvider`` class
- * User Side is specified in the ``FfMacSchedSapUser`` class
-
-* CSCHED SAP API
-
- * Provider Side is specified in the ``FfMacCschedSapProvider`` class
- * User Side is specified in the ``FfMacCschedSapUser`` class
-
-Blocks
-######
-
-There are 3 blocks involved in the MAC Scheduler interface: Control block, Subframe block and Scheduler block. Each of these blocks provide one part of the MAC Scheduler interface. The following figure shows the relationship between the blocks and the Service Access Points they provide.
-
-.. figure:: figures/ff-mac-saps.png
-
-Implementation details
-**********************
-
-This subsection details the criteria adopted during the development of the FF MAC API:
-
-* The definition of the MAC Scheduler interface follows the naming conventions of the |ns3| Coding Style. In particular, we follow the CamelCase convention for the primitive names. For example, the primitive **CSCHED_CELL_CONFIG_REG** is translated to ``CschedCellConfigReg`` in the |ns3| code.
-
-* The same naming conventions are followed for the primitive parameters. As the primitive parameters are member variables of classes, they are also prefixed with a ``m_``.
-
-* FF MAC API is a C-based oriented API but |ns3| network simulator is written in C++. So, STL vectors (``std::vector``) are used, instead of using C arrays as the FF MAC API document suggests.
-
-* In C++, members with constructors and destructors are not allow in ``unions``. These ``unions`` have been converted to ``structs``.
-
-
-
-Usage in the ns-3 LTE module
-****************************
-
-The files ``rr-ff-mac-scheduler.{cc,h}`` implement a Round Robin MAC scheduler. To interact with the MAC of the eNB, the Round Robin scheduler implements the Provider side of the SCHED SAP and CSCHED SAP interface. If you plan to develop your own scheduler, we advise to create your own class taking inspiration from the Round Robin scheduler.
-
-
-The User side of both the CSCHED SAP and the SCHED SAP are implemented in the file ``lte-enb-mac.cc``. You are normally not expected to modify these files in order to implement your own scheduler.
-
-
-.. figure:: figures/ff-example.png
-
-
Binary file src/lte/doc/ff-example.dia has changed
Binary file src/lte/doc/ff-mac-saps.dia has changed
--- a/src/lte/doc/lte-design.rst Thu May 19 17:29:28 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,149 +0,0 @@
-.. include:: replace.txt
-
-
-++++++++++++++++++++++++++
- LTE Design Documentation
-++++++++++++++++++++++++++
-
-
-An overview of the LTE module
-*****************************
-
-
-Design Criteria
-~~~~~~~~~~~~~~~
-
-The LTE module has the long term objective of supporting the evaluation of the following aspects of LTE systems:
-
-* LTE Radio Resource Management
-* QoS-aware Packet Scheduling
-* Call Admission Control
-* Inter-cell Interference Coordination
-* Load Balancing
-* Mobility
-
-
-In order to model LTE systems to a level of detail that is sufficient to allow a correct evaluation of the above mentioned aspects, the following assumptions have been made:
-
-#. At the radio level, the granularity of the model should be at least that of the Resource Block. In fact, this is the fundamental unit being used for resource allocation. Without this minimum level of granularity, it is not possible to model accurately, for example, packet scheduling and inter-cell-interference solutions. Note that this design choice rules out system level simulator, which work at the granularity of call / bearer establishment.
-#. The simulator should scale up to tens of eNBs and hundreds of UEs. This rules out the use of a link level simulator, i.e., a simulator whose radio interface is modeled with a granularity up to the symbol level. This is becaise a symbol layer model needs to implement all the PHY layer signal processing, whose huge complexity severely limits scalability in terms of number of eNBs and UEs. In fact, link-level simulators are normally limited to a single eNB and one or a few UEs.
-#. MAC-level KPIs (e.g., per-UE and per-bearer throughput, delay and loss rate measured at the RLC PDU level) are probably the most straightforward KPIs that can be extracted by the simulator. Still, these KPIs cannot be mapped directly to the Quality of Experience (QoE) perceived by the end user, at least without some gross approximation. Hence, to allow a proper evaluation of the QoE, the LTE user plane protocol stack should be modeled accurately. In particular, the RLC protocol should be modeled: in fact, since the RLC takes care of fragmentation, concatenation & fragment retransmission of user-plane IP packets, it
-#. While it is acceptable to idealize some aspects of the control plane for ease of simulations, there are some other aspects that need to be modeled in order to obtain accurate simulation results. For example, control signaling consumes radio resources and can be the cause of a limitation in the user-perceived performance; furthermore, the correct or erroneous reception of the control signalling affects important aspects of LTE such as cell selection by the UEs and the neighbor relation function of the eNBs.
-
-
-Module Architecture
-~~~~~~~~~~~~~~~~~~~
-
-
-The overall architecture of the LTE module is represented in the following figures.
-
-.. figure:: figures/lte-enb-architecture.*
- :align: right
-
- The architecture of the LTE eNB
-
-.. figure:: figures/lte-ue-architecture.*
- :align: right
-
- The architecture of the LTE UE
-
-
-
-Detailed description of the components
-**************************************
-
-LTE Spectrum Model
-~~~~~~~~~~~~~~~~~~
-
-Based on the Spectrum
-
-
-
-
-Radio Resource Management and Packet Scheduling
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For how the ns-3 LTE module handles Radio Resource Management and Packet Scheduling at the eNB, please see the :ref:`ff-mac-sched-api`.
-
-
-Physical layer
-~~~~~~~~~~~~~~
-
-The `ns3::LtePhy` class models the LTE PHY layer.
-
-Basic functionalities of the PHY layer are: (i) transmit packets coming from the device to the channel; (ii) receive packets from the channel; (ii) evaluate the quality of the channel from the Signal To Noise ratio of the received signal; and (iii) forward received packets to the device.
-
-Both the PHY and channel have been developed extending `ns3::SpectrumPhy` and
-`ns3::SpectrumChannel` classes, respectively, which are provided by the Spectrum Framework [1]_.
-
-The module implements an FDD channel access. In FDD channel access, downlink and uplink
-transmissions work together in the time but using a different set of frequencies.
-Since DL and UL are indipendent between them, the PHY is composed by couple of
-`ns3::LteSpectrumPhy` object, one for the downlink and one for the uplink.
-The `ns3::LtePhy` stores and manages both downlink and uplink
-`ns3::LteSpectrumPhy` elements.
-
-In order to customize all physical functionalities for both UE and eNB devices, dedicated
-classes have been inherited from ones described before. In particular,
-`ns3::LteUePhy` and `ns3::LteEnbPhy` classes, inherited from
-the `ns3::LtePhy` class, implement the PHY layer for the UE and the
-eNB, respectively.
-
-The figure below shows how UE and eNB can exchange packets through the considered PHY layer.
-
-
-For the downlink, when the eNB whants to send packets, it calls the ``StartTx`` function to
-send them into the downlink channel. Then, the downlink channel delivers the burst
-of packets to all the `ns3::UeLteSpectrumPhy` attached to it, handling the
-``StartRx`` function.
-When the UE receives packets, it executes the following tasks:
-
-* compute the SINR for all the sub channel used in the downlink
-
-* create and send CQI feedbacks
-
-* forward all the received packets to the MAC layer through the PHY SAP.
-
-The uplink works similary.
-
-Propagation Loss Models
-~~~~~~~~~~~~~~~~~~~~~~~
-
-A proper propagation loss model has been developed for the LTE E-UTRAN interface (see [2]_ and [3]_).
-It is used by the PHY layer to compute the loss due to the propagation.
-
-The LTE propagation loss model is composed by 4 different models (shadowing, multipath,
-penetration loss and path loss) [2]_:
-
-* Pathloss: :math:`PL = 128.1 + (37.6 * log10 (R))`, where R is the distance between the
- UE and the eNB in Km.
-
-* Multipath: Jakes model
-
-* PenetrationLoss: 10 dB
-
-* Shadowing: log-normal distribution (mean=0dB, standard deviation=8dB)
-
-Every time that the ``LteSpectrumPHY::StartRx ()`` function is called, the
-``SpectrumInterferenceModel`` is used to computed the SINR, as proposed in [3]_. Then,
-the network device uses the AMC module to map the SINR to a proper CQI and to send it
-to the eNB using the ideal control channel.
-
-
-References
-----------
-
-.. [1] N. Baldo and M. Miozzo, Spectrum-aware Channel and PHY layer modeling for ns3, Proceedings
- of ICST NSTools 2009, Pisa, Italy. The framework is designed to simulate only data
- transmissions. For the transmission of control messages (such as CQI feedback, PDCCH,
- etc..) will be used an ideal control channel).
-
-.. [2] 3GPP TS 25.814 ( http://www.3gpp.org/ftp/specs/html-INFO/25814.htm )
-
-.. [3] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, and Pietro Camarda", A Two-level
- Scheduling Algorithm for QoS Support in the Downlink of LTE Cellular Networks", Proc. of
- European Wireless, EW2010, Lucca, Italy, Apr., 2010 ( draft version is available on
- http://telematics.poliba.it/index.php?option=com_jombib&task=showbib&id=330 )
-
-.. [4] 3GPP R1-081483 (available on
- http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip )
Binary file src/lte/doc/lte-enb-architecture.dia has changed
--- a/src/lte/doc/lte-testing.rst Thu May 19 17:29:28 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,154 +0,0 @@
-.. include:: replace.txt
-
-
-+++++++++++++++++++++++++++
- LTE Testing Documentation
-+++++++++++++++++++++++++++
-
-
-Overview
-********
-
-To test and validate the ns-3 LTE module, several test suites are provided which are integrated with the ns-3 test framework.
-To run them, you need to have configured the build of the simulator in this way::
-
- ./waf configure --enable-tests --enable-modules=lte --enable-examples
- ./test.py
-
-The above will run not only the test suites belonging to the LTE module, but also those belonging to all the other ns-3 modules on which the LTE module depends. See the ns-3 manual for generic information on the testing framework.
-
-You can get a more detailed report in HTML format in this way::
-
- ./test.py -w results.html
-
-After the above command has run, you can view the detailed result for each test by opening the file ``results.html`` with a web browser.
-
-You can run each test suite separately using this command::
-
- ./test.py -s test-suite-name
-
-For more details about ``test.py`` and the ns-3 testing framework, please refer to the ns-3 manual.
-
-
-
-Description of the test suites
-******************************
-
-Unit Tests
-~~~~~~~~~~
-
-SINR calculation in the Downlink
---------------------------------
-
-The test suite ``lte-downlink-sinr`` checks that the SINR calculation in downlink is performed correctly. The SINR in the downlink is calculated for each Resource Block assigned to data transmissions by dividing the power of the intended signal from the considered eNB by the sum of the noise power plus all the transmissions on the same RB coming from other eNBs (the interference signals).
-
-.. math::
-
- \gamma = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} }
-
-In general, different signals can be active during different periods of time. We define a *chunk* as the time interval between any two events of type either start or end of a waveform. In other words, a chunk identifies a time interval during which the set of active waveforms does not change. Let :math:`i` be the generic chunk, :math:`T_i` its duration and :math:`\mathrm{SINR_i}` its SINR, calculated with the above equation. The calculation of the average SINR :math:`\overline{\gamma}` to be used for CQI feedback reporting uses the following formula:
-
-.. math::
-
- \overline{\gamma} = \frac{ \sum_i {\gamma}_i T_i }{ \sum_i T_{i} }
-
-The test suite checks that the above calculation is performed correctly in the simulator. The test vectors are obtained offline by an Octave script that implements the above equation, and that recreates a number of random transmitted signals and interference signals that mimic a scenario where an UE is trying to decode a signal from an eNB while facing interference from other eNBs. The test passes if the calculated values are equal to the test vector within a tolerance of :math:`10^{-7}`. The tolerance is meant to account for the approximation errors typical of floating point arithmetic.
-
-
-
-SINR calculation in the Uplink
-------------------------------
-
-The test suite ``lte-uplink-sinr`` checks that the SINR calculation in uplink is performed correctly. This test suite is identical to ``lte-downlink-sinr`` described in the previous section, with the difference than both the signal and the interference now refer to transmissions by the UEs, and reception is performed by the eNB.
-This test suite recreates a number of random transmitted signals and interference signals to mimic a scenario where an eNB is trying to decode the signal from several UEs simultaneously (the ones in the cell of the eNB) while facing interference from other UEs (the ones belonging to other cells).
-
-The test vectors are obtained by a dedicated Octave script. The test passes if the calculated values are equal to the test vector within a tolerance of :math:`10^{-7}` which, as for the downlink SINR test, deals with floating point arithmetic approximation issues.
-
-
-System Tests
-~~~~~~~~~~~~
-
-Adaptive Modulation and Coding
-------------------------------
-
-The test suite ``lte-link-adaptation`` provides system tests recreating a scenario with a single eNB and a single UE. Different test cases are created corresponding to different SINR values perceived by the UE. The aim of the test is to check that in each test case the chosen MCS corresponds to the values in a known test vector.
-
-The test vector is obtained with the model described in [Piro2011]_ which cites [Seo2004]_. Here we described how this model works. Let :math:`i` denote the generic user, and let :math:`\gamma_i` be its SINR. We get the spectral efficiency :math:`\eta_i` of user :math:`i` using the following equations:
-
-.. math::
-
- \mathrm{BER} = 0.00005
-
-.. math::
-
- \Gamma = \frac{ -\ln{ (5 * \mathrm{BER}) } }{ 1.5 }
-
-.. math::
-
- \eta_i = \log_2 { \left( 1 + \frac{ {\gamma}_i }{ \Gamma } \right) }
-
-Then, 3GPP [R1-081483]_ document (its XLS sheet annexed file) is used to get 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 (i.e. the MCS index that appears on the same line looking at the MCS table on the right). Note that the quantization of the CQI is coarser than the spectral efficiency reported in the CQI table.
-
-Finally, 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 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 test passes if both the following conditions are verified:
-
- #. the SINR calculated by the UE corresponds to the value intended for the given test case within a tolerance of :math:`10^{-7}`. The tolerance is meant to account for the approximation errors typical of floating point arithmetic. This test condition acts as a system test of the SINR calculation. This is needed because the other test suites that deal with the SINR calculation are unit tests, and hence might not be able to detect system-level bugs in the SINR calculation.
- #. the MCS index chosen by the scheduler matches exactly with the MCS index in the test vector, determined using the above described procedure.
-
-
-
-Round Robin scheduler performance
----------------------------------
-
-The test suite ``lte-rr-ff-mac-scheduler`` creates different test cases with a single eNB and several UEs, all having the same Radio Bearer specification. In each test case, the UEs see the same SINR from the eNB; different test cases are implemented by using different distance among UEs and the eNB (i.e., therefore having different SINR values) and different numbers of UEs. The test consists on checking that the obtained throughput performance is equal among users and 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 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 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 transport block size in bits as defined by 3GPP TS 36.213. We first calculate the number :math:`L` of RBGs allocated to each user as
-
-.. math::
-
- L = \left\lfloor \frac{B}{NG} \right\rfloor
-
-The reference throughput (in bytes per second) :math:`T` in bps achieved by each UE is then calculated as
-
-.. math::
-
- T = \frac{S(M, L G)}{8 \; \tau}
-
-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 (e.g., CQI feedback is only available after a few subframes) as well as for the accuracy of the estimator of the average throughput performance over the chosen simulation time (0.04s). We note that a lower value of the tolerance can be achieved by making each test case running longer simulations; we chose not to do this in order to keep the total execution time of this test suite as low as possible in spite of the high number of test cases.
-
-
-
-Proportional Fair scheduler performance
----------------------------------------
-
-The test suite ``lte-pf-ff-mac-scheduler`` creates different test cases with a single eNB, using the Proportional Fair (PF) scheduler, and several UEs, all having the same Radio Bearer specification. The test cases are grouped in two categories in order to evaluate both the performance in terms of adaptation to channel condition and from fairness perspective.
-
-In the first category of test cases, the UEs are all placed at the same distance from the eNB, and hence all placed in order to have the same SINR. Different test cases are implemented by using a different SINR value and a different number of UEs. The test consists on checking that the obtained throughput performance matches with the known reference throughput up to a given tolerance. The expected behavior of the PF scheduler when all UEs have the same SNR is that each UE should get an equal fraction of the throughput obtainable by a single UE when using all the resources. We calculate the reference throughput value by dividing the throughput achievable by a single UE 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 throughput :math:`T` achieved by each UE is calculated as
-
-.. math::
-
- T = \frac{S(M,B)}{\tau N}
-
-The second category of tests is aimed at verify the fairness behavior in presence of UEs with different SINRs (and therefore different estimated throughput from PFS). The test consists of checking whether the throughput obtained by each UE over the whole simulation matches with the steady-state throughput expected by the PF scheduler according to the theory (see for instance [Kushner2004]_).
-Let :math:`Ri` the estimation done by PFS of the throughput of the :math:`i` UE for the next TTI according to the CQIs received and :math:`Ti` the throughput preceived by the :math:`i` UE . The test verifies that the ratio of the obtained throughput value respect to the global one (i.e. the sum of the ones of all users) is equal to the steady-state throughput of the PFS, that is
-
-.. math::
-
- K = \frac{Ri}{\sum_{k=1}^N Ri} = \frac{Ti}{\sum_{k=1}^N Ti}
-
-The test passes if the measured throughput matches with the reference throughput within a relative tolerance of 0.1. The choice of this tolerance has the same motivations already discussed for the Round Robin scheduler test suite.
-
-References
-**********
-
-.. [TS36.213] 3GPP TS 36.213 "LTE Physical layer procedures"
-
-.. [Kushner2004] H.J. Kushner and P.A. Whiting, "Convergence of proportional-fair sharing algorithms under general conditions", IEEE Trans. on Wireless Communications, July 2004
-
-.. [Piro2011] G. Piro, N. Baldo. M. Miozzo, "An LTE module for the ns-3 network simulator", Wns3 2011
- (in conjunction with SimuTOOLS 2011), March 2011, Barcelona (Spain)
-
-.. [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)
-
-.. [R1-081483] 3GPP R1-081483 "Conveying MCS and TB size via PDCCH"
Binary file src/lte/doc/lte-transmission.pdf has changed
Binary file src/lte/doc/lte-transmission.png has changed
Binary file src/lte/doc/lte-ue-architecture.dia has changed
--- a/src/lte/doc/lte-user.rst Thu May 19 17:29:28 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,70 +0,0 @@
-.. include:: replace.txt
-
-
-+++++++++++++++++++++++++
- LTE User Documentation
-+++++++++++++++++++++++++
-
-EUTRA stack diagram
-*******************
-
-
-Usage
-*****
-
-Users interact with the LTE model through the LENA helper API and through the publicly visible methods of the model. The helper API is defined in ``src/lte/helper/lena-helper.h``.
-
-The ``src/lte/examples/`` directory contains some basic examples that shows how to set up the LTE model in order to simulate an EUTRA downlink transmission.
-
-Example simulation program
---------------------------
-
-``src/lte/examples/lena-first-sim.cc`` shows how to build a simple but complete simulation with one LTE eNB and one LTE UE. The detail explanation of the code follows:
-
-#. Declare the helper. This helper keeps together all the LTE components::
-
- LenaHelper lena;
-
-
-#. Enable the logs in the LTE components::
-
- lena.EnableLogComponents ();
-
-
-#. Create eNB and UE. They are created in its own node container::
-
- NodeContainer enbNodes;
- NodeContainer ueNodes;
- enbNodes.Create (1);
- ueNodes.Create (1);
-
-
-#. Install mobility models to eNB and UE. This has to be done before devices are created and installed::
-
- MobilityHelper mobility;
- mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
- mobility.Install (enbNodes);
- mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
- mobility.Install (ueNodes);
-
-
-#. Create devices and install them to the eNB and UE::
-
- NetDeviceContainer enbDevs;
- NetDeviceContainer ueDevs;
- enbDevs = lena.InstallEnbDevice (enbNodes);
- ueDevs = lena.InstallUeDevice (ueNodes);
-
-
-#. Attach a UE to a eNB. It will also create a RRC connection between them and configure the UE::
-
- lena.Attach (ueDevs, enbDevs.Get (0));
-
-
-#. Activate an EPS Bearer including the setup of the Radio Bearer between an eNB and its attached UE::
-
- enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
- EpsBearer bearer (q);
- lena.ActivateEpsBearer (ueDevs, bearer);
-
-
--- a/src/lte/doc/lte.rst Thu May 19 17:29:28 2011 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,20 +0,0 @@
-
-########################
-LTE Module
-########################
-
-
-This chapter describes the ns-3 LTE module located in ``src/lte``.
-
-
-
-.. toctree::
-
- lte-design
- ff-api
- lte-user
- lte-testing
-
-
-
-
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/lte/doc/source/ff-api.rst Thu May 19 17:40:40 2011 +0200
@@ -0,0 +1,63 @@
+.. include:: replace.txt
+
+.. _ff-mac-sched-api:
+
+FemtoForum MAC Scheduler Interface
+----------------------------------
+
+This section describes the ns-3 specific version of the `FemtoForum LTE MAC Scheduler Interface Specification v1.11 <http://www.femtoforum.org/femto/technical.php>`_
+
+The goals of the definition of this MAC scheduler API in the |ns3| network simulator are:
+
+* to let MAC's developers to implement its own MAC schedulers allowing these developers to provide the standard MAC scheduler API.
+* to let MAC's users to use different MAC schedulers using always the same standard MAC scheduler API.
+
+Design
+******
+
+The MAC Scheduler interface is **specified** or defined as **abstract classes**. The MAC Scheduler interface is **implemented** as **derived classes** from the abstract classes. We have splitted the MAC Scheduler interface into 4 abstract classes:
+
+* SCHED SAP API
+
+ * Provider Side is specified in the ``FfMacSchedSapProvider`` class
+ * User Side is specified in the ``FfMacSchedSapUser`` class
+
+* CSCHED SAP API
+
+ * Provider Side is specified in the ``FfMacCschedSapProvider`` class
+ * User Side is specified in the ``FfMacCschedSapUser`` class
+
+Blocks
+######
+
+There are 3 blocks involved in the MAC Scheduler interface: Control block, Subframe block and Scheduler block. Each of these blocks provide one part of the MAC Scheduler interface. The following figure shows the relationship between the blocks and the Service Access Points they provide.
+
+.. figure:: figures/ff-mac-saps.png
+
+Implementation details
+**********************
+
+This subsection details the criteria adopted during the development of the FF MAC API:
+
+* The definition of the MAC Scheduler interface follows the naming conventions of the |ns3| Coding Style. In particular, we follow the CamelCase convention for the primitive names. For example, the primitive **CSCHED_CELL_CONFIG_REG** is translated to ``CschedCellConfigReg`` in the |ns3| code.
+
+* The same naming conventions are followed for the primitive parameters. As the primitive parameters are member variables of classes, they are also prefixed with a ``m_``.
+
+* FF MAC API is a C-based oriented API but |ns3| network simulator is written in C++. So, STL vectors (``std::vector``) are used, instead of using C arrays as the FF MAC API document suggests.
+
+* In C++, members with constructors and destructors are not allow in ``unions``. These ``unions`` have been converted to ``structs``.
+
+
+
+Usage in the ns-3 LTE module
+****************************
+
+The files ``rr-ff-mac-scheduler.{cc,h}`` implement a Round Robin MAC scheduler. To interact with the MAC of the eNB, the Round Robin scheduler implements the Provider side of the SCHED SAP and CSCHED SAP interface. If you plan to develop your own scheduler, we advise to create your own class taking inspiration from the Round Robin scheduler.
+
+
+The User side of both the CSCHED SAP and the SCHED SAP are implemented in the file ``lte-enb-mac.cc``. You are normally not expected to modify these files in order to implement your own scheduler.
+
+
+.. figure:: figures/ff-example.png
+
+
Binary file src/lte/doc/source/figures/ff-example.dia has changed
Binary file src/lte/doc/source/figures/ff-mac-saps.dia has changed
Binary file src/lte/doc/source/figures/lte-enb-architecture.dia has changed
Binary file src/lte/doc/source/figures/lte-ue-architecture.dia has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/lte/doc/source/lte-design.rst Thu May 19 17:40:40 2011 +0200
@@ -0,0 +1,149 @@
+.. include:: replace.txt
+
+
+++++++++++++++++++++++++++
+ LTE Design Documentation
+++++++++++++++++++++++++++
+
+
+An overview of the LTE module
+*****************************
+
+
+Design Criteria
+~~~~~~~~~~~~~~~
+
+The LTE module has the long term objective of supporting the evaluation of the following aspects of LTE systems:
+
+* LTE Radio Resource Management
+* QoS-aware Packet Scheduling
+* Call Admission Control
+* Inter-cell Interference Coordination
+* Load Balancing
+* Mobility
+
+
+In order to model LTE systems to a level of detail that is sufficient to allow a correct evaluation of the above mentioned aspects, the following assumptions have been made:
+
+#. At the radio level, the granularity of the model should be at least that of the Resource Block. In fact, this is the fundamental unit being used for resource allocation. Without this minimum level of granularity, it is not possible to model accurately, for example, packet scheduling and inter-cell-interference solutions. Note that this design choice rules out system level simulator, which work at the granularity of call / bearer establishment.
+#. The simulator should scale up to tens of eNBs and hundreds of UEs. This rules out the use of a link level simulator, i.e., a simulator whose radio interface is modeled with a granularity up to the symbol level. This is becaise a symbol layer model needs to implement all the PHY layer signal processing, whose huge complexity severely limits scalability in terms of number of eNBs and UEs. In fact, link-level simulators are normally limited to a single eNB and one or a few UEs.
+#. MAC-level KPIs (e.g., per-UE and per-bearer throughput, delay and loss rate measured at the RLC PDU level) are probably the most straightforward KPIs that can be extracted by the simulator. Still, these KPIs cannot be mapped directly to the Quality of Experience (QoE) perceived by the end user, at least without some gross approximation. Hence, to allow a proper evaluation of the QoE, the LTE user plane protocol stack should be modeled accurately. In particular, the RLC protocol should be modeled: in fact, since the RLC takes care of fragmentation, concatenation & fragment retransmission of user-plane IP packets, it
+#. While it is acceptable to idealize some aspects of the control plane for ease of simulations, there are some other aspects that need to be modeled in order to obtain accurate simulation results. For example, control signaling consumes radio resources and can be the cause of a limitation in the user-perceived performance; furthermore, the correct or erroneous reception of the control signalling affects important aspects of LTE such as cell selection by the UEs and the neighbor relation function of the eNBs.
+
+
+Module Architecture
+~~~~~~~~~~~~~~~~~~~
+
+
+The overall architecture of the LTE module is represented in the following figures.
+
+.. figure:: figures/lte-enb-architecture.*
+ :align: right
+
+ The architecture of the LTE eNB
+
+.. figure:: figures/lte-ue-architecture.*
+ :align: right
+
+ The architecture of the LTE UE
+
+
+
+Detailed description of the components
+**************************************
+
+LTE Spectrum Model
+~~~~~~~~~~~~~~~~~~
+
+Based on the Spectrum
+
+
+
+
+Radio Resource Management and Packet Scheduling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For how the ns-3 LTE module handles Radio Resource Management and Packet Scheduling at the eNB, please see the :ref:`ff-mac-sched-api`.
+
+
+Physical layer
+~~~~~~~~~~~~~~
+
+The `ns3::LtePhy` class models the LTE PHY layer.
+
+Basic functionalities of the PHY layer are: (i) transmit packets coming from the device to the channel; (ii) receive packets from the channel; (ii) evaluate the quality of the channel from the Signal To Noise ratio of the received signal; and (iii) forward received packets to the device.
+
+Both the PHY and channel have been developed extending `ns3::SpectrumPhy` and
+`ns3::SpectrumChannel` classes, respectively, which are provided by the Spectrum Framework [1]_.
+
+The module implements an FDD channel access. In FDD channel access, downlink and uplink
+transmissions work together in the time but using a different set of frequencies.
+Since DL and UL are indipendent between them, the PHY is composed by couple of
+`ns3::LteSpectrumPhy` object, one for the downlink and one for the uplink.
+The `ns3::LtePhy` stores and manages both downlink and uplink
+`ns3::LteSpectrumPhy` elements.
+
+In order to customize all physical functionalities for both UE and eNB devices, dedicated
+classes have been inherited from ones described before. In particular,
+`ns3::LteUePhy` and `ns3::LteEnbPhy` classes, inherited from
+the `ns3::LtePhy` class, implement the PHY layer for the UE and the
+eNB, respectively.
+
+The figure below shows how UE and eNB can exchange packets through the considered PHY layer.
+
+
+For the downlink, when the eNB whants to send packets, it calls the ``StartTx`` function to
+send them into the downlink channel. Then, the downlink channel delivers the burst
+of packets to all the `ns3::UeLteSpectrumPhy` attached to it, handling the
+``StartRx`` function.
+When the UE receives packets, it executes the following tasks:
+
+* compute the SINR for all the sub channel used in the downlink
+
+* create and send CQI feedbacks
+
+* forward all the received packets to the MAC layer through the PHY SAP.
+
+The uplink works similary.
+
+Propagation Loss Models
+~~~~~~~~~~~~~~~~~~~~~~~
+
+A proper propagation loss model has been developed for the LTE E-UTRAN interface (see [2]_ and [3]_).
+It is used by the PHY layer to compute the loss due to the propagation.
+
+The LTE propagation loss model is composed by 4 different models (shadowing, multipath,
+penetration loss and path loss) [2]_:
+
+* Pathloss: :math:`PL = 128.1 + (37.6 * log10 (R))`, where R is the distance between the
+ UE and the eNB in Km.
+
+* Multipath: Jakes model
+
+* PenetrationLoss: 10 dB
+
+* Shadowing: log-normal distribution (mean=0dB, standard deviation=8dB)
+
+Every time that the ``LteSpectrumPHY::StartRx ()`` function is called, the
+``SpectrumInterferenceModel`` is used to computed the SINR, as proposed in [3]_. Then,
+the network device uses the AMC module to map the SINR to a proper CQI and to send it
+to the eNB using the ideal control channel.
+
+
+References
+----------
+
+.. [1] N. Baldo and M. Miozzo, Spectrum-aware Channel and PHY layer modeling for ns3, Proceedings
+ of ICST NSTools 2009, Pisa, Italy. The framework is designed to simulate only data
+ transmissions. For the transmission of control messages (such as CQI feedback, PDCCH,
+ etc..) will be used an ideal control channel).
+
+.. [2] 3GPP TS 25.814 ( http://www.3gpp.org/ftp/specs/html-INFO/25814.htm )
+
+.. [3] Giuseppe Piro, Luigi Alfredo Grieco, Gennaro Boggia, and Pietro Camarda", A Two-level
+ Scheduling Algorithm for QoS Support in the Downlink of LTE Cellular Networks", Proc. of
+ European Wireless, EW2010, Lucca, Italy, Apr., 2010 ( draft version is available on
+ http://telematics.poliba.it/index.php?option=com_jombib&task=showbib&id=330 )
+
+.. [4] 3GPP R1-081483 (available on
+ http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_52b/Docs/R1-081483.zip )
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/lte/doc/source/lte-testing.rst Thu May 19 17:40:40 2011 +0200
@@ -0,0 +1,154 @@
+.. include:: replace.txt
+
+
++++++++++++++++++++++++++++
+ LTE Testing Documentation
++++++++++++++++++++++++++++
+
+
+Overview
+********
+
+To test and validate the ns-3 LTE module, several test suites are provided which are integrated with the ns-3 test framework.
+To run them, you need to have configured the build of the simulator in this way::
+
+ ./waf configure --enable-tests --enable-modules=lte --enable-examples
+ ./test.py
+
+The above will run not only the test suites belonging to the LTE module, but also those belonging to all the other ns-3 modules on which the LTE module depends. See the ns-3 manual for generic information on the testing framework.
+
+You can get a more detailed report in HTML format in this way::
+
+ ./test.py -w results.html
+
+After the above command has run, you can view the detailed result for each test by opening the file ``results.html`` with a web browser.
+
+You can run each test suite separately using this command::
+
+ ./test.py -s test-suite-name
+
+For more details about ``test.py`` and the ns-3 testing framework, please refer to the ns-3 manual.
+
+
+
+Description of the test suites
+******************************
+
+Unit Tests
+~~~~~~~~~~
+
+SINR calculation in the Downlink
+--------------------------------
+
+The test suite ``lte-downlink-sinr`` checks that the SINR calculation in downlink is performed correctly. The SINR in the downlink is calculated for each Resource Block assigned to data transmissions by dividing the power of the intended signal from the considered eNB by the sum of the noise power plus all the transmissions on the same RB coming from other eNBs (the interference signals).
+
+.. math::
+
+ \gamma = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} }
+
+In general, different signals can be active during different periods of time. We define a *chunk* as the time interval between any two events of type either start or end of a waveform. In other words, a chunk identifies a time interval during which the set of active waveforms does not change. Let :math:`i` be the generic chunk, :math:`T_i` its duration and :math:`\mathrm{SINR_i}` its SINR, calculated with the above equation. The calculation of the average SINR :math:`\overline{\gamma}` to be used for CQI feedback reporting uses the following formula:
+
+.. math::
+
+ \overline{\gamma} = \frac{ \sum_i {\gamma}_i T_i }{ \sum_i T_{i} }
+
+The test suite checks that the above calculation is performed correctly in the simulator. The test vectors are obtained offline by an Octave script that implements the above equation, and that recreates a number of random transmitted signals and interference signals that mimic a scenario where an UE is trying to decode a signal from an eNB while facing interference from other eNBs. The test passes if the calculated values are equal to the test vector within a tolerance of :math:`10^{-7}`. The tolerance is meant to account for the approximation errors typical of floating point arithmetic.
+
+
+
+SINR calculation in the Uplink
+------------------------------
+
+The test suite ``lte-uplink-sinr`` checks that the SINR calculation in uplink is performed correctly. This test suite is identical to ``lte-downlink-sinr`` described in the previous section, with the difference than both the signal and the interference now refer to transmissions by the UEs, and reception is performed by the eNB.
+This test suite recreates a number of random transmitted signals and interference signals to mimic a scenario where an eNB is trying to decode the signal from several UEs simultaneously (the ones in the cell of the eNB) while facing interference from other UEs (the ones belonging to other cells).
+
+The test vectors are obtained by a dedicated Octave script. The test passes if the calculated values are equal to the test vector within a tolerance of :math:`10^{-7}` which, as for the downlink SINR test, deals with floating point arithmetic approximation issues.
+
+
+System Tests
+~~~~~~~~~~~~
+
+Adaptive Modulation and Coding
+------------------------------
+
+The test suite ``lte-link-adaptation`` provides system tests recreating a scenario with a single eNB and a single UE. Different test cases are created corresponding to different SINR values perceived by the UE. The aim of the test is to check that in each test case the chosen MCS corresponds to the values in a known test vector.
+
+The test vector is obtained with the model described in [Piro2011]_ which cites [Seo2004]_. Here we described how this model works. Let :math:`i` denote the generic user, and let :math:`\gamma_i` be its SINR. We get the spectral efficiency :math:`\eta_i` of user :math:`i` using the following equations:
+
+.. math::
+
+ \mathrm{BER} = 0.00005
+
+.. math::
+
+ \Gamma = \frac{ -\ln{ (5 * \mathrm{BER}) } }{ 1.5 }
+
+.. math::
+
+ \eta_i = \log_2 { \left( 1 + \frac{ {\gamma}_i }{ \Gamma } \right) }
+
+Then, 3GPP [R1-081483]_ document (its XLS sheet annexed file) is used to get 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 (i.e. the MCS index that appears on the same line looking at the MCS table on the right). Note that the quantization of the CQI is coarser than the spectral efficiency reported in the CQI table.
+
+Finally, 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 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 test passes if both the following conditions are verified:
+
+ #. the SINR calculated by the UE corresponds to the value intended for the given test case within a tolerance of :math:`10^{-7}`. The tolerance is meant to account for the approximation errors typical of floating point arithmetic. This test condition acts as a system test of the SINR calculation. This is needed because the other test suites that deal with the SINR calculation are unit tests, and hence might not be able to detect system-level bugs in the SINR calculation.
+ #. the MCS index chosen by the scheduler matches exactly with the MCS index in the test vector, determined using the above described procedure.
+
+
+
+Round Robin scheduler performance
+---------------------------------
+
+The test suite ``lte-rr-ff-mac-scheduler`` creates different test cases with a single eNB and several UEs, all having the same Radio Bearer specification. In each test case, the UEs see the same SINR from the eNB; different test cases are implemented by using different distance among UEs and the eNB (i.e., therefore having different SINR values) and different numbers of UEs. The test consists on checking that the obtained throughput performance is equal among users and 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 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 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 transport block size in bits as defined by 3GPP TS 36.213. We first calculate the number :math:`L` of RBGs allocated to each user as
+
+.. math::
+
+ L = \left\lfloor \frac{B}{NG} \right\rfloor
+
+The reference throughput (in bytes per second) :math:`T` in bps achieved by each UE is then calculated as
+
+.. math::
+
+ T = \frac{S(M, L G)}{8 \; \tau}
+
+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 (e.g., CQI feedback is only available after a few subframes) as well as for the accuracy of the estimator of the average throughput performance over the chosen simulation time (0.04s). We note that a lower value of the tolerance can be achieved by making each test case running longer simulations; we chose not to do this in order to keep the total execution time of this test suite as low as possible in spite of the high number of test cases.
+
+
+
+Proportional Fair scheduler performance
+---------------------------------------
+
+The test suite ``lte-pf-ff-mac-scheduler`` creates different test cases with a single eNB, using the Proportional Fair (PF) scheduler, and several UEs, all having the same Radio Bearer specification. The test cases are grouped in two categories in order to evaluate both the performance in terms of adaptation to channel condition and from fairness perspective.
+
+In the first category of test cases, the UEs are all placed at the same distance from the eNB, and hence all placed in order to have the same SINR. Different test cases are implemented by using a different SINR value and a different number of UEs. The test consists on checking that the obtained throughput performance matches with the known reference throughput up to a given tolerance. The expected behavior of the PF scheduler when all UEs have the same SNR is that each UE should get an equal fraction of the throughput obtainable by a single UE when using all the resources. We calculate the reference throughput value by dividing the throughput achievable by a single UE 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 throughput :math:`T` achieved by each UE is calculated as
+
+.. math::
+
+ T = \frac{S(M,B)}{\tau N}
+
+The second category of tests is aimed at verify the fairness behavior in presence of UEs with different SINRs (and therefore different estimated throughput from PFS). The test consists of checking whether the throughput obtained by each UE over the whole simulation matches with the steady-state throughput expected by the PF scheduler according to the theory (see for instance [Kushner2004]_).
+Let :math:`Ri` the estimation done by PFS of the throughput of the :math:`i` UE for the next TTI according to the CQIs received and :math:`Ti` the throughput preceived by the :math:`i` UE . The test verifies that the ratio of the obtained throughput value respect to the global one (i.e. the sum of the ones of all users) is equal to the steady-state throughput of the PFS, that is
+
+.. math::
+
+ K = \frac{Ri}{\sum_{k=1}^N Ri} = \frac{Ti}{\sum_{k=1}^N Ti}
+
+The test passes if the measured throughput matches with the reference throughput within a relative tolerance of 0.1. The choice of this tolerance has the same motivations already discussed for the Round Robin scheduler test suite.
+
+References
+**********
+
+.. [TS36.213] 3GPP TS 36.213 "LTE Physical layer procedures"
+
+.. [Kushner2004] H.J. Kushner and P.A. Whiting, "Convergence of proportional-fair sharing algorithms under general conditions", IEEE Trans. on Wireless Communications, July 2004
+
+.. [Piro2011] G. Piro, N. Baldo. M. Miozzo, "An LTE module for the ns-3 network simulator", Wns3 2011
+ (in conjunction with SimuTOOLS 2011), March 2011, Barcelona (Spain)
+
+.. [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)
+
+.. [R1-081483] 3GPP R1-081483 "Conveying MCS and TB size via PDCCH"
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/lte/doc/source/lte-user.rst Thu May 19 17:40:40 2011 +0200
@@ -0,0 +1,70 @@
+.. include:: replace.txt
+
+
++++++++++++++++++++++++++
+ LTE User Documentation
++++++++++++++++++++++++++
+
+EUTRA stack diagram
+*******************
+
+
+Usage
+*****
+
+Users interact with the LTE model through the LENA helper API and through the publicly visible methods of the model. The helper API is defined in ``src/lte/helper/lena-helper.h``.
+
+The ``src/lte/examples/`` directory contains some basic examples that shows how to set up the LTE model in order to simulate an EUTRA downlink transmission.
+
+Example simulation program
+--------------------------
+
+``src/lte/examples/lena-first-sim.cc`` shows how to build a simple but complete simulation with one LTE eNB and one LTE UE. The detail explanation of the code follows:
+
+#. Declare the helper. This helper keeps together all the LTE components::
+
+ LenaHelper lena;
+
+
+#. Enable the logs in the LTE components::
+
+ lena.EnableLogComponents ();
+
+
+#. Create eNB and UE. They are created in its own node container::
+
+ NodeContainer enbNodes;
+ NodeContainer ueNodes;
+ enbNodes.Create (1);
+ ueNodes.Create (1);
+
+
+#. Install mobility models to eNB and UE. This has to be done before devices are created and installed::
+
+ MobilityHelper mobility;
+ mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
+ mobility.Install (enbNodes);
+ mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
+ mobility.Install (ueNodes);
+
+
+#. Create devices and install them to the eNB and UE::
+
+ NetDeviceContainer enbDevs;
+ NetDeviceContainer ueDevs;
+ enbDevs = lena.InstallEnbDevice (enbNodes);
+ ueDevs = lena.InstallUeDevice (ueNodes);
+
+
+#. Attach a UE to a eNB. It will also create a RRC connection between them and configure the UE::
+
+ lena.Attach (ueDevs, enbDevs.Get (0));
+
+
+#. Activate an EPS Bearer including the setup of the Radio Bearer between an eNB and its attached UE::
+
+ enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
+ EpsBearer bearer (q);
+ lena.ActivateEpsBearer (ueDevs, bearer);
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/lte/doc/source/lte.rst Thu May 19 17:40:40 2011 +0200
@@ -0,0 +1,20 @@
+
+########################
+LTE Module
+########################
+
+
+This chapter describes the ns-3 LTE module located in ``src/lte``.
+
+
+
+.. toctree::
+
+ lte-design
+ ff-api
+ lte-user
+ lte-testing
+
+
+
+