Cognitive Network Simulator

Transcription

1 CELTIC initiative Telecommunication Solutions Project acronym: COMMUNE Project full title: COgnitive network ManageMent under UNcErtainty Proposal/Contract no.: CP Cognitive Network Simulator Project Document Number: D5.2 Project Document Date: Workpackage Contributing to the Project Document: WP5 Deliverable Type and Security: Report, public Editor: Mika Karlstedt Abstract: In COMMUNE project we will use simulators to better and develop the cognitive algorithms to battle the uncertainty in telecommunication network management. Since there is no publicly available simulator that would fulfil the needs of the project we are either building new simulators or extending functionality of the existing ones. This deliverable will explain the important features available in SN4G HetNet simulator, as well as functionalities of LTE module of Network Simulator 3 (NS-3) and the modifications we have made to LTE-sim. SN4G HetNet simulator is more complete simulator, which will be used in the final validation phase. NS-3 LTE module with additional extensions is mainly aimed for simulation of use case scenarios in LTE networks. LTE-sim with modifications will be used in the early phases when SN4G is not available to every partner. Keywords: LTE, simulator, cognitive algorithms COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 1 of 114

2 Project Number Project Name Document Number Document Title Workpackage Editor Authors CP COgnitive network ManageMent under UNcErtainty COMMUNE/WP5/D5.2 Cognitive Network Simulator WP5 Mika Karlstedt (Ericsson) AIT: Ericsson: Mika Karlstedt Magister Solutions: Budiarto Herman, Fedor Chernogorov, Timo Nihtilä NSN: TP: Łukasz Rajewski, Joan Meseguer Llopis SistelNetworks: Salva Díaz, Oscar Carrasco, Jordi Puig Telenium: VTT: Reviewers Contractual delivery date M15 Delivery Date (revision) Version 1.0 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 2 of 114

3 Executive Summary COMMUNE project aims to study and develop cognitive algorithms to deal with the inherent uncertainty present in telecommunication networks. Telecommunication networks are big distributed systems. There are numerous sources of uncertainty that affect the management and operation of the telecom networks. They are also very expensive and since they are used in all the time it is not feasible to install untested algorithms into them. It is also unfeasible to create a realistic testbed to test the algorithms. It is therefore important to use simulators to test the algorithms in realistic environments. Unfortunately there are no publicly available simulators that would be accurate enough. So we have implemented two different simulators to be used in different cases. SN4G HetNet simulator is full-fledged simulator that can be used to simulate the LTE network completely. It can simulate every required radio access technology as well as enodebs and other core network entities. It will be used in the final validation phase of the LTE based scenarios of the COMMUNE project. LTE-sim is more lightweight simulator, which is publicly available. It requires some modifications to fully suit our needs, which we have made. It will be used in the starting phases when the SN4G is not available to every partner. It can be used to develop and test the algorithms, which we then validate with the SN4G. NS-3 is a modular, general purpose network simulator with a module for LTE features. It will be used as the simulation tool of COMMUNE self-healing use case. NS-3 is actively developed by the open source community, and is well equipped with existing LTE features that we can utilise. However, some required features are still missing, and we made several modifications to rectify that. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 3 of 114

4 Contents 1 INTRODUCTION SCOPE OF THE DELIVERABLE STRUCTURE OF THE DOCUMENT SIMULATION VERSUS TESTBED ENVIRONMENTS SISTELNETWORKS SN4G LTE-A HETNET SIMULATOR BUILDING BLOCKS OF THE SIMULATOR RADIO ACCESS TECHNOLOGIES TRAFFIC MODEL Traffic Sessions Generation OPERATION MODEL PACKET GENERATION PROCESS CONSIDERED SERVICES VOICE: CIRCUIT BASED Voice: VoIP Video telephony Web browsing PATH LOSS MODELS: MAIN SIMULATOR FEATURES Cellular environment Radio Link Base Station User traffic behaviour Resource Model Link Management SIMULATION PROCESS Configuration parameters Performance measurements KEY PERFORMANCE INDICATORS General performance evaluation criteria Service-specific performance evaluation criteria: OTHER OUTPUTS FROM SN4G Performance & QoS measurements Spectral Efficiency Analysis of Scenarios with Actual BS Graphical Results for Synthetic Scenarios RRM FUNCTIONS Scheduling Call Admission Control Congestion Control SN4G CALIBRATION Channel Model Calibration Baseline Configuration Calibration SN4G API VARIABLES LTE SIM SIMULATOR GENERIC SIMULATION PLATFORM MAIN SIMULATOR FEATURES SIMULATOR MODIFICATIONS Generic interface implementation LTE-Sim specific changes implementation of MON and CON interface drivers NETWORK SIMULATOR OVERVIEW OF NS COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 4 of 114

5 4.1.1 Available Modules LTE Module EPC Model LENA Project Publications on NS NS-3 IN SELF-HEALING USE CASE UE Report enodeb Report Validity of Simulation Results Demonstrative Simulation Environment CURRENT NS-3 CAPABILITY RSRP and SINR Antenna Model UE Mobility Random Access X2 Interface and Handover MODIFICATIONS TO NS Propagation Loss Model Receiving Signals from Neighbouring enodebs Time Window Averaging Handover Algorithm Radio Link Failure Cell Selection SUMMARY CONCLUSIONS APPENDIX SN4G API VARIABLES BIBLIOGRAPHY COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 5 of 114

6 1 INTRODUCTION 1.1 Scope of the Deliverable COMMUNE project aims to study algorithms needed to deal with the uncertainty inherent in the large distributed systems especially in the telecommunication area. It is impossible to create big enough testbeds in a reasonable price, so we use simulators. In COMMUNE we will be using two different simulators, SN4G HetNet simulator, LTE module of NS-3 and LTE-sim. SN4G HetNet simulator will be used in the final validation. NS-3 is aimed for simulations of LTE related scenarios, especially self-healing sleeping cell use case. LTE-sim will be used in the beginning when SN4G HetNet is not available to every partner. This deliverable will cover the implementation of the SN4G to a modest degree and explain the use cases and available options of the simulator. Description of of NS-3 includes the main functionality of this simulator, our extensions and changes necessary to fulfil the needs of the COMMUNE project. We have made some modifications to the LTE-sim which are also covered. 1.2 Structure of the Document Chapter 2 describes the SN4G HetNet LTE simulator. Chapter 3 describes the modifications Orange has made to the LTE-sim. In Chapter 4 we describe NS-3 simulator developed by Magister Solutions. Finally in the appendix there is a comprehensive list of the API parameters of the SN4G simulator 1.3 Simulation versus Testbed Environments It is possible that at the final stage of the COMMUNE project Orange will possess a femtocell testbed. Therefore, we have decided to design simulation and testing environment in such a way that will help us to change simulator or to switch to the testbed usage without significant modifications in the execution environment specified in the WP3 as well as in the cognitive algorithms for Energy Saving and Self-Optimization scenarios. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 6 of 114

7 2 SistelNetworks SN4G LTE-A HetNet Simulator The SistelNetworks 4G (SN4G) HetNet simulator is one of the tools used by COMMUNE project to emulate the wireless network defined at the project. The scenarios, detailed at D2.1 [1] Section 4, will provide the required inputs to configure the simulation. Section 2.1 gives us a brief description of the simulator. The scenario inputs should be mapped to SN4G input variables. At this point, it is important to identify the critical inputs: users technology and femtocellular capabilities, type of service VoIP, www, etc. and the quality of service (QoS) requirements. Moreover, SN4G needs some additional variables defined at this section. Each scenario entails different situations and, hence, the type of traffic should be different. The simulator has to identify the most appropriate traffic models (2.9.4) for each service at each situation. All scenarios can be modelled with the same variables; therefore, the variables should be configurable inputs to the SN4G simulator. These inputs are introduced in the simulator using an init file. The init file has to be modified by the user each time a new scenario is tested. The variables included in the init file are detailed in Currently, SistelNetworks is developing a web-based GUI that will simplify the settings of a new simulation experiment. This GUI will be adapted according to the project needs. Figure 1 shows several inputs and the outputs that COMMUNE project will use with the SN4G. SN4G is a novel, ambitious and scalable radio simulation platform for heterogeneous wireless systems initially developed by the Universidad Politécnica de Valencia in collaboration with SistelNetworks. The platform currently integrates five advanced system level simulators, emulating the GPRS (General Packet Radio Service), EDGE (Enhanced Data-rates for GSM/Global Evolution), HSDPA (High Speed Downlink Packet Access), WLAN and LTE (Long Term Evolution) Radio Access Technologies (RATs). SN4G is a unique dynamic simulation platform that emulates all five RATs in parallel and at the packet level, which enables an accurate evaluation of many output variables that could be defined, including the final user perceived QoS through the implementation of advanced RRM mechanisms. The radio interface specifications of these five technologies have been faithfully implemented in the SN4G simulation platform, which works with a high time resolution (in the order of milliseconds). This modelling approach validates the capability of the SN4G simulation platform to dynamically and precisely evaluate the performance of RRM techniques, so important for the evaluation of the actual behaviour of technologies. The platform has been developed following a modular and scalable design, which guarantees an easy adaptation of the platform configuration to specific requirements, and allows the rapid integration of new functionalities. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 7 of 114

8 INPUTS OUTPUTS Number of users SINR Number of high-priority users CAC Cell Spectral Efficiency Cell Edge User Spectral Efficiency Pre-emtion function Reference of QoS SN4G Simulator Throughput Serving Cell Coordinates QoS Transmitted Power Service Delay RAT Service (voice, HTTP, mail, ) Figure 1 SN4G Simulator for Real Scenarios Coverage Maps Delivered / Undelivered traffic 2.1 Building Blocks of the simulator The main building blocks of the simulator can be seen in figure 2, where every box shown represents a software module, that models or implements one precise feature of SN4G. Base Station Layout Mobile terminal MAC Scheduling Policy Channel GPRS Location of sites Traffic Model Mobility Model Channel Allocation EDGE Resource Allocation Table HSDPA CRRM Module Interference Calculation WLAN LTE GPRS Link GPRS EDGE Pathloss EDGE Link Control HSDPA Shadowing HSDPA Link Control WLAN WLAN LTE Fast fading LTE Figure 2 SN4G Simulator COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 8 of 114

9 For its special interest, a logical structure of the LTE simulation platform is shown in Figure 3. Interactions among functional entities are shown as connections among blocks in Figure 3. Main features of each functional entity have been included within the block representing this functional entity. The components shown in this figure and their interactions are described in the following subsections. Figure 3 LTE Functional Scheme 2.2 Radio Access Technologies The main features of the radio interfaces emulated in SN4G are briefly summarized in this section: GPRS The GPRS radio interface is based on a combined FDMA/TDMA multiple access mechanism and a FDD scheme. The GPRS standard can be modelled as a hierarchy of logical layers with specific functions. Prior to transmission, data packets are segmented into smaller data blocks across the different layers, with the final logical unit being the Radio Link Control block (RLC), which has duration of 20ms. The resulting RLC data blocks are then coded and block-interleaved over four normal bursts in consecutive TDMA frames. Although GPRS is based on a single modulation scheme, it defines four different coding schemes (CS) (see Table 1) that have all been emulated within SN4G. A GPRS TDMA frame is equal to ms and is divided into eight ms time-slots. Such timeslots impose the SN4G time resolution for the GPRS radio interface. GPRS defines a temporal hierarchy with higher order structures such as super- and hyper-frames that have not been implemented in SN4G since the platform is aimed at radio resource management investigations. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 9 of 114

10 EDGE GPRS TRANSMISSION MODES MODE MODULATION CODE RATE BITS PER RADIO BLOCK BIT RATE (KBPS) CS1 GMSK 1/ CS2 GMSK Approx. 2/ CS3 GMSK Approx. 3/ CS4 GMSK Table 1 GPRS transmission modes The EDGE radio interface is based on the same multiple access scheme as GPRS, but considers different transmission modes (Modulation and Coding Schemes, MCS), all implemented in the SN4G platform following the description in Table 2. The main difference to GPRS is the introduction of 8PSK, a multilevel modulation that theoretically increases EDGE data rates by a factor of three. The EDGE transmission modes are divided into three different families, namely A, B and C. Each family has a different basic payload unit of 37 (and 34), 28 and 22 octets respectively. Different code rates within a family are achieved by transmitting a different number of payload units within one radio block. For families A and B, 1, 2 or 4 payload units can be transmitted per radio block, while for family C, only 1 or 2 payload units can be transmitted. These families are designed to allow a radio block to be retransmitted with a transmission mode, within the same family, different from that used in the original transmission; this option is not possible in the current GPRS standard. A block received in error can be re-segmented and retransmitted using a more robust transmission mode within the same transmission family. The GPRS and EDGE transmission procedures are very similar, although some differences for high order modes are appreciated. When 4 payload units are transmitted (MCS-7, MCS-8 and MCS-9), these are split into two separate blocks. These blocks are in turn interleaved over only two bursts, for MCS-8 and MCS-9, and over four bursts for MCS-7. All the other MCSs can only transmit a single block that is interleaved over four bursts. When switching to MCS-3 or MCS-6 from MCS-8, three or six padding octets are, respectively, added to fill a radio block. Identically to GPRS, the transmission of a whole EDGE radio block requires 20 ms. EDGE transmission modes MODE MODULATION CODE RATE FAMILY BITS PER RADIO BLOCK BIT RATE (KBPS) MCS1 GMSK 0.53 C 1 x MCS2 GMSK 0.66 B 1 x MCS3 GMSK 0.85 A pad. 1 x A 1 x MCS4 GMSK 1.00 C 2 x MCS5 8PSK 0.37 B 2 x MCS6 8PSK 0.49 A pad. 2 x A 2 x MCS7 8PSK 0.76 B 4 x MCS8 8PSK 0.92 A pad. 4 x MCS9 8PSK 1.00 A 4 x Table 2 EDGE transmission modes COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 10 of 114

11 HSDPA HSDPA is based on a CDMA multiple access scheme and considers both a FDD and TDD component, although SN4G only emulates the FDD one. The FDD mode operates at a chip rate of 3.84 Mcps, which results in an approximated bandwidth of 5 MHz. In the time domain, a Transmission Time Interval (TTI) of 2 ms is defined. A TTI is further divided into three 667 pts slots. In the code domain, channelization codes at a fixed spreading factor of 16 are used. Multi-code transmission to a single user during a TTI is also allowed. Current version of HSDPA implemented in SN4G (Release 6) achieves high data rates of up to 14 Mbps by means of adaptive modulation and coding (AMC), fast scheduling mechanisms (each TTI) and a powerful Hybrid ARQ mechanism. AMC or Link adaptation (LA) is a process of paramount importance to optimize system functioning. Its operation is based on user equipment reporting the channel state either cyclically or in a triggered-based manner by means of the Channel Quality Indicator (CQI). The definition and processing of the CQIs is explained in detail in [2]. Numerically, CQI varies from 1 to 30, increasing its value when the channel quality augments. To model the radio channel quality, the simulator considers several look-up tables (LUT) matching the SINR (Signal to Interference Ratio) as a function of the BLER (Block Error Rate); in particular, one for each CQI such that the maximum CQI can be calculated considering a specific QoS. These LUT also include the effect of the HARQ retransmission with chase combining. The available number of codes has also been carefully taken into account and, in the same way, power consumption of all the control channels has been considered to determine the available power per user. Assuming code multiplexing of n users per TTI, n HS-SCCH channelization codes should be allocated, whereas the available power is equally divided among the n users. The maximum number of HS-SSCH codes has been set to 4. WLAN Current WLAN standards do not contemplate the same level of radio resource management functionality than mobile systems. However, extensions that support a more advanced RRM framework have been developed in standardization bodies. In this context, SN4G implements the e specification, which provides more advanced MAC mechanisms to support QoS. This standard specifies two access mechanisms; the Enhanced Distributed Channel Access (EDCA) and the HCF controlled channel access (HCCA). According to the literature, the optimum system operation corresponds to the case in which both access mechanisms work together, and this is the philosophy followed in SN4G. At the physical layer, both WLANs b/g versions have been implemented. Table 3 summarizes the list of properties for both specifications. In SN4G, user equipments are simply characterized by the receiver sensitivity (S) and the transmission power, which has been set to 100 mw (20 dbm). LTE The Long Term Evolution (LTE) radio interface is based on OFDMA multiple access mechanism and can be deployed in FDD or TDD. However, our implementation is restricted to FDD mode. User data are transmitted from the enodeb to the User Equipments (UEs) using a shared channel. Fast scheduling is performed in the enodeb in order to decide how to distribute shared downlink resources (time, frequency and power) among the UEs. For each one of the receivers, one or two (with MIMO) transport blocks (TBs) can be transmitted in each 1ms transmit time interval (TTI), which is the minimum required simulation resolution. These TBs can be transmitted according to different combinations of modulation and coding rate. HARQ (Hybrid Automatic Repeat Request) mechanisms are used. Besides, different MIMO schemes can be applied. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 11 of 114

12 SCHEME DSSS OFDM MOD. WLAN PHY MAIN CHARACTERISTICS MAX PHY DATA RATE (MBPS) MAX MAC DATA RATE (MBPS) FAMILY S (DBM) BPSK b -94 QPSK b -92 CCK b -91 CCK b -89 BPSK g -82 BPSK g -81 QPSK g -79 QPSK g QAM g QAM g QAM g QAM g -65 Table 3 WLAN PHY main characteristics The LTE simulator (Release 8) presents some specific features: New link to system model based on the effective SINR calculation. An effective SINR is calculated based on a sampling of the SINR in frequency domain using previously calibrated functions. Then, this effective SINR value is mapped to a BLER value using LUTs obtained for AWGN channels. All the required information has been simulated. As LTE is based on OFDM, the scheduling is in frequency, space and time. CQI (Channel Quality Indicator) presents a different definition in LTE. Besides, other indicators, namely PMI (Precoding Matrix Indicator) and RI (Rank Indicator), are present and useful for MIMO operation. One or two TBs can be transmitted in each TTI, so up to two HARQ processes can be active at the same time. The Table 4 shows the possible CQI indexes, and the corresponding modulations, code rates and efficiencies. In LTE, there are more possible transmission modes but in order to reduce the number of cases, only the modes proposed in [3] are considered in the simulator. After the measurement and evaluation of the radio channel conditions, the UE (User Equipment) selects a CQI index. This selection entails that the UE is able to receive information with the modulation, code rate and efficiency associated with this CQI index and with a BLER less than 10%. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 12 of 114

13 CQI TABLE CQI INDEX MODULATION CODE RATE X 1024 EFFICIENCY 0 out of range 1 QPSK QPSK QPSK QPSK QPSK QPSK QAM QAM QAM QAM QAM QAM QAM QAM QAM Table 4 CQI table 2.3 Traffic Model The traffic generation is divided in two stages: - Session generation: A traffic session is created. A session generator decides which service is related with the new traffic session and the session duration. - Object generation: The objects of each session are generated (web pages, video frames etc.) Traffic Sessions Generation The following parameters have to be taken into account. Traffic generation process Considering the possibility of having a set of simultaneous users characterized by a Poisson distribution, the time between two session generations follows: exp x f x Where (sessions per second) is the session generation rate. Session duration, (4.3) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 13 of 114

14 If any service does not have specific session duration, it is defined by the following distribution: Where exp x f x 1 is the mean duration of sessions. 2.4 Operation Model, (4.4) During a communication there are periods of activity (ON periods) and periods of non-activity or silence (OFF periods): - Duration and distribution of the ON period. - Duration and distribution of the OFF period. For streaming services there is no OFF period. 2.5 Packet Generation Process It is characterized by statistical distributions of the following parameters: - Beginning of packet transmission. - Packet size. 2.6 Considered Services The following types of service are considered: - Voice o o Circuit based. VoIP - Video Telephony. - Web browsing. 2.7 Voice: Circuit based Speech is the most classical service provided in mobile communications systems. The voice service modeling hereinafter described considers a circuit-based connection. - Service specification Real Time (RT) services (voice, videophone, voice over IP, etc.) are characterized by their symmetric or quasi-symmetric nature, where the inherent Quality of Service (QoS) allows a very small delay (20 ms). - Source operation model COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 14 of 114

15 The traffic model should be an on-off model, with activity and silent periods being generated by an exponential distribution. Mean value for active and silence periods are equal to 3 seconds and independent on the up and downlink, and both are exponentially distributed. The activity factor of the source is defined as the proportion of the time that the source is active. For negative exponential distributions, the activity factor can be extracted as: T T active active T inactive With the proposed activity periods the activity factor is equal to 0.5., (4.5) Finally, it can also be defined the parameter Penetration. This parameter indicates the percentage of users in the simulation that request a particular service. For the circuit based voice service, Penetration is 20% Voice: VoIP - Service parameters VOIP SERVICE PARAMETERS Service Type Delay Bit Rate Symmetry VoIP Conversationa l (Real Time) < 150 ms VBR* depending on CODEC Number of Users BER Protoco l 1UL-1DL 1-1, 1-m 10-4 UDP *Variable Bit Rate. - Session generation Table 5 VoIP Service parameters The traffic is modelled by means of a Poisson process, which indicates when the calls are generated. The call duration is defined by a negative exponential distribution with a mean of 120 seconds. Depending on the Poisson process rate, the load of the network varies. Table 6 shows these parameters. VOIP SESSION GENERATION PARAMTERS Service Generation Process Penetration Session Duration Mean Session Duration VoIP Poisson 35% Negative exponential 120s - Source operation model Table 6 VoIP Session generation parameters In order to describe the traffic at session level, the ON and OFF periods must be defined. These parameters follow a negative exponential distribution. As it is shown in Table 7, the mean durations of ON periods and OFF periods are 1,35 seconds and 1,70 seconds, respectively. These last definitions are necessary because the newest coders detect the OFF periods during communications in order to save resources. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 15 of 114

16 Service Burstiness* Distribution VOIP SOURCE OPERATION MODEL PARAMTERS Mean duration of ON period Mean duration of OFF period VoIP 1 Negative Exponential 1.35 s 1.70 s Table 7 VoIP Source operation model parameters * The ratio between the peak bit rate and the mean bit rate is known as burstiness and describes the traffic variability. - Packet generation The packet generation model is based on the statistics of the different codecs used for voice audio signals. These codecs are presented with its respective usage probabilities. Moreover, it has to be defined the interval between each packet transmission and its size (with and without compression). The codec for each user is selected depending on the usage probability. A constant packet flow with compression is transmitted every interval. Codec Voice Bit Rate (kbps) Interval (ms) VOIP PACKET GENERATION Load (Bytes) IP Load (Bytes) IP Load Compression (Bytes) VoIP bit rate (kbps) Usage probability G G x G / /24 60/64 22/26 5.8/ Video telephony - Service parameters Table 8 VoIP packet generation The video transmission requires data compression because otherwise the needed data rate is not available in mobile communications. Nowadays, two types of compression are used: o o H.26x (ITU) MPEG (International Standardization Organization, ISO) The standard H.263 allows compression rates around 100:1 (sometimes even 200:1) achieving acceptable video quality. Consequently, this is the chosen standard for our platform. Table 9 shows main service parameters. VIDEO TELEPHONY SERVICE PARAMETERS Service Type Delay Bit Rate Symmetry Videotelephony Conversational < 200 ms VBR kbps Number of Users BER Protocol 1UL-1DL UDP - Session generation Table 9 Video telephony service parameters COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 16 of 114

17 Table 10 shows main parameters of session generation. It is modelled by means of a Poisson process with mean session duration of 300 seconds. Service Videotelephony Generation Process VIDEO TELEPHONY SESSION GENERATOR Penetration Session Duration Mean Session Duration Poisson 15% Negative exponential 300sec - Source operation model Table 10 Video telephony session generation The source is always active. However, the parameter burstiness could be different to 1 because the data rate variability. Table 11 summarizes these ideas. Service - Packet generation (Frames) Burstiness Video-telephony 1-5 The video coder H.263 has two modes: Table 11 Video telephony source operation model - Intra: Each coded frame is the coding of one single image. These frames are called I frames. - Inter: Each coded frame is the coding of one image taking into account also the previous image. Only the zones that are different for the image of interest and the previous one are coded. These frames are called P frames. According to this, the first frame in a video sequence H.263 must be an I frame. The usage of P frame allows a bandwidth saving because the P frames are shorter than I frames. The frequency of I frames transmission is called refresh frequency. A higher refresh frequency allows better video quality but needs higher bandwidth. The standard H.263 has four optional modes. The selected mode here is the PB frames mode, which allows an increment in terms of images per second without increasing the needed data rate considerably. This is possible because the same frame contains information of two different coded images. A PB frame consists of a P image and a B image. The B image is coded taking into account not only the previous image but also the following image. A PB frame is only generated when both, the P and B images, are ready. The receiver reconstructs first the P image and then the B image, after that the B image is shown first and the P image later. The codification process and the different types of frames are shown in Figure 4 and Figure 5. The considered model implements the three different types of frames: I, P and PB. The I frames are generated with a given regular frequency but the P and PB frames generation is determined by a Markov chain. The Markov chain is shown in Figure 6. The frame size and duration are determined by probabilistic methods based on a real coded video sequence. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 17 of 114

18 Frames I Frame P Frame PB Frame PB Frame P Frame I Frame I P B P B P P I t Figure 4 Coding process for H.263 with the different types of image: I, P and B P P TI TP TPB TPB TP TI I PB PB I t DI DP DPB DPB DP Figure 5 The different types of frame. Each type of frame has different size (TI, TP, TPB) and duration (DI, DP, DPB) PPB-P PP-P P Frame PB Frame PPB-PB PP-PB Figure 6 Markov model for the transition between types of frame Table 12 summarizes the main parameters of the packet generation. VIDEO TELEPHONY PACKET GENERATION Refresh Frequency (Hz) Size T (B) Duration D (ms) Transition Probability I 1e P Normal M=837 Std=125 Normal M=138 Std= PB Normal M=1821 Std=107 Normal M=224 Std= From P From PB COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 18 of 114

19 Table 12 Video telephony packet generation Web browsing - Service parameters The main protocols involved in this service are: o o HTTP (HyperText Transfer Protocol) TCP (Transmission Control Protocol) A web page is composed of different objects (text, pictures, list, etc.). In order to download a web page, the user has to receive each element. To do that, the protocol HTTP establishes TCP connections. Table 13 summarizes main service parameters. WEB BROWSING SERVICE PARAMETERS Service Type Delay Bit Rate Symmetry Web Browsing Number of Users BER Protocol Interactive Few seconds VBR > 16 kbps 1UL-5DL TCP - Session generation Table 13 Web browsing service parameters The session duration is determined by the calculation of the number of pages per session. This parameter follows a lognormal distribution (α = 1.8 y β = 1.68). According to this, the mean number of pages per session is 25 with a standard deviation of 100. Table 14 and Table 15 summarize these parameters. WEB PAGES PER SESSION Service Generation Process Penetration Session Duration Page Size Web Poisson 25% Number of Pages Per Session 50 kb Table 14 Web browsing session generation Parameter Mathematical Distribution Probability Distribution Function Constant values Number of Web Pages per Session Lognormal 1 f x e x 2 ln x α=1.8 β = Source operation model Table 15 Calculation of number of web pages per session In the traffic model is based on the establishment of one TCP connection per object. Usually, during a session the user visits more than one web page. The transfer stage starts when the user requests a web page, and ends when this web page is completely received. The period while the user is reading the web page is considered an inactivity stage. This stage ends when the user requests for another web page. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 19 of 114

20 Indoor Hotspot (InH) Table 16 and Table 17 summarize main parameters of source operation model. SERVICE AND BURSTISNESS Service Burstiness Web 1-20 Table 16 Service and burstiness INACTIVITY STAGE Parameter Mathematical Distribution Probability Distribution Function Constant values OFF period (inactivity stage) Pareto k f( x) x 1 k=1 α=1,5 Table 17 Definition of inactivity stage - Packet generation As the selected model is based in one TCP connection per object, during the transfer stage there are ON and also OFF periods. The ON periods correspond to the transmission of web page objects, and OFF periods are the time intervals between the end of an object transmission and the transmission start of next object. Table 18 summarizes main parameters of packet generation. WEB BROWSING PACKET GENERATION Parameter Mathematical Distribution Probability Distribution Function Constant Values Object Size Pareto k f( x) x 1 k=1000 α=1,0 OFF period (transfer stage) Number of web objects per web page Weibull Pareto bx f ( x) a b1 b e k f( x) x b ( x/ a) 1 a=1,46 b=0,382 k=1 α=2,43 Table 18 Web browsing packet generation 2.8 Path Loss Models: Path loss models implemented in SN4G PATH LOSS MODELS SCENARIO PATH LOSS (DB) NOTE: F C IS GIVEN IN GHZ AND DISTANCE IN M! SHADOW FADING STD (DB) LoS PL = 16.9 log 10 (d) log 10 (f c ) = 3 APPLICABILITY RANGE, ANTENNA HEIGHT DEFAULT VALUES 3 m < d < 100 m h BS = 3-6 m h UT = m COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 20 of 114

21 Suburban Macro (SMa, optional) Urban Macro (UMa) Urban Micro (UMi) NLoS PL = 43.3 log 10 (d) log 10 (f c ) = 4 LoS PL = 22.0 log 10 (d) log 10 (f c ) PL = 40 log 10 (d 1 ) log 10 (h BS ) 18 log 10 (h UT ) + 2 log 10 (f c ) = 3 = 3 10 m < d < 150 m h BS = 3-6 m h UT = m 10 m < d 1 < d BP (1) d BP < d 1 < m (1) h BS = 10 m (1), h UT = 1.5 m (1) NLoS PL d, d k l 3log Manhattan grid layout: PL min PL( d1, d2), PL( d2, d1) where: PL ( d ) n 10n log 10 ( f c LOS ) j k and n max d,1.84 k j j 10 ( d ) l = 4 10 m < d 1 + d 2 < m, w/2 < min(d 1,d 2 ) (2) w = 20 m (street width) h BS = 10 m, h UT = 1.5 m. When 0 < min(d 1,d 2 ) < w/2, the LoS PL is applied. O-to-I PLLOS: path loss of scenario UMi LoS and k,l {1,2}. Hexagonal cell layout: PL = 36.7 log10(d) log10(fc) PL PL PL b tw PL Manhattan grid layout (θ known): PL PL PL b tw in PL B1 0.5d ( d d in 14 15(1 cos(θ)) in out For hexagonal layout (θ unknown): PL tw = 20, other values remain the same. in ) 2 = 4 = 7 10 m < d < m h BS = 10 m h UT =1-2.5 m 10 m < d out + d in< m, 0 m < d in< 25 m, h BS = 10 m, h UT = 3(n Fl -1) m, n Fl = 1 Explanations: see (3) PL = 22.0 log 10 (d) log 10 (f c ) = 4 10 m < d < d BP (1) LoS PL 40.0log log ( d 10 1 ( h' ) log UT ) 2.0log f ( h' c BS ) = 4 d BP < d < m (1) h BS = 25 m (1), h UT = 1.5 m (1) 10 m < d < m h = avg. building height W = street width NLoS PL = log 10 (W) log 10 (h) ( (h/h BS ) 2 ) log 10 (h BS ) + ( log 10 (h BS )) (log 10 (d) 3) + 20 log 10 (f c ) (3.2 (log 10 (11.75 h UT )) ) = 6 h BS = 25 m, h UT = 1.5 m, W = 20 m, h = 20 m. The applicability ranges: 5 m < h < 50 m 5 m < W < 50 m 10 m < h BS < 150 m 1 m < h UT < 10 m 10 m < d < d BP (4) LoS PL 1 = 20 log 10 (40 d f c /3) + min(0.03h 1.72,10) log 10 (d) min(0.044h 1.72,14.77) log 10 (h)d PL 2 = PL 1 (d BP ) + 40 log 10 (d/d BP ) σ = 4 σ = 6 d BP < d < m h BS = 35 m, h UT = 1.5 m, W = 20 m, h = 10 m (The applicability ranges of h, W, h BS, h UT are same as in UMa NLoS) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 21 of 114

22 Rural Macro (RMa) NLoS PL = log 10 (W) log 10 (h) ( (h/h BS ) 2 ) log 10 (h BS ) + ( log 10 (h BS )) (log 10 (d) 3) + 20 log 10 (f c ) (3.2 (log 10 (11.75 h UT )) ) = 8 10 m < d < m h BS = 35 m, h UT = 1.5 m, W = 20 m, h = 10 m (Applicability ranges of h, W, h BS, h UT are same as in UMa NLoS) 10 m < d < d (4) BP LoS PL 1 = 20 log 10 (40 d f c /3) + min(0.03h 1.72,10) log 10 (d) min(0.044h 1.72,14.77) log 10 (h)d PL 2 = PL 1 (d BP ) + 40 log 10 (d/d BP ) = 4 = 6 d BP < d < m, h BS = 35 m, h UT = 1.5 m, W = 20 m, h = 5 m (Applicability ranges of h, W, h BS, h UT are same as UMa NLoS) 10 m < d < m, NLoS PL = log 10 (W) log 10 (h) ( (h/h BS ) 2 ) log 10 (h BS ) + ( log 10 (h BS )) (log 10 (d) 3) + 20 log 10 (f c ) (3.2 (log 10 (11.75 h UT )) ) = 8 h BS = 35 m, h UT = 1.5 m, W = 20 m, h = 5 m (The applicability ranges of h, W, h BS, h UT are same as UMa NLoS) 2.9 Main simulator features Figure 7 shows the scenario modelled by the SN4G platform, which includes the GPRS/ EDGE, HSDPA, WLAN and LTE radio interfaces. As shown in the figure, the SN4G platform does not only model the radio interface of the four technologies but also implement various RAT specific RRM features and a centralized CRRM (Common RRM) entity. This entity directly collects specific RAT information (e.g. load, channel quality conditions, etc.) and interacts with the RRM entities implemented at each RAT. The main components of SN4G simulator, their features, interactions and data flow are described in the following subsections Cellular environment The Cellular Environment entity is a system module storing the location of each base station and the interfering relations among them; this information is needed to estimate the experienced interference levels. The cellular layout can be modified offline at any time to change the system configuration under study. In order to avoid border effects, a wrap-around technique has been applied. Moreover, sectorized cell sites can be modelled. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 22 of 114

23 Figure 7 SN4G heterogeneous scenario For the COMMUNE project, in order to simulate HetNets would be possible to define network layers, specifying the number of micro/pico/femto base stations per macrocell, allowing realistic analysis that includes different types of radio channels, depending on the network layer Radio Link This module models the radio propagation conditions between transmitter and receiver and is a generic entity employed by any wireless link established. It characterizes the three radio propagation effects, namely path loss, shadowing and fast fading. Depending on the technology, the radio link modelling is different. In the case of LTE, the channel model is the one proposed by the ITU in the M.2135 document [1]. For GSM and UMTS the path loss (in db) reported in [4] has been considered: L p 2 ( hb )log 10 d 18log 10 hb 21log 10 f 80 Where d is the distance in km between the base station transceiver and the mobile terminal, f is the carrier frequency in MHz and Δh b is the base station antenna height, measured in meters from the average roof top level. Typical values for these parameters are Δh b = 15m, f=2000 MHz for HSDPA and f=1800 MHz for GPRS and EDGE. For WLAN, the following path loss model has been implemented [1]: L ( ) log p db 10 d The shadowing loss has been modelled as a random process with a normal distribution of mean 0 db and standard deviation of 6 db for urban and suburban environment. The shadowing is a spatially correlated process so that the shadowing loss experienced by a mobile at a given position is correlated to that experienced at a nearby position. The current version of the SN4G platform models this spatial correlation as detailed in [7], with a de-correlation distance of 20 m. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 23 of 114

24 Fast fading modelling is also important when considering technologies, such as EDGE and HSDPA, which base their radio operation on link adaptation techniques [8]. In these RATs, transmission conditions are modified depending on the current channel characteristics. For the sake of simplicity, in SN4G only a simple block fading model is considered, i.e. the fast fading stays constant over a coherence time interval and each sample is statistically independent. Hence, in addition to the path loss and shadowing value of each radio block, in SN4G a third multiplicative factor is considered when determining the received carrier: the fast fading coefficient. This factor is of unit mean and follows the probability density function: M ( M 1)! M 1 M f ( ) ( M ) e Here, M denotes the number of resolvable independent multi-paths at the receiver. In GPRS and EDGE M is set to 1 and in HSDPA M= Base Station Base Station entity is responsible for the Medium Access Control (MAC) and RRM functions. It also controls the channel pool where the status of all channels per RAT is maintained. In the Base Station is also located the session generation process. Once a new mobile is active in the system, the CRRM entity chooses its initial RAT depending on a specific policy. When a mobile station requests a channel from a given RAT, the channel pool of the serving base station is examined to search for an available channel. If a free channel is available on the requested RAT, the mobile station is assigned a randomly chosen channel or based on some quality metrics [9]. If a free channel is not available on the requested RAT, the mobile station is assigned a channel from a different RAT, depending on the CRRM scheme under consideration, or it is placed in a queue until a transmitting mobile ends its transmission and releases its channel. For users in GPRS and EDGE queues, a First-Come First-Served (FCFS) scheduling policy is applied so that channel requests are satisfied in the same order as they appear. Users in the HSDPA/LTE queue can be served either in a round robin fashion, according to the Max C/I criterion, which selects at any moment the user with better transmission quality, or following the proportional fair algorithm. In WLAN, real-time traffic is delivered through HCCA with a FCFS policy, whereas best effort users mutually contend to get the channel control being served using the EDCA protocol. Apart from the scheduling, other implemented RRM functionalities include Link Adaptation for GPRS, EDGE, HSPDA, WLAN and LTE, multi-channel operation for GPRS and EDGE, multi-code allocation in HSDPA, multi-resource Block allocation in LTE and call admission control in all technologies. Link adaptation (LA), also referred to as Adaptive Modulation and Coding (AMC) in HSDPA and LTE, is an adaptive RRM technique that periodically estimates the channel quality conditions and selects the optimum transmission mode based on a predefined selection criterion. For web browsing, the transmission mode that maximizes the throughput is selected. For H.263 video service, in GPRS and EDGE the algorithm proposed in [10] has been used since it outperforms the former in several key aspects affecting real-time operation. In the case of multi-channel transmissions, the channel quality conditions are estimated over all channels simultaneously assigned to a single user and their average value is used to estimate the optimum transmission mode according to the established selection criterion. In HSDPA and LTE, the mobile directly reports its channel conditions to the base station by means of the CQI. With this information, the base station knows the maximum number of codes or resource blocks to be allocated as well as the modulation and coding scheme. The final allocation shall always be as high as possible but not exceeding the transmission mode reported by the user. Automatic Rate Fallback (ARF) is the implemented LA algorithm for WLAN; ARF and other algorithms with similar operating concepts have been widely implemented in many WLAN products although they are not included in the IEEE standards. In ARF, the sender deduces the channel conditions by COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 24 of 114

25 measuring the numbers of consecutively successful and failed transmissions. The sender adjusts its modulation mode and data rate in accordance with these measurements. Multi-channel, multi-code and multi-resource block operation is considered in the SN4G simulation platform for the GPRS-EDGE, HSDPA and LTE radio interfaces, respectively. The number of channels, codes or resource blocks that a base station can simultaneously allocate to a single user depends on factors such as the capability of the terminal, the system load, the availability of radio resource, the requested service type and the considered multi-channel allocation policy. In the current implementation, CRRM techniques can be also included. These CRRM mechanisms base their RAT selection on utility functions and operating parameters, such as the RAT load, required service and its QoS parameters, interference levels and effect on active transmissions, etc. The RAT selection can be performed for each new session, periodically, or every time a new packet is generated. It is important to highlight that RAT changes are done dynamically in the SN4G platform and that the radio transmission can be immediately resumed with the newly selected RAT at the stage where the radio transmission ended using the previous RAT. The platform has also been prepared to consider the case in which a user handles different application sessions through various RATs User traffic behaviour User traffic demands are usually described at two levels: session-arrival process and traffic models. Session-arrival processes, also referred as traffic generation, are usually modelled as a birth-death process, which can be characterized by the following parameters: busy hour call attempts (BHCA), arrival distribution, mean session duration, duration distribution, etc. On the other hand traffic models describe the source behaviour within a session. They vary depending on the type of service and they can be described by parameters such as: average active/inactive times, time distributions, data rate, packet length distribution, etc. In SN4G, the session-arrival has been implemented at the base station, while for optimization purposes the mobile station controls the traffic models. Three different services have been implemented in SN4G, namely web browsing and real-time H.263 video transmissions. Cellular subscribers are usually considered to have independent behaviour one from each other, which results in exponentially distributed inter-session arrival times. For each one of the implemented services a specific inter-session time is defined, which allows controlling the traffic load. The web browsing service follows the model described in [11]. It follows an ON/OFF pattern where a web browsing session starts with the submission of a web page request by the user. The time interval needed to transfer the requested web page is referred to as active period. When the transfer is completed, the user will take some time to read the information before initiating another request. This time corresponds to the inactive period. The implemented model is based on the HTTP 1.0 standard where a different TCP connection is established for the transmission of each object in a web page. In this case, the active ON time has been considered as the time needed for the transmission of a single object of a web page, while the active OFF time represents the time elapsed between closing a TCP connection and opening a new one to transfer another object of the same web page. The implemented web browsing traffic distributions are shown in Table 19. PARAMETERS OF THE WEB BROWSING TRAFFIC MODEL COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 25 of 114

26 PARAMETER PARAMETERS OF THE WEB BROWSING TRAFFIC MODEL MATHEMATICAL DISTRIBUTION PROBABILITY DISTRIBUTION FUNCTION CONSTANT VALUES Object Size Pareto k f( x) x 1 k=1000 α=1,0 Active OFF Time Weibull bx f ( x) a b1 b e b ( x/ a) a=1,46 b=0,382 Inactive OFF Time Pareto k f( x) x 1 k=1 α=1,5 Number of Elements/Web Pareto k f( x) x 1 k=1 α=2,43 Table 19 Parameters of the web browsing traffic model Real-time services have also been included in SN4G through the emulation of real-time VoIP [1] and H.263 video transmissions following the model presented in [12]. This last model takes into account the three different frame types considered in the H.263 standard, namely I, P and PB. The model characterizes the size and duration of the video frames, the correlation between both parameters for each video frame, and the transition probability between different video frame types. The modelling is performed at two levels. The first one establishes the frame type to generate. I-frames are periodically created, while a Markov chain drives the transition generation between P- and PBframes. Once the frame type is selected, the model determines the size and the duration of the video frame to be transmitted. The reader is referred to [1] and [12] for a detailed analytical described of the real-time VoIP and H.263 video traffic model, respectively Resource Model The resource model entity is implemented at the mobile station and is basically responsible for controlling the radio transmission parameters of a channel currently assigned to a user and for estimating the experienced channel quality conditions, in this case carrier to interference ratio. For WLAN systems only the received power is calculated since it is the only value needed to obtain the maximum bit rate to be allocated Link Management The Link Management module is responsible for handling the radio transmission and emulating channel errors. Transmission Process GPRS controls the radio transmission of RLC blocks through an Automatic Repeat request (ARQ) protocol, described in specification 3GPP TS 04.60, which is implemented in SN4G. This ARQ protocol is based on the numbering of the blocks and a selective repeat principle with sliding transmitting and receiving windows. The transmitting and receiving ARQ windows have a size of 64 RLC blocks. The reporting period, which defines how regularly the receiver sends acknowledgment messages, has been set to 16 blocks. No block losses and errors on the transmission of the acknowledgement messages have yet been considered in SN4G. A similar ARQ protocol has been implemented for EDGE, with varying window sizes according to the number of channels simultaneously assigned to a single user; the window sizes range vary from 64 to 1024 radio blocks. For EDGE transmissions, a 32 radio blocks has been selected. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 26 of 114

27 In HSDPA and LTE, retransmission of erroneous transport blocks is performed by an N-channel stopand-wait (SAW) ARQ protocol. In stop-and-wait schemes, the transmitter handles the transmission of a single block until it has been successfully received. In SN4G, a maximum of 8 channels can be set up simultaneously since this is the value suggested in the standard. Block size is determined by the reported CQI. As for GPRS and EDGE, no transport block losses or errors on the acknowledgement messages have been emulated. For WLAN, the SN4G platform also implements an ARQ protocol. In this case only one channel SAW is employed. The transport block is a fixed-length IP packet of 1500 bytes although it is possible to perform fragmentation to improve channel utilization. One of the key techniques of LTE is the link adaptation that allows the transmitter to adapt the transmission format, including the MCS, transmission rank and precoder among other parameters, to the channel quality variations. As the simulator implements a FDD system, in which uplink (UL) and DL are separated in frequency, DL quality cannot be estimated directly by the BS through measurements of the UL channel. Instead, the user must report the to the BS what is the channel state that it is experiencing. Several methods are allowed to perform the channel state report. First, explicit channel estimates can be reported to the BS. For example, one channel estimated can be reported per subcarrier. To reduce the overhead of such a transmission only channel correlation matrices could be transmitted. Besides these methods, other kind of non-explicit information could be transmitted. In fact, this approach is common in LTE. Following this approach, the user performs SINR measurements and calculates the most suitable format for transmission. This information includes the most suitable MCS, multi-antenna scheme, and precoding matrices and rank in case of spatial multiplexing. This information is conveyed in a set of reports known as Channel Quality Indicator (CQI), Precoder Matrix Indicator (PMI) and Rank Indicator (RI). In this process, it is necessary to have an interface with the physical layer to know the channel state and also with the link abstraction model to be able to translate the channel state into a transmission quality estimate. An additional source of information used to perform the link adaptation is the HARQ feedback sent by the user to the BS. For instance, if the BS receives a negative acknowledgement, it means that the transmission format used in a previous transmission was incorrect and adaptation is needed. Link adaptation algorithms are not included in the LTE specifications. Therefore, each developer uses a different solution to obtain the best system performance. Channel Errors Emulation The link level performance is represented by a simplified model consisting of a set of Look-Up Tables (LUTs) [8] mapping the CIR (Carrier to Interference Ratio) to a given link quality parameter such as the BLER. Different LUTs need then to be produced for different operating conditions, e.g., RAT and transmission mode, mobile speed and propagation environments (typical urban or rural area). SN4G employs these LUTs to decide whether a radio block is received in error once the CIR experienced by the radio block has been computed. When modelling WLAN it is unusual to make use of LUTs as in cellular systems. Rather, the concept of sensibility is employed. If a certain physical transmission mode is given and the mean received power is over its specific sensibility then the transmitted block will be properly received, otherwise the block is dropped. Regarding LTE, this technology is based on Orthogonal Frequency Domain Multiplexing (OFDM) that is a multicarrier modulation. Then, the outcomes of SINR measurements performed over the air interface are vectors whose elements represent the SINR of each carrier. This fact has made link-tosystem mapping developed for single carrier systems to be useless for LTE. Instead, a family of methods known as Effective SINR Mapping (ESM) is commonly used. These methods map an instantaneous set of SINR samples into a scalar value, which is called effective SINR. The general formula used to obtain the effective SINR is: COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 27 of 114

28 where is the number of samples, is an information measure function and its inverse and and are two configurable parameters. Once the effective value,, has been calculated, a look up table obtained through simulations conducted in an AWGN scenario is used to translate the effective value to, for instance, a BLER value. With this aim, an AWGN look up table must be obtained for each Modulation and Coding Scheme (MCS). For each MCS, and must be calibrated through link level simulations to minimize the error between real BLER (obtained through simulation) and predicted BLER (obtained through the ESM). If the model is perfect, the would be the scalar value that in an AWGN scenario would produce the same BLER obtained in the multicarrier scenario with the measured SINR vector. The most common ESM model in LTE evaluation is the Mutual Information Effective SINR Mapping (MIESM), which is implemented in SN4G. MIESM uses as its information measure the so-called mutual information Simulation process The configuration of the simulated SN4G scenario is made through a web application. This file is read at the beginning of the simulation process and the specified input parameters are loaded. In the course of the simulation process, some performance parameters are written and saved in several output text files. These input and output parameters are described in next sections Configuration parameters The input parameters are introduced by using the SN4G web page. It is possible to create synthetic scenarios with investigation proposals or realistic scenarios where the base stations are located over a map. Relevant parameters are: Active RATs considered in the simulation. In SN4G, it is possible to select the RATs to be considered in the simulated scenario among all the implemented RATs in the platform: GPRS, EDGE, HSDPA, WLAN and LTE. Cell radius for each RAT. For each considered RAT, the cell radius must be configured. Number of interfering cells. This parameter establishes the number of interfering cells considered to calculate the interference signal level. Several examples are shown in Figure 8. In a scenario considering four 120º-sectorised cells per cluster, 7 interfering cells mean that the first and the second interference rings are considered to calculate the interference signal level. In a four omnidirectional cells per cluster pattern, the number of interfering cells will be 6 if the first interference ring is only considered. The same number of interfering cells must be established if an interference reuse factor of 1 is considered as in HSDPA systems or LTE. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 28 of 114

29 Figure 8 Interference patterns for different cell clusters User load. Number of users that are being simulated. Number of frequency carriers per RAT. Thermal noise (default: -121 dbm for GPRS/EDGE, -102 dbm for HSDPA, -90 dbm for WLAN and bandwidth-specific for LTE). Transmission power (default: 30 dbm for GPRS/EDGE, 43 dbm for HSDPA and LTE and 20 dbm for WLAN). HSDPA orthogonality factor (default: 0.8). The orthogonality factor quantifies the loss of orthogonality between the signals transmitted simultaneously using two different channelization codes in the same cell due to multipath dispersion. Number of cells. Total number of cells consider in the current simulation. Session and traffic input parameters. All the parameters needed to configure the traffic model employed at the platform must be specified at the configuration file. For a more complete description of these session and traffic parameters, [13] can be consulted. Number of static/pedestrian/vehicular users. Users can be simulated as static, pedestrian or vehicular users with different average speeds. Average pedestrian/vehicular speed (default: 3-5km/h and 80 km/h respectively). The average speed established for each type of users can be specified. LA/AMC updating period (default: 60ms for GPRS/EDGE, 2ms for HSDPA, 1ms for LTE). Seed. The seed to initialize the random number generator. Simulation time Performance measurements Currently, the SN4G output parameters are: BLER and throughput at radio block level per traffic service. BLER and throughput at radio block level per RAT. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 29 of 114

30 Normalized delay at application level per traffic service. Waiting times per traffic service. The time a user has waited for receiving resources to carry out its transmission is saved per traffic service. User satisfaction: percentage of satisfactory transmissions per traffic service: o o WWW transmission is considered satisfactory if a web page is transmitted in less than 4 seconds. Video frames transmissions are considered satisfactory if they are completely transmitted before the next video frame is to be transmitted. Percentage of unsent and aborted video frames for real-time video services. Statistics about the transmission modes utilization are also saved per each RAT and traffic service. The statistics are: o o o o o o o o Total Number of blocks transmitted. Percentage of times each transmission mode has been used. Percentage of times the employed transmission mode was optimally selected. When a block is received, the optimum transmission mode is calculated based on the current radio conditions. Then, the optimum transmission mode is compared with the transmission mode used to transmit the block. If both values are equal, the employed transmission mode is considered optimally selected. Percentage of times the employed transmission mode was more robust than necessary. If the optimum transmission mode calculated at the receiver is less robust than the used transmission mode. Percentage of times the employed transmission mode was less robust than necessary. If the optimum transmission mode calculated at the receiver is more robust than the used transmission mode. Transmission mode change rate. Rate at which the optimum transmission mode selected by the LA mechanism has changed. This parameter provides an estimation of the channel quality variability. Retransmission rate. This output parameter accounts for the radio blocks erroneously received, and then, which must be retransmitted. Percentage of times the employed transmission mode was not optimally selected per each transmission mode. RAT selection statistics. Percentage of times each RAT has been selected to carry out a user transmission. These results are provided per each traffic service. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 30 of 114

31 2.11 Key Performance Indicators General performance evaluation criteria The following indicators should be evaluated for all types of services. Cell spectral efficiency Cell edge user spectral efficiency Peak spectral efficiency calculation Control plane latency calculation User plane latency calculation Intra- and inter-frequency handover interruption time derivation These are all defined in [14]. Average blocking rate It should be determined for all the services that can be blocked. It is calculated over the simulation duration as the ratio of blocked to total service requests of the same type. Average drop rate It should be determined for all the services that can be dropped during operation; typically it is due to handovers, QoS requirements, requests for higher priority services, etc. It is calculated over the simulation duration as the ratio of dropped to total established services of the same type. User Satisfaction The user satisfaction is a subjective concept very difficult to quantify. While a user can be satisfied if its transmission is carried out in less than 4 seconds, other user with a less restrictive criterion can be satisfied if the time transmission is not higher than 6 seconds. Following 3GPP recommendations [15], in SN4G it has been established that and WWW transmissions are considered satisfactory if an or web page is transmitted in less than 4 seconds. Real-time video transmissions are considered satisfactory if video frames are completely transmitted before the next video frame is to be transmitted. In this context, the user satisfaction parameter accounts for the percentage of satisfactory transmissions. Another important performance indicator for real-time video services is the Quality of Experience (QoE) established by the ITU-T that is next presented Service-specific performance evaluation criteria: Voice Services VoIP system capacity Number of users the cell can have while ensuring that more than 95% of the users are satisfied. A VoIP user is not satisfied (in outage) if 98% radio interface latency of the user is greater than 50 ms. This assumes an end-to-end delay below 200 ms for mobile-to-mobile communications. Quality of Experience (QoE) of Voice Services COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 31 of 114

32 The quality of service provided to applications is defined in terms of a Service Level Agreement (SLA), a specification that defines the QoS parameters thresholds. The more frequent QoS parameters used are: bandwidth, delay, jitter and packet loss. In order to evaluate and measure permanently the quality of voice during a conversation as perceived by the user, we adopted the objective metric E-Model. The E-Model, defined in the ITU-T G.107 [16], analyses the QoS parameters and quantify the voice quality by calculating a scalar factor between 0 (worst case) and 100 (excellent), which is called the R factor. This factor represents the sum of all degradation factors in the communication and is obtained using the following expression: ( ) Signal-to-Noise Ratio [ ], results of several types of noise, like transmission circuit noise, environment noise both in the transmitter and receiver, and a noise ceiling corresponding to the sensitivity of the human hearing system. ITU-T G.107 specification, defined the value for this factor. Simultaneous Impairment [ ] represents all the impairments that occur simultaneous with the voice signal, like the quantization distortion caused by digitizing the voice signal. ITU-T G.107 specification defined the value 1.41 for this factor. Delay Impairments [ ], represents the losses associated to the end-to-end delay. According to Lustosa [17], it is possible to obtain the value through an interpolated expression of the expressions defined in ITU-T G.107. The following expression calculates the value: where represents the system absolute delay. Equipment Impairment [ ] represents the equipment impairments caused by the Codec and packet losses. ITU-T G.113 [18] defines a set of provisory values for this factor. Advantage Factor [ ] allows for compensation of impairment factors where there are considered advantages of access to the user, e.g. mobile terminals. ITU-T G.113 specification defines for fixed telephone networks. Video Services Playable I-frame and total frame rate Averaged over the whole video sequence. Transmission loss Ratio between the number of frames that never arrived and the total number of frames in the sequence. Late loss Ratio between the number of frames that arrived too late and the total number of frames in the sequence. Quality of Experience (QoE) of Video Services COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 32 of 114

33 End-user perception is crucial for the successful deployment of IPTV services. A practical way to measure end-user quality is to use a parametric objective opinion model to estimate the subjectively perceived quality of the video, taking as quality factors the coding quality and potential problems due to transport on the network. ITU-T has standardized a parametric computational model, as Recommendation G.1070 [19], for evaluating QoE of video-telephony. The model estimates the QoE of video-telephony services based on quality design/management parameters in terminals and networks. This model can be extended to live streaming IPTV environments to compute the best video quality (MOS) at any specific moment in time, by the equation: { } where represents the basic video quality affected by the coding distortion under a combination of video bit rate ( [kbit/s]) and video frame rate ( [fps]), and the packet loss robustness factor expresses the degree of video quality robustness due to packet loss where [%] represents the packet-loss rate. The basic video quality affected by coding distortion is expressed as: { ( ( ) ( )) ( ) } The is an optimal frame rate that maximizes the video quality at each video bit rate ( ) and is expressed as: where, fr, represents the maximum video quality at each video bit rate ( ) and is expressed as: represents the degree of video quality robustness due to frame rate ( ) and is expressed as: Coefficients, and are dependent on codec type, video format, key frame interval, and video display size. The packet loss robustness factor represents the degree of video quality robustness against packet loss and is expressed as: { } { }, Coefficients, and are dependent on codec type, video format, key frame interval, and video display size. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 33 of 114

34 2.12 Other Outputs from SN4G Additionally to the performance measurements defined in and 2.11, SN4G provides other kind of results that would be useful for COMMUNE project, explained in the following points Performance & QoS measurements These outputs comprise QoS concepts measured in terms of block probability, drop probability and average throughput or outage probability for voice or data services. Besides, QoS is applicable to each type of service voice, www, etc. There are some aspects that should be mentioned in terms of QoS analysis: The QoS is a reference of quality for each service and for each type of user - with and without priority. SN4G provides complete QoS information with variation of total system load, total number of priority users and the use of each service. Main outputs values are: Average Throughput of packet services. Outage probability: depends on the requirements and the scenario. The requirements are different if an emergency situation occurs in a central metro station or in the forest. Block probability for priority users: probability that a service request by priority user is not accepted Block probability for non-priority users: probability that a service request by non-priority user is not accepted Drop probability for priority users: probability that an ongoing call voice or data of a priority user drops Drop probability for non-priority users: probability that an ongoing call voice or data of a non-priority user drops Establishment time for priority www: time between a priority user request a service and the real user data starts to be transmitted or received Establishment time for priority VoIP Establishment time for non-priority www Establishment time for non-priority VoIP Spectral Efficiency SN4G simulator provides a wide set of spectral efficiency analysis, including CDF of user spectral efficiency or cell edge user spectral efficiency in different scenarios defined by 3GPP. These outputs could be seen in the figures below. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 34 of 114

35 C.D.F. [%] Org Org. 2 SN4G 20 Org Org. 6 Org ,0 0,2 0,4 0,6 0,8 1,0 normalized user throughput [bps/hz] 3,000 2,500 2,000 1,500 1,000 0,500 0,000 cell spectral efficiency [bps/hz/cell] InH Umi Uma Rma SN4G 3GPP 0,1000 0,0800 0,0600 0,0400 0,0200 0,0000 cell edge user spectral efficiency [bps/hz] InH Umi Uma Rma SN4G 3GPP Figure 9 Different spectral efficiency outputs Analysis of Scenarios with Actual BS SN4G simulator can analyse in deep real scenarios, providing the most relevant results in terms of network performance, traffic, SNR, etc. Real locations of BSs can be loaded together with external traffic maps. Besides, from drive test, SN4G can load mobility traces and path losses, thus resulting in a real use simulation. Next figures show an example of these concepts. Figure 10 Path Loss Map Loaded in SN4G COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 35 of 114

36 Figure 11 Real Drive Test used for Calibration Purposes Figure 12 MAC throughput & Serving ID prediction Figure 13 Cell ID and SNR Maps COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 36 of 114

37 Figure 14 Serving Cell and Delivered Traffic Maps Graphical Results for Synthetic Scenarios SN4G simulator can generate different type of outputs for synthetic scenarios as defined by ITU-R M Some examples could be found here. The statistical results are also available for Real Scenario Simulations. Figure 15 SINR and Throughput Maps for InH Synthetic Scenario Figure 16 Some of the statistical results for InH Synthetic Scenario (Spectral Efficiency and SINR) 2.13 RRM Functions Scheduling Scheduling is one of the main functions of the Radio Resource Management (RRM) and is carried at the BS. Scheduling decides how to allocate resources to the users in each transmission, that is, at a fast pace (once per millisecond in case of LTE). Additionally, the scheduling process includes not only the selection of the resources devoted to each user, but it also decides for each selected user which HARQ process will carry the transmission. This implies that the scheduler decides if the transmission carried is a retransmission or a new one. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 37 of 114

38 Given a utility function (for example, the cell spectral efficiency), the problem of performing an optimum scheduling decision to maximize this utility function is usually a Non-deterministic Polynomial-time (NP)-hard problem. That is, it is not feasible to obtain the optimum solution in a limited amount of time and with a limited amount of computational resources. Instead, suboptimal algorithms are designed to get the most of the available resources. Opportunistic scheduling is a term that includes the group of algorithms that use the channel state information reported by the users to allocate each resource to the user with better channel state at that resource. Scheduling algorithms are not included in the specifications. In the simulation platform, different kind of schedulers are implemented including the Round Robin algorithm that allocates resources equally among the users, the MaxCQI algorithm that allocates each resource to the user with best quality and the Proportional Fair algorithm that allocates the resources to the users with a priority that is directly proportional to the channel quality of this user but inversely proportional to the throughput experienced in the past by this user Call Admission Control The main objective of the Call Admission Control (CAC) is to prevent oversubscription in the mobile communications network. The CAC is the first step to control the load and uses user and service priorities to make proper and fair decisions. The CAC is activated when a new service request arrives. Then, the CAC has to check if a pre-defined threshold is reached or exceeded. When it occurs, the CAC has to decide upon the next action. For example, it will reject the call if the service and the user are non-priority. There are several methods to define the threshold. The method depends on the measured parameter. At this point, it is possible to define two examples to explain how to set the threshold values. For example, it is possible to define a minimum QoS per RAT and per service. Then, when the QoS is lower than the threshold, the CAC is activated. On the other hand, it is possible to define a maximum percentage of the system utilization. When the system is overloaded, then the CAC has to execute the required actions to reduce this congestion. In SN4G all CAC techniques contemplated in the standards for GPRS/EDGE, HSDPA and LTE are implemented. Closed Subscriber Group In 3GPP, a HeNB access is classified either as a closed, hybrid or open access type. A closed access HeNB maintains a Closed Subscriber Group (CSG) white list where access is limited only to subscribed users (i.e. to UEs that are members of the CSG). Hybrid access HeNBs allow limited access to nonsubscribed UEs, but provide differentiated higher quality of service to CSG users. Open access HeNBs provide undifferentiated access to all UEs. In Rel-10, X2 interface is used between open access HeNBs and between closed/hybrid access HeNBs with identical CSG IDs and between closed/hybrid HeNBs and open access HeNBs. SN4G is able to model the concept of CSG in a HetNet scenario Congestion Control The Congestion Control (CC) mechanism comprises the set of processes that are used to reduce congestion in a network. There are different solutions to achieve this purpose, as for example: reduce the bit rate, delay non-real time transmission until the network becomes unloaded or directly remove users. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 38 of 114

39 CC is always checking the total load at each RAT. When the load is over a threshold, the CC starts to work. The goal of the CC is to keep the load level under this threshold. In order to establish the threshold, it is important to know the characteristics of the different services. How the load is reduced depends on the service and the priority of the user. Table 20 is a summary of the SN4G CC module. The table is an example of different configurations, - option 1, option 2 and option 3 - in order to find the best solution. Besides, it is defined considering different services. In this example, VoIP is the service with higher priority, followed by video calling and web browsing respectively. CC: CHARACTERISTICS OF THE SN4G SIMULATOR USER PRIORITY USER SERVICE OPTION 1 OPTION 2 OPTION 3 VoIP Do nothing Do nothing Do nothing Priority Non-priority Video call Reduce quality Reduce quality Reduce quality www Reduce bit rate Reduce bit rate Reduce bit rate VoIP Reduce quality Reduce quality Reduce quality Video call Reduce quality Reduce quality Remove www Reduce bit rate Remove Remove Table 20 CC: Characteristics of the SN4G simulator The CC executes the required actions starting with the lowest priority service for non-priority users. The last option is the highest priority service for priority users. In the previous example, when the CC detects congestion, it should start removing the bit rate of www non-priority users in Option 1; or remove the users in Option 2 and Option 3. These actions are recursive until congestion is reduced. Finally, we will remain with the optimal solution. The SN4G simulator has one CC per RAT unless it is testing Join Congestion Control (JCC). In this case, the SN4G simulator only implements one CC for all the RATs. The scenarios should define which service type has the highest priority for priority users SN4G Calibration In order to ensure the validity of the results obtained with the simulation platform, it is necessary to conduct a calibration process after the development phase. In this process, several tests are defined and outcomes of different simulators are crosschecked to detect incoherencies. If results are aligned, the simulators are considered well calibrated. Otherwise, more work is needed to achieve calibration. It is important to define properly the calibration tests to ensure that the key building blocks of the simulation are calibrated. A stepwise calibration methodology was followed in the framework of the WINNER+ project. This process consists of three steps: calibration of the large-scale parameters of the channel model, calibration of the small-scale parameters of the channel model and calibration of a baseline system configuration. The first two steps involve mainly the calibration of the channel model, that is, a technology-agnostic building block, while the last step is focused on the calibration of the MAC layer and link abstraction model that are technology dependent. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 39 of 114

40 CDF (%) CDF (%) Channel Model Calibration In the calibration of the large-scale parameters of the channel model, all the multipath effects are neglected. Simulations are conducted to obtain for each user a path gain and a wideband SINR value. The path gain is defined as the average signal gain between a user and its serving BS. It includes distance attenuation, shadowing and antenna gains. The wideband SINR is the ratio of the average power received from the serving cell and the average interference power received from other cells plus noise. Sometimes this measure is called geometry factor since it presents a great dependency with the position of the user in relation to the position of the BSs. Then, the calibration of this measure ensures not only the calibration of the channel model but also the calibration of the network layout. In addition, it involves the calibration of the physical layer considered in the simulation platform functional description, since the SINR is calculated in this layer. In addition to the evaluation principles and assumptions in [1] the assumptions shown in next table have been considered. Cell selection Feeder loss BS antenna tilt 1 db of handover margin 2 db InH UMi UMa RMa 0º 12º 12º 6º Table 21 Additional simulation assumptions Figure 12 shows the cumulative density function (CDF) of the path gain (left) and wideband SINR (right) obtained from a set of simulations conducted with the LTE-Advanced simulation platform. It has been shown the CDF for each one of the test scenarios considered in IMT-Advanced evaluations. Comparison of the presented results with these obtained in the WINNER+ project [20] and these obtained by the 3GPP [21] proves the calibration of the presented simulator InH UMi UMa RMa Path gain (db) 40 InH UMi 20 UMa RMa Wideband SINR (db) Figure 17 Distribution of path gain (left) and distribution of wideband SINR (right) in the channel model large-scale parameters calibration step In the calibration of the small-scale parameters of the channel model, the set of characteristics whose distributions are investigated include the delay spread and the departure and arrival angular spread at the BS and MT, respectively. The root mean square delay spread (DS) and circular angular spread at the BS (angle of departure, AoD) and MT (angle of arrival, AoA) are calculated for a large number of radio links. Mathematical definitions of these spread measures are included in [20]. The calibration is performed separately for Line of Sight (LoS), Non Line of Sight (NLoS), and Outdoor-to- Indoor (OtoI) propagation conditions. For simplicity, this calibration step assumes omnidirectional antennas at both the BS and the user. Delay spread distributions for each test scenario in LoS and NLoS are shown in Figure 13, while in Figure 14 and Figure 15 the AoA spread and AoD spread are COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 40 of 114

41 CDF (%) CDF (%) CDF (%) CDF (%) CDF (%) CDF (%) shown. The distributions of the small scale parameters have been compared with the results of other partners in the framework of the WINNER+ project [20], proving the correct implementation of the IMT-Advanced channel model in the LTE-Advanced simulation platform Delay Spread ( s) InH UMi UMa RMa Delay Spread ( s) Figure 18 Distribution of delay spread for LoS (left) and NLoS (right) in the channel model small-scale parameters calibration step InH UMi UMa RMa InH UMi 20 UMa RMa AoA Spread (degrees) 40 InH UMi 20 UMa RMa AoA Spread (degrees) Figure 19 Distribution of angle of arrival spread for LoS (left) and NLoS (right) in the channel model small-scale parameters calibration step InH UMi 20 UMa RMa AoD Spread (degrees) Figure 20 Distribution of angle of departure spread for LoS (left) and NLoS (right) in the channel model small-scale parameters calibration step Baseline Configuration Calibration 40 InH UMi 20 UMa RMa AoD Spread (degrees) In a third stage, spectral efficiencies, user throughput distributions and SINR distributions have been obtained and compared using a basic LTE configuration. In this configuration, baseline assumptions are made for non-standardized algorithms. For example, the chosen downlink scheduler is the Round Robin algorithm with full bandwidth allocation, that is, the whole set of resources is allocated to one of the users served by a cell in each transmission time. The DL transmission scheme is SIMO with one COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 41 of 114

42 CDF (%) CDF (%) antenna at the transmitter side and two antennas at the receiver side. The antennas are vertically polarized with 0.5 wavelength separation at UE. In order to get a gain from diversity, MRC is used at the receiver. Link adaptation is achieved through a wideband CQI sent with a 5ms periodicity and without measurement errors. Channel estimation is also ideal. In this calibration stage, the focus of the calibration is for the first time on the MAC layer and link abstraction model. Results of this stage are presented in terms of three performance indicators. First, cell spectral efficiency is calculated as the total amount of bits correctly transmitted by the BS per unit of time and frequency. Second, the cell-edge user spectral efficiency is the spectral efficiency met by at least the 95% of the simulated MTs. The number of active users in the scenario under the test heavily affects both performance indicators. A user density of 10 users per cell has been considered in the simulations. The third performance indicator is the post antenna combination SINR, that is, the SINR obtained after the MRC receiver and before the decoder. A unique SINR value is obtained through linear averaging over time and frequency for each user. Spectral efficiencies are presented in Table 22 while SINR and user spectral efficiency distributions are shown in Figure 16. Again, results obtained with the LTE-Advanced simulation platform are consistent with those obtained in the WINNER+ project [20] and in the 3GPP [21]. Scenario Metric Evaluator InH UMi UMa RMa Cell spectral efficiency (b/s/hz) Cell-edge user spectral efficiency (b/s/hz) SN4G GPP SN4G GPP Table 22 Cell and cell-edge user spectral efficiencies SINR (db) Figure 21 Distribution of SINR after antenna combination (left) and distribution of user spectral efficiency (right) 2.15 SN4G API variables InH UMi UMa RMa 40 InH UMi 20 UMa RMa User Spectral Efficiency (b/s/hz) There are many variables that can be set to control the simulation. These are covered in more detail in Appendix 5. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 42 of 114

43 3 LTE SIM simulator 3.1 Generic simulation platform Although SN4 will be used as a main COMMUNE simulator, during the simulation environment design phase TP has noticed that there will be necessity to use also another, much simpler simulator that will significantly speed up the development of the execution environment and the cognitive algorithms for the Energy Saving and Self-Optimization scenarios. For this purpose, TP has decided to use, at the first stage of the development, the LTE-Sim simulator, described with details in chapter Error! No se encuentra el origen de la referencia., which has been tailored to meet requirements specified in the D5.1 document. It s simplicity and ease of modifications will help us to speed up the development and to go faster into the COMMUNE concepts validation stage which will be performed with SN4G usage. It is possible that at the final stage of the COMMUNE project TP will have available a femtocell testbed. In consequence, we have decided to design simulation and testing environment in such a way, that will help us to change a simulator or to switch to the testbed usage without significant modifications in the execution environment specified in the WP3 as well as in the cognitive algorithms for the Energy Saving and Self-Optimization scenarios. To follow these postulates, TP has decided to develop the simulation environment presented in the Figure 22. x N N- number of nodes Logic execution layer Generic MON and CON interface Simulator and testbed interaction layer MON CON MON CON MON CON MON CON Drivers/adapters layer SN4 Simulator LTE-Sim Simulator Orange Femtocell Testbed NS-3 LENA Simulator Simulators and testbeds layer Used solution Planned to use solution (not guaranted) Figure 22 Simulation environment used by TP COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 43 of 114

44 The presented simulation environment consist of following elements: 1. Logic Execution Layer, which is the GARSON OSGi/JADE framework (described in D3.1), acts as the execution environment where GARSON and, in consequence, the COMMUNE logic of nodes will be executed. For each simulated node there is one instance of the OSGi/JADE framework. The number of nodes exceeds the number of all managed nodes (i.e. all simulated enodebs), because there are also some GARSON specific nodes like TLM or IDMLM. 2. It is possible to run many OSGi/JADE frameworks on the same machine. All the frameworks (nodes) are connected to the LAN network and are accessible by the IP address (assigned by the DHCP server) and nodes that act a special role in the system (like TLM) are accessible over DNS. 3. The Generic MON (monitoring) and CON (configuration) Interface is broker (an ACT interaction layer) that provides communication between the OSGi/JADE framework and a simulator or a testbed. The interface (used methods and protocols) is the same for all used simulators and/or testbeds but its implementation is different for each of them. Thanks to such architecture, no matter which simulator will be used, the implementation of bundles inside the OSGi/JADE framework will be the same and we will be able to use LTE-Sim at the first stage, SN4G later and femtocell testbed at the end. 4. The Generic MON and CON Interface has been developed in C++ and one of its main components is a service that serves monitoring data for the OSGi/JADE frameworks (this functionality is being used by the GARSON AMON plane) and is responsible also for the interpretation of configuration commands from the same framework (the GARSON ACT plane activity). 5. In case of simulators employment it is planned to use one simulator for whole simulation and to connect it over the generic interface with as many OSGi/JADE framework instances as network nodes created during the simulation in a simulator. 6. The next visible layer in the Figure 22 is the drivers/adapters layer. It contains drivers or rather adapters that are implementation of the simulator s specific functions of the Generic MON and CON Interface. For each simulator or testbed another set of drivers (different for MON and CON) should be created. The intention is to put simulator independent logic into the Generic MON and CON Interface code and the simulator specific logic into the drivers. 7. The last layer are simulators and testbeds. As mentioned before, TP is going to use LTE-Sim in the first stage when the GARSON OSGi/JADE framework and cognitive algorithms will be in the development phase and when they will be ready then SN4G simulator will be used for final validation of the COMMUNE concepts. 8. It s worth to mention that presented style of communication between the OSGi/JADE framework and the simulation or testbed environment has been developed for our internal usage and it is possible that another solution can be used. However, with the usage of some different approach, there will be a need of providing of changes in the AMON and ACT bundles, which are responsible for the communication with physical managed nodes. 3.2 Main simulator features According to the specified description of LTE-Sim [22], LTE Sim is a system simulator where analytical approach for LTE radio environment emulation is used. The simulator has been written in C++ and its main feature is an event-based way of simulations execution. LTE-Sim features cover the most important aspects of LTE networks like: LTE radio interface (E-UTRAN) in multi-cell environment with interferences and frequency reuse mechanism multi-user environment with user mobility and handover procedures COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 44 of 114

45 flow and Qos management including several types of flows e.g. VoIP, Video, CBR. Four types of network nodes are present in the simulator: user equipment (UE), evolved Node B (enb) and Home evolved Node B (HeNB). There is also a stub of Mobility Management Entity/Gateway (MME/GW), however its functionality is residual and in consequence Evolved Packet System (EPS) has not been sufficiently modelled. LTE-Sim uses an analytical approach for PHY layer modelling. For all network devices, an instance of the PHY class has been defined and it is attached to a given channel in order to accomplish several functionalities: SINR (Signal to Interference and Noise Ratio) estimation The selection of a proper MCS before packets transmission The access to the channel, in order to allow transmission and reception of packets. LTE-Sim has several built-in simulation scenarios (i.e. urban micro-cell, suburban macro-cell, urban macrocell and rural macro-cell) and gives easy environment for new scenarios development. The channel model in LTE-Sim includes: the path loss, the penetration loss, the shadowing and the effect of fast fading due to the signal multipath. The general simulator architecture is based on the following components (see Error! No se encuentra el origen de la referencia.): The Simulator is responsible for scenario interpretation and execution and events management The NetworkManager is performing all network operations like handovers or nodes management The FlowsManager user s applications management The FrameManager LTE frame management including support for duplex mode and bandwidth change or frame information access The ChannelRealization there are some variant of ChannelRealization which are modelling mentioned analytical models of radio channel, e.g. for microcell areas or femtocell urban areas. The BandwidthManager is responsible for storage of physical information like: frequency carrier, available bandwidth, list of available RBs for downlink and uplink, frequency reuse parameters, etc. The simulator implements most important user-plane and control-plane LTE protocol stacks including RRC, PDCP, and MAC protocols. These are available in each node as entities located in a protocolstack container: The RLC Entity has been created for each dedicated radio bearer. It models the UM, TM and AM transmission modes of the RLC layer. It implements also the segmentation and the concatenation of service data units. The RRC Entity manages downlink and uplink dedicated radio bearers for a given device. The PDCP Entity provides the header compression of packets coming from the upper layer that will be enqueued into a proper MAC queue. The MAC Entity is an interface between the device and the PHY layer which additionally contains the AMC module. An enb specific MAC Entity adds further functionalities, such as uplink and downlink packet schedulers. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 45 of 114

46 Figure 23 Internal structure of LTE-Sim in class diagram [22] Several traffic generators (types of applications) have been implemented e.g. VoIP, Video, CBR, BE or Web traffic. The most important scheduling strategies have been also implemented: Proportional Fair Modified Largest Weighted Delay First COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 46 of 114

47 Exponential Proportional Fair Frame Level Scheduler. LTE-Sim supports the EPS bearers that provide QoS differentiation. In the simulator both guaranteed bit rate (GBR) and non-guaranteed bit rate (non-gbr) bearers are available. The default bearer is a non-gbr; a dedicated bearer can be GBR or non-gbr - now only dedicated radio bearers are available. For each type of flow and application different QoS parameters can be used. QoS parameters for particular applications are configured in the definition of simulation s scenario. Additionally LTE-Sim supports also other important functionalities like AMC scheme and Channel Quality Indicator (CQI) feedback (both periodical and aperiodical CQI reporting and both full band and wide band reporting modes). Moreover, enbs and UEs are aware of the LTE cell they belong to. LTE-Sim provides a support for radio resource allocation in a time-frequency domain and the minimal allocation block available for one flow is one RB, according to the LTE specification. The number of available RB depends on the selected bandwidth of the system, what is managed by the frame manager. Inter-cell handover procedure implementation provides user s mobility. Two types of handovers are present: power-based handover and position based handovers. Unfortunately the first one is not considering hysteresis and offset thresholds. Many types of mobility models are supported: Random Direction, Random Walk, Random Waypoint, Manhattan and Constant Position. Unfortunately, simulator has also many missing functionalities. There is no implementation of HARQ mechanism and what is even more important it is not using real 3GPP signalling messages and communication between enodeb is uninterrupted. In consequence all resource blocks in frame can be used for traffic (there is no burst management) - there are no signalling, shared or broadcast bearers. Also, there is no implementation of admission control mechanism, so all connections are accepted and it is easy to cause cell congestion problem. Moreover, uplink traffic is also very simplified. There are also simplifications in the coverage area modelling, because there are no sectorized cells and, as a consequence, only omni-directional antenna pattern is present. Simulator has also very limited set of methods for topology modelling. There is no functionality to read topology file, but it s possible to add from code simple streets or buildings. LTE-Sim does not have GUI environment and all simulation results are written to the standard output or to the files, which makes analysis of the results difficult. Also the simulator does not support multithreading, however it is possible to run many instances of the simulator in the same time. Summarizing, LTE-Sim is a simple system level simulator. It is performance effective but it has also limited functionality. In consequence, its adaptation for energy saving scenario simulation requirements will be necessary but will be done as simple as possible having in mind that it will be used as a helpful tool for GARSON OSGi/JADE execution environment development as well as for algorithms design and development. In later stage the SN4 simulator will substitute it and maybe by the LTE femtocell testbed provided by TP, though that is however not guaranteed and will be known only at the final stage of the project. 3.3 Simulator modifications Accordingly to the requirements specified in D5.1 (chapter 6 and 6.3.2) and after analysis of LTE-Sim capabilities, following list of changes that will be developed in LTE-Sim has been prepared: There is a lack of sectorized antennas in LTE-Sim and antenna patterns only omni-antennas are supported, which makes it impossible to employ antenna tilt parameter into the algorithm logic. However, it has been decided that such functionality will not be deployed COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 47 of 114

48 into LTE-Sim because it will cause too many changes in the simulator and the antenna tilt parameter will be introduced into the algorithm when simulations will be switched to the SN4G simulator. The position of enodebs in LTE-Sim is always set in a style of regular grid in all simulation scenarios that are available in LTE-Sim. In consequence, there is a need to prepare another simulation scenario (which will be based on multi-cell simulation scenario) with position of enodebs being manually set in style suitable for Energy Saving simulations (areas with offices with high density of enodebs and residential areas with low density of enodebs). LTE-Sim supports simple topology configuration which can be set manually directly in the source code of scenario, however it s too simplified and very difficult to use in case of urban area topology simulation. Implementation of mechanism that will use topology files is difficult and time consuming and will not be provided in LTE-Sim. Simulations with topology utilization will be performed with SN4G usage. LTE-Sim provides different types of mobility models but none of them gives possibility to manually select position where user should be in particular time and what will be the path that the user will follow. Moreover, Energy Saving operations in real system are being performed in very long time scale (hours, days or even months) what is impossible to simulate in any simulator. To cope with it, simulations will be performed in a style in which position of users will be constantly changing, what will be far away form nomadic style of users mobility (migration between office areas and residential areas) which is typical case of energy saving appliance. Although a time span in which users will not be moving will be removed, it will have no impact on simulation results because we will provide mapping of simulation time to real time as well as mapping of the time duration spent in one place in simulator s timescale to the time duration observed in a real timescale Generic interface implementation (a) Event registration mechanism As it will be explained later on in section 3.3.2(a), TP provides in LTE-Sim a mechanism, which is generating Events carrying values of some network monitoring and configuration parameters. Therefore, there is also a need to implement another mechanism to register event s data into the generic interface s internal storage (see next section). This mechanism is implemented as a set of methods called RegisterNetworkEvent (owned by MeasurementsManager class), which extract the event occurrence time, network element (object) ID and the parameter s value of thrown event. These methods are saving it into a part of memory associated to its generator network element. This allows to concentrate all parameters that belong to the certain network object and to make them available in one place. This technique increases significantly the speed of the monitoring process of GARSON approach at the simulation stage. (b) Monitoring and configuration data storage As mentioned in previous section, our approach is based on a proactive behaviour of simulator s objects. This means that instead of reading periodically a parameter directly from the network s objects, when the parameter changes the value at some time, the object owner of this parameter throws an Event and then the MeasurementsManager class captures it and send it to a dedicated memory to this object. Storage system in our simulator can be done as an implementation of a set of hash tables (one per parameter) grouped by network object. However, other types of grouping the data will be considered. For example, there can be one table per pair <<parameternetwork_object>>, or rather one bigger table per network object containing all parameters and its values. This is a matter of memory optimization considering access efficiency versus memory space. It is important to mention that data will not be permanently kept along the simulation, i.e. after COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 48 of 114

49 some row is being read, at the same time it is removed from the table. However at the beginning of each simulation all memory is cleaned. (c) Service for interaction with JADE/OSGi framework In order to provide remote communication between OSGi/JADE framework of each management node and physical node emulated in LTE-Sim, simulator has been enriched with a set of logical servers (each for one emulated enodeb). Each server is responsible for providing of monitoring (MON), configuration (CON) and also information data of enodeb to which is attached. As mentioned before, servers are a part of generic interface and they can be used also in different simulator. Each server visible on Figure 24 is operating as a separated thread on different TCP port and is waiting for connection with one particular management node (registration process must be performed). The communication between the server and the framework is handled with the usage of a dedicated BSON (Binary JavaScript Object Notation) based protocol - GIBSON. This protocol has been designed for Generic Interface usage only. OSGi/JADE Management Node LTE-Sim: IP enb (a) - Server: port 1 OSGi/JADE Management Node enb (b) - Server: port 2 enb (c) - Server: port 3 OSGi/JADE Management Node GIBSON protocol enb (z) - Server: port n MON CON Figure 24 Server based communication between OSGi/JADE and LTE-Sim GIBSON protocol contains a set of messages following the structure showed in Figure 25: MESSAGE TYPE type of the GIBSON message TIMESTAMP time of sending of the message used for synchronization purpose TRANSACTION ID enables merging of a request with a response MESSAGE BODY content of the message dependent on the message type MESSAGE TYPE MESSAGE HEADER TIMESTAMP TRANSACTION ID MESSAGE BODY Figure 25 GIBSON protocol message structure Following types of messages are present: COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 49 of 114

50 REG_REQ and REG_RESP messages are used to register management node with managed node. Management node is receiving IP address and port number of managed node server from the AMDM as well as a special token known only by this managed node and AMDM. The management node is sending REG_REQ with the token inside to the managed node and if the token is the same as the token possessed by the managed node, then REG_RESP OK is sent. UNREG_REQ and UNREG_RESP is similar to the REQ_REQ and REQ_RESP but the purpose is to unregister from the managed node. MON_DATA_REQ and MON_DATA_RESP This type of message is used to retrieve monitoring data from the managed node by the management node. After receiving such messages server, in response, is sending back all values of monitoring parameter which has been stored by the simulator from the last time when this procedure has been also performed. A response can contain one value or a set of values of specified parameter. CON_DATA_REQ and CON_DATA_RESP The purpose of using this message is to set or get value of specific configuration parameter of the managed node. For instance, this type of message can be used to change value Tx power parameter. NODE_STATUS This message is send by the managed node to the management node in order to inform it about some important changes that have occurred, which can have influence on the behaviour of management process like an alarm about cell congestion or refused connection caused by the admission control mechanism. All above mentioned parameters will be used by the AMON or ACT bundles implemented in the JADE/OSGi framework. The structure of each message will be described later on in one of annexes to the D5.2 document,. Moreover structure of these messages matter only in case of simulations performed for COMMUNE and it will have an influence only on a part of ACT and AMON bundles GIBSON is neither a part of AMON and ACT planes design nor a part of COMMUNE management system LTE-Sim specific changes implementation of MON and CON interface drivers (a) Implementation of the monitoring parameters In LTE-Sim, some parameters, that are necessary for the monitoring process of the ES and Self- Optimization scenarios, have to be calculated from other ones or they even do not exist. As mentioned before, part of the monitoring in our approach has been realized as a mechanism which is launching parameter specific Events associated with the network objects, every time the value of some parameter is changing. Thus, when a network object (i.e. enodeb, cell, etc.) registers some change (e.g. new user in certain cell) that is related to some of its monitoring parameters, it automatically creates and throws a new Event associated to it containing the parameter s new value. Then MeasurementsManager, acting as a kind of middleware, catches it, takes its parameter s value and stores it in the simulator s interface database. In Figure 26 is shown a usage example of this process for the Number of Users parameter. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 50 of 114

51 Registered new user enodeb_1 enodeb_2 enodeb_1 Register Event (...) MEAS_EVT_CELL_RRC_DL_SCHEDULER_NU Obj. ID Time Evt ID Size Event Data MeasurementManager Param2: Param1 enodeb_1 Param1: enodeb_1 EventData Value Time Time Time Write (value, time,...) Data Storage System Figure 26 LTE-Sim Monitoring: Event mechanism. Therefore, this method makes almost all monitoring parameters accessible at one place just by reading data tables. The Table 23 contains a list of parameters and events that are currently available in LTE-Sim after our changes: Name DL/UL PRB usage Number of active UEs RRC-IDLE Users Radio Link Failure (RLF) Blocked / dropped calls ratio UL inter-cell interference Throughput rate Power consumption Handover Ping-Pong Handover failure Handover attempt Handover success Connection accepted Type Parameter Parameter / EVENT Parameter Parameter / EVENT Parameter Parameter Parameter Parameter / EVENT EVENT EVENT EVENT EVENT EVENT Table 23 LTE-Sim enhanced list of available monitoring parameters COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 51 of 114

52 (b) Implementation of the configuration parameters In order to apply changes into the on-going simulated network in LTE-Sim, the CON driver at the Drivers/Adapters Layer showed in Figure 22 has been also implemented. In our case, configuration parameters are spread along many classes of LTE-Sim. Therefore, the main task of this adapter is to create a level of abstraction between the logic execution layer (see Figure 22) and the simulator. This has been achieved by creating a set of functions called (Set Get)ParameterValue which by giving the configuration parameter identifier, the ID of the object holding this parameter and its new value, any parameter from the following list can be changed or retrieved: Tx Power Physical Cell identifier Base Station type HO Hysteresis HO Cell Offset HO Time To Trigger (TTT) Admission Control Load Threshold Power OFF/ON (c) New type of handover Originally LTE-Sim implements two types of handovers. Position based handover, where only position of the user is taken into account, and power based handover which is considering only SINR of particular cells received by the user. In order to make handovers mechanism more realistic new handover algorithm has been implemented (based on the power based algorithm available in LTE- Sim) according to the following inequality: where: Mn SINR measurement result of the neighbouring cell in db Ms SINR measurement result of the serving cell in db Ocn cell specific offset of the neighbouring cell Ocs cell specific offset of the serving cell Off offset value in db which should be fulfilled in order to perform handover Hys power offset which delays time of handover Additionally also TTT (time to trigger in ms) parameter has been taken into account which delays the handover itself the Off value must be exceeded uninterruptedly over the time expressed by the TTT parameter. Thanks to this changes it is possible to optimize handover s parameters for each cell separately, which is useful in Energy Saving or Self-Optimization scenarios. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 52 of 114

53 (d) Simple admission control mechanism LTE-Sim has no built-in admission control mechanism. Thus all new users under the target cell or new connections under the serving cell are accepted even if there are no resources to handle the new traffic generated by them. Such drawback makes unrealistic simulations when the network coverage and capacity are being optimized; that is the case for Energy Saving and Self-Optimization scenarios. To cope with that, we have decided to add to the simulator simple AC mechanism. The simulator has been changed in two places: NetworkManager::HandoverProcedure() in order to cancel the handover if there are no resources under target cell Application::Start() and RrcEntity::AddRadioBearer() in order to prevent creation of new connections, when there are no RB available to serve them. Admission control mechanism has been implemented as simple as possible because is not an end itself. For both cases cell resource blocks utilization is computed (the value is measured every one frame and is aggregated over specified number of frames it is configurable) and If it is greater than specified threshold (its value can be configured) then new user or connection is not accepted. (e) Dedicated mobility model We had to develop new mobility model in order to simulate the Energy Saving scenario. In this model, instead of a random generation of the speed and position of the user, that information is read from the data file. This data file contains information about user position and speed in particular simulation time data for all users are present in this file. Each record contains additionally mapping of simulation time to the real time, which is used as additional monitoring parameter. Such mapping is needed because real scale time is necessary. (f) Power consumption model Unfortunately in LTE-Sim lacks power consumption model. Therefore, in order to realize the Energy Savings scenario described in deliverable D2.1 a simple energy consumption model has been added. This new model provided in LTE-Sim can be summarized with the following three equations together with Table 24 [23]: Model Component Static/Dynamic Symbol Average Power Consumption ENB Base Band Static 200W RRU (Radio Remote Unit) Dynamic 100W Cooling (CSI) Static 2000W Backhaul (CSI) Static 200W Lighting (CSI) Static 50W COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 53 of 114

54 Monitoring (CSI) Static 50W Output Power per Carrier Static 20W Number of Sectors Static 1 PA Efficiency Factor Static 20% Table 24 Components power consumption As it is shown in Table 24, CSI (Common Site Infrastructure) and BBU (Baseband Unit) power consumption remains constant, being the RRU (Radio Remote Unit) the unique part of the site with variable power consumption, which in fact is proportional to the output power per carrier (P Carrier ). However, in LTE-Sim there is only one carrier per node and so far only download communication (enodeb to user) is available, hence only three possible power consumption sates are considered: Transmitting, IDLE and Power OFF. So the variability of total site consumption depends only of the current energy state of the node. LTE-Sim enodeb transmits only when it has some Bearer attached, being in that moment in TRX state. Oppositely, when the node does not contain Bearers the site will turn into IDLE state (i.e. not transmitting). Finally, the last state belongs to the situation when the enodeb is simply switched off. Thus, from the implementation point of view, the model has been implemented inside two LTE-Sim classes: rrc-entity and ENodeB. Concluding, the implemented model looks like in Table 25: Power State TRX IDLE OFF Total Power Consumption P site = P CSI + P BBU + P RRU P site = P CSI + P BBU P site = 0 W Table 25 Implemented power consumption model COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 54 of 114

55 4 Network Simulator-3 Network Simulator-3 (NS-3) is an open source network simulator for general network systems. The LTE module of NS-3 is particularly interesting for COMMUNE project, and will be used as one of the simulator tools within the project. This chapter is dedicated to NS-3, and its role in COMMUNE project. Firstly, a brief introduction to NS-3 will be covered in the first section. Then we will describe how NS-3 will be utilised in a COMMUNE use case. The requirements of the use case will be then compared with the current NS-3 capabilities that we have identified. We have also identified several missing features, thus the following section will elaborate on our own modification to NS-3. We finally close the chapter by a brief summary. 4.1 Overview of NS-3 Network simulator 3 (NS-3) is a network simulator for Internet systems. It allows researchers to study Internet protocols and large-scale systems in a controlled environment. It is continuation of its predecessor NS-2, although not backwards-compatible with it but a new independent simulator. NS-3 is targeted primarily for research and educational use and is free software, licensed under the GNU GPLv2 license, and is publicly available for research, development, and use. The goal of the NS-3 project is to develop a preferred, open simulation environment for networking research: it should be aligned with the simulation needs of modern networking research and should encourage community contribution, peer review, and validation of the software. NS-3 is a discrete-event network simulator in which the simulation core and models are implemented in C++. It is built as a library which may be statically or dynamically linked to a C++ main program that defines the simulation topology and starts the simulator. NS-3 also exports nearly its entire API to Python, allowing Python programs to import an ns3 module in much the same way as the NS-3 library is linked by executable files in C++. More detailed information about the general software architecture can be found in the NS-3 manual [27] Available Modules NS-3 responds to trends in how Internet research is being conducted, which are: Extensible software core Attention to realism Software integration Support for virtualization and testbeds Flexible tracing and statistics Attribute system New models NS-3 is organized as several modules. Modules may contain network protocols, devices, applications, simulation utilities, integration with other supporting software, and so on. Each module is built as a separate software library, which can be linked to by the simulation script that wants to use them. Currently available modules in NS-3 are depicted in Figure 27. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 55 of 114

56 Figure 27 Available NS-3 modules LTE Module The most important NS-3 module for the COMMUNE project is obviously the LTE module. The common simulation model using the LTE module is depicted in Figure 28. There are two main components: The LTE Model. This model includes the LTE Radio Protocol stack (RRC, PDCP, RLC, MAC, and PHY). These entities reside entirely within the UE and the enodeb nodes. The EPC Model. This model includes core network interfaces, protocols and entities. These entities and protocols reside within the SGW, PGW and MME nodes, and partially within the enodeb nodes. The following Section will describe more on this model. The LTE model provides a basic implementation of LTE devices, including propagation models and PHY and MAC layers. It has been designed to support the evaluation of the following aspects of LTE systems: Radio Resource Management (RRM) QoS-aware packet scheduling Inter-cell interference coordination Dynamic spectrum access The radio access network (RAN) of the model operates with Resource Block (RB) granularity and this unit is used for resource allocation with a resolution of 1 Transmission Time Interval (TTI). This kind of accuracy enables detailed modelling of packet scheduling and inter-cell interference. Different carrier frequencies and system bandwidths can be configured to different cells, so that dynamic spectrum licensing solutions can be studied. The model simulates the transmission of IP packets by the upper layers. With this respect, it shall be considered that the scheduling and RRM in LTE do not work with IP packets directly, but rather with COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 56 of 114

57 RLC PDUs, which are obtained by segmentation and concatenation of IP packets done by the RLC entities. Hence, these functionalities of the RLC layer should be modelled accurately. Figure 28 Overview of the LTE-EPC simulation model The most important features provided by the NS-3 LTE module are: Basic implementation of both the User Equipment (UE) and the Evolved NodeB (enodeb) devices RRC entities for both the UE and the enodeb A state-of-the-art Adaptive Modulation and Coding (AMC) scheme for the downlink The management of the data radio bearers (with their QoS parameters), the MAC queues and the RLC instances Channel Quality Indicator (CQI) management Support for both uplink and downlink packet scheduling A PHY layer model with RB-level granularity A channel model with the outdoor E-UTRAN propagation loss model EPC Model The Enhanced Packet Core (EPC) model provides means for the simulation of end-to-end IP connectivity over the LTE model. In particular, it supports for the interconnection of multiple UEs to the Internet, via a radio access network of multiple enodebs connected to a single SGW/PGW node. This network topology is depicted in Figure 28 from the previous section. The focus of the EPC model is currently on the EPC data plane. To understand the architecture of this model, we look at LTE-EPC data plane protocol stack, depicted in Figure 29, where we represent the end-to-end LTE-EPC protocol stack as it is implemented in the simulator. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 57 of 114

58 Figure 29 Overall architecture of the LTE-EPC simulation model From the figure, it is evident that the biggest simplification introduced in the EPC model for the data plane is the inclusion of the SGW and PGW functionality within a single SGW/PGW node, which removes the need for the S5 or S8 interfaces specified by 3GPP. On the other hand, for both the S1-U protocol stack and the LTE radio protocol stack all the protocol layers specified by 3GPP are present LENA Project The term LENA is also commonly used to refer to the NS-3 LTE module. LENA is an acronym of LTE- EPC Network Simulator. It is the designated name of a project by Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), who are the current principal developers of NS-3 LTE module. They maintain their own development repository and regularly merge with the main NS-3 repository. This development repository is commonly referred to as LENA development branch. LENA development branch is continuously updated with new changes and bug fixes. Despite being relatively less stable than the main NS-3 branch, LENA development branch is stocked with new LTE features which are useful for COMMUNE project. For instance, the latest major release is LENA release M5, which introduced Random Access, RRC protocol, better handover functionality, and other improvements. More detailed information regarding the LTE module can be found in NS-3 model library documentation [28] and past publications [29] [30] [31] [32]. While the documentation of the bleeding edge features of LENA can be found in LENA development repository [33] Publications on NS-3 NS-3 is a product of worldwide research and collaboration. Some of the modules began as a research project. The LTE module, for instance, was the result of Google Summer of Code 2011 [30]. Then CTTC started the LENA project based on this module [31] [32], which eventually became part of NS-3 main branch since the NS-3.14 release. Many research projects outside the core NS-3 development teams also relied on NS-3 for simulation. Some of these articles and conference papers are listed in the Publication section of NS-3 website. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 58 of 114

59 Most of them are often related to a certain module in NS-3, such as Wi-Fi, OLSR, mesh network, and so on. As for the LTE module, besides the publications written by the module developers, it is very rare to find other publications which have used the module as an LTE simulator tool. For that reason, publishing results achieved within the course of COMMUNE project, with the help of NS-3 LTE module, would bring about significant contribution to the popularisation and visibility of this tool in LTE domain. 4.2 NS-3 in Self-Healing Use Case During the project s evaluation stage, the required network performance data are to be generated by simulation. The use of simulation is an obvious choice, since a live network measurement from real network equipment is not cost efficient and not flexible enough from perspective of ease of data collection and emulation of different kinds of problematic cases. To simulate a set of enodebs and UEs in a certain topology and settings and gather the required network performance data, NS-3 LTE tool will be used [35] for the use case Self-Healing in LTE Network of COMMUNE project. One of the reasons why NS-3 is suitable as the simulator tool for this use case is the ability to simulate in RB-level granularity. But the most appealing factor of NS-3 is the fact that it is open source. It implies that the results from the simulation can be validated with good confidence, because the base source code is available for the general public to verify. The main aim of LTE network simulation is to model a specific network failure and collect network performance data which can further be used by cognitive algorithms of fault detection and recovery. An example of one instance of such performance data (or measurement) is the Reference Symbol Received Power (RSRP) perceived by UEs within a certain area. Upon analysis of these data, the cognitive self-healing algorithms will detect anomalies and issue a recommended recovery action(s). In relation to the overall COMMUNE system architecture, the cognitive self-healing algorithms are part of the anomaly detection unit. The unit fits into the GARSON architecture as an Information Processing Entity (IPE) which belongs to the AMON plane, as shown in Figure 30 below. Figure 30 Mapping of self-healing IPEs to the GARSON architecture COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 59 of 114

60 Collection of network performance data will involve both UEs and enodebs. Within the context of sleeping cell problem caused by hardware failure, the anomaly detection IPE in particular requires radio network measurements from all UEs and performance metrics from the enodebs, as mentioned in Section of [34]. The document also briefly mentioned a list of possible measurements and metrics that can be useful for the anomaly detection algorithm, especially the fault detection and diagnosis part. In a similar way, the UEs and enodebs within the NS-3 simulation must produce the same kind of measurement report. The following two short subsections will describe these reports, from UE and enodeb respectively UE Report Every UE in the network system is expected to report a set of measurements to the anomaly detection IPE. Consequentially, there will be a single report from each UE. The UE should produce and submit reports periodically, so that the anomaly detection IPE can accumulate enough dataset for the data mining algorithm. A typical measurement report from a UE in the simulation would contain the following information: Time when the signal is perceived by the UE Position of the UE at the time of reporting RSRP (both serving and several neighbouring cells) SINR The current cell ID of the serving enodeb Cell ID(-s) of neighbouring cells In addition to collection, UE may perform several averaging methods to the RSRP and SINR. Averaging reduces the amount of data that have to be transmitted to the anomaly detection IPE. For example, the SINR can be reduced from RB-specific SINR values to a single wideband SINR value using linear averaging. Another example would be to use the average of the instantaneous values received in the last T seconds. In other words, the values are averaged over a certain time window with the size T seconds, for example 1 to 5 seconds. It is important to note that the size of the time window T should be dynamically adjustable, based on the UE s moving velocity. The RSRP and SINR measurements are considered only valid within a very limited area in the environment as they are largely distance-dependent and affected by slow and fast fading effects. Therefore, a fast moving UE will be able to invalidate its measurements of RSRP and SINR more quickly than slow moving UE. Thus, a faster moving UE should be assigned a smaller T. As mentioned before, averaging methods are useful, primarily because they reduce the size of the dataset. This way the UE can save energy by sending fewer amounts of reports. The anomaly detection IPE will also have less dataset to work on, which will increase its running efficiency. But this should not reduce the effectiveness of the algorithm, as long as the averaging part is done properly so that the smaller, averaged dataset is as representative as the larger, raw dataset. Additionally, the averaging also helps to diminish the effect of drops and peaks in channel fading, in both time and frequency domain enodeb Report As for the enodeb collection part, the report can be divided into two parts: scheduling statistics and quality metrics. An example of interesting metric from the scheduling statistics would be the amount COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 60 of 114

61 of RB assigned. While for the quality metrics, regular figures such as user throughput, delays, packet drop, and packet loss rates may be useful Validity of Simulation Results The COMMUNE project regards the validity of simulation results to be a very essential quality that must be enforced. Thus, it is important that the simulation tools produce realistic data. In order to achieve this, the project has defined a set of requirements that must be fulfilled by the simulation tools. These requirements are set in Chapter 6 of [35] for each use case of the project. Particularly for the self-healing use case, NS-3 is required to provide proper simulations within the following features: Connected mode mobility (handovers) and the underlying events (A2, A3, Radio Link Failure, and so on) [36] Notion of antenna(s) and its gains at enodebs, possibly with 3D tilting and separate parameters for DL and UL Random Access Channel (RACH) model, including timers and handover failure event Demonstrative Simulation Environment NS-3 provides users with plenty of parameters and options to customize the simulation environment. One of the important tasks in the project is to combine these parameters and design a simulation environment that meets the objectives of the project and the underlying use case. In this subsection, we will describe an example NS-3 simulation environment, which is designed for demonstrative purpose. The proof of concept demonstration will be based on this example simulation. The design of the demonstrative simulation obtained the basic template from the 3GPP simulation case 1 (macro cell). The template model is described in Annex of 3GPP TR [21] and 3GPP TR [37]. 3GPP has specified this simulation case as a reference case for different system evaluations. The cellular layout is a hexagonal grid with 19 cell sites, with 3 sectors on each cell site. This is equivalent to 57 enodebs in total. Figure 31 below illustrates the layout as an NS-3 Radio Environment Map (REM). Each point in the REM plot represents a point of location in the simulation world, and its colour indicates the level of the strongest downlink SINR perceived at that particular point. Figure 31 Radio environment map of demonstrative self-healing simulation environnment COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 61 of 114

62 Key Performance Indicators (KPI) are only collected from the inner cells, as border cells would have unrealistic interference picture that would inevitably skew the collected radio measurement data. The major setup parameters of the simulation are outlined in Table 26. DEMONSTRATIVE SIMULATION SETUP PARAMETER Carrier frequency Inter-site distance Operating bandwidth UE speed Channel fading Traffic Number of UEs VALUE 2,0 GHz 500 meters 10 MHz 3 kmph Rural, no building Full buffer, downlink only per cell Table 26 Demonstrative simulation setup During the running time of the simulation, one of the cells will experience problem with physical equipment, resulting in reduced (or even zero) transmission power. Measurements from UEs and enodebs will be constantly gathered, averaged, and printed as output, according to the pre-defined requirements from Section The simulation setup is designed so that repeated execution will not change the result, hence ensuring the repeatability of the simulation. 4.3 Current NS-3 Capability In the previous section, we have described various requirements that NS-3 must comply. Such requirements come from the project in general, the self-healing use case specific demands for network measurement data, and the simulation case that will be constructed. We will now explore the current capability of NS-3 to meet those demands. A good amount of capability information is available from the LTE module documentation [33]. This section will act as a scenario-specific summary of it. As a reference note, the current NS-3 used in this section is LENA development branch. This is the latest release of LENA at the time of writing, and is constantly changing in a rapid pace RSRP and SINR As been previously mentioned, UE measurement results of RSRP and SINR are required by the anomaly detection IPE. RSRP in NS-3 is represented as a floating-point number. The value is the linear power in Watt/Hz. While the original power is represented by a vector of linear power, where each number represents the power associated with a single RB. RSRP is the linear average of this vector. SINR, on the other hand, is represented as a vector of linear power, where each of the vector elements is associated with an RB. Consequently, the vector length is fixed to the number of RBs used by the signal, which correspond to the operating bandwidth of the transmission. In the default NS-3 case, this will be 5 MHz and 25 RBs. However, in the demonstrative simulation case from Section 4.2.4, this will be 10 MHz and 50 RBs. The PHY layers of the simulator, of both enodeb and UE side, receive signals from the channel in the form of linear power. All incoming signals, including signals from other irrelevant sources (interferences) and noise, are summed together, and used to calculate SINR of the useful signal, i.e. signal from the serving enodeb. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 62 of 114

63 SINR is brought up to the upper layer for further processing. In the case of enodeb, the SINR will first be converted to CQI, and then passed to the MAC layer for scheduling and link adaptation purposes. RSRP, on the other hand, is only used in PHY level KPI function of NS-3 LTE module. This function generates simulation output as described in Section 2.5 of [33] Antenna Model NS-3 has a notion of antenna model. The model determines the radiation pattern of the transmission signal. The variation in signal strength within the radiation pattern is modelled as an antenna gain, which is expressed as a number in decibels. As also described in Chapter 3 of [28], there are 3 types of built-in antenna models, shown in Table 27, which can be selected and utilized in NS-3 simulation. The default type is the isotropic antenna model, for both enodeb and UE. This is the simplest model, where there is a perfectly uniform distribution of radiation pattern. In other words, the gain is 0 db to all direction. Besides the default isotropic model, users can also choose among two other types which command more realistic representation of an enodeb in a macro site. They are the cosine antenna model and the parabolic antenna model. In contrast with isotropic antenna, the direction where the antenna is facing now does matter. This direction is also called the azimuthal orientation ( ) of the antenna, which is the direction with the maximum gain. MODEL ANTENNA MODELS IN NS-3 GAIN Isotropic ( ) Cosine ( ) ( ) ( ) Parabolic ( ) ( ( ) ) Table 27 Antenna models in NS-3 The antenna orientation is specified by an angle on a plane parallel to ground. Hence, these antenna models are two-dimensional, i.e. the radiation pattern is flat. In this sense, the height difference of the transmitter and receiver is not considered in the gain calculation. Another limitation of the antennas in NS-3 is the lack of tilting feature UE Mobility In NS-3, enodebs and UEs can be placed in the simulation world by specifying a three-dimensional vector, consisting of x, y, and z elements. UE can be moved to another position by simply updating the value of the vector on-the-fly. To simulate a constantly moving UE, the position updates have to be performed every TTI or so. In order to simplify mobility implementation, NS-3 comes with several built-in mobility models for commonly used mobility behaviour, as described in Chapter 20 of [28]. The simplest model is the constant position model, which means the UE is static and not moving. Moving UEs can be simulated using the constant velocity model or the constant acceleration model. More advanced models are also available, for example the two-dimensional random walk model, which can be useful to simulate pedestrians. In this model, each UE starts by moving in a constant speed toward a random direction. When a certain predefined time or distance has been reached, the UE will change its direction. The model also defines a world boundary, which is a rectangular area to COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 63 of 114

64 prevent the UEs from venturing too far. UE that attempts to step out the boundary will bounce away in a reflexive manner. Figure 32 illustrates an example of UE movement patterns with this model. There are 10 UEs in this plot, starting at the same point, walking for 2 minutes at a constant speed of 3 kmph, and changing direction every 25 meters. Figure 32 An example of UE movement trace using the two-dimensional random walk mobility model As noted previously, the more realistic antenna models in NS-3 are two-dimensional. This fact makes the z element of node position insignificant Random Access Random Access (RA) is one of the newest features in NS-3 LTE module. Several message exchanges are involved in this feature. The first control message is the Master Information Block (MIB), which is a broadcast message from enodeb to all UEs in the channel. This message is modelled as a control message which is sent in the beginning of every frame, i.e. every 10 TTI. MIB message travels ideally, i.e. no delay and no loss. The second control message is the System Information Block Type 2 (SIB2), which is also a broadcast message. In contrast with MIB, this message is transmitted over RRC protocol. Depending on the selected RRC protocol model, this message can be transmitted ideally (the default) or realistically using packets. The message is transmitted every longer period of 80 TTI, and contains information regarding the RA channel (RACH). Within a short moment after a UE has been created in the simulation, it will receive both MIB and SIB2. After this, the UE will initiate a contention-based RA. This will invoke further message COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 64 of 114

65 exchanges. The first message is the RA preamble, which is modelled as an ideal control message. There is a slight possibility of error in RA preamble transmission, which is when the preamble ID conflicts with another preamble ID of another UE, or so called preamble collision. The second message is the reply to RA preamble, the RA response (RAR). Similarly, this message is modelled as a control message. Further description of this process is available in Section of [33]. After a successful RA, UE and enodeb will continue exchanging messages via RRC protocol for connection configuration purpose. RRC protocol is covered in more details in Section of [33]. One major limitation in NS-3 is that initial cell selection is not yet implemented. As far as cell selection is not implemented, UE association to a particular enodeb must be manually preconfigured before the simulation begins. Only after that then the UE will be able to receive MIB and SIB2, and eventually performing the rest of the RA procedures. Section has more details on this matter. Besides the contention-based RA, NS-3 also supports non-contention-based RA, which is used when initiating a handover. Another major limitation regarding RA is that Radio Link Failure (RLF) is not implemented yet. As one of the consequences, UE will stay in CONNECTED state even though the distance from the enodeb has become too large (see Section of [33]). This issue will also impact the self-healing use case, especially in the case of hardware failure, which is usually simulated by severely decreasing the transmission power of a selected enodeb, and then expecting RLF events to occur X2 Interface and Handover NS-3 supports X2 interface between enodebs. Specifically, an X2 connection is made between two enodeb RRCs. Messages are sent by invoking service access point (SAP) API, which is a commonly used model for interfacing different modular parts in the LTE module. In NS-3, each X2 connection is implemented as sockets between 2 connected point-to-point devices. Therefore, each message running through it is actually a packet with proper header and socket configuration. In relation to the self-healing use case, this interface is used for handover signalling, as described in Section of [33]. When a handover mechanism is started, the source enodeb and the target enodeb will communicate via the X2 interface using RRC protocol. Real LTE systems will automatically perform a handover based on measurement reports from UE. However, this automatic trigger is not available in NS-3. Users must explicitly pick the UE and the target enodeb, and then instruct the simulation to do a handover at a predefined simulation time. This issue will be described in more detail in Section Modifications to NS-3 After reviewing the existing capabilities of NS-3, we identify several features which are missing from NS-3, but will be required in the development of simulation for the self-healing use case. To address this issue, we incorporate some of our own features and changes to NS-3. This section will describe the missing features and the changes that we developed Propagation Loss Model NS-3 has a separate module called Propagation, which is basically a collection of classes that handles calculation of the loss of power of each signal traveling within the channel. NS-3 provides several propagation loss models that users can choose and utilise in their simulation. The commonly used factor of calculation in these models is the distance between transmitter and receiver. The more sophisticated models may also consider the frequency into the equation. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 65 of 114

66 However, this selection of models does not include the propagation loss model required by the demonstrative simulation scenario. Because of this reason, a new propagation loss model is developed using the following formula [21] [37]: R is distance in kilometres. This model will be referred to as the 3GPP Macro propagation loss model. The use of 3GPP Macro propagation loss model will ensure that simulation results are more aligned to 3GPP standard. Moreover, simulations are expected to be less time consuming Receiving Signals from Neighbouring enodebs Transmission of signals over the air channel in NS-3 is modelled as follow. When a signal enters the channel, it will undergo a series of alteration, for instance because of the distance (propagation loss model) and the channel fading. The channel has several receivers attached to it. These receivers are known as Spectrum PHY objects within NS-3. The altered signal will be passed to every receiver. In short, when a signal enters the channel, it is broadcasted to all receivers. This procedure applies to both downlink and uplink. Figure 33 Modification for collecting RSRP from neighbouring enodebs Because of the broadcast nature, the signal carries a destination identifier to target a specific receiver. For example, the downlink control message carries the cell ID of the enodeb, so that the receiving UE will be able to determine whether the signal is coming from the serving enodeb or from one of the neighbouring enodebs. When the cell ID of the UE and the signal differs, then the UE will simply consider the signal as interference and then discard it. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 66 of 114

67 As a consequence, it is not possible to create an NS-3 simulation that gather and make use of signals from other enodebs. This feature, however, is necessary in the self-healing use case for collecting measurements from neighbouring enodebs. Figure 33 depicts the design of the modification in NS-3 to implement this feature, which is indicated by blue colour. The Spectrum PHY class is modified to add a new functionality to capture all signals, regardless of the cell ID. We then introduced a modified version of NS-3 s existing Interference and SINR Chunk Processor objects, so that they can handle multiple cell ID. Measurements of overall signals are quite resource intensive. The demand for such measurement is also not as high as for other measurements, such as CQI measurement. Thus, we added a timer to regulate the overall measurements to once every 50 milliseconds. This value is configurable through NS-3 attribute system. After the signals are collected, they are submitted to the upper layer for further processing Time Window Averaging Recall from Section that averaging of UE measurement data is a useful method to reduce the size of the dataset that anomaly detection IPE must analyse. In order to benefit the most from the size reduction, the averaging must be performed at the earliest level, which is the UE itself. Time window averaging is the averaging method that will be used in the self-healing use case. The method takes the recent RSRP from the last T seconds, and then averages them to compute the result. As a side benefit, this may produce a more steady result on top of a bumpy channel fading. RSRP from different enodebs should be handled separately, so the originating enodeb can be identified from the resulting averaging report. However, NS-3 currently does not have built-in capability to perform time window averaging. Thus we designed a new class to handle the calculation, as depicted in Figure 34 below. Figure 34 Modification for time averaging and A3 evaluation The class is to be used within each UE RRC. Measurement reports from UE are periodically delivered from UE PHY into the method Push. The class will store the measurements separately based on the originating cell ID. After a T-second worth of measurements has been pushed, the average can be computed and inquired from outside. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 67 of 114

68 4.4.4 Handover Algorithm LENA release M5 came with handover feature. This feature is accompanied by X2 interface and handover signalling, as already described in Section Even though the underlying infrastructure for handover is readily available, NS-3 lacks a built-in handover algorithm for making a handover decision. Handover must be done by explicitly invoking the corresponding function in the source enodeb RRC from the simulation script. We address this issue by designing a handover algorithm based on averaged RSRP from Section and A3 event. Two variables determine the trigger condition of A3: handover hysteresis and Time-To-Trigger (TTT). Both variables are computed in by each UE every time new set of averaged RSRP are available. They are used to check the following conditions [38]: 1. RSRP from enodeb i is higher than the RSRP from the serving enodeb by a number of decibels equal to hysteresis 2. Condition 1 has constantly been maintained for at least number of seconds equal to TTT When the above two conditions are fulfilled, then enodeb i is considered as a potential target of handover. Hence, the UE triggers an A3 event. This algorithm will be implemented in UE RRC. We designed a new class for handling the evaluating of A3 conditions. This class consumes the averaged RSRP values from the time averaging class, and then verify whether the two conditions for A3 are fulfilled. This is shown in Figure 34 from the previous section. After an A3 event has been triggered, a notification message is submitted to the serving enodeb via RRC protocol, as illustrated in Figure 35. Upon receiving the message, the source enodeb will call the existing NS-3 handover function. Figure 35 Modification of transmitting handover message to the serving enodeb Figure 36 is an example of averaged RSRP traces around the moment a handover is occurring. An example of the notion of hysteresis (3 decibels) and TTT (200 milliseconds) are also shown. The time window averaging for both enodeb are reset after the handover is triggered, which explains the short disruption of data when the sliding windows have not collected enough measurements. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 68 of 114

69 Figure 36 Example RSRP traces of handover Radio Link Failure RLF is one of the possible factors to be utilised by the cognitive self-healing algorithms. For instance, the algorithm might assume that RLF is expected to occur on UEs which are attached to an enodeb with simulated hardware failure. As noted earlier in Section 4.3.4, RLF is not implemented in NS-3. We design RLF functionality in NS-3 by utilising averaged SINR of the serving enodeb. UE collects these SINR on regular basis and perform time window averaging on them. When the averaged SINR has been below a certain minimum threshold for a certain period of time, the UE triggers an RLF event. In the RLF event, the UE will seek the best enodeb according to its signal strength, and then issues a reconnect request to it. This method is similar with the cell selection mechanism, which will be described in the next subsection. The reconnection can be triggered to the same serving enodeb, which will probably result in another RLF if the enodeb has not yet recovered. The reconnection can also be triggered to another enodeb, which is more likely, in which an effect similar to handover will take place. In this sense, the handover functionality and the RLF functionality should override each other, depending on which one is triggered the first Cell Selection As described in Section 4.3.4, cell selection is still a manual procedure in NS-3. The module provides a helper function which must be called by the simulation script for each UE in the simulation in order to attach it with a specific enodeb. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 69 of 114

70 The choice of enodeb to attach to is entirely up to the users. Users might opt to use distance as the selection factor, for which NS-3 already has provided a helper function. In the case where more than one enodebs having the exact same distance, such as in a three-sector site, this function may attach the UE to a wrong enodeb. As a workaround, another helper function can adjust the enodeb position forward by a few centimetres toward the antenna direction. These methods, however, are not sufficient for the self-healing use case. For instance, when a hardware failure is simulated on a certain enodeb, then the signal strength of the enodeb will drop drastically. Some UEs will experience RLF because of this, and will attempt to reconnect to another enodeb. In this case, distance is no longer a sufficient indicator of the best enodeb. Based on this requirement, we design a cell selection mechanism, which works as follow. When a UE has not yet attached to any enodeb, it will first quietly listen to the control downlink channel for RSRP from neighbouring enodebs. Time window averaging (see Section 4.4.3) will be applied to these RSRP measurements. When enough measurements have been accumulated, the UE simply chooses the enodeb with the best average value, and issue an RRC connection request to it. 4.5 Summary In this chapter, we have made a detailed description of NS-3 functions and the role of this simulation tool in the COMMUNE project. At first we took a brief look of NS-3 in overview, especially the LTE module, which is the part of COMMUNE project s interest. We then proceeded to compare the project s requirements of a simulation tool with current NS-3 capability. NS-3 will be used as the simulation tool for the self-healing use case, thus the use-casespecific requirements are also considered. While comparing NS-3 and the requirements, we identified existing NS-3 features which are useful and also some missing features. Finally, we elaborated on the necessary modifications to NS-3. These modifications result in several new features for NS-3. The newly developed features are the 3GPP Macro propagation loss model, receiver of overall RSRP from neighbouring enodebs, time window averaging, A3-based handover algorithm, SINR-based Radio Link Failure, and RSRP-based cell selection. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 70 of 114

71 5 CONCLUSIONS This deliverable has described three simulators that are used in the COMMUNE project, SN4G from SistelNetworks, modified LTE-sim from TP, and modified NS-3 LTE from Magister Solutions. From all simulators the overall structure and the most important features were described and also the expected use cases in the COMMUNE where simulators would be utilized. The described simulators will be invaluable assets to the COMMUNE project when we are developing and testing and applying our cognitive algorithms. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 71 of 114

72 6 Appendix 6.1 SN4G API Variables This appendix describes the variables of the simulator interface COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 72 of 114

73 INPUT VALUES OF SN4G Section Parameter Values Units Comments Margins Radio Environment Scenario Cell Configuration Cell Activity [0,1] Power level in not active cells (%) [0,1,2,3,4,5,6,7,8] [0-100] Fast Fading emulation [0,1,2,3,4] Fast Fading interference Management Parameter [cells/clust size/interf] -> omni: 0=[1/1/0],1=[7/1/6], 2=[19/1/18], sect: 3=[3/1/2], 4=[21/1/20], 5=[57/1/56], indoor: 6=[2/1/1] real: (load from InputFiles/Escenario.txt) 7 -> circle sectors, 8 -> hexagonal sectors Activity in centre cell option 0 or in every cell option 1 Valid only if Cell Activity=0. Power level in not active cells Fast fading emulation mode 0:no fast fading emulated, 1:best server, 2:all cells, 3:strongest M, 4:M db from strongest Valid with interfff = 3 or 4. decimal(4,1) unsigned int(1) unsigned decimal(3,1) unsigned Cell Radius meters Total cell radius (radius for vehicular decimal(10,3) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 73 of 114

74 Radius for static users meters Radius for static users decimal(10,3) UNSIGNED Radius for pedestrian users meters Radius for pedestrian users decimal(10,3) UNSIGNED Number of Users per Cell Number of users per cell int(3) UNSIGNED Number of GPRS carriers carriers Number of GPRS carriers int(2) UNSIGNED Number of EDGE carriers carriers Number of EDGE carriers int(2) UNSIGNED Number of HSDPA carriers [0,1] carriers Number of HSDPA carriers int(1) UNSIGNED Number of WLAN carriers [0,1] carriers Number of WLAN carriers int(2) UNSIGNED Number of LTE carriers Default = 1 slots Number of LTE carriers int(2) UNSIGNED Number of GPRS timeslots slots GRPS related int(2) UNSIGNED Number of EDGE timeslots slots EDGE related int(2) UNSIGNED Number of HSDPA secondary codes Number of WLAN timeslot [0 16] codes timeslot s users) codes of SF=16 in NodeB dedicated to HSDPA int(2) UNSIGNED int(2) UNSIGNED LTE Resource Blocks [6,15,25,50,75,100] Number of RBs in LTE deployment int(3) UNSIGNED Slot Allocation 1 GERAN related unsigned NOT NULL DEFAULT '1' GPRS MultiSlot Class 2 GERAN related int(2) UNSIGNED EDGE MultiSlot Class 1 GERAN related int(2) UNSIGNED GPRS / EDGE thermal noise dbm/hz GERAN related decimal(4,1) GPRS / EDGE TX Power 30.0 dbm GERAN related decimal(3,1) UNSIGNED HSDPA thermal noise dbm/hz decimal(4,1) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 74 of 114

75 HSDPA TX Power 43.0 dbm decimal(3,1) UNSIGNED HSDPA Orthogonality Factor [0,1[ decimal(3,2) UNSIGNED Less than 1 WLAN thermal noise dbm/hz decimal(4,1) WLAN TX Power dbm decimal(3,1) UNSIGNED LTE thermal noise dbm/hz -172dBm/Hz en 10MHz -> -102dBm decimal(4,1) LTE enb Tx Power dbm LTE enodeb transmission power decimal(3,1) UNSIGNED LTE User Equipment Noise Factor db NF of UE receiver chain decimal(3,1) LTE enb Antenna Gain dbi LTE antenna gain decimal(3,1) UNSIGNED LTE Feeder Loss dbi LTE feeder losses decimal(3,1) UNSIGNED GPRS/EDGE carrier frequency MHz decimal(4,1) UNSIGNED HSDPA carrier frequency MHz decimal(4,1) UNSIGNED WLAN carrier frequency MHz decimal(4,1) UNSIGNED LTE carrier frequency MHz decimal(4,1) UNSIGNED LTE_femto_carrier_frequency MHz To be implemented in the future decimal(4,1) UNSIGNED LTE Transmission Mode [1,4,5,90,91] Transmission mode: 1 single antenna transmission 4 closed loop spatial multiplexing 5 MU-MIMO codebook based 90 SU-MIMO non codebook based int(2) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 75 of 114

76 91 MU-MIMO non codebook based Number of Tx Antennas [1,2,4] Number of enodeb antennas transmitting int(1) UNSIGNED Number of Rx Antennas [1,2,4] Number of enodeb receiving antennas int(1) UNSIGNED Vertical polarized antennas: enodeb (ds) and UE (du) [0,1,2] vert.polarized antennas with spacing (lambdas) in enodeb (ds) and UE (du) equal to: 0 ds=10,du=0.5, 1 ds=4,du=0.5, int(1) UNSIGNED 2 ds=0.5,du=0.5 Multipath Model [0,1] 0 -> Jakes model 1 -> IMT-Advanced model int(1) UNSIGNED 0 -> Modelo de Okumura-Hata int(2) UNSIGNED 1 -> Modelo de WLAN Propagation Load Loss Map Selection [0,1,2,31,32,33,34,35,4 ] 2 -> Modelo ETSI empleado en NEWCOM 3X -> Modelo de IMT-Advanced (31:InH,32:UMi,33:UMa,34:SMa,35:R Ma) 4 -> PathLossA + PathLossB*log10(dist_km) LossMaps=0 [0,1] 0 Loss obtained with PathLossModel 1 Loss obtained from maps tinyint(1) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 76 of 114

77 Base Station Height meters decimal(4,2) UNSIGNED UE Terminal Height meters decimal(3,2) UNSIGNED Minimum distance to base station Decorrelation distance for shadowing model LoS Shadowing Standard Deviation LoS2 Shadowing Standard Deviation NLoS Shadowing Standard Deviation Indoor Shadowing Standard Deviation Shadowing Intersites Correlation >0 meters meters db db db db [0,1[ db Minimum distance to base station (related to minimum losses) Valid with Load Loss Map Selection ϵ {0,1,2}. Decorrelation distance for shadowing model. Shadowing at two points separated decorrelation distance are uncorrelated. Values between steps are interpolated. Shadowing standard desviation for Line Of Sight (LoS) users Only valid with Load Loss Map Selection =3X Shadowing stdv for LoS users past a threshold distance from the base station. Only valid with Load Loss Map Selection =3X Shadowing stdv for NLoS users Only valid with Load Loss Map Selection =3X Shadowing stdv for indoor users Only valid with Load Loss Map Selection =3X Shadowing correlation between sites. decimal(5,2) UNSIGNED decimal(5,2) decimal(4,2) UNSIGNED decimal(4,2) UNSIGNED decimal(4,2) UNSIGNED decimal(4,2) UNSIGNED decimal(2,2) UNSIGNED. Always lower than 1 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 77 of 114

78 Mean Penetration Loss db Valid with Load Loss Map Selection =3X. Mean value of penetration losses. decimal(4,2) UNSIGNED Penetration Loss Standard Deviation >0.0 db Valid with Load Loss Map Selection =3X. Standard deviation value of penetration losses. decimal(4,2) UNSIGNED TrafficSource s Antenna Downtilt >0.0 degrees Elevation [0,1] Power Delay Profile [0,1,2,3,4,5,6] Electrical down tilt of transmitting antennas. 0 no elevation used 1 elevation used Valid Jakes model Power Delay Profile. 0PA (Pedestrian A) 1VA (Vehicular A) 2RA (Rural Area) 3EPA (Extended Pedestrian A) 4EVA (Extended Vehicular A) 5ETU (Extended Typical Urban) 6oneTAP decimal(4,2) UNSIGNED tinyint(1) UNSIGNED Int(2) unsigned Saturation [0,1] Valid only for WWW or traffic tinyint(1) UNSIGNED Total Saturation [0,1] Valid only for WWW or traffic tinyint(1) UNSIGNED LTE Full Buffer Model [0,1] LTE full buffer model tinyint(1) UNSIGNED WWW References Beta Decimal(4,2): -99,99 a 99,99 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 78 of 114

79 WWW References Alpha Decimal(4,2): -99,99 a 99,99 WWW Inactive Off Beta Decimal(4,2): -99,99 a 99,99 WWW Inactive Off Alpha Decimal(4,2): -99,99 a 99,99 WWW File Size Beta Decimal(4,2): -99,99 a 99,99 WWW File Size Alpha Int(1): a 9999 WWW File Size UP Beta Int(1): -9 a 9 WWW File Size UP Alpha Int(3): -999 a 999 WWW Active Off Alpha Decimal(4,3): -9,999 a 9,999 WWW Active Off Beta Decimal(10,9): -9, a 9, Inactive Off Beta Decimal(4,2): -99,99 a 99,99 Inactive Off Alpha Decimal(4,2): -99,99 a 99,99 Size 1P1 Size 1P2 Size 2P1 Size 2P2 Decimal(11,2) unsigned: 0 a ,99 Decimal(10,9) unsigned: 0 a 9,99 Decimal(9,7) unsigned: 0 a 99,99 Decimal(10,9) unsigned: 0 a 9,99 H263 Initial Beta Decimal(4,2): -99,99 a 99,99 H263 Initial Alpha Tinyint(1): 0 o 1 VoIP On % Int(1) unsigned: 0 a 9 VoIP Off % Int(1) unsigned: 0 a 9 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 79 of 114

80 Sessions VoIP Packet Interval seconds Time between packets Decimal(4,4) unsigned: 0 a 0,9999 VoIP Payload bytes Payload of the VoIP package Int(2) unsigned: 0 a 99 VoIP Max Delay Sessions Origination Mode [0,1] seconds Maximum delay allowed for a package Mode of session generation: 0Sessions start with the simulations start and last until simulation ends 1Sessions born and die during the simulation time Decimal(3,3) unsigned: 0 a 0,999 Tinyint(1) unsigned: 0 o 1 Sessions Originator [0,1] Valid with SessionsMode=1 Tinyint(1) unsigned: 0 o 1 WWW Lambda Number of WWW Pages per Session Lambda Lambda Server s Mean s Var KBytes Bytes Valid with SessionsMode=1 Valid with SessionsMode=1 and WWWLambda >0.0. Number of WWW pages in each session. Valid with SessionsMode=1 Valid with SessionsMode=1 and Lambda>0.0 Valid with SessionsMode=1 and Lambda>0.0 Valid with SessionsMode=1 and Lambda>0.0 Decimal(4,2): -99,99 a 99,99. No 0 because it is a divisor. Int(2) unsigned: 0 a 99 Decimal(4,2): -99,99 a 99,99. No 0 because it is a divisor. Decimal(4,2) Decimal(3,1) Decimal(4,1) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 80 of 114

81 H263 Lambda 0.0 Valid with SessionsMode=1 H263 Session Duration 15 seconds Valid with SessionsMode=1 and H263Lambda>0.0 Valid with SessionsMode=1 and H263Lambda>0.0 Decimal(4,2): No 0 because it is a divisor. Decimal(4,2) Decimal (3,2) ph263user_16 [ ] Proportion of each type of service Less than 1 ph263user_32 [ ] ph263user_64 [ ] ph263user_128 [ ] ph263user_256 [ ] ph263user_512 [ ] ph263user_1024 [ ] ph263user_2048 [ ] ph263user_4096 [ ] ph263user_8192 [ ] VoIP Lambda VoIP Session Duration Probability WWW users [ ] seconds Valid with SessionsMode=1 and H263Lambda>0.0 Valid with SessionsMode=1 and H263Lambda>0.0 Proportion of each type of service Valid with SessionsMode=1 Valid with SessionsMode=1 and VoIPLambda>0.0 Valid with SessionsMode=0 Proportion of users of a specific Decimal(4,2) Decimal (3,2) Less than 1 Decimal(4,2): No 0 because it is a divisor. Decimal(3,2) Decimal(4,2) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 81 of 114

82 service Sum of proportions must be 1.0 Sum of ph263users_x must be equal to ph263users. Probability users [ ] Probability H263 users [ ] ph263users_16=0.0 [ ] Valid with SessionsMode=1 and VoIPLambda>0.0 Valid with SessionsMode=0 Decimal(3,2) Decimal(3,2): Decimal (3,2) Less than 1 Proportion of users of a specific service ph263users_32=0.0 [ ] Sum of proportions must be 1.0 Decimal(3,2): ph263users_64=0.0 [ ] Decimal (3,2) ph263users_128=0.0 [ ] ph263users_256=0.0 [ ] ph263users_512=0.0 [ ] ph263users_1024=0.0 [ ] ph263users_2048=0.0 [ ] ph263users_4096=0.0 [ ] Sum of ph263users_x must be equal to ph263users. Less than 1 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 82 of 114

83 ph263users_8192=0.0 [ ] Probability VoIP users=0.0 [ ] % Mobility Model [0,1,2,3] Selects the mobility model in use: 0 trazas 1 modelo NEWCOM 2 modelo ELCHE 3 fix positions Mobility UE Initial Position Model [0,1] Wrapping Model [0,1,2] Initial Position Matching Cell Selection CEUproportion CEUdistance [0,1] Selects the mode of initial position selection: 0 uniform per cell 1 uniform per scenario Selects the wrapping mobility model 0 owncell circle 1 owncell hex 2 all scenario If activated drops the user in a random position until the nearest cell is the serving cell. Related code is removed (commented) in current version Related code is removed (commented) in current version Int(1) unsigned Int(1) unsigned Tinyint(1) unsigned: 0 o 1 Angle variance related to degrees Angle variance related to directivity Decimal(4,1) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 83 of 114

84 directivity of mobility models ^2 of mobility models Static speed Pedestrian speed Vehicular speed Absolute Probability of static users Absolute Probability of pedestrian users Absolute Probability of vehicular users [ ] [ ] [ ] km/h km/h km/h Speed (or mean speed) of static users. Exact meaning depends on the mobility model. Speed (or mean speed) of pedestrian users. Exact meaning depends on the mobility model. Speed (or mean speed) of vehicular users. Exact meaning depends on the mobility model. Parameter valid with SessionsMode=0. Proportion of each type of user mobility. The sum must be 1.0 Speed (or mean speed) of vehicular users. Exact meaning depends on the mobility model. Parameter valid with SessionsMode=0. Proportion of each type of user mobility. The sum must be 1.0 Relative probabilities of having each type of user mobility. X ϵ {WWW, ,H263,VoIP} If X is H263 then Y ϵ {16,32,64,128,256,512,1024,2048,40 Decimal(6,6) unsigned Decimal(3,1) unsigned Decimal(4,1) unsigned Decimal(3,1) unsigned Decimal(4,1) unsigned Decimal(3,1) unsigned Less than 1 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 84 of 114

85 96,8192 } else _Y is not present. Relative probability for static users with traffic X Relative probability for pedestrian users with traffic X Relative probability for vehicular users with traffic X GPRS LA Updating [ ] [ ] [ ] Relative probabilities of having each type of user mobility. X ϵ {WWW, ,H263,VoIP} If X is H263 then Y ϵ {16,32,64,128,256,512,1024,2048,40 96,8192 } else _Y is not present. GPRS, EDGE and HSDPA related Decimal(3,2) Less than 1 LA parameters EDGE LA Updating EDGE Location Area First Updating HSDPA LA Updating HSDPA Reporting Model [0,1] RLC Block Time to check if the location area should be updated 1 RLC block = 20 ms The report is send immediately [0] or with a realistic delay [1] Int(1) unsigned. No 0 because it is a divisor. Int(1) unsigned Int(1) unsigned. No 0 because it is a divisor. Int(1) unsigned. No 0 because it is a divisor. Tinyint(1) unsigned HSDPA CQI Feedback Report Period between CQI measures Decimal(2,1) unsigned Number of HARQ processes Scheduling Period TTI Equivalence TTI and milliseconds: 1 = 2ms Int(2) unsigned Int(1) unsigned HSDPA_HAR Maximum number of Int(1) unsigned COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 85 of 114

86 Q retransmissions Options: Tinyint(1) unsigned. HSDPA HARQ Scheme [0,1] 0 Chase Combining, 1 Incremental Redundancy Discard Time Decimal(3,3) unsigned Add standard lognormal deviation [0,1] Options: 0 CQI measured 1 CQI measured + a standard lognormal deviation Tinyint(1) unsigned. 1 significa que se añade meas error Block Error Probability offset (BLEP) [0,1] Options: 0 nothing 1 Apply the BLEP offset Tinyint(1) unsigned Options: 0 Select random sample without additional process Int(1) unsigned. Value between 1 and 8. 1 Average of a period of time CQI processing mode [1,2,3,4,5,6,7,8] 2 Filter average of a period of time 3 Lowest sample of a period of time 4 Conservative filter: low samples are more relevant 5 Smart filter: recent samples are more relevant 6 LMS simple filtering COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 86 of 114

87 CQI processing WLength Interference Model [0,1,2] Number of HDSPA scheduled Users [1-16] Scheduling Algorithm [1,2,3,4] HSDPA_SCHE DULING H263DiffServ 0 7 LMS simple filtering: Exact averaging 8 Median Filter Applicable to CQI processing mode when the value is 1 to 8 Options: 0 Parcial self-interference cancellation 1 Without self-interference cancellation 2 Total self-interference cancellation Options: 0 Round Robin 1 Round Robin Best Effort 2 Max CIR 3 Proportional Fair 4 Quasi Fair Throughput Int(3) unsigned Int(1) unsigned Int(2) unsigned Int(1) unsigned: value between 1 and 4. Int(1) unsigned: H263SchedulingAlgorith 0 Int(1) unsigned BufferDependency 1 Int(1) unsigned. max_wlan_retransmissions Eg=5 CAP_Time9 Eg=0.9 WLAN_ARQ WLANmode Eg=0 WLAN related parameters Value to rethink. Could be linked to COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 87 of 114

88 ARFmode ACKmode WLAN_Max_Payload MAC_Protocol H263_Initial_Rate Best_Effort_Initial_Rate service_interval Downlink Uplink AdmissionH263 AdmissionWWW Admission SchedulingH263 SchedulingBestEffort CWmin CWmax ContentionProtocol Eg=0 Eg=0 Eg=1500 Eg=52 Eg=50 Eg=0 Eg=0.1 Eg=1 Eg=1 Eg=1 Eg=1 Eg=1 Eg=1 Eg=0 Eg=32 Eg=1024 Eg=1 simulation load per cell. Number of HARQ tx entities in enodeb Combining mode in MAC layer: 0 Chase Combining 1 Incremental Redundancy COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 88 of 114

89 numberofharqtx_entities int(3) unsigned HARQ_scheme Int(1) unsigned. LTE_MAC Number of LTE HARQ processes [1:8] Number of HARQ processes in MAC layer. Int(1) unsigned Max number of retransmissions in LTE [1 3] Maximum number of HARQ retransmissions in MAC layer Int(1) unsigned Periodicity of CQI Reports [1-1000] millisec onds Periodicity of CQI reports Int(2) unsigned Frequency granularity of CQI reports [1 100] subcarri ers Frequency granularity of CQI reports Int(3) unsigned Type of LTE CQI measurement Error [0,1] CQI measurement error 0 Without measurement error 1 With measurement error tinyint(1) UNSIGNED Outer Loop Link Adaptation (OLLA) for CQI control [0,1] Outer Loop Link Adaptation (OLLA) 0 OLLA not activated 1 OLLA activated tinyint(1) UNSIGNED BLER: LTE Aup Valid with OLLA activated Decimal(4,2) Decimal(4,2) BLER: LTE Adown Valid with LTE_CQI_controlLoop = 1 LTE CQI processing Mode [0,1,2] Options: 0 Narrowband CQI int(1) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 89 of 114

90 LTE CQI processing Window Length Dynamic Selection of transmission Rank Mode Dynamic Rank Factor [1,128] [0,1,2,3,4] Frequency Reuse Mode [0,1,2,3] Full Reuse Part 1 Wideband CQI 2 SNR to CQI Options: 0 Throughput 1 Thr threshold 2 Wideband SNR 3 Subband Thr 4 Fixed Parameter for dynamic rank selection. Valid with dynamicrankmode ϵ {1,2,4} If dynamicrankmode ϵ {1,2} is a threshold. If dynamicrankmode = 4 is the rank. Options: 0 Full Reuse 1 Reuse 3 2 Fractional Frequency Reuse (FFR) 3 Soft Frequency Reuse (SFR) Valid with frecreuse = 2. Indicates the proportion of bandwidth with full reuse. int(3) UNSIGNED Int(1) UNSIGNED. decimal(3,1). int(1) UNSIGNED. decimal(3,1) UNSIGNED. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 90 of 114

91 UEs configuration categorization CCU and CEU zones limit Radius CQI Threshold RSRP limit Wideband SNR threshold Delta Power Delta Power Per CQI Min CQI of Schedulable HARQ entity [0,1,2,3,4,5] db Options: 0 Position 1 CQI 2 RSRP 3 wsnr 4 Relative to another user 5 Pre-configured Valid only for UEs categorization configuration = 1 Valid only for UEs categorization configuration = 2 Valid only for UEs categorization configuration = 3 For SFR and FFR, difference in db between the high power band and the low power band of the fractional scheme For adjusting MCS to the modified power mask used in frequency reuse schemes. Indicates how many db correspond to one CQI. Minimum CQI of users eligible for scheduling. Recommended value is 0. int(1) UNSIGNED. decimal(5,2) UNSIGNED int(2) UNSIGNED decimal(3,1) decimal(3,1) decimal(3,1) UNSIGNED decimal(3,1) UNSIGNED int(2) UNSIGNED Max Number of Candidate Maximum number of users selected int(2) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 91 of 114

92 HARQ entities maxnbofcandidateharqentce U maxnbofcandidateharqentcc U Time domain scheduling for UEs categorization Frequency domain scheduling for UEs categorization [1,2,3] [0,1,2] Proportional Fair Metric [0,1] in the first scheduling step. Maximum number of CEU users selected in the first scheduling step. Maximum number of CCU users selected in the first scheduling step. Algorithm to select a subset of users as a first step of the whole scheduling algorithm. Also known as Time domain scheduling. Options: 1 RR (Round Robin) 2 MT (Max Throughput) 3 PF (Proportional Fair) Algorithm to allocate resources in frequency domain to the users in the scheduling. Also known as frequency domain scheduling : 0: RR (Round Robin) 1: MCQI (Maximum CQI) 2:PF (Proportional Fair) Parameter used with proportional fair algorithms. Options: 0: Classic PF (R/T), int(2) UNSIGNED int(2) UNSIGNED int(1) int(1) int(1) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 92 of 114

93 1: Modified PF (R^pfAlpha/T^pfBeta) Proportional Fair Alpha pfalpha Parameter used with proportional fair algorithms. Valid if Proportional Fair Metric=1. Modifies classic numerator of PF metric. decimal(3,1) Proportional Fair Beta parameter!0 pfbeta Parameter used with proportional fair algorithms. Valid if Proportional Fair Metric=1. Modifies classic denominator of PF metric. decimal(3,1). 0 is not allowed Parameter used with proportional fair algorithms. int(1) UNSIGNED Combo options for X: 0 NaN Frequency domain scheduling for UEs categorization Combo box that mix values X and Y 1 isd 2 i1d 3 i1nd Combo options for Y: 0 filtering 1 exact calculation Proportional Fair Factor Parameter used with proportional fair algorithms. Filter factor for rate calculation decimal(3,3) UNSIGNED Effective SINR calculation mode [0,1] Options: 0 MIESM (preferred) int(1) 1 EESM COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 93 of 114

94 RCEF db Factor used to model channel estimation error. Real SINR is decreased in this quantity. decimal(3,1) Options: int(1) UNSIGNED 0 wideband CQI Mode Configuration [0,1,2,3] 1 mean 2 maxthr 3 effectivecqi (preferred) Options: int(1) UNSIGNED OFDM Symbols per subframe devoted to control channels transmission [0,1,2,3] 0 0 OFDM symbols 1 1 OFDM symbols 2 2 OFDM symbols 3 3 OFDM symbols Options: int(1) UNSIGNED Serving Cell Selection Mode [0,1,2] 0 selected cell is the cell where the user is located. 1 highest SINR with 1dB handover margin. 2 lowest coupling loss with 1dB handover margin. Mode to allocate power between RBs. int(1) UNSIGNED Power Allocation Mode [0,1] Options: 0 Fixed power per RB 1 Power allocated according to a COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 94 of 114

95 Modulation Accuracy [0,1] PMI Calculation Mode [0,1,2] MIMO Codebook Subset Restriction [0,1] MIMO Codebook Subset Ini [1 8] MIMO Codebook Subset End [1 110] Sequential Cancellation (SIC) Interference [0,1] power mask. Options: 0 deactivate 1 active Valid only when LTE transmission mode is not equal to 1. PMI calculation mode: 0 classic (preferred) 1 interference averaged 2 without considering interference. Valid with LTE_trxMode = 4 or 5. Codebook subset restriction: 0 no restriction 1 with restriction Valid with MIMO Codebook Subset Restriction =1 Indicates the index of the first valid precoder. Valid with MIMO Codebook Subset Restriction =1 Indicates the index of the last valid precoder. Valid with LTE Transmission Mode not equal 1. int(1) UNSIGNED int(1) UNSIGNED int(1) UNSIGNED int(1) UNSIGNED int(3) UNSIGNED int(1) UNSIGNED. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 95 of 114

96 Indicates if SIC is modeled, options: 0 no SIC 1 perfect SIC Indicates the mode of CoMP operation, options: tinyint(1) UNSIGNED Cooperative MultiPoint Mode (CoMP) [0,1] 0:no CoMP 1: depends on Cell Selection Mode value: Subband Size [1-100] Radio Bearers calculate coupling losses - 2 do nothing Valid only with LTE Transmission Mode = 90 or 91. Number of RBs per subband to calculate CSI and precoders. int(3) UNSIGNED Valid with LTE_trxMode = 90 or 91. Options: int(1) UNSIGNED. 0 SLNR v1 Type of precoder for noncodebook based transmission [0,1,2,3,4] 1 SLNR v2 2 SLNR v3 3 SLNR complete (preferred over 0,1,2) Max number of Spatial Multiplexed Users [1 110] 4 ZF covariance based Valid with LTE Transmission Mode 91. Maximum number of user to multiplex in MU-MIMO transmission. int(3) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 96 of 114

97 Options: tinyint(1) UNSIGNED RLC Send Mode selection [0,1] 0 Deactivated 1 Active LTE_RLC RLC packet bundle and align mode [0,1] RLC Bits in Header Bytes [0 16] Bytes Options: 0 Deactivated 1 Active Allows controlling header overload due to Packet Bundling tinyint(1) UNSIGNED int(2) UNSIGNED Priorization and Call Admission Control activation [0,1] Options: 0 deactivated 1 activated tinyint(1) UNSIGNED LTE call admission control method Indicates the priorization standard int(5) UNSIGNED LTE Max load level % Maximum load in % of the system capacity of users with highest priority decimal(5,2) UNSIGNED Priorization level LTE Medium load level % LTE Low load level % Maximum load in % of the system capacity of users with medium priority Maximum load in % of the system capacity of users with lowest priority decimal(5,2) UNSIGNED decimal(5,2) UNSIGNED Observation Time (s) for determining quality seconds Analysis time to determinate the quality decimal(4,2) UNSIGNED Percentage of tolerated Wrong Packets 0.2 1/100 Number of accepted erronous packages decimal(3,2) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 97 of 114

98 Congestion Control Spectrum Managemen t HSPDA_AllowedWrongTB 0.2 1/100 Number of accepted erroneous TB. Ej: to accept the 2% the value is 0.02 decimal(3,2) UNSIGNED SpectrumManagementActive 0 Flag 0/1 0 deactivated 1 activated tinyint(1) UNSIGNED SpectrumManagementRBsOutO fband SpectrumManagementFreeRBPr ob SpectrumManagementFAMDPr ob SpectrumManagementStateCha ngeperiod SpectrumManagementSensingP eriod SpectrumManagementSensingT ime SpectrumManagementMeanSN R SpectrumManagementAgressiv enessmode SpectrumManagementRBsOutO fbandwithoutsensing 75 Size of the opportunistic band in RBs Flag 0/ Unused Probability of primary not transmitting in an RB of the opportunistic band When 1 indicates de FA and MD probabilities are taken from a lookup table. When 0, no FA or MD occur. 0.1 seconds Sensing periodicity 0.01 seconds How long the UE senses 30 db db 0 [0,1,2] 25 0: Agressive, 1: Normal, 2: Conservative Size of the opportunistic band, in RBs, where there is no need to sense as it is assumed to be free of primary transmissions for that location int(3) UNSIGNED decimal(3,2) UNSIGNED. tinyint(1) UNSIGNED decimal(3,2) UNSIGNED. decimal(3,2) UNSIGNED decimal(3,2) UNSIGNED decimal(4,2) UNSIGNED int(1) UNSIGNED int(3) UNSIGNED. SpectrumManagementPolluted Probability of polluted RB in the free decimal(4,3) UNSIGNED. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 98 of 114

99 OutOfBandRBProb SpectrumManagementPrimary Overlap SpectrumManagementPrimaryA ctivityfactor SpectrumManagementPositioni ngprecision SpectrumManagementDBUpdat eperiod SpectrumManagementONOFFP aretoscale SpectrumManagementONOFFP aretoshape SpectrumManagementNbRange s SpectrumManagementMetricTh reshold SpectrumManagementMetricAl gorithm SpectrumManagementMaxCQIS cheduler 0 0 opportunistic band 50 meters Location accuracy Proportion of radius overlapping with the primary system Proportion of time that primary system is active 0.5 Geo-database update period [0,1] 3 [0,1,2,3, 4,5] 0 Flag 1/0 Scale of the Pareto distribution controlling the ON-OFF periods of the primary activity Shape of the Pareto distribution controlling the ON-OFF periods of the primary activity Number of different ranges in which the coverage area is divided, having each of them a state in the geodatabase Threshold above which its is determined that the RB is occupied Metric used for geo-database update 1 activates the function to force the usage of max CQI scheduler in the opportunistic band SpectrumManagementMaxInter -110 dbm Max interference assumption for limit transmission power according decimal(3,1) UNSIGNED decimal(3,1) UNSIGNED decimal(4,1) UNSIGNED decimal(3,1) UNSIGNED. >0 decimal(3,1) UNSIGNED. >0 decimal(3,1) UNSIGNED int(2) UNSIGNED decimal(3,2) UNSIGNED int(1) UNSIGNED tinyint(1) UNSIGNED decimal(4,1) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 99 of 114

100 ference to geo-database state Parameters used in networks with multiple RATs being: 1 GPRS 2 EDGE Initial_RAN Typ=5 3 WLAN 4 HSDPA int(1) UNSIGNED 5 LTE Heterogeneo us Network WWW_Initial_RAN Typ=5 Use typical values for a pure LTE simulation Max interference assumption for limit transmission power according to geo-database state _Initial_RAN H263_16_Initial_RAN H263_32_Initial_RAN H263_64_Initial_RAN H263_128_Initial_RAN H263_256_Initial_RAN H263_512_Initial_RAN Typ=5 Typ=5 Typ=5 Typ=5 Typ=5 Typ=5 Typ=5 Parameters used in networks with multiple RATs being: 1 GPRS 2 EDGE 3 WLAN 4 HSDPA 5 LTE H263_1024_Initial_RAN H263_2048_Initial_RAN H263_4096_Initial_RAN Typ=5 Typ=5 Typ=5 Use typical values for a pure LTE simulation Used only with calibration purposes. decimal(4,1) int(1) UNSIGNED decimal(3,1) UNSIGNED int(1) UNSIGNED COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 100 of 114

101 H263_8192_Initial_RAN Typ=5 Set to 1 to get statistics. VoIP_Initial_RAN updateranmode updateranmode_2_period exit_from_queue_if_optimal_r AN_changes Typ=5 Typ=0 Typ=2 Typ=0 Used to debug RLC. Set to 1 to debug. wsnrmeas [0,1] tinyint(1) UNSIGNED Statistics DebugSpectrumManagement [0,1] Debug Used to debug Spectrum Management. Set to 1 to debug. Average Typ=1 Unused int(1). tinyint(1) UNSIGNED Seed [1,200] Seed for random number generation int(3) UNSIGNED SimulationTime s Simulation duration decimal(5,1) UNSIGNED GPRS_EDGE_UpdateTime Typ=0.005 decimal(3,3) UNSIGNED HSDPA_UpdateTime Typ= decimal(6,6) UNSIGNED ReportTime Typ=0.1 s Time between reports decimal(2,1) UNSIGNED ResetTime Typ=0.0 decimal(2,1) UNSIGNED CQI_Intra Typ=1 For HSDPA int(1). CQI_Traces=1 Typ=1 For HSDPA int(1) UNSIGNED. SimulationType Typ=0 StopWhenFinished [0,1] Unused 0 Continuous simulation 1 Drop-based simulation If set, stops simulation a the end showing the real time duration. int(1) UNSIGNED. tinyint(1) UNSIGNED. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 101 of 114

102 LogRBsUtilization [0,1] If set to 1, shows the RBs used in each cell. tinyint(1) UNSIGNED MonitorizedMobiles Unused tinyint(1) UNSIGNED. PreStoredSinAoAAoD = 1 [0,1] PreStoredDoppler = 1 [0,1] OptimizeChannelCalculation = 0 [0,1] Set to 1 to increase simulation speed. More memory needed. Set to 1 to increase simulation speed. More memory needed. Set to 1 to increase simulation speed. More memory needed. tinyint(1) UNSIGNED tinyint(1) UNSIGNED tinyint(1) UNSIGNED Nfft Typ = 2048 FFT length used in simulation int(4) UNSIGNED fres Typ = 1 cqi_reportmodeperiodic ltebwusageselection ltechannelizationbandwidth lteradiationsystemdefinition antennaconfigurationpredefine d [0,1] numberofseeds [1,99] subcarri ers int(1) Resolution of frequency domain cannel representation in simulation This field is not sent from interface to core so it has to be removed A complete simulation is composed by multiple simulations. with the same networks parameters but the users are located randomly on the cell. The number of multiple simulations is defined by this variable. int(3) UNSIGNED. No 0. DebugRLC [0,1] tinyint(1) UNSIGNED int(1) int(1) int(1) int(2) COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 102 of 114

103 Scenario cell configuration This variable configures the regular grid. The options are: - Omnidirectional antennas: SCENARIO CELL CONFIGURATION: OMNIDIRECTIONAL ANTENNAS Value Configuration [total cells/cell under study/interfering cells] 0 [1/1/0] 1 [7/1/6] 2 [19/1/18] - Sectorial configuration: SCENARIO CELL CONFIGURATION: SECTORIAL ANTENNAS Value Configuration [total cells/cell under study/interfering cells] 4 [21/1/20] 5 [57/1/56] - Indoor: SCENARIO CELL CONFIGURATION: INDOOR Value Configuration [total cells/cell under study/interfering cells] 6 [2/1/1] Power level in not active cells (%) The powers of the base stations are defined globally. When users are located only in the central cell this value is used to calculate the power of the other cells. The other cells are considered interference. This value is used to calculate the power mask of the user in the central cell Fast Fading emulation COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 103 of 114

104 SN4G defines different possibilities to emulate the fast fading effect FAST FADDING EMULATION Value Description 1 Without fast fading emulation 2 Fast fading from the best server 3 Fast fading of all cells 4 Strongest M 5 M db from strongest Option 4: Parameter valid for LTE only. Sn4g only models the fast fading of the M most powerful interference sources. Fast Fading interference Management Parameter Combined with option 5, Sn4g only models interferences under M db. Cell Radius Coverage radius of a base station or a sector depending on the scenario definition Number of Users per Cell This variable assumes that all the cells have the same number of users. The variable represents the number of users in each cell. Number of carriers The number of carriers of each base station depending on the technology Number of GPRS timeslots This is the number of timeslots assigned to GPRS. This number depends of the number of GPRS carriers Number of EDGE timeslots This is the number of timeslots assigned to EDGE. This number depends of the number of EDGE carriers Number of HSDPA synchronization codes This variable defines the number of synchronization codes. The maximum value is 16 that correspond with 512 free Spreading Factor (SF) codes in downlink. The simulator subtracts the common channel (16 codes), the DPCH and the SH-SCCH (4 per users that can be scheduled). LTE Resource Blocks COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 104 of 114

105 The simulator allows defining a number of timeslots or the channelization. The control resource blocks (RB) are not considered. The following table shows the relation between channelization and RB: LTE RESOURCE BLOCKS Channelization (MHz) Resource Blocks Slot Allocation This variable decides the free channel assigned to the user SLOT ALLOCATION Value Description 0 The first free channel is assigned 1 A random free channel is assigned GPRS MultiSlot Class and EDGE MultiSlot Class Defined in the standard, the multislot classes are associated with the number of timeslots used. Classes supported: GPRS/EDGE MULTISLOT CLASS Range of multislot classes Max number of timeslots COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 105 of 114

106 COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 106 of 114

107 HSDPA Orthogonality Factor Ideally, the orthogonality factor 1 means that HSPA sequences are completely orthogonal and consequently, they can be recovered without interferences. This situation is not possible because the spreading codes are not completely orthogonal. In order to model this we add this factor. The higher the factor is, lower the interference produced is because they are more orthogonal. When the number of mobiles increases, the relevance of this parameter also increases. LTE Transmission Mode The variable specifies the LTE transmission mode LTE TRANSMISSION MODE Value Description Simulations restrictions COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 107 of 114

108 Single antenna The configuration has to be 1x2 Closed Loop Spatial Multiplexing Transmit independent and separately encoded data signals. It utilizes Channel State Information (CSI) at the transmitter MU-MIMO codebook based SU-MIMO non codebook based MU-MIMO non codebook based Multiple Users with MIMO. The network can transmit user data through a codebook-based spatial beam or a virtual antenna. Single User with MIMO Multiple Users with MIMO The configuration cannot be 1x2 Multipath Model There are two methods to simulate multipath: Jakes model a model for Rayleigh channels based on summing sinusoids and the IMT-Advanced Model Load Loss Map Selection This option allows selecting an analytical or a real path loss model. The options for the analytical model are: Okumura-Hata; WLAN model; ETSI model used for NEWCOM; IMT-Advanced model for: indoor, urban micro, urban macro, suburban macro and rural macro; or using PathLossA + PathLossB*log10(dist_km). The wizard requires specific values depending on the selected model A real path loss model allows uploading a pre-calculated map for the simulated area. Additionally, requires general parameters as: base station height in meters, user equipment height, Decorrelation distance for shadowing model Valid when Load Loss Map Selection is Okumura-Hata, WLAN model or ETSI model used for NEWCOM. This parameter represents the distance between two points to achieve uncorrelation. Values between steps are interpolated. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 108 of 114

109 LoS Shadowing Standard Deviation The variable represents the shadowing standard deviation for Line Of Sight (LoS) users (below a threshold distance from the base station). Applicable only if Load Loss Map Selection is 3X (IMT-Advanced model) or for every user with other models Mean Penetration Loss and Penetration Loss Standard Deviation These parameters are valid only when the Load Loss Map Selection is IMT-Advanced model Saturation and Total Saturation Boolean value to saturate simulates continuous traffic of www or . LTE Full Buffer Model When the Boolean value is activated, the enodeb always transmits to maximum capacity. VoIP On and VoIP Off These values represent the percentage of VoIP active and inactive. The sum of both cannot be higher than 100. GPRS LA Updating && EDGE LA Updating The BS waits x seconds before send a new request to user equipment in order to check if a change in the location area is required. Discard Time This parameter represents the time, in milliseconds, before a packet is discarded. Add standard lognormal deviation The Boolean is used to add an error in the CQI measures. Empirical studies observe that the typical error describes a lognormal function. Block Error Probability offset (BLEP) The magnitude of this power offset determines the residual Block Error Probability (BLEP), and this variable allows adding the power offset or not. Dynamic Rank Factor The meaning of this variable is completely dependent of Dynamic Selection of transmission Rank Mode. Delta power This parameter is valid only when FFR or SRF from Frequency Reuse Mode is selected. It is useful to create the power mask. LTE call admission control method COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 109 of 114

110 This variable represents the standard proposal. For example, has to be inserted as Spectrum Management Configuration The variable activates the Spectrum management. The following figure shows a simple scenario where there is a base station (primary station) using a licensed spectrum and an enodeb that uses free frequencies when it is possible. More information at [25]. Figure 37: Picture reference from Osa et al. EURASIP Journal on Wireless Communications and Networking Positioning Precision The UE location accuracy has an error that cannot be avoid if the system does not use an auxiliary positioning system as GPS. Positioning Precision variable considers the error modifying the user position. GeoDB Update Period The GeoDB contain valuable information about which frequency bands can be used by a given enodeb at a specific moment of time and the maximum coverage range in order not to interfere with the primary system Scale of the ON-OFF Pareto distribution and Shape of the ON-OFF Pareto distribution Primary system transmissions were randomly generated following the semi-markov ON- OFF Pareto-distribution [24]. Its probability distribution function f(x) is defined as follows: f ( x ) = k x m k x k + 1 ; x x m where k is referred to as the shape parameter and xm is the scale parameter of the Pareto distribution. Note that different combinations of these two parameters result in different primary activity periodicities, TPA, i.e., different average ON-OFF intervals in the primary system. COMMUNE Celtic Project: Deliverable D.5.2: issued on Page 110 of 114