the vienna 5g system level simulator

VCCS5G System Level Simulator

User Manual

The Vienna 5G System Level Simulator

Institute of Telecommunications,TU Wien

Authors

Martin Muller, Fjolla Ademaj, Agnes Fastenbauer, Armand Nabavi,Thomas Dittrich, Blanca Ramos Elbal, Lukas Nagel, Alexander Bokor,Areen Shiyahin, Christoph Buchner, Thomas Lipovec, Jan Nausner,

Stefan Schwarz and Markus Rupp

Vienna, July 29, 2021

http://www.tuwien.ac.at/

http://www.nt.tuwien.ac.at/vccs/

http://www.nt.tuwien.ac.at/

Institute of Telecommunications, TU Wien

Gusshaussstrasse 25/389A-1040 ViennaAustria

web: http://www.nt.tuwien.ac.at/

VCCS

The Vienna 5G System Level Simulator is part of the ViennaCellular Communications Simulators (VCCS) software suite.The simulator is currently available under a non-commercial,academic use license. For download and license informationof the simulator, please refer to our license agreement.



http://www.nt.tuwien.ac.at/vccs/

http://www.nt.tuwien.ac.at/vccs/vienna-5g-simulators/

II

Contents

1 Introduction 1

2 Quick Start 3

3 System Requirements 43.1 Matlab Toolboxes . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Simulation Methodology 5

5 Predefined Scenarios 75.1 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . 75.2 Predefined Launchers and Scenario files . . . . . . . . . . . . . 8

5.2.1 Hexagonal grid with interference ring . . . . . . . . . . 85.2.2 PPP distributed BSs with interference region . . . . . 95.2.3 Mobility and multiple chunks . . . . . . . . . . . . . . 115.2.4 Multi-tier and multi-user heterogeneous network . . . . 125.2.5 Manhattan city layout . . . . . . . . . . . . . . . . . . 155.2.6 Manhattan city layout with QUAsi Deterministic RadIo

channel GenerAtor (QuaDRiGa) channel model . . . . 175.2.7 IoT with clustered nodes . . . . . . . . . . . . . . . . . 175.2.8 Lite version . . . . . . . . . . . . . . . . . . . . . . . . 195.2.9 Simulation of several chunks in parallel . . . . . . . . . 205.2.10 OpenStreetMap city layout . . . . . . . . . . . . . . . . 215.2.11 NOMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Comparison to LTE-A SL Simulator 28

7 Simulator Structure 317.1 A Typical Simulation . . . . . . . . . . . . . . . . . . . . . . . 317.2 The Simulator Time Line . . . . . . . . . . . . . . . . . . . . . 327.3 The Main Simulation Loop . . . . . . . . . . . . . . . . . . . . 34

8 Overview of Key Functionalities 378.1 Generation of Network Elements and Geometry . . . . . . . . 37

8.1.1 Base Stations . . . . . . . . . . . . . . . . . . . . . . . 378.1.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398.1.3 Blockages . . . . . . . . . . . . . . . . . . . . . . . . . 408.1.4 Cell association . . . . . . . . . . . . . . . . . . . . . . 418.1.5 Mitigation of Border Effects . . . . . . . . . . . . . . . 42

8.2 Link Quality and Link Performance Model . . . . . . . . . . . 44

III

8.2.1 Link Abstraction . . . . . . . . . . . . . . . . . . . . . 448.2.2 Link Quality Model . . . . . . . . . . . . . . . . . . . . 458.2.3 Link Performance Model . . . . . . . . . . . . . . . . . 46

8.3 Simulation of Propagation Effects . . . . . . . . . . . . . . . . 478.3.1 Path Loss Modeling and Situation dependent Model

Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.3.2 Modeling of Shadow Fading . . . . . . . . . . . . . . . 478.3.3 Modeling of Small Scale Fading - Channel Models . . . 48

8.4 Precoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.4.1 Baseband Precoding . . . . . . . . . . . . . . . . . . . 508.4.2 Analog Precoding . . . . . . . . . . . . . . . . . . . . . 51

8.5 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528.6 Technologies and Numerologies . . . . . . . . . . . . . . . . . 53

8.6.1 Composite Base Station . . . . . . . . . . . . . . . . . 538.6.2 Spectrum Scheduling . . . . . . . . . . . . . . . . . . . 548.6.3 Numerology and mixed-numerology scenarios . . . . . 558.6.4 Inter-numerology interference . . . . . . . . . . . . . . 578.6.5 Resource Grid . . . . . . . . . . . . . . . . . . . . . . . 57

8.7 Traffic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.8 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628.9 NOMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.9.1 A NOMA Transmission . . . . . . . . . . . . . . . . . . 628.9.2 NOMA User Pairing . . . . . . . . . . . . . . . . . . . 638.9.3 NOMA Scheduling . . . . . . . . . . . . . . . . . . . . 648.9.4 NOMA in the Link Quality Model . . . . . . . . . . . . 64

8.10 Parallelization . . . . . . . . . . . . . . . . . . . . . . . . . . . 658.11 Lite Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.12 Post Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9 Performance Considerations 709.1 Simulation Time . . . . . . . . . . . . . . . . . . . . . . . . . 70

10 Releases and Changelog 73

1

1 Introduction

In cellular communications, simulations are an inevitable tool for understand-ing the mutual interactions of all involved players in the network. Especiallyfor gaining insight in the performance of a large-scale scenario, a real-worldmeasurement approach becomes too costly and laborious. Therefore, systemlevel simulators were developed along with the standardization process of thecurrent mobile communications standard Long Term Evolution (LTE).

Our research group originally started off in 2009 with a freely-availableLTE link-level simulator and supplemented it with an LTE system-levelsimulator. These simulators received quite some attention and kept growingover time, adding more features as research and standardization evolvedfurther. Thanks to the open-source nature of our simulators and the vividexchange between developers and active users via an online forum, the ViennaLTE simulators have been downloaded more than 50 000 times in total.

Following the ongoing discussion about the the 5th generation of mobilenetworks (5G) we have introduced new 5G simulators to remain at theforefront of the latest developments. We again follow the approach to splitthis project in a link-level and a system-level simulator. The scope of thisuser manual is to give an overview of the capabilities and the general purposeof the Vienna 5G System Level (SL) Simulator, introduce its structure anddescribe the key features and their implementation details.

With the addition of the 5G System Level Simulator to the family of theVienna Cellular Communications Simulators (VCCS), we tackle the need forsimulating large scale networks, capturing the change in network layouts andphysical transmission, coming up with the expected 5G standard. While the5G standard has not yet been fully specified as of this writing, it is commonlyagreed upon that future networks will become more heterogeneous. Therefore,our simulator allows to create networks of arbitrary layout with several tiersof Base Stations (BSs) and various user types in the same simulation.

The implementation is done in MATLAB and uses Object OrientedProgramming (OOP). In general we made sure that the code structureis easy to expand, also with respect to the unknown prerequisites from theupcoming 5G standard. Due to the abstract structure of the code, we alsoprovide backwards compatibility to our LTE system level simulator (if notin the full extent of all available options). The usage of parallel computingis also supported by our simulator, since individual simulation chunks aredefined after an initial pregeneration step.

Our simulator performs Monte-Carlo simulations in order to achieve anaverage network performance. Therefore, we average over many spatialconstellations and channel realizations and thus obtain results for average

2

throughput per user/BS, average Signal to Interference and Noise Ratio(SINR) performance and ratio of successful transmissions.

To determine the quality of each individual link, the instantaneous SINRis evaluated. For each transmission, the received power of all transmitters(desired and interfering) is calculated by combining distance dependent pathloss, channel realization, antenna pattern and shadowing. It is possible tochoose from several models and options for each of these individual propagationeffects. Additionally, this is not a static choice that is set for the wholesimulation, but is chosen dependent on the link conditions (e.g., Line-Of-Sight (LOS)/Non Line of Sight (NLOS)). These link-types can again bedistinguished by different means. To stay with the LOS example, options are,e.g., to use pregenerated spatially correlated maps or to find obstruction ofthe transmission link from explicitly placed blockages in the scenario (a moreexplicit description can be found in Section 8.3).

Since the complexity of a simulation increases rapidly with the considerednetwork size and the resulting large number of individual network elements,we perform an abstraction step for the actual transmission. Therefore, per-formance curves from the 5G link level (LL) Simulator are used for an SINRto Bit Error Ratio (BER) mapping to assess the success of each individualtransmission, without the need to simulate all aspects of the Physical (PHY)channel.

The current version of our 5G System Level Simulator supports heteroge-neous networks with an arbitrary number of BS tiers and user types, includingmobile users. Thanks to the construction of the BSs objects with attachedantenna objects, BSs with Remote Radio Heads (RRHs) and DistributedAntennas Systems (DASs) are available for simulations. Regarding the net-work geometry, not only BSs and users can be placed, but also 3-D blockages,resembling walls and buildings. Consequently, randomly generated cities canbe created, such as a Manhattan grid layout or randomly placed buildings witharbitrary orientation. The new transmission features of 5G, such as mmWaveand massive Multiple-Input Multiple-Output (MIMO) are represented in oursimulator by the corresponding channel model for the right frequency range.

3

2 Quick Start

This quick start guide explains how to run the Vienna 5G SL Simulator forthe first time.

1. Switch to the simulator’s root directory. Make sure the file simulate.mis present in your current working directory.

2. Open one of the scripts in launcherFiles. For illustration, let’s considerone of the predefined launchers, launcherFiles.launcherExample.m

3. In this launcher file, the scenario to be used is specified:

1 % select scenario

2 result = simulate (@ scenarios.basicScenario , parameters.

setting.SimulationType.local);

4. Simulations are defined by their scenario files. In the folder +scenarioswe find basicScenario.m which contains all the parameters that areneeded to perform a simulation. To run your own simulation you canadapt this or one of the other scenarios to your needs or create yourown scenario file. To start the simulation, replace basicScenario instep 3 with your chosen scenario. More information about scenarios canbe found in Section 5. The scenario file example.m contains a list of allparameters that can be set and their respective default values. It canbe used as a template for creating your own scenario.

5. In case you want to make use of multiple processor cores and paral-lelize the simulation, you can use SimulationType.parallel insteadof SimulationType.local in step 3 (cf. Section 8.10).

6. After specifying the scenario to simulate, the results will be saved intothe variable result. Various plotting functions can be called, dependingon the postprocessor class specified in the scenario file (see Section 8.12for more details).

1 % plots the SINR ECDF of all user SINRs

2 result.showAllPlots;

7. Run the script launcherFiles/example.m. Various results are plottedwhen the simulation is finished.

4

3 System Requirements

The simulator is implemented using Matlab. The current minimum requiredversion is 2018b.

3.1 Matlab Toolboxes

It is possible to use the Vienna Cellular Communications Simulators (VCCS) 5G Sys-tem Level Simulator (SLS) without any toolboxes. However, the randomuser positioning relies on functions from the Statistics and Machine LearningToolbox and the Parallel Computing Toolbox is required to use the parallelsimulation mode of the simulator. The majority of the implementation is donerelying only on Matlab built-in functions, supported without any toolbox.The functions employing methods from toolboxes are listed in Table 1. Notethat the usage of those functions are optional, and therefore are not requiredin order to run the simulator.

function usage toolbox commentparfor ParallelSimulation.m Parallel Computing Toolbox parallelized simulation looppoissrnd PoissonStreets.m Statistics And Machine Learning Toolbox draw from Poisson distributionpoissrnd NodeDistribution.m Statistics And Machine Learning Toolbox draw from Poisson distributionpoissrnd ClusteredDistribution.m Statistics And Machine Learning Toolbox draw from Poisson distributionbinornd UMa3D.m Statistics And Machine Learning Toolbox draw from binomial distributionbinornd UMa TR28901.m Statistics And Machine Learning Toolbox draw from binomial distribution

Table 1: Employed functions requiring Matlab toolboxes.

5

4 Simulation Methodology

The Vienna 5G SL Simulator allows to investigate the performance of futurelarge scale wireless networks. It is implemented in an abstract fashion by usingOOP. The performance evaluation is done through Monte-Carlo simulationswith a large number of randomly sampled realizations of a scenario that isgenerated according to the parameters specified prior to the simulation. Adetailed description of the simulator can be found in Section 7.

The individual link quality is determined according to the geometry andthe resulting relative position of receiver and transmitter as well as severalpropagation effects. The received power of all links is then combined in aSINR value, which is used later on in the actual transmission function (cf.Section 8.2).

An arbitrary number of BS and user types can be defined and placedaccording to a predefined placement function (cf. Section 8.1). The simulatorprovides several options, such as the classical hex-grid or random placementaccording to a Poisson Point Process (PPP).

The propagation effects that largely influence the quality of the transmis-sion are split into different functions the appropriate options and models canbe chosen independently per scenario and BS and user type. In our simulator,we provide the following options:

� Individual transmission power for different tiers

� Antenna patterns

� Large scale path loss (including distinction between different link condi-tions) (cf. Section 8.3.1)

� Shadowing (blockages are modeled explicitly or implicitly) (cf. Sec-tions 8.1.3 and 8.3.2)

� Small scale fading in terms of channel models (cf. Section 8.3.3)

The Multiple Access Channel (MAC) layer is represented by the schedulerfunction and by applying Adaptive Modulation and Coding (AMC). Itutilizes the previously calculated SINR of the active links to determine theresource allocation and appropriate Modulation and Coding Scheme (MCS)for transmission (cf. Section 8.5).

In order to limit the complexity, the actual transmission is abstracted andseveral steps in the transmitter chain (e.g., coding or modulation) and receiverchain (e.g., decoding and demapping) are combined in two functions, namelythe Link Quality Model (LQM) and the Link Performance Model (LPM). A

6

more thorough explanation of these functions can be found in Section 8.2.This abstraction step is the key enabler for supporting the simulation ofvery large scale scenarios with several thousand different nodes in a singlesimulation.

The acquired results are then selectively stored (dependent on the chosensettings) and can later be combined in average values. Additionally, theempirical cumulative distribution function (ecdf) of, e.g., the average userthroughput or the user SINR are plotted.

7

5 Predefined Scenarios

In Section 2 we described how to run a simulation. To define a simulation weuse so called scenario files. The desired parameters for a specific scenario areset in these files. Undefined parameters will be initialized with their default val-ues. The default values are listed in the scenario file +scenarios/example.m.This way all options are concentrated in one spot and are not distributed inhidden configuration files. To keep simulations reproducible, we recommendsaving (a copy of) the scenario file for each simulation that might be neededlater on. A scenario file contains a function which expects one parameterof the type parameters.Parameter and returns the parameter object filledwith settings required by the scenario. Scenarios are launched by passingtheir function handle to the simulate function. For example to start thebasic scenario the function call would look like this:

1 result = simulate (@ scenarios.basicScenario , parameters.


The second argument of this function determines if the simulation is performedwith or without parallelization.

5.1 Customization

For defining new scenarios we recommend to start from the existing scenariothat is most similar to the intended simulation and modify a copy of it.

To change additional parameters that are not already set in the existingscenario, refer to +scenarios.example. In this file all parameters are set tothe predefined default values. This serves as a reference for which parametersdo not need to be set, because they are set to the desired value by default aswell as an example on how to set each parameter, if it needs to be changedfrom the default value. For each parameter, a comment explains whetherthe value set in the example file is a default value or a value that needs tobe set, because no default value is defined. For further explanations on theparameters, refer to the built-in documentation for each parameter class byusing the following line in the command line:

1 doc parameters.'subpackage '.'Class '.'property '

For example to understand the use of the setting nElements for Poissondistributed users type:

1 doc parameters.user.Poisson2D.nElements

8

in the command line. This opens a documentation window explaining whatdata types are expected for this setting and what is defined through thisparameter.

One benefit of the configuration through functions is its flexibility. Theonly constraints are that the function has to take a parameters.Parameter

object as input and returns this object with the properties set are required.Besides this, one can execute arbitrary MATLAB code in these functions. Forexample one can use calculations to find the right parameter values, call otherfunctions or simply load data from configuration/data files. This flexibilityallows to customize the scenario to a large degree.

5.2 Predefined Launchers and Scenario files

In the package +launchersFiles several launchers for simulating predefinedscenarios can be found. The corresponding scenario files are defined in+scenarios. In the following, the specifics of these scenarios are explained,including the most important parameters and how they have to be defined.

5.2.1 Hexagonal grid with interference ring

The launcher file launcherFiles.launcherHexRingInterferers.m providesan example of how to simulate a hexagonal grid network of three-sectorBSs with a defined number of rings of BSs and rings of interfering BSs.The launcher file starts by calling the corresponding scenario file located in+scenarios, in this case scenarios.hexRingInterferers.m, as shown inthe code-line below.

1 result = simulate (@ scenarios.hexRingInterferers , parameters.


The execution of this line will produce the results saved in the variable result.Afterwards, various plotting functions can be executed, depending on the

chosen post-processing method, already defined in the scenario file. To showall plots, that are predefined, the code-line below is executed.


Now let us have a closer look on how the scenario file is constructed for thisparticular example. The general network parameters are set in the scenariofile with:

1 interBSdistance = 280;

2 nRing = 1;

3 nRingInterferers = 1;

9

These settings are then used to define the size of the Region Of Interest(ROI) and the interference region:

1 params.regionOfInterest.interference = parameters.setting.

Interference.regionIndependentUser;

2 params.regionOfInterest.xSpan = 2 * interBSdistance * nRing;

3 params.regionOfInterest.ySpan=params.regionOfInterest.xSpan;

4 params.regionOfInterest.interferenceRegionFactor = 1 + 1/

nRing + nRingInterferers /(2* nRing);

For this scenario a square ROI, that spans from the two most distantdesired BSs is created. The interference region (cf. Section 8.1.5) is definedto be slightly larger than the distance between the outer interfering BSs.

Then, sector antennas are placed in a hexagonal grid, the antennas beingdefined with :

1 antenna = parameters.basestation.antennas.ThreeSector;

2 antenna.nTX = 4;

The hexagonal grid is defined with:

1 hexRing = parameters.basestation.HexRing;

2 hexRing.interBSdistance = interBSdistance;

3 hexRing.nRing = nRing;

4 hexRing.nRingInterferers = nRingInterferers;

5 hexRing.type = parameters.setting.BaseStationType.macro;

6 hexRing.antenna = antenna;

7 params.baseStationParameters('hexRing ') = hexRing;

The network parameters interBSdistance, nRing and nRingInterferersare the parameters defined at the beginning of the scenario file. Users areplaced through a PPP.

In this scenario, some BSs from the ring of interfering BSs can be thedesired BS of a user in the ROI. If this is the case, these BSs are fullysimulated with full scheduling and feedback and the ROI-users attachedto them produce simulation results. To show which BSs in the simulationwere not only creating interference, the following code-lines mark these BSspositions in orange.

5.2.2 PPP distributed BSs with interference region

The launcher file launcherFiles.launcherInterferenceRegionPPP.m pro-vides an example of how to simulate a network with BSs and users distributedaccording to a PPP with an additional interference region around the borderof the ROI. The launcher file starts by calling the corresponding scenario filelocated in +scenarios, in this case scenarios.interferenceRegionPPP.m,as shown in the code-line below.

10

1 result = simulate (@( params)scenarios.interferenceRegion(

params , 2e3 , 2e3 , 1.5), parameters.setting.SimulationType.

local);

The execution of this line will produce the results saved in the parameterresult.

Afterwards, various plotting functions can be executed, depending on thechosen post-processing method, already defined in the scenario file. To showall plots, that are predefined, the code-line below is executed.


To create a boundary region and define its size, the interference andinterferenceRegionFactor parameters have to be set in the scenario file,as is shown in the code-lines below.



2 params.regionOfInterest.interferenceRegionFactor =

interferenceRegionFactor;

This parameter will be used to create the interference region in the functioncreateInterferenceRegion from the class parameters.regionOfInterest.RegionOfInterest. This will create a network as shown in Fig. 14.

The BS placement in the interference region is an expansion of the BSplacement in the ROI, but for the user placement in the interference region,two placement options are available. The users can be placed, like the BSsin an expansion of the ROI-user placement, as they are in this scenario.Alternatively the users can be placed uniformly in the interference region,independently from the user placement in the ROI. The placement of usersin the interference region would create additional interference for an uplinktransmission and is thus not necessary for downlink transmissions.



This user placement strategy ensures that the number of users in theROI stays constant for moving users and the number of results producedby a chunk (cf. Section 7.2) is constant, which strongly simplifies the resulthandling in the post-processor.

At the end of the launcher file the border of the ROI is added to thenetwork plot.

11

5.2.3 Mobility and multiple chunks

The launcher file launcherFiles.launcherUserMovement.m shows how toenable user movement. This is done in scenarios.UserMovement with thecode-line below:

1 movingUsersRandom.userMovement.type = parameters.user.

MovementType.ConstSpeedRandomWalk;

where movingUsersRandom contains the user parameters and is an object ofthe class parameters.user.Parameters. All supported movement types arelisted in +parameters.user.MovementType.m. The scenario file shows howto set the parameters for each movement type.

The simulation is run using the command

1 result = simulate (@ scenarios.UserMovement , parameters.setting

.SimulationType.local);

Afterwards, user movement is plotted. This is done using the commands

1 for uu = 1: nUsersToPlot

2 posList = result.networkElements.userList(uu).

positionList;

3 plot(posList (1,:), posList (2,:), 'b+');

4 %draw arrow from start to finish

5 quiver(posList (1,1), posList (2,1), posList(1,end)-

posList (1,1), posList(2, end)-posList(2, 1), 0, 'r

');

6 if uu == 1 %plot path for the first user

7 plot(posList (1,:), posList (2,:), 'k-')

8 end

9 end

In the loop, the user positions are retrieved and plotted for each user for alltime slots (TSs) using blue plus signs. Next, a red arrow is plotted from thestarting position to the end position to show the direction of movement. Forthe first user only, the path is shown by black lines connecting the user’spositions in the right order. This is particularly useful for random movementschemes where the path cannot simply be deduced from the positions andthe arrow only. Showing the path only for the first user is done to avoidovercrowding the plot. If you want to plot the path for more users, you simplyneed to adapt the condition in the if statement. The next step zooms inaround the first user so that its movement becomes clearly visible. This isoften necessary since for typical simulation settings, the user speed and thesimulation time lead to traveled distances that are very small compared tothe size of the ROI.

12

1 posList = result.networkElements.userList (1).positionList;

2 distXY = [posList(1,end)-posList (1,1), posList(2, end)-

posList(2, 1)]; %traveled distance in x and y

3 %box around movement area of user 1

4 minX = min(posList (1,:));

5 minY = min(posList (2,:));

6 maxX = max(posList (1,:));

7 maxY = max(posList (2,:));

8 axis([minX -0.2* abs(distXY (1)) maxX +0.2* abs(distXY (1)) minY

-0.2* abs(distXY (2)) maxY +0.2* abs(distXY (2))])

For demonstration purposes, the user speed is set to a high value in thissimulation so that the traveled distance increases. If you want to display themovement of any subset of users, you only need to hand a list of the desiredusers to the for-loop in the first code fragment and comment out the secondcode fragment.

When using non-random movement schemes, a large gap between groupsof plus signs (which correspond to user positions) is visible. This is due to thepause between simulation chunks. It is assumed that the user continues totravel at the same speed and in the same direction during this pause. Pleaserefer to sections 7.2 and 7.3 for more details on TSs, segments and chunks.

5.2.4 Multi-tier and multi-user heterogeneous network

The launcher file launcherFiles.launcherHetNet provides an example ofhow to simulate a heterogeneous network consisting of different BS types anddifferent user types. The launcher file starts by calling the correspondingscenario file located in +scenarios, in this case scenarios.HetNet, as shownin the code-line below.

1 result = simulate (@ scenarios.HetNet , parameters.setting.

SimulationType.local);

The execution of this line will produce the results saved in the parameterresult. Afterwards, various plotting functions can be executed, dependingon the chosen post-processing method, already defined in the scenario file.For example, using the command


the simulated network consisting of all its network elements can be plotted, aswell as SINR and throughput ecdfs. It is possible to also add desired plottingfunctions in the launcher file. To demonstrate that, we give an example howto plot user-to-BS association based on the maximum received power.

13

As can be seen, all the input parameters characterizing a particularsimulation scenario have to be included in the corresponding scenario file –in our example of scenarios.HetNet.

Various BS types can be defined. BS types can differ based on thedistribution type, density, type of antenna, transmit power etc. Three differentBS types are defined:

� macro - distributed according to predefined positions denoted withparameter posMacro, with a height of 25m and transmit power of 40W

� pico - distributed according to predefined positions denoted with param-eter posPico along a straight street, with a height of 5m and transmitpower of 2W

� femto - distributed according to a PPP with a given density, a heightof 1.5m and transmit power of 0.1W.

The corresponding parameters for each of the three types are given below.

1 % macro \acp{BS}

2 predefPosMacro=parameters.basestation.PredefinedPositions ();

3 predefPosMacro.positions = [posMacro ;30* zeros(1,size(posMacro

,2))];

1 % pico \acp{BS}

2 predefPosPico = parameters.basestation.PredefinedPositions ();

3 predefPosPico.positions = [posPico ;30* zeros(1,size(posPico ,2)

)];

1 % femto \acp{BS}

2 poissonFemtoBS = parameters.basestation.Poisson2D ();

3 poissonFemtoBS.density = 0.0005;

Accordingly, for each BS type, the antenna parameters are specified,such as antenna radiation pattern, height, number of transmit and receiveantennas and transmit power. For example, for a femto BS we consider anomni-directional antenna pattern and the following parameters.

1 poissonFemtoBS.antenna = parameters.basestation.antennas.

Omnidirectional;

2 poissonFemtoBS.antenna.height = 1.5;

3 poissonFemtoBS.antenna.nTX = 1;

4 poissonFemtoBS.antenna.transmitPower = 0.1;

Next, various user types can be added, differing in distribution, speed andmovement pattern, as represented with the code below.

14

1 poissonUsersSISO = parameters.user.Poisson2D ();

2 poissonUsersSISO.speed = 0;

3 poissonUsersSISO.userMovement.type = parameters.user.

MovementType.ConstPosition;

Additionally, with the parameter

1 poissonUsersSISO.indoorDecision = parameters.indoorDecision.

Random (0.1);

it can be specified that some of the users are placed indoors – 0.1 in ourexample means that 10% of users are indoors.

Having such a highly heterogeneous network, several link-specific pathloss models can be utilized. This is possible via a predefined look-up table (cf.Section 8.3.1) of possible path loss models specified for specific link conditions,e.g., LOS/NLOS or indoor/outdoor. In the example below it is illustratedhow this look-up table is defined for our heterogeneous scenario.

1 % Macro \ac{BS}

2 params.pathlossModelContainer.setModel(...

3 parameters.setting.BaseStationType.macro , parameters.

setting.Indoor.indoor , ...

4 parameters.setting.Los.LOS , parameters.

setting.PathlossModel.UMa3D);


7 parameters.setting.BaseStationType.macro , parameters.

setting.Indoor.indoor , ...

8 parameters.setting.Los.NLOS , parameters.

setting.PathlossModel.UMa3D);

910 % Pico \ac{BS}


12 parameters.setting.BaseStationType.pico , parameters.

setting.Indoor.outdoor , ...

13 parameters.setting.Los.LOS ,

14 parameters.setting.PathlossModel.FreeSpace);

1516 % Femto \ac{BS}


18 parameters.setting.BaseStationType.femto , parameters.

setting.Indoor.outdoor , ...

19 parameters.setting.Los.NLOS , parameters.

setting.PathlossModel.Indoor);

We chose the 3rd Generation Partnership Project (3GPP) Urban Macrocell (UMa)-3-dimensional (3D) pathloss model for links from macro BSs, a

15

free-space path loss model for links from pico BSs, and an indoor path lossmodel for links from femto BSs.

5.2.5 Manhattan city layout

The launcher file launcherFiles.launcherManhattanGrid.m provides anexample of how to simulate buildings and streets arranged according to a Man-hattan grid with BSs placed on the rooftop of buildings and users distributedalong the streets. The launcher file starts by calling the corresponding scenariofile located in +scenarios, in this case scenarios.ManhattanGridScenario,as shown in the code-line below.

1 result = simulate (@ scenarios.ManhattanGridScenario ,

parameters.setting.SimulationType.local);

The execution of this line will produce the results saved in the parameterresult. Afterwards, various plotting functions can be executed, dependingon the chosen post-processing method, already defined in the scenario file.For example, using the command


the simulated network consisting of all its network elements can be plotted, aswell as SINR and throughput ecdfs. It is possible to also add desired plottingfunctions in the launcher file. To demonstrate that, we give an example onhow to plot the entire scenario consisting of buildings, streets, BSs and users,as well as illustrating LOS and NLOS users attached to one of the BSs in thescenario.

As it can be seen, all the input parameters characterizing a particularsimulation scenario have to be included in the corresponding scenario file. Inour example of scenarios.ManhattanGridScenario, we show how to set upthese input parameters.

In this scenario we use a city layout for distributing the buildings by usingthe following code,

1 manhattanCity = parameters.city.Manhattan ();

2 manhattanCity.ySize = 50;

3 manhattanCity.xSize = 50;

4 manhattanCity.streetWidth = 20;

5 manhattanCity.minBuildingHeight = 10;

6 manhattanCity.maxBuildingHeight = 25;

7 manhattanCity.heightRandomSeed = 'shuffle ';

8 manhattanCity.wallLossDB = 10;

9 manhattanCity.saveFile = [];

10 manhattanCity.loadFile = [];

11 params.cityParameters('manhattan ') = manhattanCity;

16

where the size of the building block is specified by the parameters ySize andxSize, the width of streets by the parameter streetWidth as well as the mini-mum and maximum building heights with the parameters minBuildingHeightand maxBuildingHeight, respectively. Note that the street width also definesthe spacing between the buildings. The penetration loss per wall is specifiedin the parameter wallLossDB given in dB. There are two mechanisms builtinto the +blockages/City.m class that allow for reproducibility of results, aninteger seed for the random building height generator and an option for storingand loading city parameters to and from JSON files. Further explanation onthis topic can be found in section 8.1.3.

BSs in this scenario are macro BSs and are placed on top of the buildingsby using the code-lines

1 macroOnBuildings = parameters.basestation.MacroOnBuildings ();

2 macroOnBuildings.occupationProbability = 0.2;

3 macroOnBuildings.margin = 2;

4 macroOnBuildings.type = parameters.setting.BaseStationType.

macro;

5 macroOnBuildings.antennaHeight = 4;

6 macroOnBuildings.antenna = antenna;

7 params.baseStationParameters('macroOnBuildings ') =

macroOnBuildings;

where BSs are randomly distributed according to the occupation probabilitythat we set to 20 % in our example. The antenna height parameters de-scribes the antenna height above the building. Therefore the antenna heightparameter of the antenna parameters is not used in this scenario.

Antenna parameters are defined as

1 antenna = parameters.basestation.antennas.Omnidirectional;

2 antenna.nTX = 1;

3 antenna.transmitPower = 40;

Users are distributed along the streets and are assumed to be pedestrianswith a speed of 7km/h.

1 manhattanUsers = parameters.user.PoissonStreets ();

2 manhattanUsers.density = 0.006;

3 manhattanUsers.height = 1.8;

4 manhattanUsers.streetSystemName = 'manhattan ';

5 manhattanUsers.nRX = 1;

6 manhattanUsers.userMovement.type = parameters.user.

MovementType.ConstSpeedRandomWalk;

7 manhattanUsers.speed = 7/3.6;

8 manhattanUsers.channelModelTypes = parameters.setting.

ChannelModel.PedA;

9 manhattanUsers.indoorDecision = parameters.

indoorDecision.Geometry;

17

10 manhattanUsers.trafficModelType = parameters.setting.

TrafficModelType.ConstantRate;

11 params.userParameters('manhattanusers ') = manhattanUsers;

The simulator gives the possibility to save additional information at theend of the simulation such as a map indicating LOS/NLOS positions bysetting

1 params.save.losMap = true;

and a map indicating whether the user is indoor or outdoor by setting

1 params.save.isIndoor = true;

This additional information can be used in the launcher file for furthercalculations and plotting functions.

5.2.6 Manhattan city layout with QuaDRiGa channel model

The launcher file launcherFiles.launcherManhattanGridQuadriga.m showshow to use the QuaDRiGa channel model for a Manhattan city layout scenario.The launcher file calls the scenario file scenarios.ManhattanGridQuadrigaScenarioas follows in the code.

1 result = simulate (@ scenarios.ManhattanGridQuadrigaScenario ,


The QuaDRiGa channel model is selected with the command

1 poissonUsersSISO.channelModelTypes = parameters.setting.

ChannelModel.Quadriga;

For all other details please refer to the otherwise identical Manhattan citylayout scenario described in 5.2.5.

5.2.7 IoT with clustered nodes

The launcher file launcherFiles.launcherIoTclusteredUser.m providesan example of how to simulate a large network with internet of things (IoT)devices that are active in bursts at regular intervals. The IoT users areplaced in clusters around femto BSs, additionally users and macro BSs areplaced in the network according to a PPP. The launcher file starts bycalling the corresponding scenario file located in +scenarios, in this casescenarios.IoTclusteredUser.m, as shown in the code-line below.

1 result = simulate (@ scenarios.IoTclusteredUser , parameters.


18

The execution of this line will produce the results saved in the parameterresult.

Afterwards, various plotting functions can be executed, depending on thechosen post-processing method, already defined in the scenario file. To showall plots, that are predefined, the code-line below is executed.


To create users in clusters with a femto BS at the center of the clusterthe following lines of code have to be added to the scenario file.

1 clusteredUser = parameters.user.UniformCluster;

2 clusteredUser.nRX = 1;

3 clusteredUser.density = 25e-6; %

density of clusters

4 clusteredUser.clusterRadius = 50;

5 clusteredUser.clusterDensity = 3e-3; % density

of users in a cluster

6 clusteredUser.channelModelTypes = parameters.setting.

ChannelModel.Rayleigh;

7 clusteredUser.withFemto = true;

8 clusteredUser.femtoParameters.antenna = antennaFemto;

9 clusteredUser.trafficModelType = parameters.setting.

TrafficModelType.ConstantRate;

10 clusteredUser.trafficModel.numSlots (2) = 10;

11 clusteredUser.trafficModel.size = 94;

12 params.userParameters('clusterUser ') = clusteredUser;

The above lines define the IoT users with small packet sizes that are sentevery 10 slots.

The antenna at the center of the user clusters is defined as a simpleomnidirectional antenna with the following lines in the scenario file.

1 antennaFemto=parameters.basestation.antennas.Omnidirectional;

2 antennaFemto.nTX = 1;

3 antennaFemto.height = 10;

The transmit power of the femto BSs is not set in the scenario file, it isautomatically set according to the BS type at BS creation innetworkElements.bs.BaseStation.setGenericParameters with:

1 switch baseStationParameters.type

2 case parameters.setting.BaseStationType.macro

3 baseStationParameters.antenna.transmitPower = 20;

4 case parameters.setting.BaseStationType.pico

5 baseStationParameters.antenna.transmitPower = 2;

6 case parameters.setting.BaseStationType.femto

7 baseStationParameters.antenna.transmitPower = 0.1;

8 end

19

If a transmit power is set in the scenario file, these lines of code are notexecuted and the BS is simulated with the transmit power set in the BScreation properties.

Additionally users and macro BSs are placed according to a PPP in thesimulation region.

To display more detailed results, an additional plot is created in thelauncher file for this scenario. It shows the user throughput of the IoT usersand the PPP users separately:

1 hold on;

2 clusterUser = result.params.userParameters('clusterUser ').

indices;

3 pppUser = result.params.userParameters('pppUser ').indices;

4 clusterThroughput = result.userThroughputMBitPerSec.DL(

clusterUser ,:);

5 pppThroughput = result.userThroughputMBitPerSec.DL(pppUser ,:)

;

6 hold on;

7 tools.myEcdf(clusterThroughput (:));

8 hold on;

9 tools.myEcdf(pppThroughput (:));

10 xlabel('throughput in Mbit/s');

11 ylabel('ECDF');

12 legend('IoT user', 'PPP user');

As it can be seen above, the results for the different types of users caneasily be extracted from the results, since the indices of the users in the listof all users are saved for each user type. The results for different BS typescan be extracted in the same manner.

5.2.8 Lite version

The launcher file launcherFiles.launcherLiteSimulation.m shows howto run a lite simulation. The corresponding scenario file for this launcher isscenarios.basicLiteScenario.m. As explained in Section 8.11, the litemode can be used in all types of simulations. In this example in particular,BSs and users are deployed according to a PPP. All parameters can bechanged, but in this type of simulation some parameters like the schedulerare irrelevant. The line of code that defines, whether a simulation is lite ornot is:

1 params.postprocessor = simulation.postprocessing.

LiteWithNetworkPP;

By default, the postprocessor parameter is set to PartialPP, which runsthe full simulation. To select the lite mode, we can change this parameter

20

either to LiteWithNetworkPP or to LiteNoNetworkPP. The difference betweenthis lite postprocessors is explained in Section 8.12.

Once the simulation is done, the the function showAllPlots is called.


The plots given by this function depend on the lite postprocessor employedfor the simulation. If the postprocessor is LiteWithNetworkPP, the functionshowAllPlots is defined in simulation.results.ResultsLiteWithNetwork,and it plots the network elements positions and the users SINR. On theother hand, if the postprocesor is LiteNoNetworkPP, just the users SINR aredepicted as shown in the function showAllPlots ofsimulation.results.ResultsLiteNoNetwork.

5.2.9 Simulation of several chunks in parallel

The launcher file launcherFiles.launcherParallelSim utilizes the basicparameters set in scenarios.basicScenario.m, but simulates the samescenario twice, once with the local simulation type (for serial simulation) andonce with the parallel simulation type. The displayed simulation duration atthe end of the simulation demonstrates the speed-up through parallelization.More info on this topic can be found in Section 7.2 and Section 8.10.

1 % This line launches the simulation with the scenario defined

in

2 % scenarios.basicScenario with simulation type

3 % parameters.setting.SimulationType.local.

45 fprintf('Linear simulation :\n')

6 result_lin = simulate (@ scenarios.basicScenario , parameters.


78 % This line launches the simulation with the scenario defined

in

9 % scenarios.basicScenario with simulation type

10 % parameters.setting.SimulationType.parallel.

1112 fprintf('\n\nParallel simulation :\n')

13 result_par = simulate (@ scenarios.basicScenario , parameters.

setting.SimulationType.parallel);

More insights on parallelization gains that can be achieved can be foundin Section 9.

21

5.2.10 OpenStreetMap city layout

The launcher file launcherFiles.launcherOpenStreetMapCity.m providesan example of how to simulate buildings and streets arranged according toa real world city layout based on data from the OpenStreetMap database.This data is made available at [1] under the Open Database License (ODbL).The launcher file starts by calling the corresponding scenario file located in+scenarios, in this case scenarios.openStreetMapScenario, as shown inthe code-line below.

1 result = simulate (@ scenarios.openStreetMapScenario ,


The execution of this line will produce the results saved in the parameterresult. Afterwards, various plotting functions can be executed, depending onthe chosen post-processing method, defined in the scenario file. For example,using the commands

1 result.plotUserSinrEcdf ();

2 result.plotUserThroughputEcdf ();

plots the SINR and throughput ecdfs. It is also possible to add desiredplotting functions in the launcher file. To demonstrate that, we give anexample on how to plot the entire scenario consisting of buildings, streets,BSs and users in the scenario. Additionally we indicate which user has a LOSconnection to one of the BSs and which user is currently inside of a building.

As can be seen, all input parameters characterizing a particular simulationscenario have to be included in the corresponding scenario file. In this exampleof scenarios.openStreetMapScenario, we show how to set up these inputparameters.

In this scenario we use a city layout for distributing the buildings by usingthe following code,

1 openStreetMapCity = parameters.city.OpenStreetMap ();

2 openStreetMapCity.latitude =[48.1955904 ,48.1973271];

3 openStreetMapCity.longitude =[16.3690209 ,16.3718059];

4 openStreetMapCity.streetWidth = 5;

5 openStreetMapCity.minBuildingHeight = 10;

6 openStreetMapCity.maxBuildingHeight = 25;

7 openStreetMapCity.heightRandomSeed = 'shuffle ';

8 openStreetMapCity.wallLossDB = 10;

9 openStreetMapCity.saveFile = [];

10 openStreetMapCity.loadFile = [];

11 params.cityParameters('OSMCity ') = openStreetMapCity;

where the real world area, which in this case is centered around the TU ViennaGusshausstraße Campus, is specified by the min, max tuples of latitude

22

and longitude, the width of streets by the parameter streetWidth as wellas the minimum and maximum random building heights with the parametersminBuildingHeight and maxBuildingHeight, respectively defines the setup.It is good practice to determine the coordinates of desired real-world regionwith the ”Export” feature that can be found on [1]. The penetration lossper wall is specified in the parameter wallLossDB given in dB. There aretwo mechanisms built into the +blockages/City.m class that allow for repro-ducibility of results, an integer seed for the random building height generatorand an option for storing and loading city parameters to and from JSON files.This allows for, among other things, a manual specification of the buildingheights. Further explanation on this topic can be found in section 8.1.3.

The region of interest must be manually matched to the real-world region,which is shown in the following listing.

1 params.regionOfInterest.origin2D = [0; 0];

2 params.regionOfInterest.xSpan = 500;

3 params.regionOfInterest.ySpan = 500;

4 params.regionOfInterest.zSpan = 50;

It is also possible to add user-defined buildings to the scenario definition,which is shown in the following code.

1 predefBuilding = parameters.building.PredefinedPositions;

2 predefBuilding.floorPlan =

[ -140.815 , -118.1 , -127.515 , -153.5 , -140.815;

-21.1125 , -9.023 ,9.04 , -4.754 , -21.1125];

3 predefBuilding.height = 24;

4 predefBuilding.loss = 10;

5 predefBuilding.positions = [0; 0];

6 params.buildingParameters('predefBuilding ') = predefBuilding;

The shape of the building is determined by the floorPlan, which specifiesthe coordinates of the building corners. Furthermore, the height in meters,the wall loss in dB and the x, y position of the building(s) can be specified.

The two BSs in this scenario are macro BSs and are defined by thefollowing parameters

1 % First Base Station

2 BS1 = parameters.basestation.PredefinedPositions ();

3 BS1.type = parameters.setting.BaseStationType.macro;

4 BS1.positions = [ -139.815; -18.1125]; % X,Y coordinates

5 BS1.nSectors = 3;

6 BS1.antenna = parameters.basestation.antennas.ThreeSector;

7 BS1.antenna.nTX = 1;

8 BS1.antenna.height = 30;

9 BS1.antenna.transmitPower = 60;

10 params.baseStationParameters('BS1') = BS1;

23

1112 % Second Base Station

13 BS2 = parameters.basestation.PredefinedPositions ();

14 BS2.type = parameters.setting.BaseStationType.macro;

15 BS2.positions = [70; 92.355]; % X,Y coordinates

16 BS2.nSectors = 3;

17 BS2.antenna = parameters.basestation.antennas.ThreeSector;

18 BS2.antenna.nTX = 1;

19 BS2.antenna.height = 30;

20 BS2.antenna.transmitPower = 120;

21 params.baseStationParameters('BS2') = BS2;

where the BSs are placed with predefined positions in the OpenStreetMapcity. The type of the BSs is set to macro BSs, equipped with a three-sectorantenna. The antennas in the sectors are composed of one transmit antenna,as specified by nTX and can transmit with a power given by transmitPower.

Users are distributed on ground level according to a Poisson point processand do not miove. Users can be indoors or outdoors. The decision is basedon the actual geometry. Each user is equipped with a single receive antennaby default and the full buffer traffic model is used.

1 Users = parameters.user.Poisson2D ();

2 Users.nElements = 100; % number of users in the ROI

3 Users.height = 1.5;

4 Users.nTX = 1;

5 Users.nRX = 1;

6 Users.indoorDecision =parameters.indoorDecision.Geometry;

7 Users.channelModelTypes = parameters.setting.ChannelModel.

PedB;

8 Users.userMovement.type = parameters.user.MovementType.

ConstPosition;

9 Users.userMovement.speed = 0;

10 Users.trafficModelType = parameters.setting.

TrafficModelType.FullBuffer;

11 params.userParameters('Users ') = Users;

The simulator gives the possibility to save additional information at theend of the simulation such as a map indicating LOS/NLOS positions bysetting

1 params.save.losMap = true;

and a map indicating whether the user is indoor or outdoor by setting

1 params.save.isIndoor = true;

The constellation of network elements created by the scenario is shownin Fig. 1. The blockages and streets are shaped an placed according to

24

Figure 1: Network elements of the OpenStreetMap scenario.

25

Figure 2: LOS connection vs. indoor users.

information downloaded from [1]. The blue dots correspond to users andthe red dots correspond to BS, which are placed according to the scenariospecification. The coordinate system is in meters and displays the x, y distanceto the origin of the scenario. As mentioned further above, the launcher filealso includes an example which shows how custom plots can be created. InFig. 2 all outdoor users are plotted in green and all users inside a blockageare displayed in blue. Furthermore, for all users with LOS to a BS, thisconnection is indicated with a red line.

5.2.11 NOMA

In a NOMA transmission two users in a NOMA pair share the resources allo-cated to them and the user with better channel conditions performs SuccessiveInterference Cancellation (SIC), while the user with weaker channel conditionssuffers a small amount of additional interference from the transmission of thestrong user. The implementation of a NOMA transmission is described inSection 8.9.

The example scenario for a NOMA transmission in the VCCS 5G SLS,that is defined in +scenarios.noma, simulates a single cell with two NOMAuser pairs. The network setup is shown in Fig. 3. In the launcher file for the

26

80 dB

120 dB115 dB

85 dB

Figure 3: Network setup for Non Orthogonal Multiple Access (NOMA)example scenario. A NOMA simulation with two NOMA user pairs and anOrthogonal Multiple Access (OMA) simulation with only the two near users(in dark blue) are performed. The users are paired for NOMA transmissionas indicated by the black lines between the users.

NOMA example +launcherFiles.launcherNoma, a NOMA transmission iscompared to an OMA transmission. For the OMA transmission, the NOMAfar users shown in light blue in Fig. 3 are removed from the simulation.

In Fig. 3, the path loss to the BS is indicated for each user. In the+scenarios.noma this path loss is set through the positions of the users andthe free space path loss model. The set path losses assure a large differencein channel quality between the near user and the far user in a NOMA pair. Alarge difference in channel quality is necessary for successful and efficient SIC.

To set up a NOMA transmission, the NOMA parameters from +parameters.Noma

have to be set. The setting for this scenario is shown in Listing 1.

Listing 1: Setting of NOMA parameters for a NOMA transmission.

1 params.noma.interferenceFactorSic = 0;

2 params.noma.maxFarCqi = 6;

3 params.noma.deltaPairdB = 15;

4 params.noma.mustIdx = parameters.setting.MUSTIdx.Idx01;

In the first line the SIC interference factor is set to 0. This parameter indicatesthat, after a successful SIC, no interference from the canceled signal is left. Ifthe SIC interference is set to a higher value, residual interference from thefar user will be simulated for the near user after successful SIC. The SICinterference factor should be between 0 and 1 and indicates the amount ofresidual interference from the canceled signal, i.e. a SIC interference factorof 0.3 indicates that 30% of the signal power from the far user remain asinterference for the near user, even after successful SIC.

27

In the second line of Listing 1, the maximum Channel Quality Indicator(CQI) used by the far user in a NOMA pair is set. The CQI of the far userin a NOMA pair can be limited to increase the success chances of SIC and toassure successful transmissions for the far user.

In the third line of Listing 1 the minimum distance between the cellassociation metrics of users in a NOMA pair ∆ is set. The larger the chosen∆ is, the fewer users will be paired for NOMA transmissions. The advantageof a larger ∆ is that it increases the number of successful SICs and thus theefficiency of the NOMA scheme.

The last line in Listing 1 sets the Multi-User Superposition Transmission(MUST) index. The MUST index sets the power share factor for a NOMAtransmission, that decides how much power is allocated to the near user andhow much power is allocated to the far user as specified in [2]. A MUST indexof 0 indicates only OMA transmissions and higher MUST indices indicatethe use of NOMA transmissions.

28

6 Comparison to LTE-A SL Simulator

The aim of this comparison is to show that results obtained with the ViennaLong Term Evolution-Advanced (LTE-A) SL Simulator can be reproducedwith the Vienna 5G SL Simulator. For this purpose, the same parameter setis used in both simulators. The chosen parameters can be found in Table 2.

Parameter Value

base stations hexagonal layout, 1 ring, 7 BSsusers 50, uniform density

pathloss model COST231 Urban Macro (UMa)channel model Pedestrian A PDPTTIs/slots 100

feedback delay 3user speed 30 km/h

Table 2: Simulation parameters used to compare the Vienna LTE-A SLSimulator and the Vienna 5G SL Simulator

The simulations were run 200 times to make sure that the results can becompared fairly. Several metrics are used for this comparison.

At first, it is important to show that the user placement works the sameway in both simulators. This is demonstrated by the ecdf of the distancesbetween the users and their assigned BS as depicted in Fig. 4.

Next, the ecdf of the wideband SINR as shown in Fig. 5 is examined. Theclose match of the curves indicates that the statistics of the macroscopic pathloss computed by both simulators are very similar to each other.

Finally, the ecdf of the average user throughput obtained by both simula-tors is compared in Fig. 6.

Here, small discrepancies between the curves can be noticed. They arecaused by minor implementation differences between the simulators. Never-theless, these simulations still show that the channel models and the functionof the MAC layer behave similarly in both simulators, even with a non-zerofeedback delay and a non-zero user speed.

29

0 100 200 300 400 500 600 700 800 900x in meters

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1F(

x)Vienna LTE-A SL SimulatorVienna 5G SL Simulator

Figure 4: ecdf of the distances between users and their assigned BS.

-10 0 10 20 30 40 50 60x in dB

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

F(x)

Vienna LTE-A SL SimulatorVienna 5G SL Simulator

Figure 5: ecdf of the wideband SINR.

30

0 2 4 6 8 10 12x in Mbps

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

F(x)

Vienna LTE-A SL SimulatorVienna 5G SL Simulator

Figure 6: ecdf of the average user throughput.

31

7 Simulator Structure

7.1 A Typical Simulation

The Vienna 5G SL Simulator is written in MATLAB and is utilizing OOP.Individual parts of the simulator are separated into different packages and,e.g., network elements, such as BSs, are defined in classes. In general, thesimulator is written in a modular fashion, such that new functions can beadded easily, without the need to alter other parts of the code.

The simulator’s structure is defined by four major parts, which are dis-played in Fig. 7.

In the following, the most important steps of a simulation are explainedand the corresponding functions to the four major parts of the simulator areintroduced. 1

Each simulation begins with running the desired simulation launcher file(cf. Section 5). This already fixes the parameter set which is going to be usedfor this particular simulation. In the file simulate.m, you find the line

1 %create simulation object

2 localSimulation = simulation.LocalSimulation(params);

where the simulation object is created and the predefined parameters areattached to this object.

Next, the simulation time line (cf. Section 7.2) is generated, as well asthe network element objects (cf. Section 8.1). Additionally, the fast fadingtraces are pregenerated, if necessary. This is done in

1 %setup simulation and generate network elements

2 localSimulation.setup ();

All of this is stored in localSimulation.simulationSetup.Now that the pregeneration is done, the actual simulation is carried out.

The following line contains the main simulation loop (over chunks and TSs -cf. Section 7.3):

1 %main simulation loop

2 localSimulation.run();

Here, random samples in time (represented by channel realizations andscheduling decisions) and/or in space (represented by the geometry of thenetwork elements) are simulated and the individual results for each TS arestored.

The postprocessing step then follows in

1Here we describe a local simulation - i.e., we set SimulationType.local. The explainedsteps are the same for a parallel simulation.

32

Scenario choice

Initialization Pregeneration Main Sim. Loop Postprocessing

Parameterinitialization

Compatibilitycheck

Generate network elements

Generate blockages

Distribute to chunks

Process chunksindependently

Updates of MF-values per segment

Combine outputfrom all chunks

Process TS resultsinto average values

Store results

Loop over TSs

Figure 7: Overview of the main parts of the simulator.

1 % get results

2 simulationResults = localSimulation.simulationResult;

where the individual results from the main simulation loop are extracted andstored in the results object. Which results are actually calculated and storedalso has to be specified in the simulation parameters. After processing andstoring the results, selected results are plotted, which is integrated in thesimulation launcher.

7.2 The Simulator Time Line

The time line of the simulator is divided into three different units, namelytime slots (TSs), segments and chunks. The TS is the shortest unit andalso corresponds to the scheduling granularity. Thus it corresponds to oneiteration of the inner simulation loop (cf. Section 7.3). It has a constantlength, e.g., 1ms to represent an LTE-A subframe, but can otherwise bespecified freely. A segment consists of various time slots and corresponds tothe time (and distance) in which the macroscopic fading (MF) is assumed tobe constant (e.g., the user association, large scale path loss values, but not thechannel realization). Thus, the MF values are only updated at the beginningof a segment, including the user association. The length of a segment dependson the user speed and trajectory, as well as the correlation distance of theMF values. This means that for a stationary scenario, only a single segmentis created. A chunk consists of a fixed number of TSs and on one or moresegments (depending on the maximum user speed). For creating the usertrajectory, a consecutive generation is assumed, but also a considerably longdistance between chunks, which leads to uncorrelated user positions amongchunks. Even for stationary scenarios, channel coefficients are assumed to be

33

Chunk 1 Chunk 2 Chunk N

M segments per chunk

K TS per segment

N chunks in total

Figure 8: The different time units utilized in the simulator.

uncorrelated, due to the assumption of a non-constant scattering environment.The chunks are also the basis for parallelization, since all necessary datais independent for each chunk and the results can be calculated withoutknowledge of the simulation result of the previous chunks. A more detaileddescription of the parallelization can be found in Section 8.10.

The following parameters are utilized to set up the time line:

1 params.time.numberOfChunks = 2;

2 params.time.slotDuration = 1e-3; % duration in seconds

3 params.time.slotsPerChunk = 10; % each chunk consists of that

many slots

4 params.time.timeBetweenChunksInSlots = 50; % timespan between

two simulated chunks

In the function simulation.ChunkSimulation.m, the following functionis contained:

1 function setNewSegmentIndicator(obj)

2 % creates a logical array that is true for all slots that are

the first in a segment

3 % Marks all slots , for which a user has moved further than

the

4 % maximum correlation distance. Large scale parameters are

5 % constant for a segment.

This means that based on the trajectory and correlation distance an indicatoris set, where a new segment starts.

34

Scheduler

LQM

Feedback

LPM

Update channel

Scheduler

LQM

Feedback

LPM

Update channelU

pdat

e la

rge

scal

e par

amet

ers

per

seg

men

t

Scheduler

LQM

Feedback

LPM

Update channel

independent chunks

Figure 9: A representation of the main simulation loop.

7.3 The Main Simulation Loop

The main simulation loop contains a loop over chunks, whereas each chunkcontains a loop over TSs (cf. Fig. 9). The loop over chunks is contained inthe function simulation.LocalSimulation.run for local simulations:

1 % initialitze chunk result list

2 chunkResultList(obj.parameters.time.numberOfChunks) =

simulation.ChunkResult;

34 % run simulation for each chunk

5 for ii = 1:obj.parameters.time.numberOfChunks

6 fprintf('simulating chunk %d...\n', ii);

7 obj.chunkSimulationList = [obj.chunkSimulationList ,

simulation.ChunkSimulation(obj.simulationSetup.

chunkConfigList(ii))];

8 chunkResultList(ii) = obj.chunkSimulationList(ii).

runSimulation ();

9 end

35

and in the function simulation.ParallelSimulation.run for parallel sim-ulations:

1 % prepare chunk simulation list

2 chunkSimulationList = [];

34 for ii = 1:( obj.parameters.time.numberOfChunks)

5 chunkSimulationList = [chunkSimulationList , simulation.

ChunkSimulation(obj.simulationSetup.chunkConfigList(ii))

];

6 end

78 % run simulations for all chunks

9 parfor ii = 1:obj.parameters.time.numberOfChunks

10 fprintf('simulating chunk %d...\n', ii);

11 chunkResultList(ii)=chunkSimulationList(ii).runSimulation ();

12 end

For both options, all necessary data is distributed among chunks. Thisindividual configuration per chunk is stored in chunkSimulationList.

Irrespective of local or parallel simulation, each chunk contains the innerloop over TSs. This loop can be found in the functionsimulation.ChunkSimulation.runSimulation, where the loop begins afterseveral initializing steps:

1 %% main simulation loop

2 for iSlot = 1:obj.nSlots

At the beginning of this loop, cell association and handovers are handled:

1 if obj.chunkConfig.isNewSegment(iSlot)

2 % In a new segment the cell association can change and

3 % handovers need to be performed.

45 % update cell association if this is new segment

6 obj.updateUsersAttachedToBaseStations(iSlot);

78 % find cells that belong in the interference region

9 obj.filterPureInterferenceCells(iSlot);

1011 % perform handovers - clear feedback buffers of users in new

cell

12 obj.performHandover(iSlot);

1314 end % if this slot is the first one in a segment

Another segment update is performed per user and sets the appropriate MFvalues for each user for the current segment:

36

1 if obj.chunkConfig.isNewSegment(iSlot)

2 bb = obj.userToBSassignmentArrayDL(iUE , obj.getiSegment(iSlot

));

3 desired = false(1, obj.nAntennas);

4 desired(bb) = true; % only works for one antenna per bs

56 % get new macroscopic parameters

7 thisShadowFadingdB = obj.shadowFadingdB (:, iUE , iSlot).';

8 pathlossdB = obj.pathLossTableDL (:, iUE , obj.getiSegment(

iSlot)).' + obj.wallLossdB (:, iUE , obj.getiSegment(iSlot))

.';

9 gaindB = obj.antennaGaindB (:, iUE , obj.getiSegment(iSlot)).';

1011 % update macroscopic parameters

12 LQMDL(iUE).updateMacroscopic(desired , pathlossdB , gaindB ,

thisShadowFadingdB);

13 end

37

8 Overview of Key Functionalities

8.1 Generation of Network Elements and Geometry

System level simulations aim to evaluate the performance of a large networkcomprising a substantial number of BSs and users. In this regard, at its corethe Vienna 5G SL Simulator simulates the communication between users andBSs. Due to its modular structure, the simulator allows the coexistence ofdifferent BS and user types. This, on one hand, allows to simulate multi-tiernetworks, and on the other hand, by also supporting different user types,more diverse and realistic scenarios are supported. Additionally to variouspropagation models that can be used, there is the option to distribute blockageobjects and use the geometry to calculate different propagation parameters.

8.1.1 Base Stations

The simulator distinguishes between the entity BS and antenna, the twoobjects are depicted in Fig. 10. Each BS can have one or more antennasattached, which can be seen as physical entities with a position {x, y, z}in the 3D space. The antenna object represents an antenna or an antennaarray with NTx transmit and NRx receive antennas. BSs do not have physicallocations but instead, the physical positions are specified on the assignedantenna objects. This structure also enables the simulation of DASs andRRHs without additional extensions.

Base Station: attached users resource allocation:- user allocation- power allocation

Antenna

radiation patternpositionNTx

Antenna

Figure 10: Abstract BS with two attached antennas with physical positionsin the simulation region.

Base Station The BS object handles the physical resources available fortransmission. It is defined in +networkElements/+bs/BaseStation.m and

38

holds a list of all antennas that belong to this BS as well as a list of userscurrently attached to this BS. Each BS has a scheduler that allocates theavailable resources to the users attached to the BS.

Different placement methods that can be used to define placement of BSsare given in +networkGeometry. Which placement method is to be used,is specified in the scenario file by specifying the parameters for the desiredplacement method that can be found in +parameters.basestation (see 5.2.4for more details). It is worth noting that in the initialization phase of thesimulation, the BSs are defined through a positioning mechanism and inthe main simulation loop, the BSs do not have a position in the ROI, onlytheir attached antennas have a physical position. This is because, in thepregeneration phase, the positions generated for each BS type are moved tothe antenna objects attached to the BSs.

Each BS type, e.g. macro or femto BS, is indicated with an enumeration,specified in the corresponding file +parameters/+setting/BaseStationType.m.If a new BS type is to be added in the simulator, then it has also to be in-dicated with a corresponding enumeration. Additionally a default transmitpower and path loss models should be specified for new BS types.

Antenna The antenna object is defined in +networkElements/+bs/Antenna.m.The antennas have a position in the ROI and collect all parameters necessaryto calculate the antenna gain for their antenna type. The scheduling informa-tion provided by the BS is stored at and accessible through the antenna ob-ject. Various antenna types are defined in +networkElements/+bs/+antenna

and their respective parameter files for antenna creation can be found in+parameters/+basestation/+antennas. Two important parameters for an-tenna gain calculation are the antenna azimuth φ and antenna elevation θ.Fig. 11 clarifies the definition of both, where the origin would be the positionof the antenna and the direction of the arrow where the antenna would haveits maximum gain. The elevation is only used in the antenna gain calculationof antenna arrays. Note that θ = 0◦ would mean that the antenna wouldhave its maximum gain in the direction of the zenith. The default values areϕ = 0◦ and θ = 90◦.

Sectorized Base Stations The number of base station sectors is 1 bydefault. To simulate more than one sector, the number of BS sectors has tobe specified with the BS parameter nSectors. The horizontal direction ofthe antenna, or the horizontal direction of the first sector antenna if there ismore than one sector, can be specified with the antenna azimuth parameter.It is possible to specify up to 6 sectors. The following setting of parameters

39

Figure 11: Illustration of antenna azimuth and elevation

Figure 12: Base stations with multiple sectors and rotation φ

would result in a BS with three sectors like it is shown in the left part ofFig. 12. The antennas in the sectors are set to be three sector antennas andthe rotation φ of the antenna in the first sector is 15 degrees. The anglebetween two antennas results in

360◦/3 sectors = 120◦.

1 baseStation = parameters.basestation.PredefinedPositions ();

2 baseStation.positions = positions;

3 baseStation.nSectors = 3;

4 antenna = parameters.basestation.antennas.ThreeSector;

5 antenna.azimuth = 15;

6 baseStation.antenna = antenna;

8.1.2 Users

The user object, as the other endpoint of the communication link, is definedin +networkElements/+ue/User.m. The user class, like the antenna, has a

40

position in the ROI and collects parameters to define the channel betweenuser and antenna, which include the channel model and the number of RadioFrequency (RF) transmit and receive chains.

Different placement methods that can be used to define placement ofusers are given in +networkGeometry. Which placement method is to beused, is specified in the scenario file through the parameter classes defined in+parameters.user (see 5.2.4 for more details how to set different user typeswithin one scenario).

8.1.3 Blockages

On top of the the network element generation, the Vienna 5G SL simulatorsupports the generation of blockages. The super class of blockage elements isdefined in +blockages/Blockage.m. The basic building block to representsignal blocking objects, is a wall with arbitrary dimensions and orientation in3D. Buildings are then created by combining multiple walls. With these, citylayouts can be generated, such as a Manhattan grid with streets and buildingblocks.

The buildings in the scenario are not restricted to a rectangular layout.To create an object of +blockages/Building.m the following properties needto be specified:

� floorPlan - array of x and y coordinates

� height - height of the building

� loss - loss through its walls in dB

An example of such an arbitrary building and its floorPlan is given infigure 13

Additionally there is the option to generate buildings together with streets,which is implemented in the +blockages/City.m class. This abstraction pro-vides two mechanisms for reproducibility of simulation results, which can beconfigured by the following parameters in +parameters/+city/Parameters.m.

� heightRandomSeed - integer seed or shuffle

� saveFile - JSON file where the city should be stored

� loadFile - JSON file to load the city from

Using the same heightRandomSeed will produce the same building heightson every simulation run, while using ’shuffle’ will lead to different heightson every run. If a city is stored to a JSON file, the building heights andmany other parameters of buildings and streets can be adjusted manually

41

Figure 13: Building and floorPlan

by editing the file and then loading it again on subsequent simulation runs.The following listing shows a segment of an exemplary JSON file, where theparameters stored for every building in the city are visible.

1 {buildings: [{name: Karlsgasse 13, floorPlan: [[ xCoords], [yCoords

]], height: 19.0, loss: 10}, ...], streetSystem...: { ... }}

There are two types of cities which can be found in ManhattanCity.m,where buildings and streets are generated according to a Manhattan gridlayout or in OpenStreetMapCity.m, where streets and buildings are generatedbased on real-world data from OpenStreetMap [1]. Here the buildings andstreets that are located in a certain area specified by coordinates are fetchedvia GET-request from [1]. This data is then processed and a floorPlan isderived for the buildings and a street layout is created. For an example of anOpenStreetMap scenario, refer to Section 5.2.10.

8.1.4 Cell association

In the Vienna 5G SL simulator, two different strategies for user-to-BS associ-ation are possible. These are:

� association according to maximum SINR

� association according to maximum received power

The cell association strategy has to be chosen in the scenario file, by settingone of the following lines,

1 % maximum SINR

2 params.downlinkAssociationStrategy = parameters.

setting.CellAssociationStrategy.maxSINR;

42

or

1 % maximum received power

2 params.downlinkAssociationStrategy = parameters.

setting.CellAssociationStrategy.maxReceivePower;

Based on the users choice a different object of a subclass +cellManagementis instantiated. This object handles all the parameters and functionalityrelevant for the cell association and is therefore called the cellManager. ThecellManager.computeCellAssociation computes and sets the internallystored user-to-BS association for every segment in the current chunk. Toachieve this the information of the current path loss, antenna gain andpenetration loss are forwarded for each possible link (BS-to-user). Due touser mobility, the cell association is updated on segment basis and wheneverthere is change in the network that affects the cell association conditions.

8.1.5 Mitigation of Border Effects

In SL simulations with finite simulation areas the network interference isinadequately represented for users that are close to the border of the simulatedregion. To mitigate these border effects, an interference region can be addedto the simulation area in the Vienna 5G SL simulator. Alternatively awraparound can be performed to simulate interference from outside of thesimulation region. Which mitigation scheme is more reliable and efficientdepends on the size of the ROI and the path loss exponent of the used pathloss model [3].

The different options for border effect mitigation schemes can be found inparameters.setting.Interference and the desired mitigation scheme canbe set in parameters.Parameters.regionOfInterest.interference.

Interference Region The interference region is an addition to the ROI atits border, as depicted in figure 14.

The settings for size and user placement in the interference region aredescribed in parameters.regionOfInterest.RegionOfInterest, the op-tions for different user placements in the interference regions are listed inparameters.setting.Interference. The users in the interference regioncan either be placed in the same manner as in the ROI or a fixed number ofusers is uniformly distributed in the interference region. The placement of theBSs and their antennas is an extension of the BS placement in the ROI. Theuser placement strategy is chosen, when setting an interference region withthe parameter RegionOfInterest.interference. This is also described inSection 5.2.7.

43y p

os [km

]

x pos [km]0

0

5.5

5.5

-5.5

-5.5

9

9

-9

-9

fully simulated BS

interfering BS

InterferenceRegion.xSpan

region of interest

interference region

RegionOfInterest.xSpan

· interferenceRegionFactor

Figure 14: ROI (in white) with an ad-ditional interference region (in gray)with BSs creating additional interfer-ence for users at the border of the ROI.

The size of the interference region is set with the parameter RegionOfInterest.interferenceRegionFactor. It indicates by which factor the total simulationregion is bigger than the ROI, i.e., the diameter of the ROI is multiplied bythis factor to get the diameter of the interference region.

To save computational complexity the BSs in the interference region are notfully simulated unless a user of the ROI is attached to them. Instead, simplifiedrandom scheduling and feedback are used to simulate the interference regionBSs.

Figure 15: ROI (in white) withreplicated BSs (in gray area).Each user chooses the closest BSsas virtual ROI. This is repre-sented by black boxes surroundingeach mobile station.

44

Wraparound To perform a wraparound, the BS positions are replicatedaround the ROI and each user chooses the BS positions closest to it for thesimulation as is indicated by the black boxes in Fig. 15. This virtually placeseach user at the center of its ROI, thus eliminating effects concerning theusers at the border of the ROI.

8.2 Link Quality and Link Performance Model

8.2.1 Link Abstraction

basebandprecoder

W[nTX x nLayer]

analogprecoder

Wa[nTXelements x nTX]

channel

H[nRX x nTXelements]

receive filter

F[nLayer x nRX]

nRXnTXelementsnTXnLayer nLayer

Figure 16: Abstraction of a link between a BS and a user. Each step isrepresented by a matrix in the simulation. The dimension of the matrixis indicated in squared brackets. nLayer represents the number of layers,nTX the number of transmit RF chains, nTXelements the number of antennaelements at the transmitter and nRX the number of receive antennas.

While the modulation and coding schemes are abstracted in the LPMthrough the use of Block Error Ratio (BLER) curves for SINR to BLERmapping, the precoder, channel and receive filter are represented by matricesin the LQM. Details about the precoders are discussed in Section 8.4, detailsabout the channel in Section 8.3.3. The receive filter is assumed to be a ZeroForcing (ZF) filter.

Figure 16 shows the processing chain modeled in the LQM. Each step inthe processing chain is represented by a matrix of the dimension indicated insquared brackets in Fig. 16.

Terminology In the following, the terms used in Fig. 16 are related tocommonly used terms and terms used in 3GPP standards. The layers thatare input for the baseband precoder are also often referred to as streams oruser streams. The nTX transmit RF chains are referred to as TransceiverUnit (TXRU) in 3GPP standards related to analog precoding, where analogprecoding is referred to as TXRU virtualization. The concept of antenna portsand antenna port mapping is from LTE-A standardization is not implementedin the Vienna 5G SL Simulator - equivalently it can be seen as a one to one

45

mapping - and the number of transmit RF chains nTX is always equal to thenumber of antenna ports nAtPort.

The number of transmit antenna elements nTXelements refers to thenumber of antenna elements, i.e. the antennas represented by crosses inFigs. 20 and 21. On the receiver side, nRX represents the number of receiveantennas.

8.2.2 Link Quality Model

wideband SINR

post-equalization SINRnRBFreq

nR

BT

ime

nLay

er

Figure 17: Output of the LQM for one time slot: the post-equalization SINRis calculated for each resource block and each layer, the wideband SINR iscalculated for each slot.

The Link Quality Model (LQM) quantifies the quality of a link [4] in twoSINR measures: the post equalization SINR, that is calculated for each layerof each resource block, and the wideband SINR that represents the quality ofall physical resources in one time slot. The dimensions of the output of theLQM are depicted in Fig. 17.

The post equalization SINR takes into account the utilized receive filterand precoders and the inter layer interference, as well as the transmit powerallocation. The wideband SINR is calculated based on the large scale param-eters and considers antenna gain and path loss in its calculation, as well astransmit power and noise.

To calculate these SINR values, the LQM needs constant parameters,like the receiver noise figure, that are set in the class constructor, largescale parameters, like path loss and antenna gain, that have to be updatedfor each segment with the function updateMacroscopic and small scalechannel parameters that change for each time slot, like the channel matrixand transmit power allocation, that are updated in updateSmallScale. The

46

small scale fading

linkperformance

model

sched

uling

power allocation

assigned resources(PHY)

precoding

wideband SINR

post-equalization SINR

linkqualitymodel

network layout

pathloss(including wall loss)

shadow fading

antenna gain

position-dependent time-dependent

Figure 18: Schematic of the LQM.

example function shows how to use the LQM package. The general (simplified)functioning of the LQM is depicted in Fig. 18.

The implementation assumes that a Zero Forcing receive filter is used andthat the small scale fading is constant for the duration of a time slot. It isalso assumed that if no user is scheduled at an interfering BS, that this BSdoes not generate any interference, unless the alwaysOn feature is activatedat the BS antenna. Further assumptions are that one receiver operates on aconstant number of layers within a time slot and that the allocated transmitpower is evenly distributed between those layers.

8.2.3 Link Performance Model

The Link Performance Model (LPM) takes the SINR values that were cal-culated by the LQM and the decision of the scheduler to determine thethroughput of a given user in terms of the number of bits. This is done inthree steps:

1. Calculate an average SINR value for every transmitted codeword overall scheduled Resource Blocks (RBs) and transmission layers.

2. Map the average SINR to a BLER value

3. Determine the number of transmitted bits based on the CQI and theBLER.

The last step is based on a Bernoulli experiment that determines if the currenttransmission was successful or not. In the case of a successful transmission

47

the number of transmitted bits is set to the maximum size of the TransportBlock (TB) for the scheduled RBs and for a transmission failure it is set tozero. In the simulator it is possible to select if the LPM should perform theBernoulli experiment in every slot or if it should give the expected value ofthe experiment as output.

On top of the actual throughput the LPM calculates an upper bound onthe throughput. This upper bound is the throughput that would result if thescheduler decides for the CQI that would result in the highest throughput. Toget this value the LPM performs the above mentioned steps for all possibleCQI values and takes the maximum over the resulting throughput.

8.3 Simulation of Propagation Effects

8.3.1 Path Loss Modeling and Situation dependent Model Choice

The aim, when implementing the path loss modeling was to assure modularityand flexibility on one hand but a simple, straight forward usage on the other.

As for the other parts of the simulator an object oriented approach waschosen. The superclass PathlossModel ensures that all path loss models canbe used in the same way with the functions set in it. Like the other models,it can be found in the package macroscopicPathlossModel.

For a description of the necessary parameters to be set, an enumerationfile parameters.setting.PathlossModel lists and describes all availablepath loss models. Another advantage of this enumeration file is that it offersautocomplete for the path loss model names, when choosing a model. Thepath loss is calculated without wall loss and antenna gain.

The actual path loss values are calculated for each chunk separately insimulation.ChunkSimulation.calculatePathloss. This function is calledin the initialization phase of each chunk, before the loop over TSs. Firstof all, the link condition is determined, e.g., LOS or NLOS link. Then, theappropriate model for the considered link type is chosen. An example ofthis can be found in the scenario file for the predefined scenario described inSection 5.2.4.

8.3.2 Modeling of Shadow Fading

Here should be added:

� explanations for wall loss calculations

� explanations of the use of shadow fading vs wall loss and a warningthat there is no ray tracing

48

The modeling of the Shadow Fading (SF) is based on Shadow Fading maps(SFMs). Those SFMs are arrays of so called Shadow Fading Values (SFVs)which are spatially correlated Random Variables (RVs). Such an array ofRVs can be generated by means of the following steps:

1. Generate an array of uncorrelated Gaussian RVs

2. Apply the FFT to the array

3. Multiply the transformed array with the Power Spectral Density (PSD)of the intended spatial correlation

4. Apply the inverse FFT

The advantage of this method is, that correlated shadow fading values forpositions with minimal granularity can be generated without the need toresolve the whole ROI with the same precision. A more precise explanationon this topic can be found in [5].

8.3.3 Modeling of Small Scale Fading - Channel Models

PDP Channel Models: The used channel models are defined througha Power Delay Profile (PDP). Descriptions of the available channel modelscan be found in the enumeration file parameters.setting.ChannelModel.This enumeration file also refers to the standards, in which the models aredefined [6–10].

QuaDRiGa Channel Model: The QuaDRiGa channel model [11] is ac-cessible through the Quadriga Interface provided as part of the SmallScaleFadingpackage. The interface is contained in the QuadrigaContainer file. A de-tailed description of this channel model can be found in the QuaDRiGadocumentation [12].

Before using QuaDRiGa for the first time, its source code has to be down-loaded from the developer’s website https://quadriga-channel-model.deand the quadriga src folder has to be copied to the simulator’s main directory.Currently, the simulator only supports QuaDRiGa v.2.4.0.

Please keep in mind that in order to use QuaDRiGa, you have to respectits license agreement (which is included in the download).

The QuaDRiGa channel model can be activated by setting parameters.

setting.ChannelModel.Quadriga as the channel model in the scenario file.The interface passes all relevant simulation parameters to QuaDRiGa. Ad-ditional QuaDRiGa-specific parameters can be set in the file parameters.

channelModel.QuadrigaParameters.

https://quadriga-channel-model.de

49

Trace Generation: For the PDP channel models, channel traces aregenerated before the main simulation loop. The generation of these channeltraces is handled by the PDPcontainer in the smallScaleFading package.There, all possible combinations of number of receive antennas, number oftransmit antennas, carrier frequency and channel model that can occur duringthe simulation are evaluated and channel traces for these scenarios are savedin the folder dataFiles/channelTraces. If necessary, a different folder canbe specified in the SmallScaleParameters class.

To get the channel realizations for a time slot the function PDPcontainer.

updatePDPcontainer loads the needed channel traces into memory and thefunction PDPcontainer.getChannelForAllAntennas selects a random partof the trace to get a channel realization for one time slot. The channel tracesshould be much longer than the total simulation time to assure that thesamples taken from the trace are independent from each other, but the traceshould be as short as possible, since they require memory. The length of thechannel traces has to be set in the SmallScaleParameters class.

The function smallScaleFading.example shows how to use the PDPcontainer to generate channel traces for the link quality model and whatparameters need to be set.

Assumptions: In general the channel is assumed to be constant in timefor a time slot and a single value is calculated for the channel in the timedomain. In case more different values for a TS are needed, a short block fadingscenario is possible. For this the SmallScaleParameters class symbolTimeshas to specify the time indices of the resource elements for which a channelrealization should be calculated.

In the frequency domain the channel is assumed constant for a resourceblock. Values for all subcarriers are calculated but only a fraction of them issaved in the channel traces. In the SmallScaleParameters class this fractioncan be specified, otherwise one value is saved for each resource block infrequency.

When the option correlated fading is chosen, the channel model is createdaccording to [13] and a constant user speed has to be set to generate a channeltrace. This constant user speed is used to calculate the Doppler frequency forthe channel.

8.4 Precoding

The precoders perform a mapping from the different layers to RF chainsand from RF chains to antenna elements, as is depicted in Fig. 16. Theprecoders are collected in the +precoders package and used in the LQM,

50

the feedback, and the scheduler. In the LQM, the choice of the precoderinfluences the calculated received powers for desired and interfering links andthus the calculated SINR. In the LTE feedback, each baseband precodercodebook is considered to calculate the expected SINR and then the feedbacksets the Precoding Matrix Indicator (PMI) to maximize the SINR. In thescheduler this PMI is finally used to set a baseband precoder individually foreach resource block.

8.4.1 Baseband Precoding

The baseband precoder is chosen individually for each resource block and mapsthe different layers to transmit RF chains. The layers are also often referredto as user streams. Baseband precoding is also referred to as digital precoding.The baseband precoder can utilize feedback values to choose a precodingmatrix from a codebook. The documentation of each precoder refers to thefeedback types that set the necessary feedback values. Some precoders canbe configured even further via the +parameters.transmissionParameters.PrecoderParameters. For example: In the Kronecker product based precoderthe codebook size can be set. Some important implemented precoders compat-ible with the LTE downlink feedback are listed below. For more details pleaserefer to the code documentation in +parameters.setting.PrecoderType

and in the example file of the +precoders package.

� PrecoderLTEDL: LTE precoder according to [2] for up to 4 transmitchains and four layers.

� Precoder5G: 5G precoder according to [14] for single panel antennaarrays with codebookMode=1. This precoder is suited for digital precod-ing without an analog precoder. Supports up to 6 transmit chains and 4layers. Please take a look at the code documentation for the supportedantenna configurations. The standard specifies the precoders for dualpolarized antenna arrays. Since the simulator uses single polarizedantennas some modifications were made to fit them in the simulator.The modifications are documented in the code. For a more flexibleand configurable precoder take a look at the Kronecker product basedprecoder.

� PrecoderKronecker: Kronecker product based precoder according to[15]. This precoder is designed for uniform planar arrays. Like the 5Gprecoder it is suited for digital precoding without an analog precoder.The codewords are created by taking the Kronecker product of two DFTcodewords. It is based on the same principles as the 5G precoder but

51

Figure 19: 2D Kronecker precoder beams with different oversampling factorand downtilt factor β for digital precoding.

allows for greater flexibility since it is possible to adjust the oversamplingfactors of the DFT codewords and thus the codebooks size. Figure 19shows the beams resulting from the precoders of the codebook in the2D case. Increasing the oversampling factor increases the number ofbeams (and precoders) . Also they begin to overlap. By increasing thedowntilt factor β the beams get restricted to a smaller area. For moredetails please refer to paper [15].

8.4.2 Analog Precoding

The analog precoder maps the RF chains to antenna elements. This allowsto perform beamforming by adding a phase shift for each antenna element.In case no beamforming is performed, the analog precoder uses a one to onemapping from the RF chains to the antenna elements.

MIMO Analog Precoder The MIMO analog precoder performs beam-forming for antenna arrays. The antenna array consists of several panels withantenna elements placed on them as depicted in Fig. 20. The RF chains aremapped to a column of antenna elements as specified in [16]. This mapping isrepeated for antenna columns as depicted in Fig. 21. The mapping is repeatedon each panel.

52

nV

nH

dV

dH

nPH

nPV

dPH

dPV

antennapanel

Figure 20: Antenna array consisting of panels with antenna elements placedon them.

TXRU

TXRU

Figure 21: Mapping of RF chains to antenna columns. The mapping of thefirst column is repeated to the following columns if there are more antennacolumns than RF chains.

8.5 Scheduling

The basic version of scheduling is always done seperately for every BS. Thus,there is always a one to one relation between an instance of the Schedulerclass and a BS. In the instance of Scheduler the corresponding BS is calledattached BS.

As mentioned before, the scheduling in this simulator is built on top ofthe class Scheduler. This class is an abstract class that defines the functionsscheduleDL, addUsersDL and removeUsersDL. Those functions have to beimplemented by every possible type of scheduler.

� scheduleDL: This function has to be called once for every simulationslot and allocates users and transmit power to RBs.

53

� addUsersDL: Has to be called whenever a user connects to the attachedBS. It adds users to the scheduler queue.

� removeUsersDL: Has to be called whenever a user disconnects from theattached BS. It removes users from the scheduler queue.

For example, a round robin scheduler would add newly arriving users at theend of the queue and always assign the RBs to a certain amount of users thatare at the front of the queue. Those users will then be placed at the end ofthe queue.

Additionally to those abstract functions, there are two more pairs offunctions that are not abstract:

� scheduleDLCommon: Has to be called from within scheduleDL andperforms all calculations of the scheduler that are common to all typesof schedulers. For example it decides the CQI for all RBs that arescheduled for one user.

� updateAttachedUsersDL: This function can be called instead of callingthe two functions addUsersDL and removeUsersDL separately. It takesa list of users that should be attached to the BS/Scheduler and callsthe two separate functions if necessary.

8.6 Technologies and Numerologies

Users and antennas can have different technologies. The term technologyrefers to a more abstract concept of network elements, in which the directinteraction is only possible between elements of the same technology. Ratherthan the direct interaction the goal is to model the impact of shared resourceconstraints between these multiple technologies. To allow the analysis ofmore than one technology present in the simulator two additional elementsare needed.

� Composite Base Station

� Spectrum Scheduler

These elements are further discussed in the following sections.

8.6.1 Composite Base Station

A composite base station is needed to organize several base station in ahierarchical, tree like structure. From an external point of view, it behaves

54

LTE 5G

CompositeBase Station

SubBase Stations

5GLTE

(a) Composite BS

5G

LTE

SpectrumScheduler

SubSchedulers

5G LTE

(b) Spectrum Scheduler

Figure 22: Mixed technology elements

as a single base station while internally, by allowing several base stations towork together, more advanced operations are possible.

One use case of such a composite base station is when simulating with morethan one technology present at the same base station. In that case the set upprocedure will split the antennas with respect to their technologies into severalbase stations. These are then configured utilizing the same parameterizationas for the parent base station. The property on which the splitting takes placecan be changed by overwriting the getNetworkElementSplitter function inthe CompositeBasestation class, so different types can be implemented. Anexample of such a composite base station is given in +scenario.simple4G5G.

m file.

8.6.2 Spectrum Scheduling

The spectrum scheduler is a special type of scheduler, which is always linked upto a composite base station, used for distributing resources between the severalbase stations inside the composite base station. This is accomplished accordingto some allocation rule, which is defined by the used spectrum scheduler type.The information of the spectrum scheduling is then forwarded to the schedulersof the sub base stations building up the composite base stations. An exampleof such a set procedure can be inspected in the +scenario.simple4G5G.m.Up until now three spectrum scheduler types are implemented:

55

� static

� dynamicUser

� dynamicTraffic

In each of them a different allocation rule is implemented. The static

spectrum scheduler type allocates resources evenly between all availabletechnologies. The dynamicUser spectrum scheduler type allocates based onthe number of attached users in each technology and the dynamicTraffic

utilizes the information of the traffic models by distributing resources basedon the accumulated buffer size in each technology. Table 3 summarizes theprevious described behavior.

Scheduler type Technology User count Buffer size Resource balance

dynamicTraffic LTE 20 10 MBit 1/35G 5 20 MBit 2/3

dynamicUser LTE 20 10 MBit 4/55G 5 20 MBit 1/5

static LTE 20 10 MBit 1/25G 5 20 MBit 1/2

Table 3: Spectrum scheduling strategies

An example of how the spectrum scheduler type can be specified can befound in the +scenario.simple4G5G.m file.

Additional to the spectrum scheduler type an additional parameter canbe used to manually bias the resource allocation for each technology. Thisparameter is specified in the spectrum scheduler and is called weighting. Thedefault weight value of a technology is one. Utilizing the weighting parametercombined with a spectrum scheduler of type static enables therefore anuneven resource distribution as can be seen in figure 23. Figure 23a displaysthe default resource distribution based on the static equal split withoutadditional weighting. Figure 23b shows the biased resource allocation basedon the additional weight for the LTE technology.

8.6.3 Numerology and mixed-numerology scenarios

The simulator supports mixed numerology simulations. A scenario can containusers and base stations of different numerologies. Meaning that the systemoperates with different subcarrier spacings. According to the 5G standard the

56

5G LTE

Weights1 : 1

(a) Default

5G LTE

Weights1 : 2

(b) Biased

Figure 23: Weight dependent resource distribution.

system’s subcarrier spacing is defined by the numerology parameter µ ∈ N.It is an integer number

µ ∈ {0, 1, 2, 3, 4, 5}.The subcarrier spacing f∆ is connected to the numerology with the relation

f∆ = fb2µ,

where fb is the base subcarrier spacing set to fb = 15 kHz in 5G. With thisthe possible spacings are

f∆ ∈ {15 kHz, 30 kHz, 60 kHz, 120 kHz, 240 kHz, 480 kHz}.

Note that the parameter µ and the base subcarrier spacing fb can also takeon values not specified in the 5G standard. The base subcarrier spacing canbe set in the resource grid parameters. Consult the built in documentation ofparameters.resourceGrid for more information.

Network elements of different numerologies are always separated in differenttechnologies. This ensures that users will never connect to base stations ofother numerologies. The naming convention of the technology is:

[Technology]:[Numerology]

For example, consider a user of the technology LTE and the numerology 1.The resulting total technology label will be

LTE:1.

Therefore all features applying to the technology parameter can also be usedtogether with numerologies. The numerology is set by defining the numerologyparameter on each base station and user in the scenario file.

57

1 % define antenna with numerology 0

2 ant1 = parameters.basestation.antennas.Omnidirectional;

3 ant1.numerology = 0;

4 % define antenna with numerology 1

5 ant2 = parameters.basestation.antennas.Omnidirectional;

6 ant2.numerology = 1;

78 % define user with numerology 0

9 userNum1 = parameters.user.PredefinedPositions ();

10 userNum1.numerology = 0;

11 % define user with numerology 0

12 userNum1 = parameters.user.PredefinedPositions ();

13 userNum1.numerology = 1;

An example with more details is provided by the numerologyScenario.

8.6.4 Inter-numerology interference

The simulator considers interference created due to different numerologies inthe LQM. The paper [17] provides equations for Inter Numerology Interference(INI) on a per subcarrier basis. It is assumed that the power in the resourceblocks is distributed evenly on its carriers. The INI in an RB is calculatedby summing up over the interference of its carriers. Figure 24 shows howthe numerology can change in the RB due to spectrum sharing. Thereforeit is necessary to calculate the INI in each slot, since it depends mainly onthe distance between the resource blocks. The simulator scans in the setupphase for all numerologies and precaclulates the INI factors. During chunksimulation the LQM performs a table lookup and calculates the INI whichis then treated as additional interference. The simulator also provides theoption to omit inter-numerology interference. For that the following parameteroption exists:

1 % disable ini calculation

2 params.calculateIni = false;

8.6.5 Resource Grid

The resource grid defines basic Orthogonal Frequency Division Multiplexing(OFDM) parameters like symbol duration, subcarrier spacing or the amount ofresource elements per resource block. Some of these parameters are dependenton the numerology. Figure 25 sketches a resource grid shared by two systemswith different numerologies. The size of the resource elements change in timeand frequency. Since the LQM and other components depend on equally sized

58

Figure 24: Changing numerologies in RB due to spectrum sharing

resource blocks, the number of RE in time and frequency is adjusted so thatall RBs have the same size. The base grid defines the size of the RB, andthe resource grid for other numerologies are derived from the base grid, sothat the RB size stays equal. The base grid defines this parameters for thesmallest numerology.

1 % define base grid

2 params.transmissionParams.DL.resourceGridType = params.

setting.ResourceGrid.LTE;

8.7 Traffic Models

Since 5G networks are heterogeneous with arbitrary user types, it is necessaryto account for their traffic models in the simulation. The basic operationof the traffic models is defined within the last three parts in the simulatorstructure shown in Fig. 7. After the initialization part finishes, the setupof the traffic model is done for every user individually. The interactionbetween the simulator and the model is built on top of +trafficModels.PacketProcessing class. It is a superclass for all the traffic models and wherepacket generation and transmission functionalities typically reside. Duringthe main simulation loop, the necessity of new packet generation for each useris checked according to the model statistics and the packet buffer for eachuser is updated according to its throughput. Data packets are discriminatedwith the following properties: packet generation time, successful transmissiontime, packet size, remaining of packet size after transmission and identitynumber. Further details about data packets can be found in +trafficModels.

DataPacket. After the post processing, ecdf of packets transmission latencyis plotted.

59

Symbols

Subc

arri

ers Numerology 1

30 kHz

Numerology 015 kHz

Figure 25: Resource Grid with two different numerologies. The thick linesindicate resource blocks.

60

The user data packets are discriminated with the following properties:generation time, successful transmission time, packet size, remaining of thepacket size after transmission and identity number. Further details about thedata packets can be found in the code documentation in +trafficModels.

DataPacket.The interaction between the simulator and the traffic model is built on top

of +trafficModels.PacketProcessing class. It is a super class for all thetraffic models and where packet generation and transmission functionalitiestypically reside. Fig. 26 shows the connection between any traffic model andother parts of the simulator. The functions which are defined in the superclass and have to be called by every model are listed below:

Traffic M odel

User Traffic

User Allocation

Post Equalization SIN R

CQI

User Throughput

Scheduler

LQM

Feedback

LPM

Figure 26: A block diagram illustrates the traffic model interaction with otherparts of the simulator.

� checkNewPacket: It has to be called once for every simulation slot to

61

check if a new data packet has to be generated, if necessary, a new datapacket is being appended to the packets buffer.

� get.isActive: It checks whether a traffic model is active or not. Themodel is active if there is at least one bit in the packets buffer.

� getBufferState: It checks the number of packets in the buffer, theirgeneration times and the number of remaining bits in each packet. Thisfunction has to be called by every scheduler since the scheduling decisionis being affected by the packets buffer state.

� updateAfterTransmit: It checks if there are packets in the bufferand update the number of remaining data bits and the successfultransmission time for these packets after each transmission.

� getTransmissionLatency: It calculates the packets transmission la-tency.

� clearBuffer: It re-initializes the traffic model and has to be called atthe end of each chunk simulation.

All necessary parameters to set up the traffic models can be found inthis package +parameters.user.trafficModel. The available traffic modelsare implemented as sub classes of the super class PacketProcessing. Thecurrent models are listed below:

� Constant Rate: This model generates fixed size packets governed by acertain packet arrival rate as depicted in Fig. 27. The initial time forgenerating the packets of different users is random to obtain realisticsimulations.

Time

Per-user traffic

1/Packet arrival rate

Packet size

Figure 27: Constant Rate traffic model.

� Full Buffer : Users have infinite amount of data to be transmittedaccording to [18, Annex.2.1.3]. This model is implemented such that

62

each user have a single packet of infinite size. For this model no ecdfof the transmission latency is plotted since all packets are not fullytransmitted at the end of the simulation.

Descriptions of the models can be found in the enumerationfile +parameters.setting.TrafficModelType.

8.8 Feedback

The Feedback class is used to provide the scheduler with information onchannel conditions such as the Rank Indicator (RI), the Channel QualityIndicator (CQI) and the Precoding Matrix Indicator (PMI). The schedulerneeds this to determine optimal transmission parameters for future TSs.

All supported feedback types are implemented as subclasses of the Feedbackclass. Currently, these include

� LTEDLFeedback: This feedback type corresponds to the one used in theLTE Downlink. It is implemented according to [19].

� MinimumFeedback: This feedback type shows the minimum amount offeedback required by the scheduler.

Each feedback type implements the method calculateFeedback. All sup-ported SINR to CQI mappings are implemented in subclasses of parameters.transmissionParameters.CqiParameters. They include

� LteCqiParametersTS36213NonBLCEUE1

which are defined in 3GPP TS 36.213 [20]. It is also possible to turn off thefeedback and only use the best possible CQI values. This can be done bysetting the variable params.useFeedback in scenario file to zero.

8.9 NOMA

8.9.1 A NOMA Transmission

The 5G VCCS SLS supports two user Single-Input Single-Output (SISO)power domain NOMA transmission. To use NOMA transmissions in a simu-lation the NOMA parameters in parameters.Noma have to be set. How toset the NOMA parameters is shown in Section 5.2.11.

63

Power

nearuser

faruser

near

far αfar

αnear

Figure 28: In a power domain NOMA transmissions two users share the samephysical resource in the power domain. The near user performs SIC to receivedata.

∆min��15 dB

-20 dB -50 dB-30 dB -35 dB -40 dB-25 dB -45 dB

NOMA Pair 1

NOMA Pair 2

<∆min

Figure 29: Users are paired for a NOMA transmission if the difference betweentheir cell association metric is larger than parameters.Noma.deltaPairdB.

8.9.2 NOMA User Pairing

For a NOMA transmission to be efficient, the difference in channel qualitybetween the near user and the far user needs to be large enough. The minimumdifference for NOMA transmission to be used can be set in parameters.Noma.

deltaPairdB. With this minimum difference ∆, the users are then pairedstarting with the strongest and weakest users in the cell. If the difference intheir cell association metric is larger than ∆, they form a NOMA pair andwill share their resources during the simulation. This procedure continueswith the second strongest and second weakest user in the cell and goes onuntil a pair does not reach the threshold ∆, the remaining users will not sharetheir resources and will proceed with classical OMA transmissions. Figure 29shows the user pairing strategy, NOMA near users are shown in dark blue,NOMA far users in light blue and OMA users in gray.

64

8.9.3 NOMA Scheduling

1

2

3

4

5

6

7

1

3 4

5 6

7 1

2 3

4 5

2

time

freq

uenc

y

4

6

2

57

2

4

1

3

1

3

1

3

1

3

57

57

time

freq

uenc

y

NOMARoundRobin

Figure 30: Resource sharing between NOMA users. The figure shows anexemplary cell with OMA users in gray, NOMA near users in dark blue andNOMA far users in light blue. The grid represents the RBs available fortransmission. A round robin scheduler assigns an RB to each user in the cell.Afterwards the NOMA scheduling shares all resources assigned to a NOMApair.

If two users are paired in the NOMA user pairing during cell association,then all resources assigned to the users in the NOMA pair are shared betweenthe users and used for a NOMA transmission. Figure 30 shows an exemplarycell in which the users 1 and 3 form a NOMA pair and the users 7 and 5are also paired for NOMA transmission. The remaining users 2, 4 and 6perform classical OMA transmissions, their channel conditions are too similarfor effective SIC transmissions. In the example in Fig. 30, a round robinscheduler, assigns all available resources to the users in the cell in a roundrobin fashion. All resources assigned to a user in a NOMA pair are thenshared and used for NOMA transmission for this NOMA user pair.

8.9.4 NOMA in the Link Quality Model

The SIC is modeled in the LQM. For more details about the LQM seeSection 8.2.

SIC For the near NOMA user, SIC is performed. For this, the signal ofthe far NOMA user is received and decoded at the near user. The LQM

65

calculates the post equalization SINR of the signal of the far user received atthe near user γnear(far) as follows:

γnear(far) =αfarpnear(far)

αnearpnear(near) + I + n, (8.1)

where pnear(far) is a very short notation for the power of the signal of thefar user received at the near user. In the same manner pnear(near) is a shortnotation of the power of the signal of the near user received at the near user- this is here considered as interference, since the signal of the far user isdecoded in this step. I is a short notation for the interference from other cellsand n is the thermal noise experienced in the considered RB. αfar and αnear

are the NOMA power share factors as depicted in Fig. 28.This post equalization SINR γnear(far) is then handed over to the LPM

and if the transmission of the signal of the far user is successful, the interferencefrom the far user can be canceled out through the factor ϵ for the receptionof the signal of the near user as follows:

γnear(near) =αnearpnear(near)

ϵαfarpnear(far) + I + n. (8.2)

If SIC cancels out the interference from the far user completely, then ϵ = 0,otherwise ϵ can be set to a higher value up to 1.

If the signal of the far user can not be decoded successfully, then thetransmission of the signal of the near user fails and the post equalizationSINR is set to −∞.

Additional Interference for the Far User For the far NOMA user, onlyadditional interference is added to take into account the transmission of thenear user. Since αnear is smaller than αfar, the additional interference is small.The post equalization SINR at the far user is calculated as follows:

γfar =αfarpfar(far)

αnearpfar(near) + I + n. (8.3)

The notation follows the notation used in the equations above.

8.10 Parallelization

In the function simulate.m, three different simulation modes are defined:

1 % start simulation

2 switch simulationType

66

3 case parameters.setting.SimulationType.local


6 localSimulation = simulation.LocalSimulation(params);

78 %setup simulation and generate network elements

9 localSimulation.setup ();

1011 %main simulation loop

12 localSimulation.run();

1314 % get results

15 simulationResults = localSimulation.simulationResult;

1617 case parameters.setting.SimulationType.parallel


20 parallelSimulation = simulation.ParallelSimulation(params);

2122 % run simulation

23 parallelSimulation.setup ();

24 parallelSimulation.run();

2526 % get results

27 simulationResults = parallelSimulation.simulationResult;

2829 case parameters.setting.SimulationType.cluster

3031 error('Type.cluster is not yet supported.');

3233 otherwise

34 error('Please see parameters.setting.SimulationType for

possible simulation types.');

35 end

The major difference between the first two modes (local and parallel) isthat the loop over chunks is a parfor loop in parallel mode. The chunk listis prepared (almost) the same way in both cases (cf. Section 7.3). The listis prepared in such a way that all chunks can be distributed to individualworkers and no result of any chunk is necessary to do the computation in anyother chunk.

8.11 Lite Version

The simulator provides a lite simulation mode, which offers a runtime shorterthan the complete simulation. This simulation mode is useful when thefocus of investigation is on the network geometry. The simulation result is

67

the instantaneous SINR and consequently other metrics such as outage orachievable rate. In the lite mode, not the full functionality of the simulator isutilized, including features like scheduling or the LPM/LQM.

The simulation skips the computation of the parameters within TSsand the saved parameters, i.e, SINR are updated just once per segment.In the simulation.ChunkSimulation.runSimulation function, some basiccomputation for the new segments are done for all users, including the usersoutside the ROI. After that the scheduling function is called with the line

1 obj.scheduling(s, iSlot)

In the lite simulation mode a dummy scheduler is used. Afterwards the compu-tation of the first segments for users within the ROI are done. Consecutively,the calculations in each time slot are skipped with the line:

1 if ~obj.chunkConfig.parameters.liteSimulation %

Skip time slots in lite simulation mode

The parameter params.liteSimulation indicates if the simulation is lite,but it should not be manually modified since it is set automatically accordingto the post processor chosen in the Parameter file. All launcher files can berun with the lite simulation mode. To do so, the postprocessor has to bechanged to one of the lite postprocessors explained in Section 8.12.

8.12 Post Processing

After the main simulation loop is done, the results of the individual chunksare collected and combined to a final result. This is called the post processingphase and is performed by the so called postprocessor. The 5G SL simulatorprovides different types of postprocessors to be chosen from. The chosenpostprocessor has two main impacts on the simulation. First it specifies if alite or a full simulation is performed (see Section 8.11). Further it determineswhich results will be available at the end of the simulation and offers a set ofplots to get a quick overview of the available simulation results.

The post processing starts by calling the combineResults function of thepost processor. It returns a result object which contains the collected simula-tion results and is the final result of the simulation. It also defines methodsto display them. All results contain at least the simulation parameters.

The 5G SL simulator is equipped with one postprocessor for full simulationsand two postprocessors for lite simulations. A description of the availablepostprocessors follows. For a detailed documentation of available propertiesand functions refer to the MATLAB code documentation in the packagesimulator.results.

68

� FullPP: By selecting this postprocessor the simulator performs a fullsimulation. The collected results are from type ResultsFull and includegeneral results such as the preliminary SNR and SINR values, effectiveand wideband SINR, BLER and so on. Also the network elements aresaved. In addition to the general results, additional results can be savedby selecting them with the SaveObject parameter. An example for anadditional result would be the path loss table. All available additionalresults are listed in the MATLAB code documentation. The resultobject provides some basic functions to plot the SNR values, BLERand network geometry.

� LiteWithNetworkPP: By selecting this postprocessor the simulator per-forms a lite simulation. Since in the lite simulation the functionalityis reduced, many parameters saved with the FullPP are not computed.The collected results are from type ResultsLite and include prelim-inary SNR and SINR values and the network geometry. The resultobject provides some basic functions to plot the SNR values and thenetwork geometry.

� LiteNoNetworkPP: This postprocessor behaves like LiteWithNetworkPP.The difference is that network elements are not saved. Therefore alsothe network geometry is not available.

By default, the postprocessor FullPP is set. To select the lite simulation,the parameter postprocessor has to be set to a lite postprocessor in thescenario configuration file. For example:

1 params.postprocessor = simulation.postprocessing.

LiteNoNetworkPP;

With any of the postprocessors, the results of the simulation are stored ina file inside the results folder. The filename is defined in params.filename.By default, the name contains the carrier frequency, the bandwidth, the timeand whether the simulation is lite or not. The default filename can be changedby modifying the function Parameters.setFilename.

The result classes provide the checkIntegrity() method to audit if thesimulation result sizes are matching the parameters. By default this check isexecuted by the postprocessor after every simulation and provide the userwith a warning if an error is detected.

Results from multiple simulations can be combined with the ResultsCombinedclass from the simulation.results package as long the results are from thesame type. The class provides methods to plot the combined data. Anexample:

69

1 res = ResultsCombined(result1 , result2);

2 res.showAllPlots ();

70

9 Performance Considerations

9.1 Simulation Time

Parameter Values

simulation type local, parallelsimulation extent full, litenumber of users/base stations 100/10, 1000/100number of chunks 5, 10TTIs/slots (total) 100, 1000bandwidth in MHz 3, 20, 100transmission type SISO, 4x4 MIMO

Table 4: Simulation parameters for simulation time evaluation. The boldparameters are the parameters set for the baseline scenario.

To give an idea on how the simulation time behaves depending on differentparameters, this section lists the simulation time of different simulationson the same physical machine under comparable conditions. The absolutesimulation time depends strongly on the hardware used to perform thesimulations, the following numbers only can only showcase the behavior ofthe time consumption relative to the baseline scenario.

baseline lite large largeparallel

largelite

largelite

parallel

type local parallel parallelextent full lite lite lite

nUE/nBS 100/10 1000/100 1000/100 1000/100 1000/100nChunk 5

nSlot 10BW 3

SISO 40 6 955 463 263 123

MIMO 227 7 2996 1397 302 138

Table 5: Simulation time for different simulation sizes. Simulation time isgiven in seconds for SISO and MIMO transmit mode in the last two lines.

71

baseline long longparallel

longchunks

longparallelchunks

type local parallel parallelextent full

nUE/nBS 100/10nChunk 5 10 10

nSlot 10 200 200 100 100BW 3

SISO 40 341 154 344 121

MIMO 227 2267 1077 2261 834

Table 6: Simulation time for different simulation durations. Simulation timeis given in seconds for SISO and MIMO transmit mode in the last two lines.

The simulations performed for this section are defined in the scenario filescenarios.simulationTime and the different parameters are defined in thelauncher file launcherFiles.launcherSimulationTime.

Table 4 shows the parameters used for the simulation time scenarios. Theparameters used for the baseline scenario are highlighted in a bold font.

baseline 20 MHz 100 MHz

type localextent full

nUE/nBS 100/10nChunk 5

nSlot 10BW 3 20 100

SISO 40 91 357

MIMO 227 1291 6557

Table 7: Simulation time for different bandwidths. Simulation time is givenin seconds for SISO and MIMO transmit mode in the last two lines.

In Table 5, simulations with different numbers of network elements arecompared. The simulation time for lite simulations is short since lite simula-tions only calculate the large scale fading parameters. The simulation time

72

increases strongly, when the number of users and base stations is increasedsince the number of links to be calculated increases with both the increasingnumber of users and the increasing number of base stations. For MIMOsimulations, the simulation time increases strongly because the LQM nowdeals with matrices instead of scalars. The table also shows that a significantparallelization gain can be achieved, even for very short simulations. Table 6shows that a parallelization gain can be achieved for longer simulations, whenthe simulation duration is distributed to more chunks, which can be simulatedin parallel.

Finally, Table 7 shows the increase in simulation time with the increase ofthe bandwidth.

73

10 Releases and Changelog

3. Vienna 5G SL Simulator release 1.2, released July 2021.Newly introduced features:

� Kronecker product based precoder with adjustable number of layersand precoders

� 5G Precoder according to TS 38.214

� buildings can be read in from OpenStreetMaps

� Traffic models: Full Buffer and Constant Rate.

� Path loss models: TR 38.901 RMa, UMi and UMa have been added

� Mixed numerology simulations with dynamic spectrum sharing

� NOMA transmissions

Bug fixes and improvements:

� Buildings can now have an arbitrary floorplan

� Dummy scheduler now schedules all RBs instead of just one

� Placement of clustered users with predefined cluster center

� Number of sectors can be set arbitrarily for sedctorized antennas(up to maximum number of sectors)

� Compatibility issues with older matlab versions have been resolved:minimum version requirement is now R2018b

2. Vienna 5G SL Simulator 1.1, released October 2020.Newly introduced features:

� feedback: MIMO PMI and RI according to LTE release 8

� wraparound

� analog precoder for MIMO beamforming

� antenna array according to 3GPP TR 38.901

Bug fixes and improvements:

� +simulation.results and simulation.postprocessing packages arerefactored

� bugfix for feedback read out at handover

1. Vienna 5G SL Simulator 1.0, released October 2018

74

Acknowledgements

The financial support by the Austrian Federal Ministry for Digital andEconomic Affairs and the National Foundation for Research, Technology andDevelopment is gratefully acknowledged. This work has been co-financed byA1 Telekom Austria AG, OBB Infrastruktur AG and Nokia Solutions andNetworks.

75

References

[1] OpenStreetMap. https://www.openstreetmap.org/. Accessed: 2021-04-19.

[2] 3rd Generation Partnership Project (3GPP). Evolved Universal Ter-restrial Radio Access (E-UTRA) physical channels and modulation. TS36.211. 3rd Generation Partnership Project (3GPP), Jan. 2015.

[3] A. Fastenbauer, M. K. Muller, and M. Rupp. “Investigation of WraparoundTechniques for the Simulation of Wireless Cellular Networks”. In: WSA2013; 23rd International ITG Workshop on Smart Antennas. 2019.

[4] J. Colom Ikuno. “System Level Modeling and Optimization of the LTEDownlink”. PhD thesis. TU Wien, 2013.

[5] T. Dittrich, M. Rupp, and M. Taranetz. “An Efficient Method forAvoiding Shadow Fading Maps in System Level Simulations”. In: WSA2017; 21st International ITG Workshop on Smart Antennas. Mar. 2017,pp. 1–8.

[6] 3rd Generation Partnership Project (3GPP). High Speed DownlinkPacket Access: UE Radio Transmission and Reception. Tech. rep. 3rdGeneration Partnership Project (3GPP), 2002.

[7] TSGR1 010030. Further Results on CPICH Interference Cancellationas A Means for Increasing DL Capacity. Tech. rep. Intel Corporation,2001.

[8] 3rd Generation Partnership Project (3GPP). Radio transmission andreception, annex c.3 propagation models. Tech. rep. 3rd GenerationPartnership Project (3GPP), 2009.

[9] 3rd Generation Partnership Project (3GPP). Universal Mobile Telecom-munications System (UMTS) Deployment aspects. TR 25.943. 3rd Gen-eration Partnership Project (3GPP), Feb. 2010.

[10] T. B. Sorensen, P. E. Mogensen, and F. Frederiksen. “Extension of theITU channel models for wideband (OFDM) systems”. In: VTC-2005-Fall. 2005 IEEE 62nd Vehicular Technology Conference, 2005. IEEE,2005. doi: 10.1109/vetecf.2005.1557939.

[11] S. Jaeckel, L. Raschkowski, K. Boerner, and L. Thiele. “QuaDRiGa:A 3D Multi-Cell Channel Model With Time Evolution For EnablingVirtual Field Trials”. In: IEEE Transactions On Antennas and Propa-gation 62 (2014), pp. 3242–3256.

https://www.openstreetmap.org/

https://doi.org/10.1109/vetecf.2005.1557939

76

[12] S. Jaeckel, L. Raschkowski, K. Boerner, L. Thiele, F. Burkhardt, and E.Eberlein. QuaDRiGa - Quasi Deterministic Radio Channel Generator,User Manual and Documentation v.2.4.0. Tech. rep. Fraunhofer HeinrichHertz Institute, 2020.

[13] Y. R. Zheng and Chengshan Xiao. “Simulation models with correctstatistical properties for rayleigh fading channels”. In: IEEE Transac-tions on Communications 51.6 (June 2003), pp. 920–928. doi: 10.1109/tcomm.2003.813259.

[14] 3rd Generation Partnership Project (3GPP). 5G;NR;Physical layerprocedures for data. TS 38.214. 3rd Generation Partnership Project(3GPP), Oct. 2018.

[15] Y. Xie, S. Jin, J. Wang, Y. Zhu, X. Gao, and Y. Huang. “A limitedfeedback scheme for 3D multiuser MIMO based on Kronecker productcodebook”. In: 2013 IEEE 24th Annual International Symposium onPersonal, Indoor, and Mobile Radio Communications (PIMRC). 2013,pp. 1130–1135. doi: 10.1109/PIMRC.2013.6666308.

[16] 3rd Generation Partnership Project (3GPP). Study on channel model forfrequencies from 0.5 to 100 GHz (Release 16). Tech. rep. 3rd GenerationPartnership Project (3GPP), 2020.

[17] Abuu B. Kihero, Muhammad Sohaib J. Solaija, and Huseyin Arslan.“Inter-Numerology Interference for Beyond 5G”. In: IEEE Access 7(2019), pp. 146512–146523. doi: 10.1109/ACCESS.2019.2946084.

[18] 3rd Generation Partnership Project (3GPP). Evolved Universal Ter-restrial Radio Access (E-UTRA); Further advancements for E-UTRAphysical layer aspects. TR 36.814. 3rd Generation Partnership Project(3GPP), Mar. 2017.

[19] Stefan Schwarz, Christian Mehlfuhrer, and Markus Rupp. “Calculationof the spatial preprocessing and link adaption feedback for 3GPPUMTS/LTE”. In: 2010 Wireless Advanced 2010. IEEE, 2010. doi:10.1109/wiad.2010.5544947.

[20] 3rd Generation Partnership Project (3GPP). Evolved Universal Ter-restrial Radio Access (E-UTRA); Physical layer procedures. TS 36.213.3rd Generation Partnership Project (3GPP), Jan. 2015.

https://doi.org/10.1109/tcomm.2003.813259

https://doi.org/10.1109/tcomm.2003.813259

https://doi.org/10.1109/PIMRC.2013.6666308

https://doi.org/10.1109/ACCESS.2019.2946084

https://doi.org/10.1109/wiad.2010.5544947

the vienna 5g system level simulator

Documents