An LTE module for the ns-3 network simulator

Giuseppe PiroDEE - Politecnico di Bari, Bari, Italy

g.piro@poliba.it

Nicola Baldo, Marco MiozzoCentre Tecnològic de Telecomunicacions de

Catalunya, Barcelona, Spain{nbaldo,mmiozzo}@cttc.es

ABSTRACTIn this paper, we present a novel module developed for thesimulation of the LTE technology with the ns-3 simulator.It focuses mainly on modeling the E-UTRA part of the sys-tem, with a particular attention on the aspects related to thechannel, PHY and MAC layers. First we discuss the overallmodeling assumptions according to which the module wasdesigned. Subsequently, we describe in detail the architec-ture of the module and its components. Finally, we showpossible research applications by discussing some examplesimulation scenarios.

Categories and Subject DescriptorsI.6.5 [Simulation and Modeling]: Model Development—Modeling methodologies; I.6.7 [Simulation and Model-ing]: Simulation Support Systems—Environments

General TermsAlgorithm, Design, Performance, Verification

Keywords3GPP, LTE, E-UTRA, Simulator, ns-3, Channel, MAC, PHY

1. INTRODUCTIONIn the last years the 3rd Generation Partnership Project(3GPP) has been working on the definition of a new mo-bile communication technology called Long Term Evolution(LTE), which candidates as a significant improvement withrespect to the currently widely-deployed Universal MobileTelecommunications System (UMTS) and High-Speed PacketAccess (HSPA) systems.

Thanks to features like enhanced data rates and lower powerconsumption, LTE represents an emerging and promisingtechnology for providing a broadband ubiquitous Internetaccess. For this reason, the research community is puttinga considerable effort on studying LTE for designing newerand innovative solutions that can maximize its performance,

both from a Radio Access Network (RAN) perspective andfrom the point of view of the Core Network. For instance,in order to improve the spectral efficiency, the OrthogonalFrequency Division Multiple Access (OFDMA) technique isintroduced, together with Multiple-Input Multiple-Output(MIMO) schemes. At the same time, LTE completes thetransition from Circuit Switched core network solutions (stillheavily relied upon in 3G) to an all-IP architecture, whichhad been long regarded as a much desireable feature, bothfor the increasing usage of data services by mobile users, andfor the higher flexibility and potential lower cost of the CoreNetwork equipment.

As the interest in LTE as a mobile communication technol-ogy increases, there is a growing need for instruments ableto characterize the performance of LTE systems in orderto tune and optimize them. This need is present at vari-ous stages: for the standardization of future version of thetechnology, as well as for the design and implementation ofdevices and network equipments and the roll-out of LTE net-work infrastructures. LTE is a rather complex technology,and for this reason traditional performance evaluation meth-ods based on analytical models can be applied only to verysmall portions of it. As a consequences, researchers and engi-neers most often rely on simulators to assess the performanceof LTE systems. In particular, open source network simula-tion tools are highly valued by researchers, because of theirusually wider acceptance within the research community. Inthe literature, several LTE simulators have been proposedfor different purposes. Physical layer simulation tools suchas [10] and [18] are quite limited in that they consider theperformance at the physical layer only, normally focusingon a single transmitter-receiver pair. System level simula-tors, such as for instance [14] and [13], go beyond the phys-ical layer by normally introducing the MAC layer togetherwith an abstract model of the higher layers. They are usu-ally adopted in the research community for the evaluation ofRadio Resource Management (RRM) algorithms, but due totheir abstraction of the higher layers they cannot provide anaccurate evaluation of the end-to-end performance and of thebehavior of the network as a whole. The most promising so-lution to this problem is represented by network simulators,which feature an accurate implementation of all the protocollayers from the MAC up to the application. A first step inthis direction is done with [20], which is an open source LTEnetwork simulator that supports single and multi-cell envi-ronments, QoS management, multi users environment, usermobility, handover procedures, scheduling, and frequency

reuse techniques. Unfortunately, since this simulator aimsat supporting LTE only, it lacks the many features of generalpurpose network simulator like ns-3, for example the avail-ability of a full-fledged TCP/IP protocol stack, the supportfor other wireless technologies such as WiFi and WiMAX,the possibility of integration with testbeds and real applica-tion binaries, etc. The simulation module that we describein this paper was explicitly designed in order to fill this gap.It introduces support for the simulation of the LTE tech-nology in the ns-3 simulator, with a particular attention onmodeling the most relevant aspects of the Evolved Univer-sal Terrestrial Radio Access (E-UTRA), which is the radiointerface of LTE [2].

2. THE LTE MODULE FOR NS-3The development of the LTE module for ns-3 has been car-ried out during the Google Summer of Code 2010 . Thismodule provides a basic implementation of LTE devices, in-cluding propagation models and PHY and MAC layers. Dueto the intrinsic complexity of the LTE standard and the lim-ited time of the GSoC framework, at the time of this writingit is not yet possible simulate a complete LTE network. How-ever, the proposed module already allows the simulation ofseveral important aspects of LTE systems, such as for ex-ample downlink RRM and MAC scheduling and, moreover,it provides a very good basis for further extensions as wellas the development of a complete tool in the future.

In summary, the most important features provided by theproposed module are (i) a basic implementation of both theUser Equipment (UE) and the enhanced NodeB (eNB) de-vices, (ii) RRC entities for both the UE and the eNB, (iii)a state-of-the-art Adaptive Modulation and Coding (AMC)scheme for the downlink [9], (iv) the management of thedata radio bearers (with their QoS parameters), the MACqueues and the RLC instances, (v) Channel Quality Indi-cator (CQI) management, (vi) support for both uplink anddownlik packet scheduling, (vii) a PHY layer model withResource Block level granularity and (viii) a channel modelwith the outdoor E-UTRAN propagation loss model.

The module is built completely in C++ and, at the time ofthis writing, comprises 89 classes and approximately 9000lines of code. Figure 1 shows the UML diagram of the mostimportant classes that compose the module. It is importantto remark that the diagram only reports the most impor-tant data members and functions. Some details about therelationship among classes have been omitted due to spacelimitations.

2.1 LTE PHY and E-UTRAN channel modelsIt is our opinion that the most interesting and immediate usecase for an LTE Network Simulator is to aid in the designand evaluation of RRM solutions. RRM in LTE is char-acterized by a high flexibility: thanks to the OFDMA andSC-FDMA access technologies, different radio resources inthe time and frequency domain can be dynamically assignedto different users. The reason behind this design choice isto allow the RRM process to opportunistically exploit thevariations of the channel conditions that happen both intime and frequency. For example, due to frequency selectivefading it can happen that at a certain time slots a particu-lar set of subcarriers is not suitable for communication with

certain mobile users; then, by opportunistically assigningto each user only those subcarriers which are known to begood for communication, the system can enjoy an enhancedcapacity. Clearly, in order to properly evaluate such oppor-tunistic RRM algorithm in an LTE network simulator, itis important that the simulator provides suitable means tomodel the time- and frequency-varying aspects of the com-munications in LTE system.

Ns3::Spectrum[11] was proposed to address this issue in ns3.It is a framework that provides support for spectrum-awarechannel and PHY simulation, which is particularly suitedfor the modeling of the OFDMA and SC-FDMA technolo-gies. Due to these characteristics, we chose to base ourimplementation of the LTE PHY and channel models onNs3::Spectrum. In the definition of a particular wirelessmodel based on the Spectrum framework, the first thing todo is to define (i) a set of frequencies/channels to use at thephysical layer and (ii) the signal generated at the PHY andtransported through the channel. To this aim, correspond-ing specialized versions of the SpectrumModel class have tobe developed in order to define the portions of radio spec-trum used by the considered technology and the granular-ity of their representation. In our case, we considered twoseparate SpectrumModel instances, one for the uplink (UL)and one for the downlink (DL), in order to model the pairedspectrum in which LTE operates according to the FrequencyDivision Duplex (FDD) mode. At the present, the proposedmodule supports a spectrum model for the first E-UTRANFDD operative band (i.e., [1929-1980] MHz for the UL and[2110-2170] MHz for the DL) [7]. In particular, our Spec-trumModel is designed to describe a set of sub-channels usedfor transmission. Since in LTE radio resources are dividedin sub-channels of 180 kHz, we chose this as the granularityof our spectrum model. Moreover, the LteSpectrumValue-Helper class has been developed to make it easy to createthe SpectrumValue corresponding to a given signal, takinginto account in particular the set of sub-channels to be usedfor the transmission. During the simulation, the PHY layeruses this class to create the SpectrumValue instances thatrepresent the Power Spectral Density (PSD) of both sig-nal and noise. In [11] the channel/PHY interface has beendefined by the abstract base classes SpectrumChannel andSpectrumPhy. The most important role of these classes isthe transmission and receptions of signals. In particular,the SpectrumChannel class (i) handles the packet transmis-sion process among attached PHY layers and (ii) it includesthe channel propagation models. As said before, our LTEmodule supports the FDD model only, therefore in the im-plementation we use two separate SpectrumChannel objectsin order to manage uplink and downlink independently; thischoice is motivate by its lower simulation complexity.1 Inparticular, the SpectrumChannel implementation that weuse is SingleModelSpectrumChannel, which was already pro-vided by Ns3::Spectrum. This is an acceptable choice, sincethe propagation model (for which we wanted to develop a

1For example, let us consider a single cell FDD system withN users. If this system is simulated using a single Spectrum-Channel object, the number of channel evaluations for eachslot is O(N2), whereas it is just O(N) if a separate channelobject is used for the uplink and downlink. This is becausein the uplink we are not actually interested in simulating thepropagation among the mobile users.

LteNetDevice

- m_phy: Ptr<LtePhy>

- m_rrcEntity: Ptr<RrcEntity>

+ (…)

UeNetDevice

- m_macEntity: Ptr<UeMacEntity>

- m_targetEnb: Ptr<EnbNetDevice>

+ SendPacket (p:Ptr<PacketBurst>) : bool

EnbNetDevice

- m_macEntity: Ptr<EnbMacEntity>

- m_ueManager: Ptr<UeManager>

+ StartTransmission () : bool

UeManager

- m_ueRecords:

std::vector<Ptr<UeRecord>>

+ GetUeRecord (ue:Ptr<UeNetDevice>)

: Ptr<UeRecord>

+ AddUeRecord (ue:Ptr<UeNetDevice>)

: void

+ DeleteUeRecord

(ue:Ptr<UeNetDevice>) : void

UeRecord

- m_ue: Ptr<UeNetDevice>

- m_cqi: struct CqiFeedbacks

+ (…)

MacEntity

- m_amcModule:

Ptr<AmcModule>

+ (…)

UeMacEntity

EnbMacEntity

- m_ulScheduler: Ptr<PacketScheduler>

- m_dlScheduler: Ptr<PacketScheduler>

+ ReceiveCqiIdealControlMessage (

Ptr<CqiIdealControlMessage>) : void

PacketScheduler

+ RunPacketScheduler () : void

SimplePacketSchedule

RrcEntity

- m_defaultBearer:

<RadioBearerInstance>

+ Classify (p:Ptr<Packet>)

: Ptr<RadioBearerInstance>

LtePhy

- m_downlinkSpectrumPhy:

Ptr<LteSpectrumPhy>

- m_uplinkSpectrumPhy:

Ptr<LteSpectrumPhy>

- m_listOfDlSubChannels: std::vector<int>

- m_listOfUlSubChannels: std::vector<int>

- m_txPower: double

+ SendIdealControlMessage (

Ptr<IdealControlMessage>) : void

+ ReceiveIdealControlMessage (

Ptr<IdealControlMessage>) : void

NetDevice

RadioBearerInstance

- m_queue: Ptr<LteMacQueue>

- m_qosParameters:

Ptr<BearerQoSParameters>

- m_direction: enum BearerDirection

- m_bearerType: enum BearerType

- m_rlcEntity: Ptr<RlcEntity>

- m_ipcsClassifierRecord:

IpcsClassifierRecord*

+ Enqueue (Ptr<Packet>) : bool

+ Dequeue () : Ptr<Packet>

RlcEntity

+ Dequeue () : Ptr<Packet>

BearerQoSParameters

- m_bearerQoSType:

enum BearerQoSType

- m_qci: int

- m_arpPreEmptionCapability: bool

- m_arpPreEmptionVulnerability: bool

- m_gbr: double

- m_mbr: double

- m_maxDelay: double

MacQueue

+ Enqueue (Ptr<Packet>) : bool

+ Dequeue () : Ptr<Packet>

SingleModelSpectrumChannel

SpectrumPhy

UeLtePhy

- m_listOfSubChannelsForTx: std::vector<int>

- m_listOfSubChannelsForRx: std::vector<int>

+ CreateCqiFeedbacks (

sinr:std::vector<double>) : void

+ CreateTxPowerSpectralDensity () :

Ptr<SpectrumValue>

EnbLtePhy

+ CreateCqiFeedbacks (

sinr:std::vector<double>) : void

+ CreateTxPowerSpectralDensity () :

Ptr<SpectrumValue>

+ StartFrame ()

+ EndFrame ()

+ StartSubFrame ()

+ EndSubFrame ()

IdealControlMessage

- m_type: enum MessageType

- m_source: Ptr<LteNetDevice>

- m_destination: Ptr<LteNetDevice>

CqiIdealControlMessage PdcchIdealControlMessage

LteSpectrumPhy

- m_channel: Ptr<SpectrumChannel>

- m_txPsd: Ptr<SpectrumValue>

- m_rxPsd: Ptr<SpectrumValue>

+ StartTx (p:Ptr<PacketBurst>) : bool

+ StartRx (p:Ptr<PacketBurst>) : void

UeLteSpectrumPhy

EnbLteSpectrumPhy

LteSpectrumPropagationLossModel

- m_channelRealizations: std::map <

std::pait<MobilityModel, MobilityModel>,

Ptr<ChannelRealization>>

+ CreateChannelRealization (

a:MobilityModel, b:MobilityModel) : void

+ GetChannelRealization (

a:MobilityModel, b:MobilityModel) :

Ptr<ChannelRealization>

DiscreteTimeLossModel

- m_lastUpdate: double

- m_samplingInterval: double

PathLossModel JakesFadingLossModel ShadowingLossModel PenetrationLossMod

ChannelRealization

- m_pathLoss: Ptr<PathLossModel>

- m_multipath: Ptr<MultipathLossModel>

- m_shadowing: Ptr<ShadowingLossModel>

- m_penetration: Ptr<PenetrationLossModel>

SpectrumPropagationLossModel

SpectrumErrorModel

1 1 1 1

1 1 1 1

1

N

1

1

1

1

1

1

1

N

1

1

1

N

1

1

2

1

1

1

SPECTRUM FRAMEWORK

NS-3

AmcModule

- m_cqiTable

- m_mcsTable

- m_tbSizeTable

+ (…)

1

1

N

1

1

1

1 1

1 1

Figure 1: The class diagram.

version specific for LTE) is actually a separate model thatis plugged into the channel object. Our LTE-specific propa-gation model will be discussed in detail in Section 2.1.3.

The UeLtePhy and the EnbLtePhy classes represents thephysical layer of the UE and eNB devices, respectively. Theyinherit from the LtePhy class, which provides their commonfunctionalities. In order to manage separately uplink anddownlink, the LTE PHY layer has been conceived as a con-tainer of two different baseband subsystem. Each of thesesubsystem is modeled by the LteSpectrumPhy class, whichis then specialized into the UeLteSpectrumPhy and the En-bLteSpectrumPhy classes, respectively. As we said before,each of these classes is attached to a different Spectrum-Channel object. The FDD access mode defines a differentset of sub-channels for both uplink and downlink. A list ofavailable sub-channels for the uplink and the downlink arestored into the m listOfUplinkSubchannel and m listOf−DownlinkSubchannelmember variables of the LtePhy class,respectively. We note that these sets of subchannels must bedefined at the beginning of the simulation. The SendPacket()method is the entry point for the PHY and handles thetransmission of the packets on the channel. The UE andthe eNB use different PHY interfaces to transmit packets.

Finally, the physical layer is also responsible for the trans-mission and the reception of control messages. With thisrespect, we note that the proposed module has the objec-tive of modeling the transmission of user data only. As aconsequence, in order to limit the complexity of the simu-lator and hence simulation time, an ideal control channelwas implemented. This means that control messages ex-changed among nodes are not subject to channel and prop-agation modeling, and therefore they are always receivedcorrectly. From an implementation point of view, the phys-ical layer delivers the message to the destination directly,without passing through the channel object. A control mes-sages is sent using the SendIdealControlMessage method ofthe LtePhy class. The ReceiveIdealControlMessage methodof the LtePhy class handles the reception of the control mes-sage. According to the message type, it delivers the messageto a proper device entity for processing.

2.1.1 The eNB physical layerThe EnbLtePhy class models the eNB physical layer. Thefirst task of this class is to handle the transmission and re-ception of signals by the eNB. With this respect, the trans-mission procedure is performed by the StartTx () membermethod of the downlink EnbSpectrumPhy object, while thereception procedure is performed by the StartRx () membermethod of the uplink EnbSpectrumPhy object.

At the end of the reception, the PHY interface (i) estimatesthe SINR of the received signal and (ii) delivers the receivedpackets to the device. We note that no error model is cur-rently implemented; however, considering that link adapta-tion is accurately modeled, we argue that the absence of anerror model has a very limited impact on the overall accu-racy of the model.

According to the LTE specification [3], in the time domainthe radio resources are allocated every Transmission TimeInterval (TTI), which has a duration of 1 ms; 10 consecu-

tive TTIs form the LTE Frame. In our simulation model, theeNB physical layer handles the start and end of both framesand sub-frames, using the methods StartFrame, StartSub-Frame, StopFrame and StopSubFrame. In particular, wenote that the StartSubFrame function triggers both the up-link and the downlink scheduling functions.

2.1.2 The UE physical layerThe UeLtePhy class models the UE physical layer. As weanticipated earlier, in an OFDMA/SC-FDMA system typi-cally only a subset of the spectrum resources available bothin DL and UL are normally assigned to an UE in a givenslot. The allocation is performed by the MAC scheduler atthe eNB on a per-TTI basis. To implement this per-userresource allocation, we use the m subChannelsForTran−smission and m subChannelsForReception member vari-ables of the LtePhy class. The first one describes a listof uplink sub-channels assigned by the uplink scheduler fortransmitting packets through the uplink channel. The sec-ond one, instead, described a list of downlink sub-channelsassigned by the downlink packet scheduler for the down-link packet transmission. These variables are updated everyTTI, according to the scheduling decisions.

When the UE device has to transmit a packet, it calls theUeLtePhy::SendPacket () method; this in turn delivers thesepackets to the StartTx () method of the the uplink Lte-SpectrumPhy instance of the UE, which is in charge of twotasks. First, it creates the SpectrumValue instance, whichmodels the signal to be transmitted by describing the PSDthat the signal assumes for each sub-channel used for thetransmission. To this aim, it uses the LteSpectrumValue-Helper component, taking into the account the informationcarried out by the m subChannelsForTransmission vari-able, stored into the UeLtePhy class. Second, the UE callsthe SpectrumChannel::StartTx () to actually simulate thetransmission of the signal on the channel.

The reception procedure is performed by the StartRx ()member method of the downlink SpectrumPhy object. Atthe end of the reception procedure, the PHY interface (i)computes the SINR of the received signal, (ii) transfers thesevalues to the MAC layer for the creation of the CQI feed-back, and finally (iii) delivers all the received packets to thedevice.

2.1.3 Propagation Loss ModelThe propagation loss model proposed for the E-UTRAN in-terface is made up by four different components: path loss,shadowing, multipath and penetration loss [8], which areimplemented respectively using the classes PathLossModel,JakesFadingLossModel, ShadowingLossModel, and Penetra-tionLossModel. All of these classes inherit from the Discrete-TimeLossModel class which provides methods and membervariables common to all propagation loss models. Due to thetime depent channel nature, all models should be updatedperiodically. In particular, the m samplingPeriod variable,defined into the DiscreteTimeLossModel class, describes theinterval between two consecutive updates of the model. Wenote that this value should be set taking into considerationthe coherence time of the channel.

The fast fading model has been implemented using the Jakes

5 10 15 20 25

20

40

60

80

100

-40

-30

-20

-10

0

10

20

Time [TTI]

Frequency [PRB]

Multip

ath

[dB

]

Figure 2: Time-Frequency Fast Fading Realization,UE speed = 3 km/h.

model [16] for Rayleigh fading, taking into account the fre-quency f , the user speed s, and the number m of multiplepaths. In order to reduce the computational load duringsimulations, we chose to use pre-computed realizations of theJakes model for p ∈ {6, 8, 10, 12}, s ∈ {0, 3, 30, 120} km/hand f the central frequency of the j-th sub-channel definedaccording to the spectrum model that we described in Sec-tion 2.1. During simulation, m is randomly drawn accordingto the uniform distribution [23], and s is inferred from thens-3 mobility model. Figure 2 shows in time and frequencyone of the pre-computed multipath realizations obtained fora user speed of 3 km/h and 6 paths. The path loss, PL, iscalculated according to the outdoor urban propagation lossmodel in [4]; in particular, the loss expressed in dB is com-puted as PL = 128.1 + 37.6 log10 d, where d is the distancein kilometers between the eNB and the UE. The large scaleshadowing fading is modeled using a log-normal distributionfor the loss coefficient; i.e., the loss value in dB is normallydistributed with a zero mean and standard deviation of 8 dB.Finally, the penetration loss has been set to a fixed value of10 dB according to [8]. The ChannelRealization class im-plements a realization of the propagation model for a givenUE–eNB pair. This class instance acts as a wrapper for theinstances of all the LossModel components to be used.

The LteSpectrumPropagationLoss class wraps all the prop-agation loss model functionality for a given SpectrumChan-nel. It stores all ChannelRealization objects into a std::mapcontainer, where each realization is identified by pointers tothe mobility models of the pair of nodes it refers to. Be-fore delivering the transmitted packets to all the attachedreceiving PHY instances, the SpectrumChannel uses the Cal-cRxPowerSpectralDensity () member method of the LteSpec-trumPropagationLoss object for calculting the power spec-tral density of the signal to be received. Let PTX,i MPLi bethe transmission power and the mutipath loss for the i− thsub-channel; furthermore, let PL, PNL and SW be , thepath loss, the penetration loss and the shadowing, respec-tively, ∀i. The power PRX,i of the received signal for thesub-channel i, expressed in dB, is computed as follows:

PRX,i = PTX,i − PL−MPLi − PNL− SW (1)

2.2 Network DevicesThe LTE device, modeled by the LteNetDevice class, im-plements the abstract NetDevice class provided by the ns-3.In addition to performing all the common functionality of

an ns-3 device, it contains and manages the main entitiesof the E-UTRAN protocol stack, i.e., the RRC, RLC, MACand PHY. A couple of dedicated classes, UeLteNetDeviceand EnbLteNetDevice, inherit from LteNetDevice and im-plement the functionality specific of the UE and the eNBdevices, respectively.

The UeNetDevice

Since most of the functionalities are in charge of the the eNB,the implementation of the UE is simple. The UE storesinformation about which eNB it is registered to; for thispurpose, a private member variable namedm targetEnb hasbeen defined. This variable should be set at the beginning ofthe simulation, by using the SetTargetEnb() method. Thisis used, for example, to implement the ideal control channelthat we described in Section 2.1.

The EnbNetDevice

The eNB plays a crucial rule into the E-UTRAN interface.The most important task of the eNB is the Radio ResourceManagement (RRM), which is performed by uplink and down-link packet schedulers. A specific eNB MAC entity has beencreated for the eNB, where both UL and DL packet sched-uler component are defined.

The eNB uses the UE Manager component to manage UEsin various of its operations. First of all, using UE Manager,the eNB knows all the registered UEs. For each of them, anUE Record is created and stored into the UE manager com-ponent. It is important to note that the UE Record is usedalso to store information about the latest CQI feedbacks sentby the UE. This information is used by the packet schedulerto allocate resources to the UEs taking into account theirchannel conditions.

2.2.1 The Radio Resource Management EntityRadio Bearers

In LTE, each traffic flows between the UE and the eNBare grouped into logical entities called End-to-End Bear-ers which are identified by their common end-to-endd QoSrequirements and the corresponding accounting and billingpolicies. At the radio level, Radio Bearers [17] are used,which represents the QoS requirements to be guaranteed atthe radio interface in order to satisfy the requirements repre-sented by the End-to-end bearer. In our simulation module,the class RadioBearerInstance models the Radio Bearer es-tablished between UE and eNB. The direction of a radiobearer is stored into the m direction variable. Each radiobearer is identified by a socket pair, i.e., the source and des-tination IP address, the type of transport protocol, and thesource and destination port. In order to manage this in-formation, we chose to reuse the IpcsClassifierRecord classwhich was defined for the WiMAX and is already present inns-3 [15].

The BearerQoSParameters class has been designed to rep-resent the QoS requirements associated to each bearer. It isa data structure that holds the parameters that character-ize Bearers [2], in detail: (i) m bearerType, which describesthe type of a radio bearer (Guaranteed Bit Rate (GBR) or

Non-Guaranteed Bit Rate (Non-GBR)); (ii) the QoS ClassIdentifier m qci which identifies the different treatment tobe adopted for each bearer (e.g., it will be translated by theRRM into specific scheduling weights, admission thresholds,queue management thresholds, link layer protocol configura-tions, etc.), (iii) the value of the guaranteed bit rate m gbr,that represents the expected bit rate for a GBR bearer and(iv) m mbr that represents the minimum bit rate to provideto the GBR bearer.

The RrcEntity

According to the LTE specifications [6], the Radio ResourceControl (RRC) entity handles (i) connection establishmentand management, (ii) broadcast of system information, (iii)radio bearer establishment/reconfiguration and management,(iv) mobility management, and (v) paging. In our imple-mentation, the RRC entity is implemented by the RrcEntityclass, and provides only the Radio Bearer management func-tionality. The method Classify of the RRC entity performsthe classification of the packets coming from the upper layerinto the corresponding Radio Bearer. This classification isbased on the information provided by the class IpcsClassi-fierRecord which we described earlier.

The class MacQueue implements the MAC queue where allthe packets packets coming from the application layer andthat belong to a particular Radio Bearer are stored. TheMacQueue class implements a First In First Out (FIFO)management policy. This is acceptable since all the packetsin the same queue instance always belong to the same trafficclass.

The interaction between the MAC and the Radio Bearer isprovided by the RLC entity, which is implemented by theRlcEntity class. In our simulation model, the RLC entitytakes care of dequeueing the packets from the MAC queueand delivering them to the to the lower layer. The stan-dard defines three different modes of operation for the RLC:Transparent Mode (TM), Unacknowledged Mode (UM) andAcknowledged Mode (AM) [5]. Currently, our simulationmodule provides only TM, i.e., the RLC delivers all packetsto the MAC layer without performing neither segmentationnor concatenation of RLC PDU and without adding anyRLC header.

2.2.2 The MAC EntityThe MAC Entity, implemented by the MacEntity class, pro-vides an interface between the device and the physical layerfor both the UE and the eNB devices. This interface hasbeen designed for delivering packets coming from the upperlayer to the physical layer and vice versa. In particular, it isresponsible for the creation of the transport block to be sentto the PHY layer by composing packets and/or fragmentsprovided by the RLC. Moreover, the MAC entity hosts theAdaptive Modulation and Coding (AMC) module [1], whichwill be described in the following.

The MAC functionalities differs between the UE and theeNB. For this reason, we defined two separate UeMacEn-tity and EnbMacEntity classes, in order to specialize theMAC functionalities for these different type of nodes. TheEnbMacEntity is responsible of the radio resource allocation

procedure, i.e., it host both the uplink and downlink packetscheduler components. On the other hand, an importantfeature provided by the UeMacEntity is the creation of CQIfeedback, described below.

The Adaptive Modulation and Coding module

The AMC module implements the AMC functionality de-fined in the LTE standard, i.e., it takes care of adapting themodulation and coding scheme used in the physical layerto the channel conditions faced by each user, in order tomaximize the channel capacity and keep the residual bit er-ror rate below a maximum acceptable threshold. AMC isvery important in the context of simulating RRM, becauseit causes the available channel capacity to vary according tothe variations of the channel for each user. In particular,the MAC scheduler needs to consider the behavior of AMCin order to take effective scheduling decisions.

AMC works according to the following scheme: the UE pe-riodically measures the quality of the signal received fromthe eNb, and converts it into a specific representation for-mat which is called CQI. CQI is then forwarded to the eNB,where it is exploited by the AMC module to select, for eachUE, the most suitable modulation and coding scheme [12].

The AMC component is implemented by theMacEntity classand it is used differently by UE and eNB. In general, theAMC module provides an unique mapping among the CQI,the MCS, the spectral efficiency, and the Transport Block(TB) Size. We chose to use the mapping function proposedin [9] and illustrated in Table1. The spectral efficiency refersto the information rate that can be transmitted over a givensub-channel. The TB Size refers to the amount of bits atthe physical layer, coming from the MAC layer during trans-mission (or passed to the MAC layer during reception) ontransport channels; it depends on the MCS chosen by theAMC module, the number of antenna ports, the durationof the prefix code used at physical layer, and the numberof symbols used by the control channel. As proposed in [9],our AMC module computes the TB size by using this con-figuration: normal prefix code, 2 antenna ports, 3 OFDMsymbols for PDCCH (Physical Downlink Control Channel),no sync signals, and the absence of PBCH Physical Broad-cast Channel.

CQI management

CQI feedback in LTE is determined according to the follow-ing procedure. The eNB sends reference symbols every TTI,spreaded over the whole operative downlink bandwidth. Inorder to estimate the channel quality, the UE uses the datacollected from these reference symbols to compute the SINRof the received signal. In particular, a SINR value is ob-tained for each downlink sub-channel. These values are thenconverted into CQI values that are sent to the target eNBusing the uplink control channel [12].

In the simulator, we have implemented a full-bandwidthperiodic CQI reporting scheme: the UE creates a set ofCQI feedbacks, one for each downlink sub-channel, everyTTI. This operation is composed by three consecutive steps.First, the UE uses the PHY layer to compute a list of SINR

Table 1: Mapping Function: from the spectral effi-cient to the TB sizeInterval forηi,j

CQIIndex

ModulationScheme

TB size [bit]

≤ 0.15 1 4-QAM 180.15÷ 0.23 2 4-QAM 280.23÷ 0.38 3 4-QAM 450.38÷ 0.60 4 4-QAM 720.60÷ 0.88 5 4-QAM 1050.88÷ 1.18 6 4-QAM 1411.18÷ 1.48 7 16-QAM 1771.48÷ 1.91 8 16-QAM 2301.91÷ 2.40 9 16-QAM 2892.40÷ 2.73 10 64-QAM 3082.73÷ 3.32 11 64-QAM 3633.32÷ 3.90 12 64-QAM 4333.90÷ 4.52 13 64-QAM 5064.52÷ 5.12 14 64-QAM 578≥ 5.12 15 64-QAM 640

values, one for each downlink sub-channel. Second, theMAC entity converts these SINR values into a set of CQIindices, using some functionalities of the AMC module com-ponent. Third, an ideal control message is be created andsent to the target eNB.

The exact CQI values are determined according to the pro-cedure proposed in [19]. At the end of the physical receptionprocedure, the UeSpectrumPhy computes the SINR for thei-th sub-channel using the following equation:

SINRi =SPDRX,i ·B

FN0B(2)

where PSDRX,i is the PSD of the received signal for thei-th sub-channel (i.e., its value is taken from the Spectrum-Value instance associated with the received signal), B is thebandwidth of a resource block (in our case, 180kHz), Fis the noise figure (default value 2.5) and N0 is the noisespectral density (default value −174dBm/Hz). After theSINR values have been computed, the UE PHY interfacecalls the UeMacEntity::CreateCqiFeedbacks () function toconvert these SINR values to a set of CQI indices. Thisfunction first converts the SINR to the corresponding spec-tral efficiency ηi using Shannon’s theorem [21] as follows:

ηi = log2

(1 +

SINRi

Γ

), (3)

where Γ is a coefficient introduced to model the differencebetween the theoretical bound and the performance of realmodulation and coding schemes; such a coefficient dependson the target BER [22]: Γ = − ln(5 · BER)/1.5. The spec-tral efficiency value is then mapped to a corresponding CQIvalue, using the mapping function reported in Table 1.

A set of CQI values are used to create an ideal CQI feedbackcontrol messages that the UE sends to the eNB through theideal control channel. As soon the eNB receives this controlmessage from a given UE, it updates the channel qualityreport for this user, which is stored into the correspondingUE record.

Packet Scheduler

The proposed module supports both uplink and downlinkschedulers. The virtual class PacketScheduler define the in-terface for the implementation of MAC schedulers (we notethat a similar approach was followed for the ns-3 WiMAXmodule [15]). Therefore, custom scheduling strategies shouldbe implemented by inheriting for this class. The imple-mented downlink and uplink schedulers are then pluggedinto the eNB, by setting them downlikScheduler andm up−linkScheduler variables of the EnbMacEntity component,respectively. At the present, only a simple downlink schedul-ing strategy has been implemented in the class SimplePack-etScheduler. This strategy consists of sending every TTIone packet from each active downlink Radio Bearer. Thesepackets are included in the packet burst that is sent to thephysical layer. Note that, in the case where there are nodata packets to send, the eNB sends an empty packet burstwhich simulates the transmission of reference signals.

Finally, no uplink scheduling strategies have been developed.Still, UEs can send packets (routing messages, MAC controlmessages, TPC ACKs, application packets, etc..) over theuplink channel: a packet is forwarded to the physical layerand sent over the uplink channel as soon it is received bythe device.

MAC Control Messages

The class IdealControlMessage provides support for the sim-ulation of generic control messages to be sent over the idealcontrol channel. This class is to be extended in order to im-plement any specific type of control messages. For example,to send CQI feedback as well as PDCCH control informa-tion, two dedicated classes, namely CqiControlMessage andPdcchControlMessage, have been developed.

2.3 Example scenarioIn this section we discuss an LTE simulation setup whichshows how the implemented propagation loss model works2. The scenario is composed by two nodes: a eNB and asingle UE (registered to the eNB). The UE moves into thecell using the ns3::ConstantVelocityMobilityModel, along aradial direction. As for the available radio resources, weuse a bandwidth of 10MHz for both the uplink and thedownlink. The proposed example describes how the chan-nel quality decreases as the distance between UE and eNBincreases. We note that we have analyzed what happens forthe central sub-channel, but identical considerations holdfor all the other sub-channels. Figure 3 shows how the es-timated SINR, the chosen CQI value and the selected TBsize decrease when the UE leaves from the eNB. In otherwords, the total bit rate (in bits per TTI) available to theUE decreases as the distance between nodes increases, asexpected.

3. CONCLUSIONSIn this paper, a novel module for the simulation of the LTEtechnology with the ns-3 simulator has been presented. Dueto high complexity of the LTE technology, the module doesnot includes all the functionalities defined in the standard.However, with the features implemented in this module (i.e.,

2The considered scenario is implemented into the lte-amc.ccfile present into the ns-3-lte branch.

0 100 200 300 400 500 600 700 800 900 10000

10

20

30

40

50

60

70

Distance between UE - eNB [m]

Estim

ate

d S

INR

[d

B]

(a)

0 100 200 300 400 500 600 700 800 900 1000

2

4

6

8

10

12

14

16

Distance between UE - eNB [m]

CQ

I /

MC

S v

alu

es

(b)

0 100 200 300 400 500 600 700 800 900 1000

100

200

300

400

500

600

700

Distance between UE - eNB [m]

Tra

nspo

rt B

lock S

ize

(c)

Figure 3: Estimated SINR (a), Chosen CQI (b), Selected TB size (c) vs distance between UE and eNB.

a basic implementation of LTE devices, RRC, RLC, andMAC entities, PHY layer, and propagation loss models) isjust possible testing several aspects of the LTE networks,such as: RRM and scheduling algorithm, link adaptationtechniques, and downlink physical transmission. In the nearfuture, we plan to add several enhancements including up-link and downlink scheduling strategies, inter-cell interfer-ence and physical error models, ARQ (RLC side) and HARQ(MAC side).

4. ACKNOWLEDGMENTSThis module has been developed as part of the Google Sum-mer of Code (GSoC) 2010 , to which the ns-3 project wasparticipating as a mentoring organization.

5. REFERENCES[1] 3GPP. Evolved Universal Terrestrial Radio Access

(E-UTRA); Medium Access Control (MAC) protocolspecification, 3GPP TS 36.321.

[2] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); Overall description; Stage 2, 3GPP TS36.300.

[3] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); Physical channels and modulation, 3GPPTS 36.211.

[4] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); Radio Frequency (RF) system scenarios,3GPP TS 36.942.

[5] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); Radio Link Control (RLC) protocolspecification, 3GPP TS 36.322.

[6] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); Radio Resource Control (RRC); Protocolspecification, 3GPP TS 36.331.

[7] 3GPP. Evolved Universal Terrestrial Radio Access(E-UTRA); User Equipment (UE) radio transmissionand reception, 3GPP TS 36.101.

[8] 3GPP. Physical layer aspect for evolved UniversalTerrestrial Radio Access (UTRA), 3GPP TS 25.814.

[9] 3GPP. Tech. Specif. Group Radio Access Network;Conveying MCS and TB size via PDCCH, 3GPPTSG-RAN WG1 R1-081483.

[10] S. Ascent. 3GPP LTE toolbox and blockset. [OnLine]Available: http://www.steepestascent.com/content/default.asp?page=s2_10.

[11] N. Baldo and M. Miozzo. Spectrum-aware channel andphy layer modeling for ns3. In Proc. of ICST

VALUETOOLS, Pisa, Italy, Oct. 2009.

[12] E. Dahlman, S. Parkvall, J. Skold, and P. Beming. 3GEvolution HSPA and LTE for Mobile Broadband.Academic Press, 2008.

[13] D. Gonzalez, S. Ruiz, M. Garcia-Lozano, J. Olmos,and A. Serra. System level evaluation of LTE networkswith semidistributed intercell interferencecoordination. In Proc. of IEEE PIRMC 2009, Tokyo,Japan, Sep. 2009.

[14] J. C. Ikuno, M. Wrulich, and M. Rupp. System levelsimulation of LTE networks. In Proc. of IEEE Veh.Technol. Conf., VTC Spring, Taipei, Taiwan, May.2010.

[15] M. A. Ismail, G. Piro, L. A. Grieco, and T. Turletti.An improved IEEE 802.16 WiMAX module for thens-3 simulator. In Proc. of SIMUTools 2010, Mar.2010.

[16] W. C. Jackes. Microwave Mobile CommunicationsNew York. Wiley, 1975.

[17] F. Khang. LTE for 4G Mobile Broadband, AirInterface Technologies and Performance. CambridgeUniversity Press, 2009.

[18] mimoOn. mi!Mobile. [OnLine] Available:http://www.mimoon.de/pages/Products/miMobile/.

[19] G. Piro, L. A. Grieco, G. Boggia, and P. Camarda. ATwo-level Scheduling Algorithm for QoS Support inthe Downlink of LTE Cellular Networks. In Proc. ofEuropean Wireless, EW2010, Apr. 2010.

[20] G. Piro, L. A. Grieco, G. Boggia, F. Capozzi, andP. Camarda. Simulating LTE cellular systems: anopen source framework. IEEE Trans. Veh. Technol.,2010. to be published.

[21] J. Proakis. Digital Communications, IV Edition.McGraw-Hill, 2002.

[22] H. Seo and B. G. Lee. A proportional-fair powerallocation scheme for fair and efficient multiuserOFDM systems. In Proc. of IEEE GLOBECOM,Dallas, TX, USA, Dec. 2004.

[23] C. Wei, Z. Lili, and H. Zhiyi. Second-order statistics ofimproved Jakes’ models for rayleigh fading channelswireless communications. In Proc. of Int. Conf. onNetworking and Mobile Computing, WiCom, pages1108 – 1111, Shanghai, China, Sep. 2007.