On the Evaluation of LTE Random Access ChannelOverload in a Smart City Scenario

Michele Polese, Marco Centenaro, Student Member, IEEE,Andrea Zanella, Senior Member, IEEE, and Michele Zorzi, Fellow, IEEE

Department of Information Engineering, University of Padova – Via Gradenigo, 6/b, 35131 Padova, ItalyEmail: {polesemi,marco.centenaro,zanella,zorzi}@dei.unipd.it

Abstract—Several studies assert that the random access procedureof the Long Term Evolution (LTE) cellular standard may not beeffective whenever a massive number of synchronous connectionattempts are performed by terminals, as may happen in a typicalInternet of Things or Smart City scenario. Nevertheless, simu-lation studies in real deployment scenarios are missing becausemany system-level simulators do not implement the LTE randomaccess procedure in detail. In this paper, we propose a patch forthe LTE module of ns–3, one of the most prominent open-sourcenetwork simulators, to improve the accuracy of the routine thatsimulates the LTE Random Access Channel (RACH). The patchedversion of the random access procedure is compared with thedefault one and the issues arising from massive synchronous accessfrom mobile terminals in LTE are assessed with a simulationcampaign.

This paper was accepted for presentation at the IEEE ICC 2016conference, May 23 - 27, 2016, Kuala Lumpur, Malaysia.

I. INTRODUCTION

A huge increase in fully automated communications betweendevices is forecasted in the next few years as new use cases,e.g., connected cars, e-health, monitoring, are being identi-fied. This new paradigm is called Machine-to-Machine (M2M)communication, since it is performed without any humanintervention, and is considered a fundamental enabler of theInternet of Things (IoT) vision.A desirable requirement for the deployment of Machine-TypeDevices (MTDs) is the place & play concept [1], i.e., MTDsshould just need to be deployed in a certain area to be readyto operate. Indeed, the expected number of devices (40 MTDsper household according to [2]) makes a manual configurationinfeasible. For this reason, the cellular network infrastructureis suitable to provide connectivity for M2M communications,since it can provision (ideally) worldwide, ubiquitous coverage,in contrast to many ad hoc proprietary technologies. However,deploying such a huge number of devices in current cellularnetworks, e.g., the Long Term Evolution (LTE), discloses newissues that need to be addressed. In particular, an importantproblem is the overload of the LTE Random Access (RA)procedure under a massive number of simultaneous connectionattempts, since the LTE standard has been designed to provideaccess to a fairly limited number of terminals.In this paper, we aim at evaluating the delay that a devicemay undergo while accessing an LTE network in the case ofa massive number of access requests in a real deployment.In particular, we address a Smart City scenario using one ofthe most accurate open-source system-level network simulators,i.e., network simulator 3 (ns–3, [3]). We found that the currentimplementation of the RA procedure in ns–3 is idealized;

therefore, we developed a patch to make the routine suitableto study the impact of M2M traffic in LTE networks inurban scenarios. Simulation results show that if a few hundredsmart sensors require simultaneously network access, e.g., toreport some kind of failure event, an MTD would experienceextremely long delays in time to complete the access procedure,thus not respecting the delay constraints of important SmartCity applications, such as alarms.The remainder of the paper is organized as follows. In Sec. II,the random access procedure in LTE is described and issuesrelated to massive access are briefly explained. In Sec. III theimplementation of LTE Random Access Channel (RACH) inns–3 is discussed and its weaknesses are highlighted; then, apatch to the default routine is proposed to enhance the accuracyof the simulator. In Sec. IV the patched routine is comparedwith the default one and is used to evaluate the impact of amassive number of synchrounous access attempts in a realisticSmart Cities scenario. Finally, conclusions are drawn in Sec. V.

II. THE RANDOM ACCESS PROCEDURE IN LTE

The RA procedure in LTE is initiated when a User Equipment(UE) is in the RRC_CONNECTED state1 and has new datato transmit or receive but no uplink synchronization, whenit recovers after radio link failure, when it switches fromRRC_IDLE to RRC_CONNECTED, or, finally, when it performsa handover. The procedure takes place in a dedicated physicalchannel called Physical Random Access Channel (PRACH) [6],which is multiplexed in time and frequency with the PhysicalUplink Shared Channel (PUSCH). The PRACH consists of 6Resource Blocks (RBs) for an overall bandwidth of 1.08 MHzand has a duration between 1 and 4 subframes. Its periodicityis variable and it is defined by the PRACH ConfigurationIndex, which is broadcast by the base station (eNodeB, eNB)on the System Information Broadcast 2 (SIB2) along with thefollowing signaling information:

• numContentionPreambles, i.e., the number ofpreambles reserved for contention-based RA (at most 64);

• preambleInitialReceivedTargetPower, i.e.,the target power (in dBm) to be reached at the eNB fortransmissions on PRACH;

• powerRampingStep, i.e., the power ramping step usedto increase the transmission power after every failedattempt;

1A UE is in RRC_CONNECTED when a Radio Resource Control (RRC)connection has been established; if this is not the case, the UE is in RRC_IDLEstate [4, Sec. 4.2.1].

arX

iv:1

601.

0509

8v2

[cs

.NI]

3 F

eb 2

016

• the maximum number of preamble transmission attempts.We recall that the preamble is a signature composed of a cyclicprefix and a Zadoff-Chu (ZC) sequence that is obtained byshifting a root, which is common to all the UEs connected toa certain eNB. Preambles containing different sequences areorthogonal to one another.2 There are 4 different preambleformats, with duration from 1 to 4 subframes, in order toguarantee coverage of different cell sizes.The RA procedure consists of 4 messages.a) Preamble Transmission: The UE selects a random ZCsequence and transmits a preamble on one of the resourcesspecified by the PRACH Configuration Index. The eNB willdetect the sequence with a peak detector applied on differentwindows of the Power Delay Profile (PDP) of the receivedsignal [6]. However, since the number of ZC sequences is finite,it may happen that more than one UE select the same sequence,thus incurring in a collision. If the colliding UE preamblesare received with high-enough Signal-to-Noise Ratio (SNR),and are sufficiently spaced apart in time, two energy peaksseparated by a time that is longer than the Maximum DelaySpread (MDS) are detected and the eNB will interpret thisevent as due to a collision. On the other hand, if only oneof the colliding preambles is received with high SNR, or thedelay of the different preambles is similar,3 the eNB will notbe able to recognize the collision.We remark that MDS and the preamble detection algorithmare not standardized but left to the eNB vendor. However, the3GPP report [11] requires a miss-detection probability lowerthan 10−2 for an SNR value of −14.2 dB and a 2-antennareceiver in AWGN channel.b) Random Access Response (RAR): The eNB answers tocorrectly decoded preambles (including those with undetectedcollision) by sending the RAR message on the DownlinkShared Channel (DLSCH). RAR carries the detected preambleindex, which corresponds to the sequence sent by the UE,a timing alignment to synchronize the UE to the eNB, atemporary identifier (RNTI), and an uplink scheduling grantthat specifies the resources assigned to the UE to transmit inthe next phase of the RACH procedure. If a UE receives aRAR, then it proceeds with the third step; otherwise, it restartsthe RA procedure anew (unless it has reached the maximumnumber of preamble transmission attempts) after a backoff timethat is uniformly distributed in the interval [0,BI], where BIis the Backoff Indicator carried by the RAR. If the counter ofconsecutive unsuccessful preamble transmissions exceeds themaximum number of attempts, a RA problem is indicated toupper layers.c) Connection Request: The UE transmits a Radio ResourceControl (RRC) message containing its core-network terminalidentifier in the uplink grant resources and starts a ContentionResolution timer. Note that the UEs that transmitted the samepreamble but whose collision remained undetected will transmiton the same resources, colliding again.d) Contention Resolution: If the eNB correctly receives theRRC message, it replies with an RRC Connection Setup that

2For eNBs with a large coverage area there may be more than one rootsequence. However the sequences obtained have low cross-correlation [5].

3This is typical in Small Cells scenarios [6].

532 F.J. López-Martínez et al. / Digital Signal Processing 22 (2012) 526–534

Table 3PRACH missed detection requirements for normal mode.

Number of Propagation Burst 0 Burst 1 Burst 2 Burst 3RX antennas conditions (FO)

2 AWGN (0 Hz) −14.2 dB −14.2 dB −16.4 dB −16.5 dBETU70 (270 Hz) −8 dB −7.8 dB −10.0 dB −10.1 dB

4 AWGN (0 Hz) −16.9 dB −16.7 dB −19.0 dB −18.8 dBETU70 (270 Hz) −12.1 dB −11.7 dB −14.1 dB −13.9 dB

Fig. 8. MDP vs SNR. 2 antennas, AWGN.

Fig. 9. MDP vs SNR. 4 antennas, AWGN.

Fig. 10. MDP vs SNR. 2 antennas, ETU70.

Figure 1: Pmiss vs SNR Γ, taken from [14].

signals to the UE that the RA phase is successfully completed.Instead, if the Contention Resolution timer expires, the UErepeats the RA procedure from the beginning after a randombackoff time. Again, when the number of unsuccessful attemptsreaches the maximum value, the network is declared unavail-able by the UE and an access problem exception is raised tothe upper layers.

Massive Access Threats

The LTE RA process is efficient if a small number of de-vices requires access to the network, which is the typicalcase for Human-to-Human (H2H) traffic. However, the num-ber of terminals is envisioned to grow exponentially in IoTscenarios, especially for what concerns Smart Cities wheresmart meters will be deployed to monitor a large variety ofparameters, from air pollution to supply levels. In the case ofextraordinary events, e.g., power outages, many MTDs maybe activated simultaneously, thus, causing a PRACH overload.The consequences are that the constraints of delay-sensitiveM2M applications can be violated, the power consumption ofsensors is increased, and the Quality of Service (QoS) of H2Happlications can be degraded.In this paper we aim at evaluating how this massive event-triggered reporting may impact the LTE network performancein a Smart City scenario using a well-known open-source net-work simulation tool, i.e., ns–3, written in C++, which is partic-ularly suitable to simulate an urban propagation environment.In fact, other open-source simulation platforms are available,e.g., the LTE Vienna Simulator [9], programmed in Matlab,Omnet++ [8], and LTE-sim [7], both written in C++. However,they cannot be used for our purposes. Indeed, the ViennaSimulator is a link level simulator in the uplink, thereforecannot be used to model a network of MTDs; Omnet++ andLTE-sim, instead, provide a naive and idealized abstraction oflower layers, focusing rather on higher layers.

III. LTE RACH IN NS–3

In this section the LTE RACH implementation in ns–3 is ad-dressed and an enhancement to evaluate IoT traffic is proposed.We refer to the version 3.23 of the ns–3 simulator, whichmakes use of the LTE-EPC Network simulAtor (LENA) [10]module to simulate the LTE protocol stack and the EvolvedPacket Core (EPC) network. In the current implementation ofLENA, however, the RACH preamble is an ideal message,i.e., not subject to radio propagation; moreover, Connection

Parameter Value

Downlink carrier frequency 945 MHzUplink carrier frequency 900 MHz

RB bandwidth 180 kHzAvailable bandwidth 50 RBHexagonal sectors 1

eNBs for each sector 3 (co-located)eNBs beamwidth (main lobe) 65◦

TX power used by eNBs 43 dBmMax TX power used by MTDs 23 dBm

eNB noise figure 3 dBMTD noise figure 5 dB

Shadowing log-normal with σ = 8Number of buildings 96

Apartments for each floor 6Floors for each building 3

MTD speed 0 Km/hNumber of MTDs N {50, 100, 150, 200, 300, 400, 500, 600}Simulation time ∀N {60, 60, 120, 120, 300, 300, 400, 400} s

Table I: Simulation parameters [2].

Parameters Value

PRACH Configuration Index 1Backoff Indicator BI 0 ms

preambleInitialReceivedTargetPower −110 dBmpowerRampingStep 2 dB

numContentionPreambles 54Contention resolution timer 32 ms

Table II: Parameters of LTE RACH.

Request and Connection Resolution messages are not modeledand, therefore, all collisions are detected and solved at the firststep of the RA procedure. Furthermore, we found that it isnot possible to simulate the connection and disconnection ofUEs during runtime, since LENA allows every UE to switchonly once from RRC_IDLE to RRC_CONNECTED states atthe beginning of the simulation. Therefore, we implementeda more realistic RA procedure, along with the possibility todisconnect UEs from the eNB (i.e., switching from RRC_IDLEto RRC_CONNECTED and viceversa). The enhanced module iscalled LENA+.4 However, to maintain the backward compati-bility with current release, an option has been introduced to usethe idealized LENA RA procedure if desired. In the following,the details of our implementation will be discussed.

PRACH Characterization

PRACH is implemented as a real physical channel, relying onthe already developed and tested channel model. Nonetheless,PRACH preambles are now subject to noise and radio prop-agation, since they are sent on specific time and frequencyphysical resources, and therefore the eNB can fail their de-tection. We remark that only format 0 of PRACH preamblesis implemented. Whenever a UE starts the RA procedure,it checks whether it has received SIB2 and has configuredRACH. Then, it chooses a random index drawn uniformlyin [0, numContentionPreambles] and transmits it in thenext PRACH opportunity. Note that we are assuming that, in aPRACH-dedicated subframe, no PUSCH traffic is allocated by

4The source code is available at https://github.com/signetlabdei/lena-plus.

0

50

100

150

200

250

0 50 100 150 200 250 300 350 400

Y [m

]

X [m]

Figure 2: Smart City network deployment example. The rect-angles are the buildings, the small triangles are the MTDs, andthe black square is the position of the three co-located eNBs.

the scheduler, while the PRACH is allocated in the first 6 RBsavailable. The power (in dBm) for the transmission is computedaccordingly to the standard [12]:

Pprach = min{PUE,max,

PREAMBLE_RECEIVED_TARGET_POWER + Plc}(1)

where PUE,max is the maximum transmit powerfor a UE, Plc is the estimated pathloss andPREAMBLE_RECEIVED_TARGET_POWER is given bythe MAC layer, as [13]:

PREAMBLE_RECEIVED_TARGET_POWER =

preambleInitialReceivedTargetPower

+ ∆preamble + (PREAMBLE_TX_COUNTER− 1)

× powerRampingStep

(2)

where PREAMBLE_TX_COUNTER is the number of consecu-tive preamble transmissions and ∆preamble = 0 for format 0preamble. The other parameters are given by the eNB withSIB2, as explained in Sec. II. At the eNB side, the SNRis computed for each preamble and a decision on correct ormissed detection is taken. In [14] different eNB detectionalgorithms are introduced and evaluated in terms of miss-detection probability Pmiss vs SNR Γ at the receiver. The miss-detection probability performance of the algorithms is reportedin Fig. 1. Note that our improved PRACH model for ns–3assumes a time domain detector with decimation (LT), which isthe simplest algorithm which satisfies the 3GPP requirementsin [14], as can be seen from Fig. 1. The ns–3 LTE module hasalso been modified, in order to handle the reception of multiplesignals in the same time and frequency resources. Indeed, thedefault implementation raises an exception whenever two ormore signals are received in the same time and frequencyresources by the eNB, since the MAC scheduler forbids mul-tiple transmissions in physical channels other than PRACH.In PRACH, indeed, transmissions cannot be scheduled and theZC sequences allow multiple access by Code Division MultipleAccess (CDMA). If a preamble is correctly received but thereare two or more preambles with the same ZC sequence, thenthe collision is either detected or not according to the following

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(a) N = 100

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(b) N = 200

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(c) N = 300

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(d) N = 400

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(e) N = 500

10−2 100 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

LENALENA+

(f) N = 600

Figure 3: ECDFs of access delay for N ∈ {100, 200, 300, 400, 500, 600}. The x-axis is expressed in logarithmic scale.

heuristic. Since the PDP of different users is not simulated ina system-level simulator such as ns–3, as a rule of thumb acollision is detected if

|dmax − dmin|c

> Tchip (3)

where dmax and dmin are the distances from the eNB of thefarthest and closest colliding UE, respectively, c is the speedof light, Tchip = 1/(2B), and B = 1.08 MHz is the bandwidthof PRACH.RAR message transmission was already implemented as amessage on the DLSCH. For each not-collided preamble orundetected collision, an uplink grant is allocated by the sched-uler and added to the RAR response; the Backoff indicator hasalso been added.Connection Request transmission on granted resources wasalready implemented, as well. However, since in the default im-plementation of RACH all the collisions are resolved at the firststep, collisions of messages 3 were not handled and raised anexception. This exception has been handled as follows. Firstly,no capture effect has been considered. Then, if two or moreConnection Request messages collide, they are considered asreceived with errors, triggering an HARQ retransmission untilthe maximum number of attempts is reached. The ContentionResolution timer has also been added.

IV. PERFORMANCE EVALUATION

In this section the enhanced version of the LENA module isevaluated and compared with the current release. Moreover,

we will use our module to evaluate the impact of massivesynchronous accesses to an LTE network in a Smart Cityscenario.The scenario we simulated is compliant with the specificationsin [2]; the main simulation parameters are in Tab. I, while theRACH-related parameters can be found in Tab. II. We refer toan urban environment with a high density of tall buildings; thedeployment of buildings and MTDs is depicted in Fig. 2. Forwhat concerns the radio propagation model, we employed thens–3 Hybrid Buildings Propagation Loss Model, which exploitsdifferent propagation models to account for several factors,such as the position of the UE and the eNB (both indoor, bothoutdoor, one indoor and the other outdoor), the external wallpenetration loss of different types of buildings (i.e., concretewith windows, concrete without windows, stone blocks, wood),and the internal wall penetration loss. We remark that allthe MTDs have been placed inside the buildings and theirpositions are not changed during the simulation according tothe specifications found in [2].Let us denote with N the number of MTDs that are tryingto simultaneously access the LTE network. For every valueof N ∈ {50, 100, 150, 200, 300, 400, 500, 600}, 10 Montecarlosimulations have been run and the Empirical Cumulative Dis-tribution Functions (ECDFs) of the access delays have beenproduced. Fig. 3 shows the ECDFs of the delay (in logarithmicscale) for the various values of N , obtained using both thedefault LENA module and the LENA+ module. We remark that,for what concerns the LENA+ performance curves, the ECDFs

10−2 10−1 100 101 1020

0.2

0.4

0.6

0.8

1

Delay [s]

EC

DF

50

100

150

200

300

400

500

600

Figure 4: ECDF for various values of N . The x-axis isexpressed in logarithmic scale.

0 2 4 6 8 100

20

40

Time [s]

Succ

essf

ulR

AC

HA

ttem

pts

50

100

150

200

300

400

500

600

Figure 5: Successful RACH attempts vs time.

of the single Montecarlo simulations are represented with thedashed lines, while the average ECDF is shown in solid line.It can be seen that the idealized RACH implemented in LENAgives quite unrealistic results, as all the MTDs succeed incompleting the RA procedure in less than 1 s for all the valuesof N . The simulations that have been carried out using LENA+,instead, show that, as N grows, the access delay increases, up tohundreds of seconds for most MTDs, which is not acceptablefor many delay-constrained Smart City applications, such asalarms. Moreover, using our module, we are able to observe thatsome UEs (approximately 5% of the total in each simulation)do not succeed in completing the RACH procedure before thesimulation time expires, due to their unfavorable position inthe scenario, e.g., inside buildings which are far away from theeNB, although the number of preamble transmission attemptsis not upper bounded in this simulation campaign.Focusing on the dotted curves of these figures, which repre-sent the ECDF of the single simulation runs, we notice that,considering the logarithmic scale, the spreading of the bundleof curves around the average ECDF increases for N ≥ 300,meaning that the system performance tends to become moreerratic. We want to remark that the slope of the ECDF curvesremains constant in the logarithmic domain as N increases,as shown in Fig. 4, therefore in the linear domain the curvesbecome less and less steep.Finally, Fig. 5 represents the number of successful RACHattempts vs time for different values of N . Note that, as Nincreases, the maximum number of successful RACH attemptsdecreases, and is achieved later in time, as a consequence

of the higher number of collision events. For N > 300, wecannot observe any meaningful peak, denoting that the RACHis congested and the success probability is very low.

V. CONCLUSION

The implementation of a more realistic model of the LTERACH procedure in the network simulator ns–3 has been pro-posed and evaluated in a Smart City scenario. The simulationresults show that the default release of the LENA moduleunderestimates the impact of M2M traffic in cellular networksand confirms the concerns about LTE RACH overload in caseof massive simultaneous access attempts. As part of our futurework, we will implement and test the effectiveness of someof the strategies proposed in [1] to tackle the RACH overloadusing our enhanced ns–3 LENA module, called LENA+.

REFERENCES

[1] A. Biral, M. Centenaro, A. Zanella, L. Vangelista, and M. Zorzi, “Thechallenges of M2M massive access in wireless cellular networks,” DigitalCommunications and Networks, Vol. 1, Issue 1, pp. 1-19, Feb. 2015

[2] 3GPP, “Cellular System Support for Ultra Low Complexity and LowThroughput Internet of Things,” TR 45.820, V. 1.3.1, June 2015

[3] https://www.nsnam.org[4] 3GPP, “Radio Resource Control (RRC) – Protocol specification,” TS

36.331, V. 12.6.0, June 2015[5] M. Amirijoo, P. Frenger, F. Gunnarsson, J. Moe, K. Zetterberg, “On

self-optimization of the random access procedure in 3G Long TermEvolution,” in Proceedings of the IFIP/IEEE International Symposiumon Integrated Network Management-Workshops, pp. 177-184, June 2009

[6] P. Bertrand and J. Jiang, “Random Access,” in S. Sesia, I. Toufik, and M.Baker (editors), “LTE – The UMTS Long Term Evolution: From Theoryto Practice,” John Wiley & Sons, pp. 421-457, 2009

[7] G. Piro, L. A. Grieco, G. Boggia, F. Capozzi, and P. Camarda, “Sim-ulating LTE Cellular Systems: An Open-Source Framework,” in IEEETransactions on Vehicular Technology, Vol. 60, No. 2, pp. 498-513, Feb.2011

[8] A. Virdis, G. Stea, and G. Nardini, “SimuLTE - A modular system-levelsimulator for LTE/LTE-A networks based on OMNeT++,” in InternationalConference on Simulation and Modeling Methodologies, Technologiesand Applications (SIMULTECH), pp. 59-70, Aug. 2014

[9] J. Blumenstein, J. Ikuno, J. Prokopec, and M. Rupp, “Simulating thelong term evolution uplink physical layer,” in Proceedings ELMAR, pp.141-144, Sept. 2011

[10] N. Baldo, M. Miozzo, M. Requena, J. Nin Guerrero, “An Open SourceProduct-Oriented LTE Network Simulator based on ns-3,” in Proceedingsof the 14th ACM International Conference on Modeling, Analysis andSimulation of Wireless and Mobile Systems (MSWIM), pp. 293-298,Nov. 2011

[11] 3GPP, “Base Station (BS) radio transmission and reception,” TS 36.104,V. 13.0.0, July 2015

[12] 3GPP, “Physical layer procedures,” TS 36.213, V. 12.6.0, June 2015[13] 3GPP, “Medium Access Control (MAC) protocol specification,” TS

36.321, V. 12.6.0, June 2015[14] F. J. López-Martínez, E. del Castillo-Sánchez, E. Martos-Naya, J. Tomás

Entrambasaguas, “Performance evaluation of preamble detectors for3GPP-LTE physical random access channel,” Digital Signal Processing,Volume 22, Issue 3, pp. 526-534, May 2012