LTE - FDD Planning &

Dimensioning

1
Change Control
Version Author Date Change Description
Draft A Pinaki Roychowdhury 26/09/16
• Some additional information in the Base-band section
Draft B Pinaki Roychowdhury 12/10/16
• Appendix sections added with information on Capacity Monitoring
• Executive Summary Section Added
• Link-Budget section updated with the GCTO Link-budget
• Detailed technical information in some sections moved to Appendix
Issue 1 Pinaki Roychowdhury 11/11/16 sections in the end
• Included vendor specific Parameters & KPIs details for the all the
relevant sections

Issue 1.1 Pinaki Roychowdhury 21/11/16 • Minor changes to the Link-Budget section
Issue 2.0 Pinaki Roychowdhury 14/02/17 • Huawei Specific details added

2
Objective
• LTE Traffic is expected to grow significantly from 2017 onwards and the hence the objective
of the slides is the following…..

 To provide an overview of the planning and dimensioning areas for the LTE-FDD

 To provide recommendations for each key areas

 To provide Capacity Planning Guidelines

• This document is expected to be updated with the nB-IoT aspects in 2017

• A separate version will be issued later on for LTE-TDD

3
Contents (I)
• Section 1 - Executive Summary
• Section 2 – Air Interface Dimensioning(Link-Budget, Coverage Planning Thresholds, Cell
Range etc.)
• Section 3 - Modelling the Traffic Demand & Site Count
• Section 4 - Base-band Dimensioning (C-Plane, Cells, Users & Throughput)
• Section 5 - Control Channel Dimensioning (UL & DL)
• Section 6 - Key Procedures - Paging (DL), Random Access (UL)
• Section 7 - Tracking Area Planning & Dimensioning
• Section 8 - Miscellaneous Planning Areas (eNB Identity, Neighbour etc.)
• Section 9 - VoLTE Simulations & VoLTE Impact Assessment
• Section 10 - Hot-Spot Capacity Analysis & Dimensioning
• Appendix Sections
4
Document Structure

• For each of the topics listed in the Contents slide, there are guidelines for the most
important topics of that section

• For each section there is a relevant Appendix section which has more details and some
additional information

• Wherever applicable vendor specific details have been provided.

5
01 Executive Summary

6
Dimensioning Process – High Level Overview
STRATEGIC DIMENSIONING
• Long Term High level • Detailed Engineering Rules
Network Dimensioning for
defining network
infrastructure required in
order to plan investment
to support strategic
network decisions
• This process maps the
relationship between the
overall Mobile Data
Network Capacity and the
Mobile Broadband Traffic
demand and also evaluates
the impact of introducing
VoLTE
NETWORK PLANNING REACTIVE DIMENSIONING
• Detailed Engineering
for network dimensioning Process for Short Term Site
& planning for the Upgrades based on the
following areas following bottlenecks
 eNB Base-band
• Control Channels
 Air-Interface Control • Paging Capacity
Channel Dimensioning • Random Access
 Air-Interface Procedure
Capacity
Dimensioning (Paging &
• User Experience
Random Access)
 Miscellaneous Areas
(Tracking Area Planning,
Neighbours, eNode B
and Cell Identity)
 Impact of VoLTE
7
Dimensioning & Planning– Key Areas
• Link- Budget & Initial Site Count
• Traffic Modelling & Site Upgrades
• e NodeB Base-band
• Control Channels
• Paging (DL) & Random Access (UL)
• Miscellaneous Planning Areas (PCI, RSI
etc.)
• VoLTE Readiness..
• Hot-Spot Capacity Upgrades Process for
short term capacity alleviation
8
Strategic Dimensioning
Initial site Count based on
planned service & Site Upgrade
count based on existing network
trends & traffic forecast
Network Planning
Dimensioning Guidelines to arrive
at a base-line capacity
Reactive Dimensioning
Reactive measures to counter the
capacity issues in the short term
Strategic Dimensioning – Link Budget
• The first step is going through the link budget process based on the defined DL & UL
aspirational services.
• Why is it important? – The output of the Link-Budget
provides the Coverage Planning Thresholds which in
turn will provide the initial site count for the planned
services
• The Link-Budget will also take into account the
impact of introducing VoLTE in the LTE network
• Document Output

 Updated GCTO Link-Budget with Target services as DL

1 Mbps & UL 100 Kbps

 Impact of Introducing VoLTE

9
Strategic Dimensioning – Traffic Modelling (I)
• Following the initial site count numbers, number of site upgrades and new site
requirements need to be estimated
• The first step in this direction is Traffic Forecasting. Telefónica OBs need to define a traffic
forecasting process which needs to take into account for example the following…
 Traffic Demand Forecast – What the OBs expect the customers to use from the contracted
demand or in other words a forecast of the network capacity required
 Traffic Supply Forecast – Primarily dependant on Network Build targets. Telefónica UK Example

• Voice and Data should be forecasted separately but usually Data is the dominant part of the
forecast as voice growth is slower and SMS is declining with APPs like WhatsApp etc.
10
Strategic Dimensioning – Traffic Modelling (II)
• Once the Annual Traffic Forecasts are in place we need to translate this into number of site
upgrades and new site requirements for each year.
• Flow chart below captures the concept. Currently ongoing work to finalise this aspect

Traffic Spectral Efficiency

Annual BH DL Traffic LTE Bands Deployed on site
Demand 5 MHz 10 MHz 15 MHz 20 MHz
Data Forecast Distribution

Spectral Efficiency
per Site Cell
5 10 15 20
Throughput
Mbps Mbps Mbps Mbps
(Mbps)
Site
12.5 25 37.5 50

Distribution
Throughput
Mbps Mbps Mbps Mbps
Traffic
(Mbps)

Annual BH
VoLTE Traffic Site New
Voice VoLTE Offload
Forecast Upgrades Sites
Forecast
11
Network Planning – Base-Band & Control Channels
• Dimensioning and Planning guidelines for the Base-band HW, UL & DL Control Channels
• Base-Band Hardware
 Control Plane Load or Processing Capacity
 Licensed User Numbers & Throughput
 Number of Cells
• Control Channels
 DL Control Channels
 PHICH – Needed for ACK/NACKs for UL data
 PDCCH – Needed for Scheduling Paging,
Random Access Response, SI, DL & UL data
RF
including VoLTE (voice & IMS signalling)
 UL Control Channels Base-Band
 PRACH – Initial Access & Handover
 PUCCH – Scheduling Requests, ACK/NACK for
DL Data, CQI
12
Network Planning – Paging, Random Access etc.
• In addition to the control channels, Dimensioning activity also needs to be carried out for
the following procedures
 Paging – Key Points
 Paging Requests/Message – Channel BW dependant
 TAC Planning – TAC size
 Different MME Paging Profiles – MME feature
 Paging sub-frame repetition
 Random Access Procedure – Key Points
 CBRA & CFRA pool sizes
• Apart from this, the planning rules are needed for the following for optimum performance
 Physical Cell ID
 Root Sequence Index – Linked to Cell Range
 PRACH Frequency Offset
 Miscellaneous – eNB & Cell Identity, Neighbours
13
Reactive Dimensioning – Short Term Upgrades (I)
• Apart from the Network Strategic Dimensioning which is cater for Long Term Traffic Growth,
there is also a need for reactive process to cater for the traffic growth in the short term
Trigger Areas Possible Remedial Measures
Control Channel Capacity Capacity Increase in the domain of PUCCH (UL), PRACH (UL) & PDCCH (DL)

Control Plane Capacity Trigger C-Plane Overload handling measures

Connected Users With the new commercial agreements with the vendors, the license
aspects will hopefully not be an issue. Process still required to optimise
Throughput the parameters based on traffic requirements

Paging Capacity TA Size increase, Increasing Paging Capacity, Separate Paging Profiles etc.

Random Access Capacity > 1x PRACH, Optimising the Pool sizes for CBRA & CFRA etc.

Average User Experience Only an approximation as no direct measure available from counters
14
Reactive Dimensioning – Short Term Upgrades (II)
• In terms of the process, each metric will have a baseline design and a few upgrade steps
• There will be a trigger criteria associated for the upgrade which will be based on a
combination of vendor specific Counters & Parameters
• Once the final upgrade step has Baseline Trigger Upgrade
been reached and thereafter there is Design Criteria
Step 1
still further increase in traffic then Monitor Monitor
Trigger Criteria
other options need to be considered
viz.
Final Upgrade
 Tactical Options Trigger
Upgrade Criteria Step 2
 Aggressive Traffic Balancing
 Down-Tilting
 Features Monitor

 New Site

15
02
Air-Interface Dimensioning
(Link-Budget)

16
 Air-Interface Dimensioning Process
• Air-Interface dimensioning involves several successive steps which are categorised in the
picture and is referred to as Link Budget
General Equipment
• The output of the air-interface Parameters Parameters
dimensioning should be the following
 Maximum Path Loss Propagation
Parameters Maximum Path Loss User Service
 Cell Range
 Inter-site Distance
• The air-interface dimensioning is based Propagation
Cell Range
Prediction
on a minimum Cell Edge Throughput
Requirement for UL & DL
• It allows the calculation of maximum cell Network
Inter-site Distance
Configuration
range & the inter-site distance and also
the planning thresholds for the planning
tool
17
LTE FDD Operating Bands UL Frequencies DL Frequencies
Band
Lowest Highest Lowest Highest
• From the Link-Budget perspective and its 1 1920 1980 2110 2170

2 1850 1910 1930 1990

accuracy, the uplink and the downlink
3 1710 1785 1805 1880
calculations should be performed using the 4 1710 1755 2110 2155

same frequency band 5 824 849 869 894

6 830 840 875 885

• Only the centre frequencies need to be 7 2500 2570 2620 2690

considered for the link budget calculations 8 880 915 925 960

• In the case of Band 4 or Band 10

9 1749.9 1784.9 1844.9 1879.9

10 1710 1770 2110 2170

(AWS:1700/2100) it is recommended that 2 11 1427.9 1452.9 1475.9 1500.9

separate link-budget scenarios for Uplink 12 698 716 728 746

13 777 787 746 756

and Downlink be performed and then 14 788 798 758 768
consider the Minimum Allowed Path Loss 17 704 716 734 746

values 20 832 862 791 821

18
Channel Bandwidth Configurations
• Scalable bandwidths is one of the biggest advantages of the LTE- Air interface.
• E-UTRAN can operate in a channel bandwidth which ranges from 1.4 MHz to 20 MHz
• Telefónica OBs will be able to implement E-UTRAN exploiting this bandwidth scalability in
case of limited frequency resources. Scalability also allows the migration of spectrum from
lower generation systems like GERAN and UTRAN in incremental steps of small bandwidths
BW (MHz) 1.4 3 5 10 15 20
PRBs 6 15 25 50 75 100

Sub-Carrier
15 KHz
Spacing

• Physical Resource Block (PRB) is an allocation unit of the OFDMA (DL) and SC-FDMA (UL)
resources in the time and frequency domain the size of which depends on the cyclic prefix
in use and also the sub-carrier spacing
19
Link – Budget Process (I)
• The Link-Budget calculations, detailed explanations and examples are highlighted in
Appendix I
• Embedded is the revised GCTO Link-Budget which should be used by OBs

• GCTO recommends that for official reporting purposes (towards the “Informe de
Gestion”, OBs should use a DL service of 1 Mbps. The real design can be done as per the
requirements in each OB taking into account the competitive situation
• For the above services, using the Link-Budget firstly it is necessary to compute the
Maximum Allowed Path Loss (MAPL).
• Based on the MAPL and the propagation model selected, the coverage planning
threshold can be ascertained. For example a planning threshold of -85 dBm coverage
level for on-street coverage
20
Link – Budget Process (II)
• This output needs to be fed into ATOLL for site planning purposes
• For VoLTE the same Link-Budget calculations can be used. The only change required is the
SINR values
• VoLTE being a lower bit rate service (albeit with higher SINR requirements), the link-budget
calculations should not pose any additional challenges. Below is an example of the L800
cell with 1 Mbps (DL) and 100 kbps (UL). It is UL limited case with 500m coverage. It can be
observed that VoLTE can be supported in the cell for about 545m

21
 Modelling the Traffic

03 Demand & Future Site

Builds/Upgrades

22
Introduction
• Following on from the Link-Budget process which provides the initial site count, there needs
to be a traffic modelling process in place which provides an estimate of the number of site
upgrades and new site build required in the following years which also needs to be
calibrated with the CAPEX spend
• The most important input to this modelling process is the Annual Traffic Demand Forecast
• Robust processes are needed to forecast the Voice and Data Traffic separately for the
network
• Impact of Introduction of VoLTE also needs to be taken into consideration
• GCTO are currently working in parallel to fine tune this traffic modelling process for 4G.
• This section provides a high level overview of the key concepts of Traffic Forecasting &
Traffic Modelling in general
• Appendix II contains Telefónica UK specific details of the Traffic Forecasting (Voice & Data)
and also the Traffic Modelling Process in use at the moment
23
Key Concepts - Radio Capacity
• 3 Key Questions need to be answered viz.

 What is the definition of 4G Capacity?

 What is the capacity of the existing 4G network?

 What should we be planning for?

 Short Term Measures – This will be covered in Section 10

 Long Term Measures – Based on long term traffic demand and covered in this section

24
Key Concepts - System Capacity Definitions
• 4G Data
 Average DL User Throughput
 Average DL Cell Throughput
 Latency
 Packet Loss

• 4G voice
 Erlangs
 Users

25
Average DL User and Average DL Cell Throughput
• Of all the metrics for 4G data, Average User Throughput is most indicative and most
pertinent to gauge the user experience in a cell
• Average User Throughput is the average measured over the entire cell. Therefore it is
possible that users located at cell edges may consistently experience low user throughputs
although the Average User Throughput metric might still be meeting the criterion
• Although Average User Throughput is a good measure, the measure from network counters
is always not very intuitive especially in smart-phone dominant networks
• Average Cell Throughput is an indication of Cell Capacity
• In general as we increase the number of users in a cell*
• Average User Throughput should decrease
• Average Cell Throughput should increase**
*More details on the impact of increasing users captured in the section 10
** In some cases it has been observed decreasing number of users has not impacted the Average Cell Throughput as the fewer users download
more data 26
4G Cell/Site Capacity 5 MHz
• Rule of Thumb for Capacity Limits – 1bps/Hz from
simulations
 5 Mbps for a 5 MHz RF Carrier(12 Mbps for a 3
sectored site)
 10 Mbps Target for a 10MHz RF Carrier (25 Mbps
for 3 sectored site)
 20 Mbps for a 20 MHz RF carrier (50 Mbps for a 3
10 MHz
sectored site)

20 MHz

27
Traffic Forecasting Process
• Telefónica OBs need to define a traffic forecasting process which needs to take into account
for example the following…
 Traffic Demand Forecast – What the OBs expect the customers to use from the contracted
demand or in other words a forecast of the network capacity required
 Traffic Supply Forecast – This is probably a bit theoretical and is primarily dependant on what the
OB have budgeted to build or in other words Network Build Targets
 Long Term Plan – Possibly 3 or 4 year plans used for forecasting usually with an update every year
• Typically Supply < Demand (but not by much as otherwise
it will be inefficient)
• Voice and Data should be forecasted separately but
usually Data is the dominant part of the forecast as voice
growth is slow and SMS is declining with APPs like
WhatsApp etc.
• Impact of VoLTE needs to be considered as well
28
Voice Planning & Forecasting
• Voice Traffic should be predictable at a network level and more often than not it grows
slowly
• The prime factors that influence voice traffic forecasts come from customer number
forecasts (which can be derived from the long term plan) & historical voice growth rates.
Inputs should also be taken from the MVNOs if applicable
• Voice Forecasting should be split across the different network layers. In theory this could be
a function of device capability and network pop coverage by network layer. For example in
Telefónica UK network in London, from the device capability and the predicted 3G & 4G
coverage, it would appear that ~90% of voice should be on 3G network but in reality only
~60% is on the 3G network which would seem to suggest that the effective 3G layer for
coverage is substantially lower. (ISHO to 2G – 20% of Voice RABs)
• Overall though voice is increasingly only a small proportion of the network load. Main
dominance of voice is on the 2G network (going forward should be reduced)
• Impact of VoLTE would need to be factored as well
29
Data Planning & Forecasting
• Data Planning and forecasting is much more complex with data traffic expected to grow
much more rapidly than voice. Example shown for Telefónica UK network
• In reality supply maybe different from demand
and if so i.e. supply < demand then it is likely that
the achievable traffic will be less than the demand
forecast
• In general decisions can be made as part of the
long term forecasting and Network Build Targets
for every year can be arrived at.
• This is mostly based on finance approval on a
maximum envelope of costs and also on the TEF UK network
regulatory requirements and other contractual breakdown of
requirements like Network Sharing agreements data usage
etc.
30
Impact of VoLTE on CS Voice Traffic - I
• The impact of VoLTE on the 4G network and the
subsequent offload of CS Voice traffic from the
3G/2G networks needs to be evaluated as well
• There is a lot dependencies on the traffic offload
to VoLTE like device penetration, 4G coverage,
VoLTE tariffs etc.
• The example in the embedded workbook tries to
capture the aspects and presents an example of
how it can be done
• This is based on the Voice Traffic forecasts and
other inputs like 4G site build program, VoLTE
Device Penetration, VoLTE Tariffs etc.

31
Basic Traffic Modelling Process
• Once all the Annual Traffic Forecasts are in place we need to translate this into number of
site upgrades and new site requirements for each year.
• Flow chart below captures the concept. Detailed work in progress at the moment

Traffic Spectral Efficiency

Annual BH DL Traffic LTE Bands Deployed on site
Demand 5 MHz 10 MHz 15 MHz 20 MHz
Data Forecast Distribution

Spectral Efficiency
per Site Cell
5 10 15 20
Throughput
Mbps Mbps Mbps Mbps
(Mbps)
Site
12.5 25 37.5 50

Distribution
Throughput
Mbps Mbps Mbps Mbps
Traffic
(Mbps)

Annual BH
VoLTE Traffic Site New
Voice VoLTE Offload
Forecast Upgrades Sites
Forecast
32
Traffic Forecasting & Modelling Summary
• There should be a Traffic Modelling Process in place to meet the needs of the traffic growth
in the long term. To cater for the traffic growth in the short term we need to have Reactive
Processes which is covered in Section 10
• The key input to this process is the Annual Traffic Demand Forecast
• Voice and Data Traffic demand should be forecasted separately based on past trends and
also on future strategy and propositions. Impact of VoLTE traffic offload must be carried out.
• From this forecasted traffic we need to calculate the un-carried/unserved traffic with the
current network build
• The unserved traffic (and the available LTE bands for deployment) provides the number of
site upgrades required and the new site requirements. This of course needs to be calibrated
with the CAPEX spends
• GCTO is currently working to fine tune this process for 4G
• Telefónica UK process for Traffic Modelling is captured in Appendix II
33
04 Base-band Dimensioning

34
Introduction
• The snapshot below provides a general concept of base-band dimensioning
• Whilst the offered traffic can be derived from the respective selected traffic model, the
served traffic determines what can be handled from a system perspective
• It refers to system specifics (vendor specific) which determine various factors.
System
Traffic Point of
Model view

User Plane Offered Served

 BH Throughput Traffic Product
Traffic Specification
 Data Volume
 BH Throughput
 Data Volume

Control Plane
Base-band Limits
 Handovers
 Connected Users
 TA etc.
 Peak
Connected Users Throughput etc.

35
Base-band Module – Key Dimensioning Aspects
• Generally speaking the system module (base-band) connects the RAN segment with the EPC
via the S1 interfaces.
• It also provides the X2 interfaces across to neighbouring e Node Bs
• It is a very essential and fundamental part of the e Node B which processes user plane and
control plane traffic (for example – admission control, mobility etc.)
• Key Dimensioning aspects which need to be considered (vendor agnostic)
 Control Plane Dimensioning or Processor loading
 Number of supported cells per System Module
 Different MIMO Order (typical deployments - 2x2 MIMO), Spectrum Bandwidth, Operating Bands, UL Receive Paths (typical
deployments – 2Rx), etc.

 Peak Throughput
 Connected Users
• In the following slides the above have been discussed for the 2 main vendors in the
Telefónica fold i.e. NOKIA & ERICSSON. Huawei
36
details will be added later on
Control Plane Loading – Introduction
• LTE has a flat network architecture i.e. there is no longer a concentrator/aggregator element
in the RAN like the BSC and RNC. In the 2G/3G networks, the traffic modelling and
dimensioning is focussed on the BSC and RNC
• Additionally in 2G/3G networks, statistical approaches based on user behaviour could be
easily applied since rather high number of base-stations created a kind of averaging or
resource multiplexing from the BSC/RNC perspective
• In LTE networks, this modelling and dimensioning has to be eNB based and hence the
location of the eNB is very important as well.
• eNB Control Plane Capacity dimensioning is dependant on the data traffic model we select
i.e. whether it is bursty traffic or full buffer traffic which usually defines the average e Node
B busy hour Control plane load.
• For some vendors Control Plane load/capacity is measured in terms of
“Transactions/second” where a transaction can be Paging, TAU, Call Attempts. For others it
is a hard coded implementation with very little information on the triggers
37
Control Plane Loading – NOKIA (I)
• The eNB Traffic Model is used to calculate the number of C-Plane events per second
• The typical C-Plane events are
 ATTACH System
Transactions/Second
 DETACH
Module
 UE State Transition – IDLE > ACTIVE FSMD 110
 UE State Transition – ACTIVE > IDLE FSME 150
 Bearer Addition
FSMF 200 (6 cells@10MHz)
 Bearer Release
 Intra-eNB HO FSMF + FBBA 400 (12 cells @ 10MHz)

 Inter eNB HO FSMF + 2FBBx 600 (18 cells@10MHz)

 Tracking Area Update
 Paging
• Embedded snapshots highlight the transactions/second capability for the NOKIA BB
products
38
Control Plane Loading – NOKIA (III)
• With the NOKIA FSMF product, there have been no reported issues vis-à-vis C-Plane
overloading. So as long as the TEF OBs are using FSMF BB C-Plane overloading should not
be an issue. However for FSME the C-Plane needs to be monitored carefully.
• There is C-Plane overloading feature which take remedial measures. For example increasing
the RRC back off timer to a maximum value of 16s. This feature needs to be used for FSME
sites especially covering busy traffic ares

39
Control Plane Loading – NOKIA (IV)
• Attached is a document which lays out the NOKIA recommended counters to verify the
status of the BB in terms of C-Plane Load
• As an example here we have taken the FSMF
(as this should be the preferred HW). The
table shows the capability of the FSMF in
terms of handling different LTE procedures
• The document describes in details the
network counters we can use to calculate
the number of events for a FSMF in the
network
• The final results from the calculations can be compared to the values in
the table and we can ascertain whether the FSMF is reaching its limits

40
Control Plane Loading – NOKIA (IV)
• Typical Remedial Actions
 ATTACH
 DETACH
 UE State Transition – IDLE > ACTIVE
 UE State Transition – ACTIVE > IDLE
RRC Inactivity Timer
 Bearer Addition
 Bearer Release
 Intra-eNB HO
 Inter eNB HO
Hysteresis
• TA Size
 Tracking Area Update • TA Boundary Locations
 Paging • Inter-system Mobility
• TA size
• Paging Capacity
• Adaptive Paging
41
Control Plane Loading – ERICSSON(I)
• Ericsson have 2 features in this regard. Most of the trigger mechanisms are hard coded
• Feature 1 – Basic Load Management (FAJ 121 3092)
• The feature consists of the following self-contained functions viz.
 Paging Intensity Control
 DU Connection Intensity Control
 Static Cell Connection Intensity Control
 MP Load Control
 Latency Supervision
 Access Class Barring
 BB Management Interface Intensity Control
• For each of the above areas there are counters to monitor which is detailed in Appendix III
along with the corrective actions
• Optionally there is a licensed feature Dynamic Load Control (FAJ 121 3083)
42
Number of Cells per system module (I) - NOKIA
• This is also one of the key dimensioning aspects of the system module
• Different vendors have different HW versions. Depending on the requirements a particular
HW version should be selected although it is recommended to opt for the latest HW for
future proofing the network. For e.g. the FSMF for NOKIA
• NOKIA - number of cells supported for different
system module HW versions for the FDD-L15A
software for 2x2 DL MIMO & 2Rx in the UL.
• Although the recommended rollout option is 3
sector but the number of cells will depend on
the number of frequency layers, network sharing
agreements and hence the detailed requirement
needs to be worked out closely with the vendors
• Air-Scale will need to be factored in for FL-17
onwards
43
Number of Cells per system module (II)- ERICSSON
• The 3 tables in this slide show E/// capability for the different HW modules
• There is also a BandWidth restriction for the different HW modules
• For example for BB 5216 can support 12 cells with 20 MHz with 4x4 MIMO
HW Max BW
 12*20*4 = 960 MHz
DUS 31 240 MHz
HW L13B L14B L15B L16B L17A
DUS 41 480 MHz
Max PRBs DL UL DL UL DL UL DL UL DL UL
BB 5212 480 MHz
DUL 20 300 225 300 225 300 225 300 225 300 225 BB 5216 960 MHz

HW L13B L14B L15B L16B L17A

DUS 31 350 300 400 400 400 400 400 400 400 400
DUL 20 - 6 cells 6 cells 6 cells 6 cells

DUS 41 600 375 600 600 600 600 600 600 600 600 DUS 31 - 9 cells 9 cells 9 cells 9 cells

DUS 41 - 12 cells 12 cells 12 cells 12 cells

Baseband
- - - - - - 600 600 600 600
5212 BB 5212 - - - 12 cells 12 cells
Baseband
- - - - 600 600 600 600 1200 600 BB 5216 - - 6 cells 18 cells 18 cells
5216
44
Peak Throughput (I) - NOKIA
• Peak Throughput corresponds different things for different vendors.
• NOKIA – Peak Throughput is the peak single user DL and UL throughput supported in each
cell of the system module. This is compliant with 3GPP. There is no licensing required
• There is also a e Node B throughput limit as well. For example for FSMF+2xFBBC with 9 cells,
2x2 MIMO & 20MHz there is a limit of 1661 Mbps (DL+UL). No licensing required.

DL Throughput UL Throughput

45
Peak Throughput (II) - ERICSSON
• Ericsson – Peak Throughput refers to the maximum base-band capacity, which is defined as
the maximum throughput per eNode B.
• This is dictated by the capacity of the base-band HW module itself and by a hardware
activation code/license. The lowest of the 2 usually applies….
• The table below shows an example of the maximum capacity for the different base-band
HW versions for the different SW Releases
DUL20 DL BB UL BB DUS31 DL BB UL BB DUS41 DL BB UL BB
L13B 175 Mbps 50 Mbps L13B 300 Mbps 90 Mbps L13B 500 Mbps 150 Mbps

L14B 175 Mbps 50 Mbps L14B 350 Mbps 150 Mbps L14B 500 Mbps 250 Mbps
L15B 175 Mbps 50 Mbps L15B 350 Mbps 150 Mbps L15B 500 Mbps 250 Mbps

L16B 175 Mbps 50 Mbps L16B 350 Mbps 150 Mbps L16B 600 Mbps 250 Mbps

L17A 175 Mbps 50 Mbps L17A 350 Mbps 150 Mbps L17A 600 Mbps 250 Mbps

• With the new RAN SW contracts in place, this license limitation is expected to be removed.
In other words the BB hardware will have the licenses maxed out
46
Peak Throughput (II) - ERICSSON
• Throughput Capabilities for the latest HW

BB5212 DL BB UL BB BB5216 DL BB UL BB
L13B - - L13B - -

L14B - - L14B - -

L15B - - L15B 500 Mbps 250 Mbps

L16B 600 Mbps 250 Mbps L16B 1000 Mbps 420 Mbps

L17A 600 Mbps 250 Mbps L17A 1000 Mbps 420 Mbps

47
Connected User(I)
• Different Types of Users
 UEs in RRC Connected Mode but performing TAU, SMS etc. i.e. without a DRB - (1)
 UEs in RRC Connected Mode with DRB established - (2)
 UEs in RRC Connected Mode and have data in the buffer – (3)
 UEs in RRC Connected Mode and are being scheduled in a TTI – (4)

Actively Scheduled UEs (4)

UEs in RRC Connected Mode & with data in the buffer(3)

UEs in RRC Connected Mode with DRB established(2)

UEs in RRC Connected Mode without DRB(1)

48
Connected User(II) - NOKIA
• Different vendors have different implementation of the Connected User license.
• Nokia do not have connected user license in the base-band. The number of users (1) are
controlled by parameters at a cell level. An example table is shown below……

• A key point in the NOKIA implementation

is the fact that the connected users
Max Number of Users per cell
capacity is not pooled at the system HW Combination
5 MHz 10 MHz 15 MHz 20 MHz
module level which is inefficient
FSMF + 2xFBBC (3 sectors) 480 600 1030 1200
• This connected user/cell varies with the FSMF + 2xFBBC (6 sectors) 480 600 720 840
bandwidth and the number of cells on FSMF ( 3 sectors) 480 600 720 840
the site FSMF (6 sectors) 420 420 - -

• To support the required connected users, FSME (3 sectors) 480 600 720 840
FSME (6 sectors) 420 420 - -
the PUCCH resources needs to be
dimensioned adequately
49
Connected User(III) - Ericsson
• A connected user in E/// terminology is essentially a user in RRC Connected state. The
maximum number of simultaneous users allowed in a node is controlled by Connected User
Capacity License
HW L13B L14B L15B L16B L17A
360 (V) on 20 Mhz
DUL 20 1500 360 (V) on 10 Mhz 1500 500 (V) 1500 500 (V) 1500 500 (V) 1500 500 (V)
150 (V) on 5 Mhz
600 (V) on 20 Mhz
DUS 31 2500 450 (V) on 10 Mhz 2500 800 (V) 2500 800 (V) 2500 800 (V) 2500 800 (V)
300 (V) on 5 Mhz
1000 (V) on 20 Mhz
DUS 41 3500 750 (V) on 10 Mhz 3000 1000 (V) 4000 1000(V) 4000 1000(V) 4000 1000(V)
500 (V) on 5 Mhz
Baseband 5212 - - - - - - 2000 400 (V) 2000 400 (V)
500 100 (V)
Baseband 5216 - - - - 5000 1000 (V) 5000 1000 (V)
(restricted) (restricted)

• The Connected user licenses are pooled at the base-band level and individual cells can be
dimensioned from a PUCCH perspective. For example, for a 3 sector site with DUS 31 at
L15B SW level, each of the 3 cells can have PUCCH dimensioning for 1000 users. The base-
band supports 2500 connected users and it treats each user from each sector on a first
come first basis 50
Base-band Dimensioning – Summary
• Base-Band Dimensioning is closely linked traffic model type. The Key aspects of Base-band
dimensioning are viz. C-Plane/Processor Load, Connected Users, Cells and Throughput
• Different vendors have different BB implementations but usually C-Plane dimensioning is
not an issue unless we have a very busy network (and sites). For Both NOKIA there is a guide
to calculate the C-Plane dimensioning based on network counters (with some
approximations). For E/// it is all hard coded with no operator control.
• Different BB HW for different vendors are capable of supporting different number of cells
based on configuration like MIMO, bandwidth etc.
• Each BB HW from each vendor is capable to support maximum DL & UL throughput and this
is licensed for some vendors like E///.
• User License is usually for RRC Connected User. For E/// this is licensed based and for NOKIA
there is no user license on 4G and is based on cell level parameters
• Going forward it is expected that with the new RAN SW contracts, all the BB licenses will be
maxed out. 51
05
Control Channel
Dimensioning

52
UL & DL Channel Dimensioning - Contents
• DL Reference Signal – Needs Design Consideration
• Physical Cell ID & Synchronisation Signals – Needs Planning
• DL Physical Channels
 PBCH
 PCFICH
 PHICH - Needs Dimensioning
 PDCCH - Needs Dimensioning
• UL Physical Channels
 PUCCH – Needs Dimensioning
 PRACH – Needs Dimensioning
• Root Sequence Index – Needs Planning

53
Downlink Channel Mapping
• Set of Logical & Transport Channels map
onto
Logical BCCH PCCH CCCH DCCH DTCH MCCH MTCH
 PBCH
 PDSCH
 PMCH
• Other Physical Channels only exist at theTransport BCH

Physical Layer
PCH DL-SCH MCH
 PDCCH
 PCFICH
 PHICH PHYS.

• Reference Signal exists only at the Physical PDSCH PMCH REFERENCE

PBCH
Layer SIGNALS
PDCCH
• Overhead calculation for peak throughputs PCFICH
PHICH
54
DL Reference Signal
• DL Reference signal (DL RS) is similar to the concept of CPICH in WCDMA
• DL RS are distributed in both time and frequency domains which allows the propagation
channel to be estimated in both domains
• DL RS is used for cell search, channel estimation and neighbour cell monitoring
• Reference Signals reduce the maximum achievable user plane throughput by occupying a
sub-set of the Resource Elements

90.5% of symbols available

95.2% of symbols
available
55
DL Reference Signal Boosting
• DL Reference can be boosted by up to 3 dB utilising the
power from the unused DTX channels. Not
recommended
• The DL RS de-boost improves performance including
the DL User Throughput
• Recommendations
 DL Reference Signal Power Boost should not be Used as
it degrades performance without any additional benefits
 It is recommended to use the DTX power available for
the PDSCH Resource Elements for DL Throughput
benefits
 For High Capacity sites, it is recommended to use the de-
boost feature which is able to reduce the DL RS power
between 1 and 3 dB
56
Synchronisation Channels & PCI
• Primary and Secondary Synchronisation Signals (PSS & SSS)
• Transmitted during the 1st and the 11th slots within a radio frame
• Occupy the central 72 sub-carriers (around the D sub-carrier) to
facilitate the cell search procedure
• From the PSS & the SSS the UE is able to decode the Physical Cell
Identity (PCI)
• Deducing the PCI allows the UE to read the Cell Specific Reference
Signal which allows the UE to read the MIB(BW of the carrier)
• The primary objective of the PCI is to identify the cell accurately
• There are 168 PCI Groups with each group having 3 PCIs. Hence a
sum total of 504 PCIs
• PCI needs Planning
57
PCI Planning Guidelines
• PCI Planning is similar to Scrambling Code Planning in WCDMA.
• Need to avoid PCI Collison & PCI Confusion to avoid HO Failures & Call Drops
• ATOLL supports PCI Planning
• PCI MOD 3 rule should be the initial starting point. This can be achieved by applying one
unique PCI group to a eNB and then letting ATOLL select the individual PCIs within the
group based on Interference calculations
• For small cells, indoor solutions and FEMTO
cells, PCI Groups should be reserved.
• It is recommended to start with at least 3 PCI
Groups reserved

58
 PCI Planning for 6 sector sites
• The following PCI planning rules need to be modified for 6 sector sites (if applicable)
 2 PCI Groups should be assigned to every site with > 3 sectors
 The angular separation of the sectors with equal PCI MOD 3 should be maximised

59
 Physical Hybrid Indicator Channel (PHICH) - I
• PHICH is used to signal positive or negative acknowledgements for UL data transferred on
the UL shared channel
• A PHICH acknowledgement is defined by the following
 PHICH Group
 PHICH Orthogonal Sequence Index within the PHICH Group
• Each PHICH Group occupies 12 RE (normal CP) on the first symbol of every sub-frame and
uses BPSK
2 slots = 1 TTI = 1 ms
• The set of 12 RE is divided into 3
quadruplets
• The mapping of these PHICH RE is
dependant on CH BW & Physical
Cell Identity
First
quadruplet
60
 Physical Hybrid Indicator Channel (PHICH) - II
• The number of PHICH groups is a function of DL CH BW an PHICH Group Scaling Factor
• Each PHICH Group has 8 Orthogonal sequences and hence can be used to acknowledge 8
different UEs
• PHICH overhead is variable and needs to be calculated as a minimum and maximum
overhead (For the example below, MIN.= 0.2% & MAX. = 1.8%)
• As a starting point the PHICH TX. PHICH Group Normal Cyclic Prefix

PWR should be kept the same as Scaling Factor 1.4 MHz 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz
PDSCH 1/6 1 1 1 2 2 3

• Dimensioning – Initial starting Point 1/2 1 1 2 4 5 7

1 1 2 4 7 10 13
 PHICH Group Scaling Factor = 1/6 2 2 4 7 13 19 25
 For example for a 20 MHz CH BW, there will be 3 PHICH Groups which means there will be 36
PHICH RE divided into 9 quadruplets. This should allow 24 UEs to be acknowledged in the same
TTI.
 This should be tallied with the maximum number of UEs that can be scheduled in the DL
61
 Physical Downlink Control Channel (PDCCH) - I
• The PDCCH is a DL control channel which is
used to transfer DL Control Information (DCI)
• DCI can be for Paging, DL data, UL Data etc.
• The PCFICH signals the number of OFDMA
symbols which can be occupied by the PDCCH
which are always at the start of the each DL
frame – example shows 2 x OFDMA symbols
• Resource Elements allocated to the PDCCH are
grouped into quadruplets (groups of 4
Resource Elements) which is known as a
Resource Element Group (REG)
• REGs are then grouped into Common Channel
Elements – 9 REGs form 1 CCE = 36 RE/CCE
62
 Physical Downlink Control Channel (PDCCH) - II
• The PDCCH format is selected according to the size of the DCI
• One of the most important factors for PDCCH
PDCCH No. of No. of No. of
format selection is coverage Format CCE REG Bits

• The number of CCE available depends on the CH 0 1 9 72

1 2 18 144
BW and no. of OFDMA symbols configured
2 4 36 288
• Example for 10 MHz for 3 OFDMA symbols 3 8 72 576
 No. of sub-carriers = 600 (50*12)
 No. of OFDMA symbols = 1800 (600*3)
 No. of RE for PCFICH = 16 RE
OFDMA Symbols 5 MHz 10 MHz 15 MHz 20 MHz
 No. of RE for PHICH = 24 RE for PDCCH (CCE) (CCE) (CCE) (CCE)

 CRS & DTX = 200 (4/RB & for 10 MHz-50 RB) 1 5 10 16 21

2 13 27 41 55
 Total RE used up = 240 (200+16+2)
3 21 43 66 88
 RE left over for PDCCH = 1560 (~43 CCE)
63
 Physical Downlink Control Channel (PDCCH) - III
• As the UE moves into weaker coverage areas, higher levels of PDCCH Aggregation is needed
along with lower MCS values
• PDCCH presents a big overhead. For e.g. for 3 symbols using Normal CP the overhead is 19%
• Dimensioning – Initial starting Point
 A maximum number of 3 OFDMA symbols should be allocated to
PDCCH
 The eNB should be allowed to dynamically change the number of
OFDMA symbols for PDCCH based on load
 Default CCE aggregation of 4 should be used to allocate resources
for control plane messages. For example , SIB, Paging, Random
Access etc.
 Dynamic CCE Aggregation should be used to allocate resources for
user plane data
 Features like Pre-Scheduling for Data should be carefully
considered as it increases PDCCH Loading especially for NOKIA
64
UL Channels
• Set of Logical & Transport Channels map
onto the PUSCH
• Other physical channels only exist at the
physical layer
 PUCCH
 PRACH
• RACH is illustrated as a Transport Channel
but is used only to transfer Random Access
Control information from the MAC layer to
the physical layer
• Reference signals only exist at the physical
layer

65
UL Reference Signals
• There are 2 types of UL Reference signals
 Demodulation Reference Signal
 Sounding Reference Signal
• UL Reference Signals are used by the eNB for estimating channel quality, synchronisation
and Timing Advance
• UL Reference Signal need planning rules
• Initially PCI MOD 3 rule should suffice for both types of UL Reference signal
• As inter- eNB timing and phase synchronisation is introduced in the network, it is
recommended to use the Group Hopping for Demodulation Reference signal for whichever
vendor this is applicable

66
 Physical Uplink Control Channel (PUCCH) - I
• Physical Uplink Control Channel (PUCCH) is always allocated at the upper and lower edges
of the channel bandwidth
• This avoids fragmentation of the PUSCH
Resource Blocks and also provides Frequency
Diversity
• PUCCH Dimensioning in terms of Resource
Blocks is required to ensure the minimum
overhead vis-à-vis UL Data
• 3GPP Release 8 and Release 9 do not allow simultaneous PUCCH and PUSCH transmission
and hence PUCCH is used to transfer Uplink Control Information when the PUSCH is not in
use

67
Physical Uplink Control Channel (PUCCH) - II
• Different Types of UL Control Information uses different PUCCH formats

Format Uplink Information

1 Scheduling Request
1a 1xHARQ-ACK OR 1xHARQ-ACK + SR
• Details of PUCCH Design
and Dimensioning are
1b 2xHARQ-ACK OR 2xHARQ-ACK + SR captured in Appendix IV
2 CQI (PMI & RI)
2a 1 x HARQ-ACK + CQI
2b 2 x HARQ-ACK + CQI

• The PUCCH Dimensioning in terms of Resource Blocks (RB) needs to be calculated in terms
of the different PUCCH Formats
• PUCCH always occupies 2 x RB across 2 time-slots
68
Physical Random Access Channel (PRACH)
• PRACH is used to transmit Random Access preambles
• It is of 1ms/2ms duration in the time domain and occupies 6 RB in the frequency domain
• It needs to be adjacent to the PUCCH RB either top or bottom of the spectrum. With some
vendors, this is flexibility does not exist and the PRACH has to be at the bottom of the
spectrum

69
PRACH Planning & Dimensioning – Key Points
• PRACH is used for the Initial Random Access by the UE or during handovers and the
following points need to be borne in mind
 Where is the PRACH transmitted in the time and frequency domain?
 What is the frequency of PRACH transmission in the time domain?
 What is the planned cell range

• Planning & Dimensioning Areas

 PRACH Preamble Format – Impacts the cell range
 PRACH Configuration Index – Impacts the cell range & eNB processing load
 Zero Correlation Zone – Impacts Cell Range & Root Sequence Re-use pattern
 High Speed Flag – To tackle Doppler at very high speeds (>200 km/hr)
 Root Sequence Index – Ensures that neighbouring cells have unique PRACH preambles
 PRACH Frequency Offset – Determines the position of the PRACH in relation to the PUCCH
70
PRACH Preamble Format
• Selecting a Preamble Format is a pre-requisite to selecting the PRACH Configuration Index

• Preamble Format selection depends on the planned cell range

• For lower LTE bands, we would need to select Format 1 to allow Cell Range > 15Km should
there be a need to do so (Some vendors have a separate license for cells > 15 Km)
• For Higher LTE bands, Format 0 should be sufficient
• Format 1 should not be used where Format 0 suffices as Format 1 has higher overheads

71
PRACH Configuration Index
• PRACH Configuration Index defines the
location of the PRACH in the 10ms radio
frame
• As an example, For 3 sector sites, PRACH
Configuration Index of 3,4 & 5 should be
selected for sectors 1,2 & 3 respectively
• This will separate the out the PRACH in the
time domain for the different sectors of the
same site

72
Zero Correlation Zone
• Zero Correlation Zone is linked to the
Root Sequence Index planning and the
cell range
• For example to plan a cell range of 22.78
Km (with Preamble Format 1), a value of
167 needs to be selected for the Zero
Correlation Zone
• This implies that every cell needs to 13
Root Sequences to generate the 64
preamble sequences
• Since there are 839 Root Sequences available, this implies a Root Sequence Index re-use
pattern of 64
• There are 2 options for Root Sequence Index Planning i.e. either at a cell level or at an e NB
level
73
Root Sequence Index Planning
• Option 1 – PRACH Preamble separated out in time domain for the different sectors of a site
and this allows Root Sequence Index Planning at an eNB level (PRACH to PUSCH Interference)
• Option 2 – Same sub-frame for the PRACH preamble for all sectors and hence cell planning
required for the Root Sequence Index (PRACH to PRACH Interference)

• Option 1 is the preferred

Option if supported by the
vendor
74
Root Sequence Index (RSI) Planning Guidelines
• Based on the example cell range in the zero correlation zone slide for a cell range of
22.78km, we would need 13 Root Sequences to generate the 64 preamble sequences in a
cell and hence a re-use pattern of 64 as there are 839 Root Sequences
• ATOLL supports the RSI Planning from v3.2.1

• Some RSI (typically 2) need to be reserved for 0

FEMTO or small cells if there are plans to deploy

these 26 13
0 0
• Since the small cells will have less than km as cell
39
range it would require 2 Root Sequences per cell 26 26 13 13

39 39

75
PRACH Frequency Offset
• PRACH Frequency Offset (PFO) determines the position of the
PRACH preambles in the frequency domain
• PFO should be always allocated adjacent to the PUCCH in
order to avoid fragmentation of the PUSCH resources
• PFO signals the position of the first PRACH PRB
• The PRACH can be assigned either at the top or the bottom of
the spectrum. E/// only allow bottom of the spectrum and is
the placement is hardcoded based on the PUCCH calculation
• In the example shown, assuming the following
 PUCCH RBs required = 8
 PFO = 40 (top of the spectrum)
 OR
 PFO = 4 (bottom of the spectrum)

76
 Root Sequence Index Planning for 6 sector sites
• As per the previous slides, a 3 sector site uses PRACH Configuration Index 19,20 & 21 which
will separate the individual sectors of a site in the time domain
• The above will not be applicable to 6 sector sites
• For the 6 sectors, the recommended solution combines both time and frequency domain

77
High Speed Flag
• High Speed Flag needs to be set in order to counter the effect of Doppler shift at high
speeds
• Activating the High Speed Flag has an impact on the zero correlation zone parameter and
impacts the Root Sequence Index Planning and the Cell range
• Zero Correlation zone parameter along with the High Speed Flag are pre-requisites for Root
Sequence Index
• Initially the High Speed Flag can be OFF

78
Channel Dimensioning – Summary (I)
DOWNLINK
• DL RS
 Power Boost should not be used
 Power for the DTX RE should be used for the PDSCH RE
 For High Capacity sites, it is recommended to use DL Power de-boost
• PCI
 PCI MOD 3 Planning Rule should be used &
 3 PCI Groups should be reserved for small and Femto cells
• PHICH – Initial starting point for Group scaling factor = 1/6
• PDCCH
 All 3 OFDMA symbols should be used for PDCCH with load based dynamic allocation
 CCE Aggregation of 4 should be used for control plane messages
79
Channel Dimensioning – Summary (II)
UPLINK
• PUCCH
 PUCCH RBs should be calculated based on the users/cell, CQI and SR requirements
 It needs to be borne in mind that Carrier Aggregation has slightly different PUCCH requirements
 PUCCH Dimensioning is also dependant on the vendor implementation
 Details on PUCCH Dimensioning have been provided in Appendix IV
• PRACH
 The right PRACH Format needs to be selected (Either Format 0 or Format 1)
 PRACH Configuration Index and Zero Correlation Zone needs to be chosen accordingly
 Root Sequence Index Planning should be done accordingly
 Root Sequence Index should be reserved for small cells and Femto cells
 High Speed Flag should be switched OFF
80
Parameter Summary (III)
• NOKIA Parameter Summary • Huawei Parameter Summary

• Ericsson Parameter Summary • HUAWEI do not have a PUCCH Calculator. They

recommend using the Adaptive PUCCH
Configuration Solution which dynamically
adjusts the PUCCH configuration and SRI and
CQI period based on load/users

• More details on the PUCCH Dimensioning are provided in Appendix IV

81
06
Paging & Random
Access Procedures

82
 Paging – Introduction(I)
• The MME is responsible for sending Paging Records to the eNB using S1AP: Paging Message
• Depending on the MME design, the MME sends the Paging Records to an e NB, a eNB list or
to all e NBs in a Tracking Area
• Paging Records being sent by the MME can be either from the CS Core, PS Core or the IMS
• The eNB collects, schedules and broadcasts the individual Paging Records
• The eNB can pack in more than one Paging Record in a Paging Message it transmits taking
into account the Paging Frame and the Paging Occasions
• UE monitoring the PDCCH for Paging Indication during its Paging Occasion and reads the
PDSCH for actual Paging Message

83
 Paging – Introduction(II)
• Maximum Number Paging records that can be packed in one Paging message is dependant
on the CH BW

• The frequency of occurrence of the Paging Sub-frame also needs to be dimensioned based
on the estimated Paging Load

• Lower value of the nB required to minimise the PDCCH load but can risk Paging Discards
84
 Paging Dimensioning - I
• Maximum Paging records should be packed in a Paging message. This is dependant on the
CH BW. For example for CH BW >= 10 MHz, this value is 16 Paging Records
• A good starting point for Paging Capacity Dimensioning for CH BW >= 10 MHz in the eNB is
400 pages/s.
• In certain vendors, there is an eNB buffer which buffers the MME pages for a certain
duration and then discards it
• The Paging Discard timer should be set equal to the MME timer T3413 and also should be
set > DRX cycle length
• Average Paging Load & Discards should be monitored and nB parameter should be
changed likewise. This is covered in the Reactive Dimensioning section (Section 10) in more
detail

85
 Paging Dimensioning - II
• Telefónica OBs should look to enable Adaptive Paging (or Equivalent) in the MME in the
long term especially as DL Data Notification constitutes almost 85% of the Pages
• Essentially there could be different Paging Profiles for CSFB, VoLTE and DL Data. An example
shown below of such a design

Parameter Parameter Description Paging Profile 4 Paging Profile 5

id (Identity) 4 5
enb (EnodeBPagings) 1 0
ta (TaPagings) 2 2
talist (TaListPagings) 0 0
ptpt (ProfileT3413PagingTimer) 2000 2000
enbl (EnodeBListPagings) 1 1

• The chart shows the impact on Paging Load with the introduction of the Adaptive Paging
feature
• Based on performance investigations on TEF UK, there are now have 3x Paging Profiles i.e.
one for data, one for CSFB and one for VoLTE
86
Random Access Procedure - I
• The Random Access procedure using PRACH is required in the following cases
 Transition from RRC IDLE to RRC CONNECTED
 Completing an INTRA-SYSTEM HANDOVER
 Arrival of UL or DL data when the UE is in unsynchronised state
 RRC Re-establishment
• During the RA procedure the UE uses one of the 64 PRACH preambles in the cell to access
the cell and this procedure can either be contention based or non-contention based
• The contention based procedure is based on the UE selecting a PRACH preamble and the
non-contention based procedure is when the UE is allocated a PRACH preamble by the e
Node B
• The contention based procedure has to go through contention resolution at the eNB and
the RRC process is successful only if there is a successful contention resolution
• The non-contention resolution process is always initiated by the e NB
87
Random Access Procedure - II

• The 64 PRACH Preamble Sequences are divided into contention based and non-contention
based pools
• In some vendor implementations the contention pool is further sub-divided into 2 further
groups viz. Group A and Group B. For example in ERICSSON, there is only one contention
based pool
• The key dimensioning question is how should the 64 preambles be split between the
contention and non-contention pools
88
PRACH PREAMBLE Dimensioning
• Initial Starting Point (for NOKIA)
 Contention Pool = 40 Preambles
 Non-Contention Pool = 24 Preambles
• For Ericsson without the basic feature “Contention Free Random Access” all the preambles
are in the CBRA (contention based) pool
• With the enabling of the above mentioned feature the preambles are distributed as 12 in
the Contention Free pool and 52 in the contention based pool and is controlled by system
constants and is not available for operator modification
• Ericsson can change these parameters globally for all cells in a network but not on a cell by
cell basis

89
Paging & Random Access Dimensioning – Summary(I)
• Paging & Random Access are very important procedures and therefore need to
dimensioned accurately
• Number of Paging records should be maximised in a paging message and wherever
applicable the eNB Paging Buffer timer should be set equal to the MME Paging repetition
timer
• The frequency of the paging sub-frame will depend on the dimensioning calculation and
would need to be changed as required based on increased paging load
• In the long run Telefónica OBs should look to deploy Adaptive Paging Feature (or
equivalent) in the MME
• The 64 Random Access Preambles should be divided appropriately for the CBRA and the
CFRA procedures
• A good starting point is 40 preambles for CBRA and 24 for CFRA (NOKIA)
• Some vendors will have a further split of Grp A and Grp B within the CBRA pool
90
Parameter Summary
• NOKIA Parameter Summary

• Ericsson Parameter Summary

• Huawei Parameter Summary

91
07
Tracking Area Planning
& Dimensioning

92
Tracking Area
• Tracking Area (TA) is similar to the Routing Area for 3G and 2G. TA consists of several eNBs
with the same TA Code and is used to identify the UE location in Idle Mode
• Several TAs can be grouped into one TA List

• Several TAs can be grouped into one TA List

• The UE does not need to TA Update whilst in the

TACs in the TA List but this increases the Paging
Load.

• Initial Starting Point Recommendation – TA List not

to be used.

93
Tracking Area Planning Rules - General
• For Tracking Area Planning in general the following rules should be followed…….
 TA should be planned to be relatively large rather than relatively small
 TA size should be revisited if Paging Load becomes an issue
 Existing 2G and 3G Location Areas and Routing Area boundaries should be used as an initial guide
for the TA boundaries especially if 4G sites are co-sited with 3G/2G sites
 TA boundaries should not run close to and parallel to major roads or railways
 Cells which are located at TA boundaries and which experience large number of TA updates should
be monitored to evaluate the impact of this excessive signalling associated with the procedures

94
Tracking Area Planning (Example) – MME Perspective
• To plan the Tracking Area from the perspective of the MME, the following information is
needed
 Attached subscribers in the MME
 Average Paging Requests per subscriber in the busy hour
 MME Capacity and Configuration – Vendor Specific
 Paging Intensity per subscriber
eNB per TAC - MME Perspective

Attached Subscribers per MME 700000

MME Type – E/// MkVIII
No. of SCTP Boards per MME 22 An example calculation for
Paging Capacity per SCTP 6000
MME Paging Capacity 132000
a E/// MME
Average Paging Intensity/sub (BH) 3
Average Paging Intensity/sub/second(BH) 0.000833 Paging Capacity/ (subscribers*Paging
eNB per TAC for MME Paging Capacity 227 Intensity/s)
95
Tracking Area Planning (Example) – eNB Perspective
• To plan the Tracking Area from the perspective of the eNB, the following information is
needed
 Attached subscribers – eNB
 eNB Paging Capacity
 Average Paging Requests per subscriber in the busy hour
 Paging Intensity per subscriber

eNB per TAC - eNB Perspective

Attached Subscribers per eNB 4000

eNB Paging Capacity (pages/second) 400
Average Paging Intensity/sub (BH) 3 An example calculation
Average Paging Intensity/sub/second(BH) 0.0008333

eNB per TAC for eNB Paging Capacity 120

96
Tracking Area Planning Summary
• Number of e NBs in a Tracking Area = min (MME perspective , eNB perspective)
• From the previous 2 slides for TEF UK we should have 120 eNB/TAC
• In reality it is not recommended much higher than ~75-80 eNB/TAC

97
Tracking Area Planning & Dimensioning Summary
• Tracking Area Planning is one of the key planning aspects which need to be undertaken in
order to have a good network performance
• Certain basic rules need to be followed when planning a Tracking Area border
• Tracking Area Planning and dimensioning in terms of number of eNode Bs per Tracking area
should be done both at an eNode B level and also at a MME level and the minimum of the 2
should be selected
• The usual recommendation is not to exceed more than 80 e Node Bs in TAC.
• With the introduction of Adaptive Paging Feature (or equivalent) in the network, Telefónica
OBs should consider the use of Tracking Area Lists i.e. more than one Tracking Area in a
Tracking Area List – Needs to be discussed with the Core Network colleagues and the
vendors if this is suitable

98
08 Voice Over LTE

99
Voice Over Internet Protocol
• VoIP Traffic in general is characterised by regular traffic pattern and relatively low bit rate
• It generates small packets of data which are transmitted in an almost synchronous way
with stringent requirements for latency, delay and jitter
• Figure below depicts a typical VoIP call where the CODEC output is every 20ms during the
spurt period with intermittent periods of silence where the SID frames are sent every
160ms
VoIP Call

Talk Spurt Silence Talk Spurt

20ms 20ms
160ms

VoIP SID
Pkt. Pkt.

100
Voice Over Internet Protocol
• The performance in terms of quality for VoIP is determined mainly by three factors
 CODEC Bit Rate
 Delay Caused by scheduling and re-transmissions on the air interface
 Frame Error Ratio for RLC frames
• User satisfaction can be measured in terms of mouth to ear delay
• The table below shows the impact of delay as per ITU

Mouth to Ear Delay User Satisfaction

Delay < 200ms Very Satisfied

200ms < Delay < 285ms Satisfied

285ms < Delay < 390ms Dissatisfied

101
VoLTE Bearers (I) – Telefónica UK Example
• VoLTE is a packet switched voice services across the 4G radio access network which
requires the following bearers. An example shown from Telefónica UK in the picture
 QCI 1 bearer to be used for speech traffic (GBR bearer) - Dedicated
 QCI 5 bearer to be used for IMS SIP signalling (non-GBR bearer) - Default
 QCI 8 bearer to be used for data traffic (non-GBR bearer) - Default
UE e NB P-GW

Default Bearer, QCI-8, non-GBR, APN-idata.o2.co.uk/mobile.o2.co.uk

Default Bearer, QCI-5, non-GBR, APN-ims

Dedicated Bearer, QCI-1, GBR

102
VoLTE Bearers (II) – SRB & DRB Combinations
• VoLTE is a packet switched voice services across the 4G radio access network which
requires the following bearers
 QCI 1 bearer to be used for speech traffic (GBR bearer) - Dedicated
 QCI 5 bearer to be used for SIP signalling to IMS (non-GBR bearer) - Default
 QCI 8 bearer to be used for data traffic (non-GBR bearer) - Default

• VoLTE needs the following LTE bearers

 SRB1 + SRB2 + 3 x DRB

• If we were to launch ViLTE then we would need another DRB for the QCI-2
 SRB1 + SRB2 + 4x DRB

103
Quality of Service Table

• EPS Bearers for

Conversational Voice
• Support for GBR QCI 1
• Support for non GBR QCI 5

104
VoLTE Protocol Stack
• SIP signalling can flow over either
UDP or TCP
• RRC configures the lower layers –
(PDCP/RLC/MAC/PHY)
• Key Points
 LTE Signalling – RRC & NAS is
carried by the Signalling Radio
Bearer
 VoLTE Signalling (SIP) and VoLTE
user plane data is carried by the
DRB i.e. both are treated as User
Plane Data

105
VoLTE Dimensioning Considerations
• The LTE radio network uses the following Physical Channels:
 PDCCH, PDSCH, PUSCH, PHICH, PUCCH
• Any of these could generate a bottle-neck for VoLTE capacity.
• The impact of VoLTE on each channel and the limitations to VoLTE capacity presented by
each channel is explained in more detail in Appendix VII. The capacity of each channel must
be studied to identify the limiting channel
• 50 % speech activity factor needs to be assumed
• For the dimensioning purposes only the 12.65 kbps and 23.85 kbps codecs are considered.

106
VoLTE Capacity Limitations
• At a high level 3 things can limit VoIP capacity in an LTE system viz.
 Control Channel Capacity
 The number of RB
 UE TX Power
• PDCCH is likely to be the limiting factor in most scenarios except for very large cells where
UE Tx. power becomes an issue

UE Power

Large Cells PDCCH/ RB

Short Delay Requirements

PUSCH
High Cell Isolation
PUSCH
PDSCH
107
VoLTE PDU Transformation - I
• The AMR CODEC produces a voice packet every 20ms when a user is in Talk Spurt Mode
• The AMR WB-CODEC is widely used for VoLTE services and either of the 2 CODEC rates of
12.65 kbps or 23.85 kbps is used across different networks
Layer 3 SDU
IP
Source Frame PDCP RLC MAC Voice Frame
CRC Segment L1 SDU Header
CODEC Rate Size Header Header Header
(bits) (bits) (bits)
(kbps) (bits) (bits) (bits) (bits)

AMR
12.65 253 40 8 8 24 336 336
12.65

AMR Layer 3 PDU

23.85 477 40 8 8 24 560 560
23.85
PDCP IP
Header Voice Frame
Header

• The table above shows the additional bits which are

added to the CODEC source rate as the voice packet
reaches the PHY layer from the higher layer Layer 2 PDU
RLC MAC PDCP IP
Header Header Voice Frame CRC
Header Header

108
VoLTE PDU Transformation - II VoIP over LTE
(with header compression)
• The speech service protocol stack impacts the PDSCH
capacity Speech 12.65 kbps

 Various headers must be transferred by the PDSCH 253 bits every 20 ms

• Robust Header Compression (RoHC) is a technique used to 5 Bytes Header

(Compressed)
compress the RTP/UDP/IP headers
• It is very essential for RoHC to be switched ON within the RLC 1 Byte Header

PDCP layer which usually compresses the RTP/UDP/IP header MAC 1 Byte Header

from 40 bytes to 5 bytes. These 5 bytes include the PDCP

header as well which is 1 byte L1 ~15.5 kbps
• The lower layers as seen in the previous slide add another 24
bits or 3 Bytes

109
VoLTE Capacity in a Cell
• The VoLTE Capacity needs to be estimated based on the UL and DL channels
 PDCCH
 PHICH
 PUCCH
 PDSCH
 PUSCH
• Of all the above channels, the most likely capacity bottleneck is PDCCH especially for a
smartphone centric network
• Detailed VoLTE calculations are presented in the Appendix VII using network counter
results from Telefónica UK LTE network

110
VoLTE only Cell Example – Telefónica UK
• Based upon the calculations shown in Appendix VII the maximum number of VoLTE
connections per cell as calculated is shown in the table below in voice only cell scenario

40ms transmission period

12.65 kbps codec 23.85 kbps codec

PDCCH 137 – 164 130 - 156

PDSCH 936 576
PHICH 1280 1280
PUCCH 330 330
PUSCH 792 576

• The PDCCH is the limiting physical channel

 There are a range of capacities defined for the PDCCH because actual capacity depends upon
coverage conditions and CCE used

111
Summary
• If we assume a 12.65 kbps CODEC, for a voice only scenario we should be able to support
between 137 – 164 Users/Erlangs
• In reality, when a Telefónica OB introduces VoLTE service, it is most likely to be in addition
to the existing data services being offered to the customers
• Therefore it is important to formulate a methodology to gauge the approximate impact on
data experience with the increase in VoLTE traffic in a call
• In the next section, some results are presented from some vendor simulations regarding
the impact of VoLTE users on Cell Throughput.

112
09
VoLTE Simulations &
VoLTE Impact Tool

113
NOKIA Simulations (I)
• NOKIA carried out VoLTE Capacity simulations
for Telefónica UK in London using real network
data
• Mean Cell throughputs and total non-GBR
throughput is decreasing with higher number of
VoLTE users per cell as VoLTE users have higher
priority but do not have higher throughput
• Throughput for VoLTE users is increasing linearly
as those UEs have constant throughput
• The key message is even with high number of
VoLTE users in a cell, there is still sufficient
room for non-GBR traffic

114
NOKIA Simulations (II)
• This is the scenario for the 10MHz L800 layer
• Non-GBR user Throughputs is decreasing with
higher number of VoLTE users in the cell
• This is because non-GBR users have lower
priority than VoLTE users and therefore can only
be scheduled once VoLTE users have been
satisfied
• When there are lots of VoLTE users in a cell,
there are less scheduling occasions for a non-
GBR user
• For the same reason the cell edge throughput is
very low as well

115
NOKIA Simulations (III)
• VoLTE user is satisfied when at least 95% of the packets are sent within the configured
delay target
• The chart below shows 150 VoLTE users being satisfied. With these many VoLTE users
there is still room for about 5.5 Mbps for non-GBR DL traffic

116
NOKIA Simulations (IV)
• The results in the previous slides are also a
function of the channel bandwidth. This set of
results are now for the 5 MHz L1800 channel
• Only 85 satisfied users can be supported with
still room for 1.8 Mbps non-GBR Dl traffic

117
Impact of VoLTE Traffic on MBB (Cell Throughput) - I
• The following excel model takes into account the data traffic. Most Telefónica OBs are
smartphone dominated networks and hence they are likely to have a bursty traffic model
• The following values need to be filled in the excel tool which is based on several factors like
vendor implementation, bandwidth available, design settings etc.
 Target Available CCE – Based on Design setting
 DL PRB per VoLTE User – vendor implementation. From network log files. An example snapshot
showed for the NOKIA implementation in Telefónica UK
 UL PRB per VoLTE User – same explanation as the DL
 PRB in Channel Bandwidth – Based on spectrum availability
 PRB Allocated to PUCCH – Based on Design setting
 Max DL Data Throughput per User – Counters (DL PDCP Data Volume/(Active TTIs * DL Users per TTI)
 Max UL Data Throughput per User – same explanation as the downlink
 VoLTE CODEC to be used – Telefónica OB dependent
118
Impact of VoLTE Traffic on MBB (Cell Throughput) - I
• The following values would need to gauged from the network counters:
 Average CCE used per transmission – Network Counters
 CCE Load in Cell – Network Counters (AVG CCE Utilisation)
 DL PRB Load – Network Counters (Average DL PRB Utilisation)
 UL PRB Load – same as the downlink

NOKIA Counters (DL Only) ERICSSON Counters (DL Only)

 Average CCE utilisation/ transmission =
(M8011C39+M8011C40*2+
M8011C41*4+M8011C42*8)/(M8011C39+M8011C40+M
8011C41+M8011C42)
 Average PRB utilisation = avg([M8011C37])/10
 DL Cell Throughput =
8*sum([M8012C20])/sum([M8012C90])
 Average CCE utilisation = pmPdcchCceAggregationDistr
 This is a pdf distribution counter which has bins for the 4
AGG levels. So similar formula as shown in the NOKIA
example
 Average PRB utilisation = pmPrbUtilDl (pdf)
 DL Cell Throughput =
pmPDCPVolDlDrb/pmSchedActivityCellDl/1000
119
Impact of VoLTE Traffic on MBB (Cell Throughput) - II
• The following values would need to gauged from the network counters:
 Average CCE used per transmission – Network Counters
 CCE Load in Cell – Network Counters (AVG CCE Utilisation)
 DL PRB Load – Network Counters (Average DL PRB Utilisation)
 UL PRB Load – same as the downlink

Huawei Counters & KPI Formula

 Average CCE utilisation/ transmission = (L.ChMeas.CCE.CommUsed + L.ChMeas.CCE.ULUsed +
L.ChMeas.CCE.DLUsed)/L.ChMeas.CCE.Avail x 100%
 Average PRB utilisation = (L.ChMeas.PRB.DL.Used.Avg/L.ChMeas.PRB.DL.Avail) x 100%
 DL Cell Throughput = (L.Thrp.bits.DL/L.Thrp.Time.Cell.DL.HighPrecision)

120
Snapshot of DL & UL PRB usage per VoLTE User

DL PRB Usage from Drive

Test Logs

UL PRB Usage from Drive

Test Logs

121
 Ex – I (Bursty Traffic with 80% DL PRB Utilisation)
• For a Live cell in Telefónica UK, the following information
VoLTE Codec
has been filled in and as an example the impact on DL Cell
Throughput is plotted
Target Available CCE 38
Average CCE per transmission 4
CCE Load in Cell 31

DL Cell Throughput 12
UL Cell Throughput 2.4

DL PRB Load 80
UL PRB Load 10

DL PRB per VoLTE User 4

UL PRB per VoLTE User 1 • In this case DL PRB utilisation is 80%
PRB in Channel Bandwidth 50 • The DL Cell throughput is impacted around 95 VoLTE
PRB allocated to PUCCH 6
users.
Max DL Data Throughput per User 4
Max UL Data Throughput per User 2 • The impact is because of the PDSCH constraints

122
Ex – II (Bursty Traffic with 100% DL PRB Utilisation)
• For a Live cell in Telefónica UK, the following information
VoLTE Codec has been filled in and as an example the impact on DL Cell
Throughput is plotted
Target Available CCE 38
Average CCE per transmission 4
CCE Load in Cell 31

DL Cell Throughput 12
UL Cell Throughput 2.4

DL PRB Load 100

UL PRB Load 10

DL PRB per VoLTE User 4

UL PRB per VoLTE User
PRB in Channel Bandwidth
PRB allocated to PUCCH
Max DL Data Throughput per User
Max UL Data Throughput per User
1 • As the PRB utilisation is 100% in this case before the first
50 VoLTE user is introduced, the DL Cell Throughput starts
6
getting impacted straightaway i.e. PDSCH Limitation
4
2
• The second breakpoint is because of PDCCH congestion
and as VoLTE is GBR PDCCH is prioritized for it
123
Summary & Conclusions
• The impact of VoLTE users on data traffic depends on the mainly 3 points viz.
 Traffic Model in use in the network
 Full Buffer scenario
 Bursty Traffic scenario
 PRB Utilisation
 PDCCH Availibility
• For a cell with 100% PRB utilisation, the Cell Throughput starts to degrade straightaway with
the first VoLTE user. The initial impact on data throughput is because of PDSCH but beyond a
certain number of VoLTE, PDCCH becomes the limiting factor.
• For cells with < 100% PRB utilisation, the impact on cell throughput is not likely to be
straightaway with the first VoLTE user but later on with a certain number of VoLTE users
• The results from the VoLTE model more or less matches with the NOKIA simulation. GCTO
currently working with vendors for some further simulations results
124
10 Hot-Spots (Reactive)
Dimensioning

125
Reactive Dimensioning – General Principles (I)
• Apart from the Network Strategic Dimensioning which is cater for Long Term Traffic Growth,
there is also a need for reactive process to cater for the traffic growth in the short term
Trigger Areas Possible Remedial Measures
Connected Users With the new commercial agreements with the vendors, the license
aspects will not be an issue. Process still required to optimise the
Base-band Throughput parameters based on traffic requirements

Random Access Capacity > 1x PRACH, Optimising the Pool sizes for CBRA & CFRA etc.

Paging Capacity TA Size increase, Increasing Paging Capacity, Separate Paging Profiles etc.

DL Control Channel Capacity Capacity Increase in the domain of PDCCH (DL)

Only an approximation as no direct measure available from counters

Average User Experience This user metric is still being finalised and will be updated in subsequent
document issue

126
Reactive Dimensioning – General Principles (II)
• In terms of the process, each metric will have a baseline design and a few upgrade steps
• There will be a trigger criteria associated for the upgrade which will be based on a
combination of vendor specific Counters & Parameters
• Once the final upgrade step has been Baseline Trigger Upgrade
reached and thereafter there is still Design Criteria
Step 1
further increase in traffic then other Monitor Monitor
Trigger Criteria
options need to be considered viz.
 Tactical Options
Final Trigger Upgrade
 Aggressive Traffic Balancing Step 2
Upgrade Criteria
 Down-Tilting
 Features
 The final step in this process will be the Monitor

planning of a new site

127
Number of Simultaneous RRC Connections
• With all the new SW RAN contracts the eNB User licenses should not be a limiting factor and in
the following slides that assumption has been made. However there are examples of the current
TEF UK process in Appendix VIII in which eNB license is a limiting factor
• Even if we remove the license limitations from a license perspective, we still cannot max out the
users at a cell level as that has an impact on cell capacity. So ideally we need to have a starting
point and beyond that we need to have a process to uplift the Connected User capacity based on
trend of traffic increase.
• In general as the number of users increase in a cell, the user experience is likely to degrade as
resources are in contention.
• However the margin for tolerance (i.e. how many users can be allowed into the system before the
user experience starts getting unacceptable) is higher in networks dominated by Smartphones
because of the relatively small amounts of data per subscriber per session.
• There are 2 approaches which is explained in the next slide in terms of approaching this topic of
users/cell
128
RRC Connected Users - Approach
• Before we discuss the 2 approaches it is fundamental that we understand the point below
• As can be seen from the chart (average busy hour data for 2 weeks from TEF UK), that as
the RRC Connected users increase, the Average DL User Throughput decreases
• Does the End User really suffer from a bad user experience when the RRC Connected User
numbers are high in a cell?

129
RRC Connected Users - Approach
• The 2 approaches for handling the increased traffic vis-à-vis the increase in the connected
user in a cell/site are….
 Approach 1 – Allow as many users as possible in order to maximise the RRC Accessibility at the
expense of user data experience
 Approach 2 – Restrict users beyond a certain point so as to maintain user data experience but at
the expense of RRC Accessibility
• Some key points to consider are the following……
 In smartphone dominated networks, the average data volume per subscriber per session is very
small because of the Bursty nature of the applications
 The KPI Average DL User Throughput = (Total Data Volume)/(Active TTI * Buffered Users)
 Therefore KPI will decrease with increased users but does not necessarily mean the user
experience is getting any worse as the numerator is very small owing to the small data packets
 LTE does not have specific RRC causes for either CSFB or VoLTE traffic and hence use the same
cause value as is used for data (normal cause value > mo_data or mt_data) & hence VoLTE or
CSFB users cannot pre-empt data users 130
RRC Connected Users - Approach 1(I)
• This approach mandates that we allow as many RRC Connected Users as possible into the
cell so as to maximise the RRC Accessibility
• With this approach, we tend to avoid blocking Voice calls (CSFB & VoLTE) on the LTE cell but
with the possible impact on DL data user experience
• In reality though for smartphone centric networks, the picture is quite unique as shown
below for 2 different scenarios

131
RRC Connected Users - Approach 1(II)
• The Average User Throughput is not influenced by RRC Connected Users but Buffered Users
i.e. Users for which the eNB buffer has data to send. This is typically ~10% of the RRC
Connected Users (in general with an RRC Inactivity Timer of 10s)
• This implies that the ~90% of the RRC Connected Users have no data activity in a given TTI
but are awaiting the Inactivity Timer to expire for the UE to go to IDLE Mode
• It is evident from the previous slide that if a user needs a higher throughput service, that is
still possible with high numbers of Connected Users. For example for the scenario when we
had ~390 RRC Connected Users in the cell, the individual user was still able to experience ~2
Mbps in good RF conditions
• In summary if we adopt the approach of maximising the RRC Connected User admissions in
the cell, for a smartphone dominated network scenario, the impact on user experience is
likely to be very minimal up to a certain point
• At the same time with this approach we allow voice calls(CSFB & VoLTE) not to be blocked
132
 RRC Connected Users – Approach 2
• This approach mandates that we restrict RRC Connected User numbers beyond a certain
number so as to offer very good user experience but at the cost of RRC Accessibility
• This Connected User number figure can be arrived at looking at trends. For example
 Increase in the DL Latency (ms) beyond a certain measure
 When the DL DRB Data volume starts decreasing at the expense of the DL & UL SRB Data Volume
 DL PRB utilisation starts dipping down at the same time as the PDCCH usage plateaus
• This approach however will lead to blocked Voice Calls (CSFB & VoLTE)

133
RRC Connected Users - Recommendations
• Given the fact Approach 2 can lead to voice call blocking and the fact for a smartphone
network the impact of increasing number of users is not that drastic up to a certain point, it
is recommended that Approach 1 is followed
• However to assuage the impact of growing number of users, Telefónica OBs could earmark a
certain Average DL User Throughput as a trigger point for taking capacity alleviation
measures like additional frequency layer, increased sectorisation, small cells, new macro-site
etc. This will maintain the User data experience
• For example, if the Link-budget is dimensioned for meeting 1Mbps at the cell edge we could
target 1 Mbps. For a full buffer scenario this would be 10 Buffered Users for 10 MHz.
• However for Bursty traffic we could make an assumption of 75% loading and hence this
number would be ~28 Buffered users. Hence if a cell reaches ~28 Buffered users in the busy
hour, we can add to this a site list which requires future capacity upgrade
• Overall Approach 1 is a safer approach to avoid poor voice experience. There are upcoming
features which resolve this issue but we need Release 12 devices (Appendix VIII)
134
RRC Connected Users – Approach 1 (I)
• Approach 1 is about maximising the RRC Connected Users in order to avoid Voice Call
Blocking and achieve high RRC Accessibility.
• The maximum allowed users per cell/site is vendor dependant and the following slides
provide some examples of this approach as followed in Telefónica UK.
• In case of some vendors like E///, the RRC users is a eNB license
• In the following slides it has been assumed that
eNB license is not a limiting factor as all the
new RAN contracts in the different TEF OBs are
looking to maximise this aspect
• The basic methodology is as shown in the
picture i.e. there is a base-line design and a few
upgrade steps and based on defined triggers,
these upgrades are activated based on the
trigger
135
RRC Connected Users – Approach 1 (II)
• Different vendors have different capabilities for the RRC Connected user capacity for their base-
band products. With the assumption that RRC User licenses will be maxed out in a eNB (for
vendors like E/// where this is applicable), this process then becomes a cell level
• In spite of being a cell level process, it is recommended that when an individual cell triggers all
cells should be upgraded
• It is recommended that trigger criteria should be satisfied for a duration of 2-3 weeks at least to
rule out upgrades due to transient spikes and also not to have more than 3 upgrade steps for the
user numbers to minimise the number of different configurations in the network
• Every upgrade in the user numbers in a cell needs its set of parameter changes especially the
PUCCH and hence the PUCCH calculators for the individual vendors in Section 5 should be used to
arrive at the new set of parameters. Following slides highlights examples from Nokia & E///
• After the final upgrade step has been reached and there is still a requirement for further capacity
increase, possible options could be adding a frequency layer on the site, tactical changes like
reducing the Inactivity Timer, Load Balancing, Down-tilting of sites, RS De-boost etc. with the final
option being of adding a new site
136
RRC Connected Users – ERICSSON Example (I)
• The following example is for a eNB with 3 cells with 10Mhz channel BW & using DUS 31
• From the base-band section it can be ascertained that DUS31 can support a maximum
number of RRC Connected users of 2500
• As mentioned before, with the new RAN contracts the license aspect is expected to be
maximised i.e. the DUS 31 BB card should have all the 2500 users licenses enabled. In case
the number of licenses need to be checked the following counter can be use.
 pmLicConnectedUsersMax
• Also assuming an equal split in the RRC Connected user numbers across the 3 sectors we
would have a maximum of 800 RRC Connected users per cell. It is possible to have unequal
RRC user split across the 3 sectors of a site
Base-Line Design Upgrade Step 1 Final Upgrade

Trigger Trigger
250 RRC users Criteria 500 RRC Users Criteria
800 RRC Users

137
RRC Connected Users – ERICSSON Example (II)
• The Trigger criterion is the PUCCH Resources available in a cell as the PUCCH resources are
intrinsically linked to the RRC Connected Users and each RRC Connected user needs PUCCH
resources
• PUCCH resources can be monitored using the counter pmRrcConnMax. PUCCH Resources in
a call can be configured using the parameters noOfPucchCqiUsers and noOfPucchSrUsers. Please
use the embedded E/// PUCCH Calculator Section XX to dimension the parameters accurately for
each step
• A potential trigger is when the cell utilises 90% of the PUCCH capacity in the cell as shown
below. It has to be borne in mind that for more complex site configurations with multiple
frequencies with different bandwidths, there might be a requirement to have unequal
distribution of users across different cells from different bands
Upgrade Step 1 Final Upgrade
Base-Line Design

250 RRC users 500 RRC users 800 RRC users

225 PUCCH 450 PUCCH
noOfPucchCqiUsers = 250 noOfPucchCqiUsers = 500 resources used
noOfPucchCqiUsers = 800
resources used
noOfPucchSrUsers = 250 noOfPucchSrUsers = 500 noOfPucchSrUsers = 800

138
RRC Connected Users – NOKIA Example (I)
• The following example is for a eNB with 3 cells using FSMF with 10 MHz channel BW
• From the base-band section it can be ascertained that FSMF can support a maximum
number of RRC Connected users of 600/cell. In NOKIA base-band implementation, there is
no concept of eNB User licenses.
• Counter to measure the max RRC Connected Users/cell = M8001C200 (RRC_CONN_UE MAX)
• Some assumptions have been made like CQI Reporting period of 40ms & Scheduling
Request Period of 10ms
• Please use the embedded NOKIA PUCCH Calculator in Section 5 for calculating the
parameters for each step. Example Parameter configurations are shown in the next slide
Base-Line Design Upgrade Step 1 Final Upgrade

200 RRC users Trigger 400 RRC Users Trigger 600 RRC Users
6 PUCCH PRBs Criteria
8 PUCCH PRB Criteria 10 PUCCH PRBs

139
RRC Connected Users – NOKIA Example (II)
• The Trigger criterion can be 90% utilisation of RRC Connected User capacity in a cell as
measured from the counter M8001C200 (RRC_CONN_UE MAX)
• NOKIA typically has more operator configurable parameters than ERICSSON. The parameter
details and example values are as shown in the figure below
• In reality we might wish to reserve some RRC connection capacity for incoming handovers
but that is down to the individual Telefónica OBs. In this example no RRC Connections have
been reserved for Incoming Handovers
Upgrade Step 1 Final Upgrade
Base-Line Design

200 RRC Connected Users 400 RRC Connected Users 600 RRC Connected Users
maxNumRrc =200 maxNumRrc =400 maxNumRrc =600
maxNumActUE = 200 180 RRC maxNumActUE = 400 360 RRC maxNumActUE = 600
maxNumRrcEmergency = 200 Users maxNumRrcEmergency = 400 Users maxNumRrcEmergency = 600
n1PucchAn = 36 n1PucchAn = 72 n1PucchAn = 72
nCqiRb = 2 nCqiRb = 4 nCqiRb = 5
PrachFreqOffset = 3 or 41 PrachFreqOffset = 4or 40 PrachFreqOffset = 5or 439

140
Base-Band Throughput License
• For some vendors like ERICSSON there is an additional license requirement for activating DL
& UL Throughput licenses in the base-band. In E/// the maximum base-band capacity,
defined as the maximum simultaneous throughput per eNode B is dictated by the capacity
of the base-band itself and by a hardware activation code. The lowest of the 2 applies…
• Baseband capacity (in terms of simultaneous throughput across all cells) is monitored
separately for the downlink and uplink using counter pmLicDlCapActual for the downlink
and pmLicUlCapActual for the uplink
• These counters show is the % of the licensed capacity that 90% of samples utilise
• It is expected that as this is a eNB license this would be maximised for a particular BB
hardware with the new RAN SW contracts
• For example for ERICSSON DUS31 BB card, the maximum DL & UL BB Throughput is 350
Mbps and 150 Mbps respectively and it is expected to maximise eNB licenses to these
maximum values to remove the throughput limitation
141
Random Access Channel Capacity
• Random Access Procedure has been discussed in detail in the Section 6
• The random access channel uses a combination of contention based and non-contention
based pre-ambles. High load for contention based preambles will lead to increased
numbers of collisions and subsequent re-attempts.
• High load for non-contention based preambles will lead to the use of contention based
preambles for procedures which usually benefit from non-contention based preambles

• It is not very easy to measure Random Access

Usage and Congestion with all vendors.
• As we know from the Section 5 that the
default recommended design is to have 1
PRACH instance in one 10ms radio frame
• The following slides highlight the processes
that need to be used for NOKIA and ERICSSON
PRACH 142
Random Access Channel Capacity – NOKIA Example (I)
• For Nokia the following counters can be used for detecting congestion
 M8001C6 - RACH_STP_ATT_SMALL_MSG (Typical value > 180000 per hour) Trigger
 M8001C7 - RACH_STP_ATT_LARGE_MSG (Typical Value > 72000 per hour) Criteria
 M8001C424 - D-PREAMB_UNAVAIL (Typical Value > 0)
• The limiting numbers for the first 2 network counters is derived at using the excel tool
shown in the following slide for 1% probability of preamble collision
• Other assumptions made in this example are : 800 MHz with cell Range of 22Km i.e. PRACH
Format 1 & RSI planning at eNB level

Base-Line Design Upgrade Step 1

1xPRACH 2xPRACH
prachConfIndex prachConfIndex
• Sector 1 = 19 Trigger • Sector 1 = 22
• Sector 2 = 20 Criteria • Sector 2 = 23
• Sector 3 = 21 • Sector 3 = 24
143
Random Access Dimensioning Tool
• The attached excel tool helps to dimension the PRACH Capacity and predicts the collision
probability of the preambles and hence the need for a capacity upgrade

• The tool captures the NOKIA network counters

mentioned in the previous slide

144
PRACH Dimensioning Tool – NOKIA Counters
• Depending on the Telefónica OB requirement the
network counters can also be used to plan the
PRACH Upgrade
145
Can be set based upon counter results:
(M8001C6+M8001C7) / 3600, assuming a 1 hour
measurement period. Alternatively, can be set based
upon future traffic expectation.
Can be set based upon counter results:
100 * M8001C6 / (M8001C6+M8001C7).
Alternatively, can be set based upon future traffic
expectation.
Can be set based upon counter results:
(M8001C286) / 3600, assuming a 1 hour
measurement period.
Alternatively, can be set based upon future traffic
expectation. THIS IS NOT USED AS SUCH AS
WE LOOK AT THE DEDICATED PREAMBLE
UNAVAILIBILITY
1 % preamble collision target for CBRA
0 % preamble collision target for CBRA
Random Access Channel Capacity – ERICSSON (I)
• In Ericsson implementation, the options to measure PRACH congestion and remedial
measures are quite limited. Moreover E/// do not support the possibility of more than
PRACH instance in one radio frame
• In the Ericsson implementation the CBRA and CFRA pool sizes are fixed with system
constant parameters to 52 and 12 respectively as explained in Section 6
• CBRA Success Rate KPI is also unreliable measure of the real performance as it is usually
quite low.
• The following slides explain the recommended process for E/// using a combination of the
tool and the PRACH excel tool
• Ericsson have the basic option of having all the 64 preambles in the CBRA pool and CFRA is
not used at all
• As mentioned in section 6 the recommendation is to switch ON feature (cfraEnabled)

146
Random Access Channel Capacity – ERICSSON (II)
• This process explains the options for detecting PRACH issues and the solutions for Ericsson
• Step 1 – To calculate the number of CBRA attempts & CFRA attempts with the following
formula using the network counters
 𝐶𝐵𝑅𝐴 𝐴𝑡𝑡𝑒𝑚𝑝𝑡𝑠 = 𝑝𝑚𝑅𝑎𝐴𝑡𝑡𝐶𝑏𝑟𝑎 ∗ (1 − (𝑝𝑚𝑅𝑎𝑈𝑛𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑𝐶𝑓𝑟𝑎𝐹𝑎𝑙𝑠𝑒) ÷ 𝑝𝑚𝑅𝑎𝑈𝑛𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑𝐶𝑓𝑟𝑎𝑆𝑢𝑚 − 𝐶𝐵𝑅𝐴𝐷𝐼𝑆𝐶
𝑊ℎ𝑒𝑟𝑒 𝐶𝐵𝑅𝐴𝐷𝐼𝑆𝐶 = 𝑝𝑚𝑅𝑎𝐹𝑎𝑖𝑙𝐶𝑏𝑟𝑎𝑀𝑠𝑔2𝐷𝑖𝑠𝑐 + 𝑝𝑚𝑅𝑎𝑓𝑎𝑖𝑙𝐶𝑏𝑟𝑎𝑀𝑠𝑔1𝐷𝑖𝑠𝑐𝑆𝑐ℎ𝑒𝑑 + 𝑝𝑚𝑅𝑎𝐹𝑎𝑖𝑙CbraMsg1DiscOoc
 𝐶𝐹𝑅𝐴 𝐴𝑡𝑡𝑒𝑚𝑝𝑡𝑠 = 𝑝𝑚𝑅𝑎𝐴𝑡𝑡𝐶𝑓𝑟𝑎 ∗ (1 − (𝑝𝑚𝑅𝑎𝑈𝑛𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑𝐶𝑓𝑟𝑎𝐹𝑎𝑙𝑠𝑒) ÷ 𝑝𝑚𝑅𝑎𝑈𝑛𝑎𝑠𝑠𝑖𝑔𝑛𝑒𝑑𝐶𝑓𝑟𝑎𝑆𝑢𝑚 − 𝐶𝐹𝑅𝐴𝐷𝐼𝑆𝐶
Where CFRADISC = 𝑝𝑚𝑅𝑎𝐹𝑎𝑖𝑙𝐶𝑓𝑟𝑎𝑀𝑠𝑔2𝐷𝑖𝑠𝑐 + 𝑝𝑚𝑅𝑎𝑓𝑎𝑖𝑙𝐶𝑓𝑟𝑎𝑀𝑠𝑔1𝐷𝑖𝑠𝑐𝑆𝑐ℎ𝑒𝑑 + 𝑝𝑚𝑅𝑎𝐹𝑎𝑖𝑙CfraMsg1DiscOoc

• Use the these attempts values as inputs to the simulator excel tool

147
Random Access Channel Capacity – ERICSSON (III)
Can be set based upon counter results:
(CBRA Attempts) / 3600, assuming a 1 hour
measurement period. Alternatively, can be set based
upon future traffic expectation.

E/// only have one CBRA pool

Can be set based upon counter results:

(CFRA Attempts) / 3600, assuming a 1 hour
measurement period. Alternatively, can be set based
upon future traffic expectation.

System Constants. Please refer to Section 4

1 % preamble collision target for CBRA

0 % preamble collision target for CBRA

• If the targets are not being met in one or the other pool then a possible option is to
request E/// to change the pool sizes using the system constant parameters.
148
Random Access Channel Capacity – ERICSSON (IV)
• The other option which is recommended is to turn on the Dynamic PRACH Back Off Feature
which starts backing off PRACHmsg1 if there are collisions
• Feature ID – FAJ 121 4299
• The effectiveness of the feature can be gauged by the pdf distribution counter
• pmRaBackoffDistr
PDF ranges:
[0]: 0 ms
[1]: [1..10] ms
[2]: [11..20] ms
[3]: [21..30] ms
[4]: [31..40] ms
[5]: [41..60] ms
[6]: [61..80] ms
[7]: [81..120] ms
[8]: [121..160] ms
[9]: [161..240] ms
[10] [241..320] ms
[11]: [321..480] ms
[12]: > 480 ms
149
Random Access Channel Capacity – Huawei (I)
• Huawei have 4 principal features to address the planning the dimensioning of the PRACH
channel. With the activation of these features, there is no need to have a capacity upgrade
process.

150
Random Access Channel Capacity – Huawei(II)
• Dynamic RACH Resource Adjustment - With this feature, the eNB is able to determine
whether the pool sizes for the Contention based Random Access and Contention Free
Random Access is sufficient or not and adjusts the pool sizes automatically
• The other aspect of this feature is also that it increases the PRACH density based on the cell
load i.e. increases the PRACH frequency in the time domain

• Parameter
 RachAlgo.Switch.RachAdjSwitch – Huawei recommended value is “ON”

151
Random Access Channel Capacity – Huawei(III)
• PRACH Frequency Position Adjustment – This is also referred to as Dynamic PUCCH. With
this feature when there are low number of users and hence low number of PUCCH Resource
Blocks, the PRACH is placed at more or centre of the spectrum which increases the PUSCH
efficiency. Once the number of users crosses a certain threshold the PRACH is moved back
to a position which is adjacent to the PUCCH

• Parameter
 RachAigoSwitch.PrachFreqAdjSwitch - Huawei recommended value is “ON”
152
Random Access Channel Capacity – Huawei(IV)
• Flow Control Back Off – With this feature the eNB adjusts the back-off index based on
statistics on Msg3 flow control every second
Msg3 Flow Control Back Off Index Adjustment
When both the following conditions are met:
(Flow Control Msg3 quantity / Received Msg3 quantity) > 5%
The eNB increases the value of the back-off index
(Number of UEs in a cell / Maximum number of UEs in a cell) > 40%

When either of the following conditions are met:

Flow Control Msg3 quantity = 0
The eNB decreases the value of the back-off Index
(Number of UEs in a cell/Maximum number of UEs in a cell) <= 40%

Other Conditions The eNB does not change the value of the back-off index

• Parameter to activate the feature (The Huawei recommendation is not to turn this feature
ON as a Default setting)
 HighLoadNetOptSwitch.FlowCtrlTriBackoffSwitch

153
Random Access Channel Capacity – Huawei(V)
• PRACH Root Sequence Conflict Detection – If the PRACH time and Frequency Resources of
the serving cell overlap with those of the neighbouring cell, then this feature helps in
providing the conflict detection mechanism

154
Paging
• As detailed in the Section 6, that the default recommended Paging Capacity should be 400
Pages per second
• Paging Overload is measured differently in different vendors. For example in NOKIA, there is
a counter to measure the DISACRDED PAGES i.e. Pages which had to be discarded by the
eNB owing to not enough Paging Capacity in the air-interface
 M8008C2 DISC_RRC_PAGING
• For E/// the paging discard counter is the following
 pmPagDiscarded
• For Huawei, the paging discard counter is as follows
 L.Paging.Dis.PchCong (Please do not use the L.Paging.Dis.Num)
• Ideally we would like to trigger the Paging Capacity Upgrade process prior to Paging
Discards.
• The following slides show examples for NOKIA & ERICSSON for paging capacity upgrade
155
Paging Capacity Upgrade – NOKIA Example
• The base-line design of 400 Pages per second can be arrived at with the nB set to T/4 for a
channel bandwidth of say 10 MHz which implies that there is one Paging sub-frame every 4
Radio Frames i.e. 40ms
• In NOKIA we have network counter M8008C2 – DISC_RRC_Paging which can be used to
upgrade the Paging Capacity
• The Paging Capacity can be upgraded when discards are measured. At the moment the
recommendation is not to exceed more than 1 sub-frame per radio frame i.e. higher than a
value of “T” for the nB parameter although it can be increased as Paging Capacity increase
starts impacting the DL Data Throughput
Base-Line Design Upgrade Step 1 Upgrade Step 2

Paging Frame Paging Frame

Paging Frame
every 20ms every 10ms
every 40ms
Discard > 0 Discard > 0
• PagingNb = T/4 • PagingNb = T/2 • PagingNb = T

156
Paging Capacity Upgrade – ERICSSON Example
• For ERICSSON the counter to measure Paging discards is the following pmPagDiscarded
which is a subset of the counter pmPagReceived and counts the number of Paging Requests
which had to be discarded by the eNB
• A similar example as shown in the NOKIA case is highlighted here below
• There are some aspersions for ERICSSON that sometimes there are discarded pages not
owing to increased paging load but due to overloading of the CPU. Therefore an alternative
method for estimating Paging Congestion is highlighted in following slides which can be
used for both the vendors
Base-Line Design Upgrade Step 1 Upgrade Step 2

Paging Frame Paging Frame

Paging Frame
every 20ms every 10ms
every 40ms
Discard > 0 Discard > 0
• PagingNb = T/4 • PagingNb = T/2 • PagingNb = T

157
Alternate Paging Congestion Detection Methodology
• This tool calculates the probability of Paging Discards from the Paging Capacity and the
average number of S1AP: Paging Requests being received by the eNB

Ericsson Counter – pmPagReceived

NOKIA Counter – M8008C1 – RRC_Paging_Requests

Default Paging Cycle

Target Discard Ratio (Typically 0.1%)

158
Paging Capacity- Remedial Measures
• Once the decision has been arrived at that the Paging Capacity needs upgrading what are
the options which can be pursued…
 Increasing Air-interface Capacity – Increasing the number of Paging sub-frames in a given period of
time. For example, for the recommended starting capacity of 400 Pages/second, we have 1 paging
sub-frame every 4 radio frames (40ms) i.e. nB =T/4. To increase air-interface capacity this can be
increased to one Paging sub-frame every 20ms i.e. (nB=T/2)
 TAC Split – This will reduce the number of e Node Bs in a TAC and hence reduce the Paging Load
on the air-interface. A key point here is that we do not wish to end up with very small TACs i.e.
TACs < 50 eNB. Hence this option is not a good option if the TAC sizes are already small enough
• As mentioned in Section 5, all Telefónica OBs should look to enable the Adaptive Paging
Feature. This should lead to big reduction in Paging Load as ~85% Pages are for Data.
• Following on from the deployment of Adaptive Feature, the Air-interface Capacity increase
should be used and TAC split being the last option if the TACs are already small enough
(50<TAC size<75)
159
PDCCH Capacity
• As mentioned in the earlier section that high PDCCH utilisation does not result in hard
blocking but can result in degraded performance in terms of user throughput, increased
latency, increase in drops and poor random access success rate
• As the maximum capacity of the PDCCH is governed by the standards and the current
design automatically adjusts to this maximum capacity according to load, there are no
corrective actions for PDCCH capacity shortage from a parameter point of view.
• PDCCH capacity is very important when introducing VoLTE as otherwise the data user
experience starts getting degraded
• If PDCCH capacity is an issue then other solutions to add capacity must be examined. These
could be….
 Down tilting to reduce area of coverage,
 Additional site, additional carriers
 6 sector (assuming solution is available) etc.
 Small cells

160
Hot-Spots Dimensioning – Summary(I)
• There are 5 Key areas for Hot-Spot Management viz.
 RRC Connected Users – All new RAN SW Contracts will have the licenses maxed out for the BB hardware
 Base-band Capacity (wherever applicable) – Same as above
 PRACH Capacity
 Paging Capacity
 PUCCH Capacity (wherever applicable)
 PDCCH Capacity
• RRC Connected Users is a very important aspect and although the general user experience is
likely to degrade by admitting more users
• As we do not have a separate RRC cause for CSFB/VoLTE (which will lead to voice blocking if
we start restricting users) and the fact that in a smartphone dominated network the
amount of data per user is very small, hence it is recommended to maximise Accessibility
for the current moment till such time when we have a very high penetration of Rel. 12
devices. Need to bear in mind the user experience degradation as well
161
Hot-Spots Dimensioning – Summary(II)
• PUCCH Dimensioning is intrinsically linked to the RRC User capacity in a cell and should
match the user capacity
• PRACH Load should be monitored using counters and the PRACH capacity increased likewise
when required. It has to be borne in mind that Ericsson do not support more than 1 PRACH
instance in a radio frame and therefore in case of Ericsson we have to use the Dynamic
PRACH backoff feature or would have to plan another site or a small cell
• Paging is also an important hot-spot measure and as required Paging Capacity should be
increased rather than reducing the area of the tracking area. In the long term Adaptive
Paging feature (or equivalent) should be activated in the MME
• PDCCH Congestion although not a hard blocking will impact the data experience and more
so in the case of VoLTE as voice packets will be discarded if they cannot be scheduled by the
eNB within ~100ms. PDCCH cannot be increased to more than 4 symbols in a cell and hence
the option is plan a new site which is more likely to be a few small cells in the coverage area
of the macro-cell
162
11
Appendix I – Link- Budget
Example Calculation

163
Link Budget Calculations
• This section provides the details of the link budget calculations with an example UL and DL
service
• The following have been covered
 UL Link-Budget Calculations
 DL Link-Budget Calculations
 Maximum Allowed Path Loss
 Coverage Planning Threshold
 VoLTE Link-Budget Example
• As mentioned in Section 2 that the VoLTE SINR tables are being re-evaluated and at some
point new SINR values will be available for VoLTE

164
Uplink Link Budget - Transmitter
Average Tx Power
• Corresponds to the power class of the UE
Link Budget Parameter Value
• Currently only power class 3 used (23 dBm)
Average Tx Power (dBm) 23
• Power class 1 (31 dBm) standardised for
operating band 14 (intended for public Tx Antenna Gain (dBi) 0

safety applications) Cable/Combiner/Body Losses (dB) 0

Tx Antenna Gain Tx EIRP (dBm) 23

• Typically assumed to be 0 dBi for a handset

Tx EIRP
Cable/Combiner/Body Losses
• Combination of other parameters,
• Typically assumed to be 0 dB for a handset i.e. 23 + 0 - 0 = 23 dBm
using a data service (device held away from
body)
165
UE Categories & TX Power
• 3GPP has specified only one power class for the UE (36.101) – 23 dBm

166
Uplink Link Budget – Receiver (I)

Rx Antenna Gain Link Budget Parameter Without

• Reflects the base station antenna MHA
gain Rx Antenna Gain (dBi) 16

• Will depend upon the operating MHA Gain (dB) -

band Rx Feeder Loss (dB) 3
• Higher operating bands tend to have
Diversity Gain (dB) 2
more directional antenna with higher
antenna gains Receiver System Gain (dB) 15

Combination of other parameters

167
Uplink Link Budget – Receiver (II)

Rx Feeder Loss
• Reflects the sum of all uplink losses belonging to the base station antenna sub-
system
• Will depend upon the design of the antenna sub-system
 Connectors and combiners will increase losses
 Remote Radio Heads (RRH) can remove requirement for feeder
 feeder type will impact the loss per meter

168
Uplink Link Budget – Receiver (III)
MHA Gain
• Common and simplistic assumption is that MHA fully compensates the Rx Feeder
Loss
• More accurate and complex analysis can be completed using Friis’ equation
without MHA with MHA
Noise figure • Friis’ equation
reference point calculates the
MHA composite noise
figure for the
antenna sub-
BTS Noise figure BTS system
reference point

169
Uplink Link Budget – Receiver (IV)
Friis’ Equation

with MHA
without MHA Simplistic approach: 3 dB composite Noise Figure
6.5 dB composite Noise Figure Friis’ approach: 2.6 dB composite Noise Figure

12 dB Gain
3.5 dB losses MHA 2 dB Noise Figure
3.5 dB losses
BTS BTS
3 dB BTS Noise Figure 3 dB BTS Noise Figure
170
Uplink Link Budget – Receiver (V)

Diversity Gain
• Inclusion depends upon the definition of the Target SINR Requirements
• Target SINR figures may already include the benefit of uplink receive diversity
• A separate UL diversity gain has been applied of 2 dB has been applied in the
calculations

171
Uplink Link Budget – Receiver Sensitivity (I)
Link Budget Parameter Value

Thermal Noise Density Thermal Noise Density (dBm/Hz) -174

• Calculated as 10*LOG(kT) + 30 Receiver Noise Figure (dB) 3

• Assuming temperature of 290 K # of Resource Blocks 8
Receiver Noise Figure Channel Bandwidth (Hz) 1 440 000
• Dependent upon network vendor Target SINR (dB) -2.5 dB
• Generic value of 3 dB assumed Receiver Sensitivity (dBm) -111.9
here (Simplistic Approach)

Thermal Noise Density + Receiver Noise Figure +

( 10 *LOG10( Channel Bandwidth )) + Target SINR

172
Uplink Link Budget – Receiver Sensitivity (II)
# of Resource Blocks
• Assumed number of Resource Blocks
allocated to connection
• link adaptation allocates a reduced
number of uplink Resource Blocks for UE
at cell edge
• Allows UE to focus transmit power
capability across smaller bandwidth
• Telefónica UK uses look-up table to
identify appropriate figure
500 kbps uplink assumed for
• Please note no MIMO in the UL
example in these slides
Channel Bandwidth
• Calculated from Resource Block bandwidth of 180 kHz
173
Uplink Link Budget – Receiver Sensitivity (III)
Target SINR
• Derived from link level simulations
• Value is selected according to the target cell edge throughput requirement
• Telefónica UK uses the look-up table shown below

500 kbps uplink assumed for

example in these slides
174
Uplink Link Budget – Required Received Level (I)

Thermal Noise Density (-174 dBm) + Link Budget Parameter Value

Noise Figure (3 dB) + Interference to
Interference to Thermal Noise Ratio (dB) -2.3
Thermal Noise Ratio (-2.3 dB)
Interference Density (dBm/Hz) -173.3
8 PRBs
Total Effective Noise + Interference (dBm/Hz) -169.0
Sum of Noise Power + Total Noise + Interference Power (dBm) -107.4
Interference Power
Required Received Signal Level (dBm) -109.9

Total Effective Noise + Interference

scaled to the channel bandwidth Sum of Total Noise + Interference Power
and SINR Target
175
Uplink Link Budget - Required Received Level (II)
Interference to Thermal Noise Ratio
• Used to account for inter-cell interference generated by network load
• Calculated as: 10 * LOG [ Uplink Cell Load / (1 – Uplink Cell Load) ]
• Figure of -2.3 dB corresponds to an 10

Interference to Thermal Noise Ratio (dB)

assumed 37% uplink cell load 5

 Indicates that interference floor is 0

below thermal noise floor
-5
 50 % load generates an interference
floor which equals thermal noise -10

-15
0 10 20 30 40 50 60 70 80 90
Cell Load (%)

176
Uplink Link Budget – Margins Link Budget Parameter Value

Penetration Loss (dB) 20

Penetration Loss
Penetration Loss Margin (sd) (dB) 6
• Dependent upon the local building
materials and target coverage area Slow Fade Margin (sd) (dB) 8
(indoor, outdoor, in-car, in-train) Path Loss Exponent 3.5
Penetration Loss Margin Cell Area Probability 0.98
• Standard deviation of penetration loss, Cell Edge Probability 0.945
i.e. the actual experienced penetration
loss has some variance and is not Fade Margin (dB) 15.9
constant Interference Margin 0
Slow Fade Margin Coverage Threshold (dBm) -73.9
• Standard deviation of slow fading
(assumed to be log-normal fading) Sum of Interference Margin, Fade Margin,
Penetration Loss and Required Received
177 Signal Level
Uplink Link Budget – Margins (II)
Path Loss Exponent
• Rate of path loss increase as a function of distance
Cell Area Probability
• Target coverage probability requirement
• Should be defined as part of the service deployment strategy
Cell Edge Probability
• The coverage probability at cell edge calculated from the cell area probability
Fade Margin
• The slow fading margin calculated from the cell edge probability, the penetration loss
standard deviation and the slow fade standard deviation

178
Uplink Link Budget – Margins (III)
• Log normal distribution used to calculate the Fade Margin for a specific standard deviation
and cell edge availability requirement
• Fade Margin = {SQRT(building penetration Standard Dev.2 + Slow Fading Standard Dev.2) +
NORMSINV(Cell Edge Probability)}
Area under this
part of the curve
represents ‘service Area under this
availability’ part of the curve
represents ‘service
unavailability’

Standard Standard
deviation deviation

Fade Margin
179
Uplink Link Budget - MAPL
• The Uplink Maximum Allowed Path Loss is calculated as:

Maximum Allowed Path Loss = TX EIRP + Receiver System Gain – Coverage Threshold

• In this example, the result is 111.9 dB

• Requirement to compare with downlink result prior to defining maximum cell ranges
and planning thresholds

180
Downlink Link Budget - Transmitter
Average Tx Power
Link Budget Parameter Value
• Corresponds to the base station downlink
Average Tx Power (dBm) 43
transmit power from a single power amplifier
Tx Antenna Gain Tx Antenna Gain (dBi) 16

• Equal to the base station antenna gain assumed Tx Feeder Loss (dB) 3
for the uplink link budget Transmit Power Gain (dB) 2
Tx Feeder Loss Tx EIRP (dBm) 58
• Reflects the sum of all downlink losses belonging
to the base station antenna sub-system
Transmit Power Gain Combination of Tx Power,
Antenna Gain, Feeder Loss
• Gain provided by spatial diversity at cell edge
and Transmit Power Gain
(benefit of using MIMO)

181
Downlink Link Budget - Receiver

Rx Antenna Gain
• Equal to the terminal antenna gain
assumed for the uplink link budget Link Budget Parameter Value
Cable/Combiner/Body Losses Rx Antenna Gain (dBi) 0
• Equal to the terminal cable and Cable/Combiner/Body Losses (dB) 0
combiner losses assumed for the
Diversity Gain (dB) 1
uplink link budget
Diversity Gain Receiver System Gain (dB) 1

• Can be used to account for downlink

receive diversity
Combination of other parameters

182
Downlink Link Budget – Receiver Sensitivity (I)
Link Budget Parameter Value

Thermal Noise Density Thermal Noise Density (dBm/Hz) -174

• Calculated as 10*LOG(kT) + 30 Receiver Noise Figure (dB) 8

• Assuming temperature of 290 K # of Resource Blocks 50

Receiver Noise Figure Channel Bandwidth (Hz) 9 000 000

• Dependent upon UE model Target SINR (dB) -5.3 dB

• Generic value of 8 dB assumed Receiver Sensitivity (dBm) -101.7
here
Thermal Noise Density + Receiver Noise Figure +
( 10 *LOG10( Channel Bandwidth )) + Target SINR

183
Downlink Link Budget - Receiver Sensitivity (II)

# of Resource Blocks
• Assumed number of Resource Blocks allocated to connection
• Maximum value assumed because maximum downlink transmit power is
assumed

Channel Bandwidth
• Calculated from Resource Block bandwidth of 180 kHz

184
Downlink Link Budget - Receiver Sensitivity (III)
Target SINR
• Derived from link level simulations
• Value is selected according to the target cell edge throughput requirement
• Telefónica UK uses the look-up table shown below

1 Mbps assumed in the

downlink for this example

185
Downlink Link Budget – Required Signal Level (I)

Thermal Noise Density (-174 dBm) + Link Budget Parameter Value

Noise Figure (3 dB) + Interference to
Interference to Thermal Noise Ratio (dB) 1.8
Thermal Noise Ratio (-2.3 dB)
Interference Noise Density (dBm/Hz) -164.2

Total Effective Noise + Interference (dBm/Hz) -162.0

Sum of Noise Power + Total Noise + Interference Power (dBm) -92.5
Interference Power
Required Received Signal Level (dBm) -97.8

Total Effective Noise + Interference

scaled to the channel bandwidth Sum of Total Noise + Interference Power
and SINR Target
186
Downlink Link Budget - Required Signal Level (II)
Interference to Thermal Noise Ratio
• Used to account for inter-cell interference generated by network load
• Calculated as: 10 * LOG [ Downlink Cell Load / (1 – Downlink Cell Load) ]

• Figure of 1.8 dB corresponds to an

10

Interference to Thermal Noise Ratio (dB)

assumed 60% downlink cell load 5

 Indicates that interference floor is 0

above thermal noise floor

-5

 50 % load generates an interference

-10
floor which equals thermal noise
-15
0 10 20 30 40 50 60 70 80 90
Cell Load (%)

187
DL Link Budget - Margins Link Budget Parameter Value

Penetration Loss (dB) 20

Penetration Loss
Penetration Loss Margin (sd) (dB) 6
• Dependent upon the local building
Slow Fade Margin (sd) (dB) 8
materials and target coverage area
(indoor, outdoor, in-car, in-train) Path Loss Exponent 3.5
Penetration Loss Margin Cell Area Probability 0.98
• Standard deviation of penetration loss, Cell Edge Probability 0.945
i.e. the actual experienced penetration
Fade Margin (dB) 15.9
loss has some variance and is not
constant Interference Margin 0

Slow Fade Margin Coverage Threshold (dBm) -61.8

• Standard deviation of slow fading

(assumed to be log-normal fading) Sum of Interference Margin, Fade
Margin, Penetration Loss and Required
188 Received Signal Level
Downlink Link Budget – Margins (II)
Path Loss Exponent
• Rate of path loss increase as a function of distance
Cell Area Probability
• Target coverage probability requirement
• Should be defined as part of the service deployment strategy
Cell Edge Probability
• The coverage probability at cell edge calculated from the cell area probability
Fade Margin
• The slow fading margin calculated from the cell edge probability, the
penetration loss standard deviation and the slow fade standard deviation

189
Downlink Link Budget - MAPL

• The Downlink Maximum Allowed Path Loss is calculated as:

Maximum Allowed Path Loss = TX EIRP + Receiver System Gain – Coverage Threshold

• In this example, the result is 120.8 dB

• Requirement to compare with uplink result prior to defining maximum cell ranges and
planning thresholds

190
Link Budget – Dominant MAPL
• The minimum of the uplink and downlink Maximum Allowed Path Loss results should be
selected
Uplink Downlink
(500 kbps) (1 Mbps)
Maximum Allowed Path Loss (dB) 111.9 120.8

• In this example, the dominant maximum allowed path loss is 111.9 dB i.e. UL is the
limiting link
 This result will vary according to the selected uplink and downlink bit rates
• This result can then be translated into:
 Maximum cell range for dimensioning
 Coverage threshold for planning

191
Link Budget – Maximum Cell Range (I)

• Translating the maximum allowed

path loss into a cell range
requires a path loss model
• Result will depend upon antenna
height assumptions and
operating band
• Typical base station antenna
height likely to depend upon the
country of deployment

192
Link Budget – Maximum Cell Range (II)
• An example of the translation from path loss to cell range is shown below
 L800 operating band
 15 m base station antenna height, 1.5 m UE antenna height
 Urban Hata 1500 path loss model

120.8 dB • Resultant cell range is 343 m based

Downlink
1 Mbps upon the requirement to provide 500
111.9 dB
kbps in the uplink at cell edge
Uplink
500 kbps

343 m

593.9 m
193
Link Budget – Coverage Planning Threshold (I)
• Planning tools use path loss calculations to provide signal strength predictions at each pixel
• Requirement to define a threshold in terms of signal strength so planning tool can identify
cell edge
• Planning tool should have correct site specific antenna gains and feeder losses
 Effectively replace assumptions in link budget

Coverage Threshold = TX Power in Planning Tool - Maximum Allowed Path Loss

+ Base Station Antenna Gain in Link Budget
- Base Station Feeder Loss in Link Budget

194
Link Budget – Coverage Planning Threshold (II)
• DL Reference Signal Power = 15 dBm
• Power Boost = 0 dB
• MAPL (UL Limited) = -111.9 dBm
• Base-station antenna gain = 16 dBi
• Feeder Loss = 3 dB

• Atoll plot RSRP (RS EPRE) level = -83.7 dBm

195
Link Budget - VoLTE
• VoLTE is a low bit rate service so coverage is greater relative to data service
• VoLTE link budgets require changes to the:
 Uplink and downlink SINR targets
 Number of allocated uplink Resource Blocks
• There can also be changes to the assumed body loss if users are expected to hold device
close to ear
• VoLTE link budgets can account for the benefit of TTI Bundling at cell edge
 Reduces the uplink SINR target

196
Link Budget – VoLTE (II)
• Example VoLTE link budget result in terms of cell range is shown below
 Compared with the 500kbps/1Mbps data service

500 kbps UL
1 Mbps DL
Data Service
VoLTE Service
343 m
499.7 m
111.9 dB
118 dB

197
 Appendix II – Telefónica UK

12 Traffic Modelling Process

198
Traffic Forecasting & Modelling – TEF UK Example
• This section provides the example of the Traffic Forecasting and Modelling processes being
currently used in Telefónica UK
• This section has the following information…
 Traffic Forecasting concept
 Analysing Voice and Data Traffic Patterns
 Voice and Traffic Forecasting Methodology
 Traffic Modelling & Site Upgrade count

199
Analysing Voice Traffic Patterns – TEF UK Example
• Voice Traffic continues to grow. It is expected to grow
at the rate of ~40 KErl per year
• Voice Traffic continues to shrink in 2G due users
adopting 3G/4G devices
• Without VoLTE all the 3G/4G device adopters will push
traffic to 3G
• With the Introduction of VoLTE in the network and the
uptake of VoLTE services, the voice traffic will start
moving across to the 4G layer
• This impact of sudden increase in VoLTE traffic on the
4G capacity and data performance needs to be borne
in mind whilst doing future dimensioning of the 4G
network
200
Analysing Data Traffic Patterns (I) Data Traffic
• This section is using the existing trends from the
Telefónica UK network
• 4G Data Volume has overtaken 3G Data Volume as
users once migrated to 4G use data more as 4G
offers a better service
• In the short term 3G Data traffic expected to grow
albeit at much slower rate than 4G Data
• In the long term most of the data expected to be
on the 4G layer with a very high DL:UL asymmetric
ratio(~9:1). This asymmetry ratio is likely to reduce
as sites start congesting (typically ~6:1)
• In addition, the impact of VoLTE would need to be
factored in on the 4G layer as more users adopt
VoLTE service. (Covered in section 9)
201
Analysing Data Traffic Patterns (II) Data Traffic Split

• This slide reiterates the data usage behaviour of 2016

smartphone dominant networks

• The top 28 usage patterns have been shown
2013
• As is the case with smartphone dominant
networks, the majority usage is for Facebook, HTTP
browsing & YouTube
• In the last one year or so Whatsapp has started
picking up big time
• In essence all the data
usage increase is of the
bursty nature which is
typical of smartphone
dominated networks
202
Telefónica UK NTF Example
• Snapshot from the Telefónica UK
Network Traffic Forecast
• VoLTE traffic expected to pick up from
the end of 2016 and rise steadily with
more and more device and tariff uptake

203
Planning for Voice & Data Traffic Growth
• Demand forecasts then made based on past years trends and future plans
• Based on the forecasts, voice is still expected to grow albeit on 3G and 4G only. The graph
below does not factor in growth of 4G voice but it will be a proportion of the 3G voice
• 2G data will plummet, 3G data expected to reach a high watermark and then gradually
decline whilst 4G data expected to grow at ~45Gb/year

204
Example – Data Modelling Process (I)
The main inputs to the model could be the existing 4G DL traffic on the
network and 2G/3G voice traffic.

Spread the existing network traffic through the landmass using coverage,
clutter and voice traffic as a proxy for where people spend their time.

Scale the data traffic using demand forecast and use the clutter and voice
weighting

Map traffic to sites and sectors.

205
Example – Modelling Process (II)

The initial setup of the model is used to name of the input

variables to the model. They contain amongst other things
 Live 4G data DL
 Live 2/3G voice data
 National clutter classifications map
 Live and planned coverage plots

206
Example – Modelling Process (III)
• Based on clutter weightings, 2G and 3G voice grids are
generated by distributing the erlang values across pixels
generated from the existing 2G/3G site locations and
their sector azimuths.
• The same process is repeated now with 4G data i.e. the
existing 4G data is distributed using the weightings
from the previous process i.e. voice weightings

207
Example – Modelling Process (IV)
• Once the base level of traffic demand is there, we need
to grow the traffic in line with where it is predicted to
grow in the future i.e. based on the clutter classification
• This growth can be based on the traffic demand forecast
• At the end of this process we would have a data traffic
map based on future demand

208
Example – Modelling Process (V)
• Once we have the revised data traffic map, we can create
the sector coverage maps
• Each sector is then assigned a certain amount of traffic
based on the coverage of that sector
• This mapping of data to sector will allow us to plan the
site upgrades and new site requirements

209
Example – Modelling Process (VI)
Assess Capacity of
Stage 2: Assess Capacity of sites

existing sites

Generate Site
Upgrade Options

• Example here is shown for Telefónica UK.

• Final site upgrades and new sites dependant on
Generate new site
requirements
budgets
• In Telefonica UK case, the site numbers are governed
by the Beacon Network Sharing agreement
210
Example – Modelling Process (VII)
This module finds candidate locations for small cells to offload the macro
demand for the broken macro-cell sectors and then the micro-cell traffic
is stripped off the macro-cell layer. Certain rules need to be followed

After the traffic offload, macro-cell traffic demand is re-run

After taking into account the traffic carried by upgraded macro-cells and
micro-cells, the remaining traffic is flagged as un-carried traffic

New macro-cells can be planned to carry this un-carried traffic

211
13 Appendix III – Base-band
Dimensioning

212
Control Plane Dimensioning – NOKIA Example
• The figures on this slide show the typical busy hour subscriber model and parameters and
also a C-Plane Loading figure (vis-à-vis transactions/second) from a very mature LTE network
in the far east using FSMF. These figures are for 20 MHz bandwidth for 3 cells

213
NOKIA capability matrix – No. of Cells (FSMF)
• This table was
presented by NOKIA in
the workshop last year
in Munich
• Different combinations
of the FSMF and the
plug in cards (FBBA/C)
are covered for
different bandwidths
• This is for a 2x2 MIMO
and 2Rx IRC
configuration

214
ERICSSON Basic Load Management Feature (I)
• Paging Intensity Control – Load Protection mechanism for MP and the BB resources

 pmPagS1Received
 pmPagS1Discarded

• Base-band & DU Connection Intensity Control – Limits the number of incoming handovers
and Initial Connection Establishments
 pmRrcConnEstabFailMpOverload
 pmRrcConnEstabFailDuIntens
 pmHoPrepRejInMpOverload
 pmHoPrepRejInDuIntens
 pmAdjustAccessMpLoadCtrl

215
ERICSSON Basic Load Management Feature (II)
• Static Cell Connection Intensity Control – Radio Resource Utilisation in a cell. Allows only
predefined number of incoming handovers and initial call establishments
 pmRrcConnEstabFailCellIntensStat
 pmHoPrepRejInCellIntensStat
 pmCellIntensHoRrcConnReqDistr
 pmCellIntensHoReqDistr
 pmCellIntensRrcConnReqDistr
• MP Load Control – Keeps the processor load below a target value. Can control the incoming traffic
(initial establishments and incoming handovers). More details on the next slide..
 pmProcessorCoreLoad
 pmProcessorLoad
 pmProcessorLoadLcDistr

216
ERICSSON Basic Load Management Feature (III)
MP Load Control State Paging RRC Connection Setups and
Handovers
OVERLOAD Discards all incoming paging. Rejects all RRC connection setups and
incoming handovers.

VERY HIGH Rejects more pagings than in the last
measurement interval by decreasing
the permitted intensity limit.
Rejects more RRC connection setups
and more incoming handovers than in
the previous measurement interval by
decreasing the permitted intensity
limit.

HIGH If the permitted intensity limit is not at If the permitted intensity limit is not at
its maximum size, it is increased at its maximum size, it is increased each
each measurement interval until it measurement interval until it reaches
reaches the maximum size. the maximum size.

NOT HIGH Performs overload protection using the Performs overload protection using the
maximum size of the permitted maximum size of the permitted
intensity limit. intensity limit.

217
ERICSSON Basic Load Management Feature (IV)
• Latency Supervision – A load control mechanism used to protect each cell and its air
interface is Procedure Latency Supervision. A number of RRC procedures are time-
supervised and statistics of the measured time of these procedures are collected. When this
measurement indicates that the average latency of the procedures is above a threshold,
overload protection actions are taken. A high latency of these RRC procedures indicate that
the cell air interface is too busy and rejection of new traffic is necessary in order to restore
normal operation. The Procedure Latency Supervision operates on a per Cell level
 pmRrcConnEstabFailCellLatency
 pmHoPrepRejInCellLatency
 pmRrcLatencyConnSetupDistr
 pmRrcLatencyConnReconfigDistr
 pmRrcLatencyCapEnqDistr
 pmRrcLatencySecModeCmdDistr
 -BB Management Interface Intensity (Internal signals)
 pmRrcConnEstabFailMISigQCong
218
14
Appendix IV - Control
Channels

219
Control Channel Dimensioning
• This appendix section provides more details on the following..
• Cyclic Prefix
• PBCH
• Peak Throughput Calculations
• DL overhead calculations for the DL Control Channels
• UL overhead calculations for the UL Control Channels
• PUCCH Dimensioning – Detailed Calculations

220
Cyclic Prefix
• Cyclic Prefix is introduced to counter the effect of multi-path or in other words delay spread

• 2 options
 Normal
 Extended
• Most deployment scenarios for macro-cells, micro-cells etc. in urban as well as rural areas a
normal cyclic prefix should be sufficient
• Recommendation – Normal Cyclic Prefix
221
Downlink Channel Mapping
• Set of Logical & Transport Channels map
onto
Logical BCCH PCCH CCCH DCCH DTCH MCCH MTCH
 PBCH
 PDSCH
 PMCH
• Other Physical Channels only exist at theTransport BCH

Physical Layer
PCH DL-SCH MCH
 PDCCH
 PCFICH
 PHICH PHYS.

• Reference Signal exists only at the Physical PDSCH PMCH REFERENCE

PBCH
Layer SIGNALS
PDCCH
• Overhead calculation for peak throughputs PCFICH
PHICH
222
Signal Mapping
• Example shown in this slide is for 1.4 MHz (72 sub-carriers), single antenna case
• Primary and secondary Synchronisation Signals occupy 2 blocks of symbols per 10ms
(ventral sub-carriers for all channel bandwidths)

223
Physical Channel Mapping
• PBCH, PCFICH, PDCCH & PHICH physical channels also occupy symbols and represent an
overhead
• PDSCH physical channel used to transfer application data has access to whatever is left over

224
DL Bit Rates
• Bit Rates (2x2 MIMO) after accounting for the overheads generated by the Reference
Signals, Synchronisation Signals and other Physical Channels

• These bit rates are applicable to the bottom of the physical layer i.e. coding rate has not
been included
225
 Physical Broadcast Channel (PBCH)
• The PBCH is used to broadcast the Master Information Block
(MIB) using the BCH Transport channel
• The PBCH is allocated to the central 72 sub-carriers belonging to
the first 4 OFDMA symbols of the second time slot of every
10ms radio frame – total of 240 Resource Elements when using
normal cyclic prefix
• PBCH transfers the MIB using a 40ms TTI and QPSK modulation
• The UE decodes the Channel bandwidth information & the
PHICH configuration from the PBCH
• Very small overhead for larger CH
BW
• 10 MHz = 0.3% & 20MHz = 0.1%
• No Dimensioning/Planning
Required 226
Down-Link Control Channel Overhead
• Assumptions
 Normal CP
 Synchronisation Signal Resource Elements & PBCH per 10ms
 PCFICH for 1ms sub-frame
Channel/Signal 5 MHz 10 MHz 15 MHz 20 MHz
 PHICH Group Scaling factor of 1/6
Synch. Signals 0.7% 0.3% 0.2% 0.2%
 PDCCH allocation for 3 symbols
Reference Signal 9.5% 9.5% 9.5% 9.5%
 2x2 MIMO PBCH 0.6% 0.3% 0.2% 0.1%

• The PDSCH (remaining) determines the PCFICH 0.4% 0.2% 0.1% 0.1%

overall peak throughputs achievable in PHICH 0.3% 0.3% 0.2% 0.2%

PDCCH 19.0%
the DL
• Please see next slide for an example for
10MHz

227
Down-Link Overhead & Peak Throughput Example
• An example below for 10MHz bandwidth with the assumptions on the previous slide
• For more details please download LTE Visualisation tool from www.ltebullets.com

• In this case the available RE for the PDSCH is ~71% and depending on the modulation used
the peak throughput can vary

228
UL Channels
• Set of Logical & Transport Channels map
onto the PUSCH
• Other physical channels only exist at the
physical layer
 PUCCH
 PRACH
• RACH is illustrated as a Transport Channel
but is used only to transfer Random Access
Control information from the MAC layer to
the physical layer
• Reference signals only exist at the physical
layer

229
 PUCCH Dimensioning - I
• PUCCH Dimensioning in terms of PUCCH formats 2/2a/2b
• Maximum number of RBs required for PUCCH format 2/2a/2b is dependant on the
maximum number of RRC users supported in the cell
𝑅𝑅𝐶 𝑈𝑠𝑒𝑟𝑠 ∗ {1 𝑜𝑟 2}
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐵𝑙𝑜𝑐𝑘𝑠 = 𝑅𝑂𝑈𝑁𝐷𝑈𝑃
𝐶𝑦𝑐𝑙𝑖𝑐 𝑆ℎ𝑖𝑓𝑡 ∗ 𝐶𝑄𝐼 𝑃𝑒𝑟𝑖𝑜𝑑𝑖𝑐𝑖𝑡𝑦
• The Cyclic Shift allows the same pair of RBs
to be shared by 12 UE by using Code
Division Multiplexing. Hence Cyclic Shift
Value = 12
• If C-DRX is ON then we need more PUCCH
Resource Blocks as CQI and RI need to be
sent every 40ms
• If C-DRX is OFF then RI and CQI needs to be
sent alternately every 40ms
230
 PUCCH Dimensioning - II
• PUCCH Dimensioning in terms of RB for Format 1 (Scheduling Requests)

𝑅𝑅𝐶 𝑈𝑠𝑒𝑟𝑠
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐵𝑙𝑜𝑐𝑘𝑠 = 𝑅𝑂𝑈𝑁𝐷𝑈𝑃
𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑒𝑥𝑖𝑛𝑔 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦 ∗ 𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑖𝑛𝑔 𝑅𝑒𝑞. 𝑃𝑒𝑟𝑖𝑜𝑑

𝐶𝑦𝑐𝑙𝑖𝑐 𝑠ℎ𝑖𝑓𝑡 (12)

𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑒𝑥𝑖𝑛𝑔 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦 =
𝑑𝑒𝑙𝑡𝑎𝑃𝑈𝐶𝐶𝐻𝑆ℎ𝑖𝑓𝑡
* 3

• 12/deltaPUCCHshift = number of allowed cyclic shifts

• 3 = number of orthogonal codes
• Hence Multiplexing is achieved by using different combinations of cyclic shift and
orthogonal codes.
• If we assume deltaPUCCHShift parameter to be set to 2, then in this example we can
support 18 PUCCH (6x3) transmissions

231
 PUCCH Dimensioning - III
• PUCCH Dimensioning in terms of RB for Format 1a/1b
𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐶𝐶𝐸
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐵𝑙𝑜𝑐𝑘𝑠 = 𝑅𝑂𝑈𝑁𝐷𝑈𝑃
𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑒𝑥𝑖𝑛𝑔 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦
𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐶𝐶𝐸 ∗ 𝑑𝑒𝑙𝑡𝑎𝑃𝑈𝐶𝐶𝐻𝑆ℎ𝑖𝑓𝑡
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐵𝑙𝑜𝑐𝑘𝑠 = 𝑅𝑂𝑈𝑁𝐷𝑈𝑃
𝐶𝑦𝑐𝑙𝑖𝑐 𝑆ℎ𝑖𝑓𝑡 ∗ 3
• The number of CCEs is as shown in the table
• Some vendors allow the sharing of PUCCH
Resource Blocks between Format 1 and Formats OFDMA Symbols 5 MHz 10 MHz 15 MHz 20 MHz
for PDCCH (CCE) (CCE) (CCE) (CCE)
1a/1b. It is recommended not opt for the sharing
1 5 10 16 21
option at least in initial deployments
2 13 27 41 55
• Hence if we consider a 10 MHz channel with 3 3 21 43 66 88
PDCCH symbols we would need PUCCH Resources
to provide ACK/NACK for 43 Connections
232
 PUCCH Dimensioning Example without CA
• RRC Users = 300, C-DRX = ON, Cyclic Shift = 12 (3GPP specified)
• CQI Periodicity = 40ms, deltaPUCCHShift =2, Scheduling Request = 10ms
• CH BW = 10 MHz
• Number of RBs for PUCCH Format 2/2a/2b = 2 RB
• Number of RB for PUCCH Format 1 = 2 RB
• Number of RB for PUCCH Format 1a/1b = 3 RB
• Total RB = 8 (as PUCCH RB needs to be an even number)
• For Carrier Aggregation, the PUCCH RB requirements increase as there are 2 data streams and
each CA UE needs 4 PUCCH resources for ACK/NACK and hence it impacts the PUCCH format
1b resources with Channel Selection
• The above dimensioning is 3GPP specific. Not all vendors will have all the parameters available
for tuning. Hence the above must be adapted to vendor specific requirements.
• Attached is the latest E/// common channel dimensioning guidelines which
233
Uplink Control Channel Overhead
• Assumptions
 Normal CP
 1xPRACH SF per Radio Frame

PUCCH 5 MHz 10 MHz 15 MHz 20 MHz

2xRB 25% 20% 18% 17%

4xRB 32% 23% 20% 19%

6xRB 39% 27% 23% 20%

8xRB 46% 30% 25% 22%

234
 Appendix – V Paging &

15 Random Access

235
Random Access Procedure - Example
• The signalling diagram is the RA procedure used
when transitioning from IDLE to CONNECTED state
• The UE selects an Initial Tx power and transmits the
preamble.
• If it does not hear back then it retransmits with
increased power
• The above process is repeated for a fixed number of
times
• Initial UE Tx power
 Min (Pmax, PL + Preamble Rx. Target Pwr.)
 PL = Reference Signal Power – Measured RSRP
 Preamble Rx. Target Pwr. = InitialRxTargetPower+
Deltapreamble+(PreambleCounter-1) x Ramping Step
236
 Appendix VI –

16 Miscellaneous Planning
Areas

237
 eNB and Cell Identity Planning
• The E-UTRAN Cell Global Identifier (ECGI) is used to
identify cells globally
• The ECGI is constructed from the MCC, MNC and E-
UTRAN Cell Identifier (ECI)
• The ECI is used to identify cells within a PLMN
• It has a length of 28 bits and contains the eNode B
Identifier
• It is only necessary to configure an ECI when a short
eNB-Id is used
• The ECI, MCC and MNC are broadcast in SIB1
• E-CGI is used during the ANR process. When the UE detects an unknown PCI and reports
back to the eNB, it is asked to decode the E-CGI using C-DRX mode
238
Neighbour Planning - I
• LTE mobility does not rely upon neighbour lists. UEs are responsible for identifying
neighbouring cells so this effectively removes the requirement for neighbour planning
• However UEs can be provided with neighbour specific measurement offsets to make certain
neighbours appear more or less attractive depending on the requirement
• 3GPP specifies the following System Information messages

SIB Neighbour Information

No Individual cells listed unless Measurement

SIB 4 Intra-Frequency
OFFSET is defined( Max PCI of 16)

SIB 5 Inter-Frequency A maximum of 8 RF Carriers can be defined

SIB 6 Inter-RAT(UTRAN) ARFCN (Max. of 16)

SIB 7 Inter-RAT (GERAN) 32 ARFCN listed explicitly (BSIC not specified)

239
Neighbour Planning - II
• Mobility from 3G and 2G are defined by 3GPP in the following System Information messages
• Recommended to switch on Fast Return (measurement based if available)

SIB 19 (UTRAN) SIB 2 Quater (GERAN)

EARFCN (4xFDD) EARFCN

Measurement BW Measurement BW

ABS Priority ABS Priority

QrxlevminEUTRA QrxlevminEUTRA

240
RF Carrier Allocation
• A frequency re-use pattern of 1 should be used.
• Suppose there is a spectrum of 15 MHz. There could 2 possible deployment options viz.
reuse pattern of 3 (Option 1) or reuse pattern of 1 (Option 1)
• Option 1 although achieves very high SINR but recommended option is Option 2 because
of much higher spectrum efficiency

Option 1

Option 2

241
17 Appendix VII- VoLTE

242
VoLTE Capacity in a Cell
• The VoLTE Capacity needs to be estimated based on the UL and DL channels
 PDCCH
 PHICH
 PUCCH
 PDSCH
 PUSCH
• Of all the above channels, the most likely capacity bottleneck is PDCCH especially for a
smartphone centric network
• This section details the capacity calculations for each of the above channels and tries to
estimate the cell capacity from a VoLTE only scenario using the live network counters from
Telefónica UK’s LTE network

243
Segmentation Requirement (1/3)
• The RLC layer may need to complete segmentation when UE are in poor coverage
 Poor coverage may mean that UE cannot send a speech packet in a single sub-frame because the
link budget does not allow it
• Packet sizes at the RLC layer with ROHC are assumed to be:
 12.65 kbps codec: 301 bits (253 speech + 40 bits RTP/UDP/IP + 8 bits PDCP)
 23.85 kbps codec: 525 bits (477 speech + 40 bits RTP/UDP/IP + 8 bits PDCP)
• The minimum transport block size (top of physical layer) is configured as 72 bits (NOKIA
specific)
• The maximum level of segmentation is:
 12.65 kbps : 301 bits segmented into 5 packets
 23.85 kbps : 525 bits segmented into 8 packets

244
Segmentation Requirement (2/3)
• Link adaptation reduces the allocated
MCS to its minimum prior to reducing
the number of allocated resource blocks
• The transport block size table indicates
that segmentation would be required for
either low MCS or low Resource Block
allocation
Segmentation required
for both codecs

Segmentation required
for 23.85 kbps codec

245
Segmentation Requirement (3/3)
• The number of UE which require segmentation can be ‘roughly’ estimated from MCS
statistics
• The percentage of UE which are allocated MCS 0 is shown below
 UE with MCS 0 may not require segmentation if allocated Resource Blocks are high
 UE with MCS > 0 may require segmentation if allocated Resource Blocks are low
• Assume for 12.65 kbps codec: 5 % of speech packets require segmentation into 2 packets
• Assume double for 23.85 kbps codec: 10 % of speech packets require segmentation into 2
packets PDF Of PDSCH PDF Of PUSCH MCS
(06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only) (06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only)
9.00% 30.00%

4.6% 8.00%
25.00%
7.00%

6.00% 20.00%
8.1%
5.00%
15.00%
4.00%

3.00% 10.00%

2.00%
5.00%
1.00%

0.00% 0.00%

MCS-0
MCS-1
MCS-2
MCS-3
MCS-4
MCS-5
MCS-6
MCS-7
MCS-8
MCS-9
MCS-10
MCS-11
MCS-12
MCS-13
MCS-14
MCS-15
MCS-16
MCS-17
MCS-18
MCS-19
MCS-20
MCS-21
MCS-22
MCS-23
MCS-24
MCS-25
MCS-26
MCS-27
MCS-28
MCS-0
MCS-1
MCS-2
MCS-3
MCS-4
MCS-5
MCS-6
MCS-7
MCS-8
MCS-9
MCS-10
MCS-11
MCS-12
MCS-13
MCS-14
MCS-15
MCS-16

MCS-26
MCS-27
MCS-28
MCS-17
MCS-18
MCS-19
MCS-20
MCS-21
MCS-22
MCS-23
MCS-24
MCS-25

246
PDCCH Capacity (1/3)
• PDCCH capacity is quantified in terms of Control Channel Elements (CCE)
 1 CCE = 36 Resource Elements and each PDCCH transmission requires 1, 2, 4 or 8 CCE
 Depends upon PDCCH payload size and UE coverage conditions
• For the 10 MHz channel bandwidth, and:
 3 symbols allocated to the PDCCH
 2 PHICH groups (2 × 12 = 24 Resource Elements)
 16 Resource Elements allocated to the PCFICH
 PDCCH Resource Elements = [(50 × 8) – 16 – 24] + [2 × (50 × 12)] = 1560
 PDCCH CCE = ROUNDDOWN[1560 / 36] = 43 CCE
• Some vendors have a PDCCH utilisation target. For example in NOKIA this is configured as
0.8 which means that the Packet Scheduler will aim to use 43 x 0.8 = 34 CCE
• This utilisation target ensures the best performance (power per CCE is higher and hence
lower AGG is used)
247
PDCCH Capacity (2/3)
• Statistics from the live network can illustrate that the average number of CCE per PDCCH
transmission is generally 5 to 6
• In the Telefónica UK network, the usage is as shown in the chart below

PDF of Average Number Of CCE Used Per Cell

(06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only)
6000

5000

4000

3000

2000

1000

0
1 2 3 4 5 6 7 8

248
PDCCH Transmissions
• All vendors support Packet Aggregation. This feature must be activated
• Using this feature allows 2 speech packets to be aggregated and sent once every 40ms
• Reduces the PDCCH usage

Uplink speech speech speech speech speech speech speech speech

(UE 1)
40 ms period

Uplink SID SID

(UE 2)
160 ms period

PDCCH transmissions per 160 ms = 4 +1 = 5 so average PDCCH use per 20 ms = 5 / 8 = 0.625

249
PDCCH Capacity (3/3)
• The 34 CCE are required to support:
 Uplink and downlink resource allocations for both signalling and data bearers
 SIB and paging message resource allocations
 PDCCH orders for UE which are out-of-sync
• Assuming:
 The dominant PDCCH load originates from uplink and downlink resource allocations
 Segmentation is completed for 5 % and 10 % of packets (12.2 and 23.85 kbps codecs)
 There is a 10 % re-transmission overhead Example
20 * ROUNDDOWN(34/4) / (0.625) = 256
Appropriate columns based
on live network statistics => 256 * 90% * 95% = 219
Average number of CCE per PDCCH transmission
2 3 4 5 6 7 8

12.65 kbps Codec 40 ms Transmission Rate 465 301 219 164 137 109 109

23.85 kbps Codec 40 ms Transmission Rate 441 285 207 156 130 104 104

250
PDSCH Capacity (1/5)
• The capacity of the PDSCH for VoLTE is influenced by the following factors:
 The number of Resource Blocks within the channel bandwidth
 The Resource Block Group (RBG) size
 The number of RBG required by each connection
 The Admission Control threshold
 Maximum number of QCI1 allowed
 Traffic Limit (if any) for GBR traffic
 The number of connections which can be scheduled per sub-frame defined
 The use of Packet Aggregation
 The bit rate generated by the speech codec and the use of header compression

251
PDSCH Capacity (2/5)
PDF of Reported CQI
(06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only)
14.00%
16QAM
• Live network statistics provide a distribution 12.00%

10.00%
of the reported CQI 8.00%
64QAM

• 3GPP specifies a mapping between CQI and 6.00%

coding rate 4.00%

QPSK
2.00%

• Allows the average coding rate to be 0.00%

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

determined for each modulation scheme: CQI

3GPP relationship between CQI and coding rate

 QPSK: 0.49, 16QAM: 0.50 & 64QAM: 0.64

252
PDSCH Capacity (3/5)
• The 10 MHz channel bandwidth has 50 Resource Blocks and a RBG size of 3, i.e. the set of
50 Resource Blocks can be allocated in groups of 3
• A single RBG includes 360 Resource Elements (360 = 120 * 3) (120 = 12 subcarriers * 11
symbols – 12 Ref Sig RE) after accounting for common channels
 QPSK: 720 bits, 16QAM: 1440 bits & 64QAM: 2160 bits
RTP/UDP PDCP/RLC/MAC Assumes 50% activity
12.65 kbps Codec Rate 23.85 kbps Codec Rate
40 ms transfer rate 40 ms transfer rate
• 2x253 + 2x40 + 24 = 613 bits every 80 ms • 2x492 + 2x32 + 24 = 1072 bits every 80 ms
• Applying modulation scheme coding rate: • Applying modulation scheme coding rate:
 QPSK: 2 RBG required  QPSK: 4 RBG required
 16QAM: 1 RBG required  16QAM: 2 RBG required
 64QAM: 1 RBG required  64QAM: 1 RBG required
Doesn’t account for SID load 253
PDSCH Capacity (4/5)
• Live network statistics indicate that approximately, for every 10 PDSCH transmissions:
 2 use QPSK
 3 use 16QAM
 5 use 64QAM

PDSCH Modulation Scheme

(06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only)
50.00%

45.00%

40.00%

35.00%

30.00%

25.00%

20.00%

15.00%

10.00%

5.00%

0.00%
QPSK 16QAM 64QAM
Modulation Scheme

254
PDSCH Capacity (5/5)

12.65 kbps Codec Rate 23.85 kbps Codec Rate

40 ms transfer rate: 40 ms transfer rate:
• 10 VoLTE connections require 12 RBG • 10 VoLTE connections require 19 RBG
• 10 MHz channel offers 16 RBG which would • 10 MHz channel offers 16 RBG which would
support ~13 connections per sub-frame support ~8 connections per sub-frame
• 10 % re-transmission overhead • 10 % re-transmission overhead
• (13 * 40ms * 0.9) * 2 • (8 * 40ms * 0.9) * 2
• 936 connections • 576 connections
• (ignored segmentation) • (ignored segmentation)

PDCCH limits capacity more than PHICH

255
PHICH Capacity
• A single PHICH group is able to provide acknowledgements for 8 uplink transmissions
• Assuming the allocation of 2 PHICH groups then 16 connections per sub-frame can be
supported
• 1280 connections when transferring data every 40 ms
• (=16*40*2)

PDCCH limits capacity more than PHICH

UL & DL

256
PUCCH Capacity
• PUCCH Dimensioning has been covered in a previous section (section 4)
• Key requirement is to take into account Packet Aggregation
• These Resource Blocks represent an overhead from the perspective of the PUSCH

PDCCH more likely to limit than PUCCH

257
PUSCH Capacity (1/4)
• The capacity of the PUSCH for VoLTE is influenced by the following factors:
 The number of Resource Blocks within the channel bandwidth after accounting for the PUCCH and
PRACH
 The number of Resource Blocks required by each connection
 The Admission Control threshold
 Max number of QCI-1 allowed
 GBR Traffic Limit if applicable
 The number of connections which can be scheduled per subframe
 Use of TTI Bundling
 Use of Packet Aggregation
• An uplink coding rate of 0.5 is assumed to match the figures derived from the reported CQI
for the downlink

258
PUSCH Capacity (2/4)
• The 10 MHz channel bandwidth has 50 Resource Blocks
• Resource Block Groups (RBG) are not used in the uplink
• A single Resource Block pair includes 144 Resource Elements
 QPSK: 288 bits
 16QAM: 576 bits

Assumes 50% activity

12.65 kbps Codec Rate 23.85 kbps Codec Rate

40 ms transfer rate: 40 ms transfer rate:
• 2x253 + 2x32 + 24 = 594 bits every 80 ms • 2x492 + 2x32 + 24 = 1072 bits every 80 ms
• QPSK: 5 RB required • QPSK: 8 RB required
• 16QAM: 3 RB required • 16QAM: 4 RB required

259
PUSCH Capacity (3/4)
• Live network statistics indicate that in general, for every 5 PUSCH transmissions:
 1 uses QPSK
 4 use 16QAM

PUSCH Modulation Scheme

(06/06/16 - 19/06/16 Averaged Busy Hours Weekdays Only)
90.00%

80.00%

70.00%

60.00%

50.00%

40.00%

30.00%

20.00%

10.00%

0.00%
QPSK 16QAM 64QAM
Modulation Scheme

260
PUSCH Capacity (4/4)
12.65 kbps Codec Rate 23.85 kbps Codec Rate
40 ms transfer rate: 40 ms transfer rate:
• 5 VoLTE connections require 17 RB • 5 VoLTE connections require 24 RB
• 10 MHz channel offers 40 RB which would support • 10 MHz channel offers 40 RB which would support
~11 connections per subframe ~8 connections per subframe
• 10 % re-transmission overhead • 10 % re-transmission overhead
• (11 * 40ms * 0.9) * 2 • (8 * 40ms * 0.9) * 2
• 792 connections • 576 connections

PDCCH limits capacity more than PUSCH

261
Impact of Poor RF Conditions on VoLTE
• Most vendors trigger TTI bundling when the UL radio conditions (UL SINR) gets worse
beyond a certain point
• For example in the E/// default design, TTI Bundling is triggered when UL SINR <-10 dB and
is deactivated when UL SINR > -8 dB
• TTI Bundling has an impact on PUSCH
capacity as the same packets are
retransmitted using the same PUSCH
resources 4 times
• It is mandatory to improve UL RF
performance to have decent VoLTE
capacity
• UL Optimisation is most essential to
improved VoLTE performance

262
Impact on Connected User Licenses
• For some vendors as we know that there is a connected user license in the base-band
module and with the onset of VoLTE, there will be an impact to this and hence some
planning needs to be done
• The analysis here in this slide is shown
for a couple cities in the UK
• Depending on the VoLTE marketing
proposition, Device availability,
customer uptake etc., the LTE
connected user license would need to
be forecasted
• With the new contracts in place this
license limitation should be removed

263
 Appendix VIII – Reactive

18 Dimensioning Process

264
RRC Connected Users & Future Possibilities - I
• Although the recommended option is Approach 1 but beyond a certain number of
Buffered/Connected Users, the user experience is likely to be very bad.
• Example below from one of cells in a football stadium
Connected UE
Increase

Signalling
Increase

Data Throughput
Decrease

UE stay connected UE consider RL to

longer be broken

265
RRC Connected Users & Future Possibilities -II
• At the current moment even for SE sites it is a better option to go for Approach 1 as
otherwise we would have Voice Call Blocking
• In future once we have very high penetration of Release 12 (or higher) devices we have the
option of using the AC Barring & Skipping feature
• This is triggered based on a certain number of Connected users (Operator Configurable) or
RRC Rejection& when triggered it will cyclically bar data call attempts from different AC UEs
• Similarly it can be de-activated once the Connected User Numbers fall below a certain
threshold or RRC Rejections stop for a while
• In this case however, Voice & SMS (Release 12)can be allowed and hence we avoid the
problem of Voice Call Blocking and we are still able to limit connected users and provide an
expected level of DL data throughput experience
acBarSkipForMMTELVideo
acBarSkipForMMTELVoice
acBarSkipForSMS

266
Examples from the Telefónica UK network
• Example from a Special Event Festival site
• As can be observed that the beyond a
certain point as the RRC Connected users
increase this results in a decrease in the DL
DRB data volume and an increase in the
SRB data volume and an overall decrease in
the DL cell throughput i.e. Cell Capacity

267
RRC Connected Users – TEF UK NOKIA Example Inactivity timer
changed to 5s

• Approach 1 is about maximising the RRC

Connected Users in order to avoid Voice
Call Blocking and achieve high RRC
Accessibility.
• The maximum allowed users per cell/site
is vendor dependant and the following
slides provide some examples of this
approach as followed in Telefónica UK.
• NOKIA Example as shown for Telefónica
UK with a maximum limit of 420 users/cell
• In case of NOKIA, there is no user license • At the moment, this is a manual process
for RRC Connected Users at a base-band (report generated every week)
level and hence the RRC Connected User • In forthcoming SW releases this can be
can be increased using parametrisation automated
268
RRC Connected Users – TEF UK ERICSSON Example(I)
• In case of E///, as mentioned in the section 4, the maximum number of RRC Connections
per eNode B is dictated by the capacity of the base-band HW & activation license. The aim
of the current RFP process is to maximise all the eNB licenses
• The E/// process follows a similar methodology as the NOKIA one. However when the
License limits are reached, a 14 day grace period begins after which the eNode B starts
rejecting RRC connections above the licensed value. It should be noted that the system
allows spikes without triggering the grace period
• The maximum number of simultaneous RRC
Connections per eNodeB can be measured using
the counter pmLicConnectedUsersMax. The current
value of the relevant HWAC license can be queried
using the counter pmLicConnectedUsersLicense
(note: this should be queried at the lowest ROP
level i.e. 15min).

269
RRC Connected Users – TEF UK ERICSSON Example(II)
• When the License limits are reached, a 14 day grace
period begins after which the eNode B starts rejecting
RRC connections above the licensed value.
• It should be noted that the system allows spikes without
triggering the grace period (pmRrcConnEstabFailLic)

270
PUCCH Capacity – TEF UK ERICSSON Example (I)
• PUCCH Capacity is intrinsically linked to the RRC Connected User dimensioning
• However the overall dimensioning steps/processes depend on the vendor specific
implementation. If PUCCH resources are not dimensioned properly then although there
might be enough RRC Connected User licenses at an eNB level but there might still be user
blocking. Some vendors have counters to link up the RRC Connected Users and the PUCCH.
• The PUCCH Dimensioning excel explained in Section 5
should be use for PUCCH dimensioning
 Every RRC connected user will require PUCCH resources.
As such PUCCH resource utilisation can be monitored at a
cell level using the counter pmRrcConnMax.
 The configured PUCCH resources can be queried using the
configuration attribute noOfPucchCqiUsers or
alternatively noOfPucchSrUsers
 A potential hot spot is defined as any cell that reaches
90% of the configured PUCCH capacity
271
PUCCH Capacity – TEF UK ERICSSON Example (II)
• If for whatever reason a cell does not have enough PUCCH capacity (regardless of the
vendor) configured to support the maximum number of RRC Connected Users, the e Node B
will start rejecting RRC Connections

272
Base-Band Thrpht License – TEF UK E/// Example (I)
• For some vendors, there is an additional license requirement for activating DL & UL
Throughput.
• For example in E/// the maximum base-band capacity, defined as the maximum
simultaneous throughput per eNode B is dictated by the capacity of the base-band itself
and by a hardware activation code. The lowest of the 2 applies…
• As mentioned in the section 3 that a recommended starting point is 50 Mbps (UL) and 100
Mbps (DL)
• Baseband capacity (in terms of simultaneous throughput across all cells) is monitored
separately for the downlink and uplink using counter pmLicDlCapActual for the downlink
and pmLicUlCapActual for the uplink
• These counters show is the % of the licensed capacity that 90% of samples utilise

273
Base-Band Thrpht License – TEF UK E/// Example (II)
• A potential hot spot is defined as any eNodeB that reaches 90% of the licensed capacity 10
times per week for 2 consecutive weeks either in the downlink or the uplink.
• The corrective action in this case is to request an increase in the DlBasebandCapacity or
UlBasebandCapacity HWAC (whichever applies)
• The recommended increase is 10% of the existing license value.

274
Paging – Real Example from Telefónica UK (I)
• BTS belonging to TAC 4288 experience relatively frequent paging discards
• Requirement to check whether or not these discards are expected
• NOTE – There have been updates from other operators which mention Paging Discard
due to eNB processing overload or parallel procedures

275
Paging – Real Example from Telefónica UK (II)
• Picking out one e Node B from the TAC to do further analysis. This e Node B regularly
experiences Paging Discards during the Busy Hour
• S1AP:Paging Messages were recorded by using BTS Logging

276
Paging – Real Example from Telefónica UK (III)
• Counters indicate paging discards
• The average pages per second during the 1 hour
measurement period is:
 695844 / 3600 = 193 per second
• The upper limit for paging capacity is currently configured
as 400 per second
 1 paging message every 40 ms
 16 paging records per message

277
Paging – Real Example from Telefónica UK (IV)
• 193 pages per second corresponds to 124 pages per 640 ms DRX cycle
• The set of 124 pages are associated with specific paging occasions
 They are not perfectly evenly distributed across the set of paging occasions
• There are 640 / 40 = 16 paging occasions during the paging DRX cycle
• There is a 0.04 % probability of a paging discard when assuming a uniform random
distribution across paging occasions
• This corresponds to 695844 * 0.0004 = 278 discards during the hour
 Compared to 989 indicated by the counters

278
Paging – Real Example from Telefónica UK (V)
• Wireshark log files illustrate that the paging records per 640 ms reaches 160
 Creates a discard probability of 0.4
 i.e. increasing the paging records per 640 ms from 124 to 160 increases the discard probability
from 0.04 % to 0.44 %

279
Paging Capacity Dimensioning & Discard Probability
• The graph below illustrates the probability of paging discards for a range of paging loads
• For example there are 99 pages sent successfully and 1 page which is discarded then the
discard probability is 1 %
• Below attached is the Paging Dimensioning
Tool which has been used to create the Paging
Discard Probability Matrix
• This tool can be used to update the paging
capacity based on discard probability

280