From 3fda1bcb636bc4e82316f0f382eb3c063f31da88 Mon Sep 17 00:00:00 2001 From: mrequena Date: Tue, 17 May 2011 18:13:13 +0200 Subject: [PATCH 1/2] Testing documentation for SINR calculation in downlink/uplink and Adaptive Modulation and Coding tests --- doc/manual/source/lte-testing.rst | 70 +++++++++++++++++++++++++++++-- 1 file changed, 66 insertions(+), 4 deletions(-) diff --git a/doc/manual/source/lte-testing.rst b/doc/manual/source/lte-testing.rst index 16b06c8a1..f83d0c25c 100644 --- a/doc/manual/source/lte-testing.rst +++ b/doc/manual/source/lte-testing.rst @@ -21,7 +21,7 @@ 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 opebning the file ``results.html`` with a web browser. +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. @@ -35,9 +35,41 @@ Unit Tests SINR calculation in the Downlink -------------------------------- -SINR calculation in the uplink +This unit test program 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:: + + \mathrm{SINR} = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} } + +The unit test program includes two test cases with random transmited signals and random interference signals. The signals are active during different periods of time. A chunk of time is a period of time during which :math:`n` signals are active (:math:`T_i`). A different SINR is calculated (:math:`\mathrm{SINR_i}`) for each chunk. The expected :math:`\mathrm{SINR}` is + +.. math:: + + {\mathrm{SINR}}_{total} = \frac{ \displaystyle\sum_{\forall\mathrm{chunks}} {\mathrm{SINR}}_i * T_i }{ T_{total} } + +The test vectors are obtained by an Octave script that applies the described algorithm. The unit test program checks that the SINR calculation in downlink is performed correctly in the :cpp:class:`ns3::LtePhy` interface. It implements this interface in the :cpp:class:`ns3::LteTestUePhy` test class. + + + + +SINR calculation in the Uplink ------------------------------ +This unit test program checks that the SINR calculation in uplink is performed correctly. The SINR in the uplink is calculated for each Resource Block assigned to data transmissions by dividing the power of the intended signal from the considered UE by the sum of the noise power plus all the transmissions on the same RB coming from other UEs (the interference signals). + +.. math:: + + \mathrm{SINR} = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} } + +The unit test program includes two test cases with random transmited signals and random interference signals. The signals are active during different periods of time. A chunk of time is a period of time during which :math:`n` signals are active (:math:`T_i`). A different SINR is calculated (:math:`\mathrm{SINR_i}`) for each chunk. The expected :math:`\mathrm{SINR}` is + +.. math:: + + {\mathrm{SINR}}_{total} = \frac{ \displaystyle\sum_{\forall\mathrm{chunks}} {\mathrm{SINR}}_i * T_i }{ T_{total} } + +The test vectors are obtained by an Octave script that applies the described algorithm. The unit test program checks that the SINR calculation in uplink is performed correctly in the :cpp:class:`ns3::LtePhy` interface. It implements this interface in the :cpp:class:`ns3::LteTestUePhy` test class. + + System Tests ~~~~~~~~~~~~ @@ -45,6 +77,28 @@ System Tests Adaptive Modulation and Coding ------------------------------ +This system test is run consisting of a single eNB and a single UE, with different test cases corresponding to different SINR values perceived by the UE; the test checks 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. We get the spectral efficiency :math:`\eta_i` for each value of the SNR in dB using Shannon's theorem: + +.. math:: + + \mathrm{BER} = 0.00005 + +.. math:: + + \Gamma = \frac{ -\ln{ (5 * \mathrm{BER}) } }{ 1.5 } + +.. math:: + + \eta_i = \log_2 { \left( 1 + \frac{ {\mathrm{SINR}}_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]_. + + + Round Robin scheduler performance --------------------------------- @@ -75,7 +129,7 @@ In the first category of test cases, the UEs are all placed at the same distance 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 [Kushner2004cpfsa]_). +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:: @@ -89,4 +143,12 @@ References .. [TS36.213] 3GPP TS 36.213 "LTE Physical layer procedures" -.. [Kushner2004cpfsa] H.J. Kushner and P.A. Whiting, "Convergence of proportional-fair sharing algorithms under general conditions", IEEE Trans. on Wireless Communications, July 2004 +.. [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" From e6dadce25ff77822e5a58bef8c1393cddf26fdb9 Mon Sep 17 00:00:00 2001 From: Nicola Baldo Date: Tue, 17 May 2011 18:58:23 +0200 Subject: [PATCH 2/2] updated design documentation --- doc/manual/Makefile | 3 ++ doc/manual/source/lte-design.rst | 66 ++++++++++++++++++++++++-------- doc/manual/source/lte-user.rst | 1 - 3 files changed, 53 insertions(+), 17 deletions(-) diff --git a/doc/manual/Makefile b/doc/manual/Makefile index 06a0015c8..9393cb22b 100644 --- a/doc/manual/Makefile +++ b/doc/manual/Makefile @@ -23,6 +23,7 @@ IMAGES_EPS = \ $(FIGURES)/auvmobility-classes.eps \ $(FIGURES)/ff-mac-saps.eps \ $(FIGURES)/ff-example.eps \ + $(FIGURES)/lte-enb-architecture.eps \ # missing figure # $(FIGURES)/lte-transmission.eps @@ -41,6 +42,8 @@ $(FIGURES)/sockets-overview.pdf_width = 10cm $(FIGURES)/snir.pdf_width = 3in $(FIGURES)/lte-transmission.pdf_width = 3in $(FIGURES)/auvmobility-classes.pdf_width = 10cm +$(FIGURES)/lte-enb-architecture.pdf_width = 10cm + IMAGES_PNG = ${IMAGES_EPS:.eps=.png} IMAGES_PDF = ${IMAGES_EPS:.eps=.pdf} diff --git a/doc/manual/source/lte-design.rst b/doc/manual/source/lte-design.rst index 1a03b13df..c753fadf2 100644 --- a/doc/manual/source/lte-design.rst +++ b/doc/manual/source/lte-design.rst @@ -5,41 +5,75 @@ LTE Design Documentation ++++++++++++++++++++++++++ ------------------------------------------------------------------------------ -* the new eutra stack diagram with all SAPs, differentiated between eNB and UE -* the explanation of the new example program +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. +#. The simulator should provide meaningful application-layer Key Performance Indicator, to effectively allow an evaluation of the Quality of Experience (QoE) perceived by the end user. For this purpose, the LTE user plane protocol stack should be modeled accurately, and in particular it should include the RLC protocol. Otherwise, only MAC-level KPIs could be extracted, which cannot be mapped directly to QoE without some gross approximation. +#. The control plane should be modeled for those parts which affect resource management. This because the control plane can be the bottleneck in several scenarios. + + +Module Architecture +~~~~~~~~~~~~~~~~~~~ + + +The overall architecture of the LTE module is represented in the following figure. + +.. figure:: figures/lte-enb-architecture.png + :align: right + + The architecture of the eNB + + +Detailed description of the components +************************************** + 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 -############## +~~~~~~~~~~~~~~ -A :cpp:class:`ns3::LtePhy` class models the LTE PHY 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 :cpp:class:`ns3::SpectrumPhy` and -:cpp:class:`ns3::SpectrumChannel` classes, respectively, which are provided by the Spectrum Framework [1]_. +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 -:cpp:class:`ns3::LteSpectrumPhy` object, one for the downlink and one for the uplink. -The :cpp:class:`ns3::LtePhy` stores and manages both downlink and uplink -:cpp:class:`ns3::LteSpectrumPhy` elements. +`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, -:cpp:class:`ns3::LteUePhy` and :cpp:class:`ns3::LteEnbPhy` classes, inherited from -the :cpp:class:`ns3::LtePhy` class, implement the PHY layer for the UE and the +`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. @@ -52,7 +86,7 @@ The figure below shows how UE and eNB can exchange packets through the considere 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 :cpp:class:`ns3::UeLteSpectrumPhy` attached to it, handling the +of packets to all the `ns3::UeLteSpectrumPhy` attached to it, handling the ``StartRx`` function. When the UE receives packets, it executes the following tasks: @@ -65,7 +99,7 @@ When the UE receives packets, it executes the following tasks: 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. diff --git a/doc/manual/source/lte-user.rst b/doc/manual/source/lte-user.rst index 08c5daa69..eaa8d8c6b 100644 --- a/doc/manual/source/lte-user.rst +++ b/doc/manual/source/lte-user.rst @@ -68,4 +68,3 @@ Example simulation program lena.ActivateEpsBearer (ueDevs, bearer); -``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: