Index Terms—link level simulations, LTE



Abstract—This paper presents an overview of the Long Term Evolution (LTE) link level simulator (LLS) developed at the Poznań University of Technology. First, the LTE standard main features are described, followed by an example of transport and physical channel implementation. Next, a simulation package is presented. Simulation package maintenance, validation and calibration problems are discussed as well. Finally, selected simulation results confirming simulation package calibration are presented.

Index Terms—link level simulations, LTE

I. I NTRODUCTION

EVELOPMENT of a simulation package is a complex and time-consuming task. Considering in particular the LTE link level simulator, there already are some freely available simulation tools. Therefore, we shall start with presenting a motivation for another simulation tool to be developed or extended.

As of today, LTE networks are already deployed in some countries, with new deployments planned as well. Their operation and performance was proven in real world scenarios.

Currently, the LTE-Advanced system which is backward compatible with LTE, is being standardized. Originally written for LTE, simulation tools are being extended and improved. To be part of this ongoing research, it is required to have a simulation capability of the LTE system to test proposed improvements. On the other hand, the LTE technology can be treated as a state of the art for comparison with systems proposing new innovative concepts that cannot be integrated into currently standardized LTE/LTE-Advanced systems. To implement new features into the simulation program, it is not only required to know the standard on which it is based but also to have an in-depth understanding of structure and design choices of the simulation tools. Due to these reasons, the development of simulation tools is worth spending time on.

The development of the simulation tool presented here began in 2009 as a research tool for the master thesis of the first author.

The results of this work were then utilized in the WINNER+

This work was supported in part by a scholarship held by the first author within the project “Scholarship support for PH.D. students specializing in majors strategic for Wielkopolska’s development”, Sub-measure 8.2.2 Human Capital Operational Programme, co-financed by European Union under the European Social Fund.

project. Some parts of the source code were also used in research projects carried out for Nokia Solutions and Networks.

Currently, the simulation tool is also used in the METIS project research activities. Last but not least, the developed code was a base for research of the second author during her work on bachelor and master theses.

In the first part of the paper, the LTE standard is presented and main features of the physical layer are described using the example of transport and physical channel implementation. In the next paragraph, the simulation package is presented. In the fifth paragraph, simulation package maintenance, validation and calibration problems are discussed. Selected simulation results are presented in the next part. The paper ends with conclusions.

II. L ONG T ERM E VOLUTION S TANDARD

The Long Term Evolution (LTE) wireless communication system was standardized in December 2008 by the 3

Generation Partnership Project (3GPP) in its Release 8 document series. LTE is going to be the first truly global mobile phone standard. Evolved – Universal Terrestrial Radio Access (E-UTRA) is the air interface of LTE. The simpler architecture results in lower operating costs (the network side of E-UTRAN is composed only of eNode Bs). LTE supports scalable carrier bandwidths, from 1.4 MHz to 20 MHz and both frequency division duplexing (FDD) and time-division duplexing (TDD) with the same radio access technology. The LTE specification provides downlink peak rates of 300 Mbit/s and uplink peak rates of 75 Mbit/s. Orthogonal Frequency Division Multiple Access (OFDMA) is used for the downlink access, whereas single carrier frequency division multiple access (SC-FDMA) for the uplink due to lower peak-to-average power ratio (PAPR) that benefits the mobile terminal in terms of transmit power efficiency and reduced cost of the power amplifier. LTE also provides improved support for mobility, as exemplified by the support for terminals moving at up to 350 km/h or 500 km/h depending on the frequency band.

K. Bąkowski is with the Poznań University of Technology, Poznań, Poland (krzysztof.bakowski@put.poznan.pl)

K. Ratajczak is with the Poznań University of Technology, Poznań, Poland (karolina.ratajczak@put.poznan.pl)

Overview of the LTE Link Level Simulator Developed at the Poznań University of

Technology

Krzysztof Bąkowski, Karolina Ratajczak

D

58 XVII Poznańskie Warsztaty Telekomunikacyjne

III. DL-SCH/PDSCH P ROCESSING C HAIN

The physical (PHY) layer of the LTE radio interface provides services to the medium access control (MAC) layer through transport channels. Data and control streams coming from the MAC layer are organized in the form of transport blocks. In the PHY layer, transport blocks are processed and mapped onto physical channels [9]. In this section, we describe downlink shared channel (DL-SCH) transport channel processing and physical downlink shared channel (PDSCH) physical channel processing. In Fig. 2, DL-SCH/PDSCH processing chain is illustrated both for the transmitter and receiver parts [10][11][12].

Transport block CRC

insertion Transport block CRC check

Segmentation and code block CRC insertion

Code block CRC check and code block concatenation

Channel encoding Channel decoding

Rate matching Inverse rate matching

Code block concatenation Code block separation

Scrambling

Modulation QPSK, 16QAM, 64QAM

Scrambling

Demodulation QPSK, 16QAM, 64QAM

Layer mapping and

precoding Layers concatenation

Resource grid mapping Resource grid demapping

OFDM symbols generation (IFFT)

OFDM symbols reception (FFT) Channel estimatin and

equalizatoin

Mobile radio channel DL-SCH

PDSCH

Fig. 2. DL-SCH/PDSCH processing chain.

It should be mentioned that only the transmitter part is standardized in 3GPP documents. DL-SCH transport channel processing is a combination of error detection, error correction, rate matching, interleaving, and transport channel mapping onto the PDSCH physical channel. Forward error correction (FEC) is provided by the turbo code, and error detection is based on cyclic redundancy check (CRC) codes. If the block size at the input of the turbo code encoder is greater than Z equal to 6144 bits, code block segmentation is performed. The rate matching performs interleaving, as well as repetition or puncturing, in order to match the size of a block generated at the output of the transport channel to the number of bits allocated for the

transmission of the physical channel. The number of bits carried by the PDSCH physical channel is determined by the modulation scheme, the number of resource blocks allocated for transmission, and the transmission mode. PDSCH processing consists of scrambling, modulation, layer mapping, precoding, mapping onto resource grid, and conversion to complex-valued OFDM baseband signals for each antenna port. These antenna ports do not correspond to physical antennas, but rather are logical entities distinguished by their reference signal sequences. Multiple antenna port signals can be transmitted on a single transmit antenna. Correspondingly, a single antenna port can be spread across multiple transmit antennas. Both layer mapping and precoding are associated with multiple antenna transmission and reception (MIMO). The split between these two steps allows the inclusion of all antenna processing schemes in a single framework. These two steps map up to two incoming code words to up to four transmit antennas (LTE Rel.

8). At the receiver side, complementary operations are performed after channel estimation and data equalization.

IV. LTE S IMULATOR OVERVIEW

Contemporary developed and standardized mobile broadband wireless communication systems are highly complex. Development and standardization of these systems relies to a large extent on simulation programs written to model their operation in the wireless channel environment. The most common approach to cellular systems modeling is to split this task into two parts: first, modeling a single link operation, and then modeling a wireless system composed of many cells serving many users using an appropriate abstraction model of a single link. The software implementation of a single communication link is performed by modeling a whole physical layer processing chain from transmitter to receiver. Programs written for this purpose are called link level simulators (LLSs).

To model a multi-link and multi-cell wireless communication system, an abstraction of single-link physical layer processing is used due to the computational overhead of modeling multiple links simultaneously. The abstraction model is called a link-to- system interface (L2S) and programs modeling communication protocols of a cellular network are called system level simulators (SLSs). Both LLSs and SLSs use appropriate mobile radio channel models of.

The developed link level simulation package consists of several parts. The core part of the simulator that models the LTE physical layer is written in C++ general purpose programming language in an object-oriented manner. This main part utilizes IT++ library [1], which is a C++ library of mathematical, signal processing, and communication classes and functions. It is mainly used for data structure management and basic signal processing procedures like Fast Fourier Transform (FFT) calculation or singular value decomposition (SVD) of matrices.

Parameters of the simulation tool can be set by means of a configuration file or command line arguments, or both.

Simulation results post-processing and visualization is implemented by scripts written in the Python programming language. In particular, numpy [7] and matplotlib [6] Python libraries are used for data structure manipulation and

PWT 2013 - Poznań - 13 grudnia 2013 59

visualization, respectively. The validation and calibration of the core part of the simulator is served by a separate project that is described in the further part of the paper. Fig. 1 presents the top- level architecture of the LTE link level simulation package implementation.

Configuration files and comand line

arguments

Parsing and validating

input parameters

Main simulation

loop

Core processing blocks written in C++ and supported

by IT++, BLAS, LAPACK and FFTW3

libraries Output files

with results

Postprocessing and visualization

Validation and calibration based on Google C++ testing framework

Fig. 1. LTE link level simulation package structure.

It is also worth mentioning that the simulation package can be run both under the MS Windows and Linux operating systems. On the Windows platform, Visual Studio or Eclipse development environments can be used. Under the Linux operating system, when graphical environment is available, the Eclipse can be used as well. The above-mentioned platforms are mainly used for the development of the simulation package.

Most of the simulations are run on the Chair of Wireless Communication computation grid where hundreds of parallel simulations can be executed. In order to build the project on the computation grid server, the CMake tool is used. CMake is a family of tools designed to build, test and package software. It controls the software compilation process using simple platform- and compiler-independent configuration files.

CMake generates native makefiles and workspaces that can be used in the compiler environment chosen by the user.

V. M AINTENANCE , V ALIDATION AND C ALIBRATION Writing a simulation program that is basically a software prototype of a designed system is a demanding task. Due to the complexity of this task, it is very easy to make a mistake in the source code of the simulation tool. Therefore, simulation tool calibration is a mandatory requirement to ensure that the conclusions resulting from using this tool are correct. Before calibration, it is also required to verify the correctness of the source code implementing various functional blocks of the simulator. Writing unit tests accompanying the main code of the simulator is important not only for the validation of proper operation of software modules but also for having a safe check that after adding a new functionality, the tool still remains fully functional. This is especially important in a project written by many programmers. Unit tests should reflect the expected functionality of the software module and as a result should be a description of it. To meet these requirements, we designed the

simulation tool to consist of two projects; one containing the required functionality to run simulations, and the second one aiming to validate the correctness, functionality and performance of the main project. This facilitates the clean implementation of the main tool compared with the design when these two goals are pursued in a single source code project.

The testing project employs unit test architecture. In computer programming, unit testing is a method by which individual units of source code, consisting of one or more computer program modules, together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use. Intuitively, a unit can be seen as the smallest testable part of an application. In object-oriented programming, a unit could be an entire interface, such as a class, but it is more commonly an individual method.

At a high level, unit testing gives the ability to verify if implemented methods work as expected for any given set of inputs by returning the proper values or handling failures (in case of invalid input). A good unit test should be able to be fully automated and should have full control over all the pieces running (by using mocks or stubs to achieve isolation when needed). All unit tests should consistently return the same results, regardless of the order it was run Moreover, each unit test should be fast and should test a single logical concept in the system. All tests should be readable, maintainable and trustworthy (after seeing the result, there should be no need to debug the code to verify it).

In test-driven development (TDD), unit tests are created even before the code itself is written. When it passes the tests, the code is considered complete. Unit testing also allows the programmer to refactor the code at a later date, making sure the module still works correctly. Furthermore, unit testing provides a living documentation of the system, in the sense that basic understanding of the unit can be acquired by understanding the corresponding unit tests.

Unit testing frameworks for handling unit tests are most often third-party products that are not distributed as part of the compiler suite. In the case of the C++ programming language, multiple testing frameworks have been developed and are ready to be used. A partial list of such frameworks is provided in [2].

One of the most commonly used C++ unit testing tools and the one used in the described simulation tool is the Google C++

Testing Framework (GTest).

GTest is a framework for writing C++ tests on a variety of platforms (i.e. Linux, Mac OS X, Windows, Cygwin, Windows CE and Symbian). It is based on the xUnit architecture and supports automatic test discovery, a rich set of assertions, user- defined assertions, death tests, fatal and non-fatal failures, value- and type-parameterized tests, various options for running tests, and XML test report generation.

Coming back to the calibration, we aligned our simulation tool performance with the results obtained by 3GPP partners during the design of the LTE system. We compared our results with [3] where ideal simulation results for PDSCH in AWGN channel are presented. After that, we configured our simulation tool according to [4] where UE demodulation simulation

60 XVII Poznańskie Warsztaty Telekomunikacyjne

assumptions were agreed by 3GPP partners. The obtained results were compared with those presented in [5]. The simulation assumptions and selected results are presented in the next paragraph.

VI. S IMULATION R ESULTS

An extensive simulation campaign was performed in order to verify the validity and performance of the LTE LLS implementation. In Table I, the most important simulation parameters are presented for various simulation setups described in [3] and [4]. In this section, selected simulation results are presented.

Fig. 3. DL-SCH/PDSCH throughput for SIMO and MISO configurations.

In Fig. 3, throughput versus SNR is plotted for 2x1 MISO and 1x2 SIMO antenna configurations in the Extended Vehicular A 5 Hz Doppler spectrum (EVA5) channel. Both the obtained and reference results are plotted. In Fig. 4, throughput versus SNR is plotted for 2x2 MIMO antenna configuration and one and two code words. It can be observed that for two code words spatial

multiplexing in 10 MHz channel approximately 60 Mbit/s information bits throughput can be achieved.

Fig. 4. DL-SCH/PDSCH throughput for MIMO configuration with one and two code words.

VII. C ONCLUSIONS

In this paper, LTE LLS implementation was presented together with a short LTE standard description. The obtained simulation results show that developed simulation tool is calibrated and suitable for providing a reliable base for further research.

R EFERENCES

[1] Open Source library, GPL license (2013, Nov. 15). IT++ Available:

http://sourceforge.net/apps/wordpress/itpp [2] List of unit testing frameworks:

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

[3] R4-071640, Nokia, Ideal simulation results for PDSCH in AWGN. TSG RAN WG4 Meeting #44bis

[4] R4-071800, Motorola, Agreed UE demodulation simulation assumptions.

TSG RAN WG4 Meeting #44bis

[5] R4-072218, Ericsson, Collection of PDSCH results. TSG RAN WG4 Meeting #45

[6] Open Source library, PSF license (2013, Nov. 15). matplotlib Available:

http://matplotlib.org/

[7] Open Source library, (2013, Nov. 15). Numpy Available:

http://www.numpy.org/

[8] 3GPP TR25.913, “Requirements for Evolved UTRA and UTRAN,”

RAN#28, June, 2005.

[9] TS 36.201: LTE Physical Layer - General Description, Release 8 v.8.3.0, 3GPP, 2008-12.

[10] TS 36.211: Physical channels and modulation, Release 8 v.8.5.0, 3GPP, 2008-12.

[11] TS 36.212: Multiplexing and channel coding, Release 8 v.8.5.0, 3GPP, 2008-12.

[12] TS 36.213: Physical layer procedures, Release 8 v.8.5.0, 3GPP, 2008-12.

Krzysztof Bąkowski (M.Sc.) is working towards a Ph.D. in the Chair of Wireless Communications at Poznań University of Technology. His scientific interests concentrate on simulation of 4G and 5G wireless systems.

Karolina Ratajczak (M.Sc.) is working towards a Ph.D. in the Chair of Wireless Communications at Poznań University of Technology. Her scientific interests concentrate on MIMO techniques.

TABLE I S

Parameter Value

Duplex FDD

Transport channel DL-SCH

Physical channel PDSCH

Radio channel AWGN, EPA 5Hz, EVA 5Hz,

ETU 70 Hz, ETU 300 Hz Channel estimation Ideal

Modulation QPSK, 16QAM, 64QAM

PDSCH transmission mode Single antenna, transmit diversity, spatial multiplexing

Cyclic prefix length Normal ('f = 15kHz) Bandwidth [MHz] 1.4, 3.2, 5, 10, 15, 20

Number of frames 100

Number of UEs 1

Number of OFDM symbols per subframe

14 Number of subframes per frame 10 Number of HARQ processes 8 Max number of transmissions per HARQ process

1, 4 RV sequence for QPSK, 16QAM {0, 1, 2, 3}

RV sequence for 64QAM {0, 0, 1, 2}

PWT 2013 - Poznań - 13 grudnia 2013 61