Lte DCL App 030940 App-Std Lncme Le6

LTE Network Capacity 05.
03 / EN 06 September 2013
Monitoring & Engineering
LTE/DCL/APP/030940 Approved-Standard
1386
LTE Network Capacity Monitoring & Engineering

Document Number: LTE/DCL/APP/030940
System Release: LE6.0
Document Issue: 05.03 / EN
Document Status: Approved-Standard
Date: 06/September/2013
22,13
Copyright © 2011 by Alcatel-Lucent. All Rights Reserved.
About Alcatel-Lucent
Alcatel-Lucent (Europe Paris and NYSE: ALU) provides solutions that enable service providers,
enterprises and governments worldwide, to deliver voice, data and video communication
services to end-users. As a leader in fixed, mobile and converged broadband networking, IP
technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that
enable compelling communications services for people at home, at work and on the move.
For more information, visit Alcatel-Lucent on the Internet: http://all.alcatel-lucent.com
Notice
The information contained in this document is subject to change without notice. At the time
of publication, it reflects the latest information on Alcatel-Lucent’s offer, however, our
policy of continuing development may result in improvement or change to the specifications
described.
Trademarks
Alcatel, Lucent Technologies, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of
Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-
Lucent assumes no responsibility for inaccuracies contained herein.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/273
LTE Network Capacity 05.03 / EN 06 September 2013
CONTENTS
1 INTRODUCTION ......................................................................................................................... 11
1.1 OBJECT .................................................................................................................................... 11
1.2 SCOPE OF THIS DOCUMENT........................................................................................................ 11
1.3 AUDIENCE FOR THIS DOCUMENT................................................................................................. 12
1.4 CHANGE CONTROL .................................................................................................................... 12
1.5 NOMENCLATURE ........................................................................................................................ 13
1.6 RELATED DOCUMENTS............................................................................................................... 13
1.6.1 Reference Documents.................................................................................................. 13
1.6.2 Customer Documents................................................................................................... 13
2 LTE OVERVIEW ......................................................................................................................... 15

2.1 LTE NETWORK OVERVIEW ......................................................................................................... 15
2.1.1 Requirements and Targets for LTE .............................................................................. 15
2.1.1.1 Air Interface Evolution............................................................................................... 15
2.1.1.2 Core Network Architecture Evolution ........................................................................ 17
2.1.2 LTE Network Architecture Overview ............................................................................ 18
2.1.3 LTE Functions & Interfaces - EUTRAN ........................................................................ 20
2.1.3.1 User Equipment (UE)................................................................................................ 20
2.1.3.2 LTE FDD Radio Interface ......................................................................................... 21
2.1.3.3 E-UTRAN Node B (eNodeB) .................................................................................... 24
2.1.3.4 EUTRAN Interfaces .................................................................................................. 25
2.1.4 LTE Functions & Interfaces - ePC ................................................................................ 28
2.1.4.1 MME.......................................................................................................................... 28
2.1.4.2 HSS........................................................................................................................... 29
2.1.4.3 AAA ........................................................................................................................... 30
2.1.4.4 S-GW ........................................................................................................................ 31
2.1.4.5 P-GW ........................................................................................................................ 32
2.1.4.6 PCRF ........................................................................................................................ 33
2.1.4.7 EPC Interfaces.......................................................................................................... 34
2.2 LTE NETWORK CAPACITY AND DIMENSIONING OVERVIEW ........................................................... 36
2.2.1 Initial Engineering and Dimensioning ........................................................................... 36
2.2.1.1 LTE Call Model Elements ......................................................................................... 37
2.2.1.2 Paging and TAU Load .............................................................................................. 44
2.2.2 Capacity Monitoring and Troubleshooting.................................................................... 48
3 INITIAL ENGINEERING & DIMENSIONING .............................................................................. 50

3.1 LTE AIR INTERFACE DIMENSIONING ........................................................................................... 51
3.1.1 Overview....................................................................................................................... 51
3.1.2 Air Interface Capacity Figures ...................................................................................... 52
3.1.2.1 Uplink Air Interface Capacity .................................................................................... 53
3.1.2.2 Downlink Air Interface Capacity ................................................................................ 54
3.1.2.3 Sectorization Gain .................................................................................................... 55
3.1.3 Air Interface Capacity & Dimensioning Computation ................................................... 56
3.1.3.1 Main Inputs Required for Air Interface Dimensioning ............................................... 57
3.1.3.2 Air Interface Dimensioning Method & Example ........................................................ 60
3.1.3.3 Downlink Output Power ............................................................................................ 64
3.1.3.4 Other Air Interface Capacity Considerations ............................................................ 66
3.2 ENB CAPACITY & DIMENSIONING................................................................................................ 66
3.2.1 Overview....................................................................................................................... 66
Page 2/273
3.2.2 LTE eNB Configurations & Capacities ......................................................................... 68

3.2.2.1 Alcatel-Lucent Call State Definitions ........................................................................ 68
3.2.2.2 ENB Dimensioning Elements ................................................................................... 70
3.2.2.3 ENB Capacity Configurations ................................................................................... 72
3.2.2.4 New ENB Configurations in LA6.0 ............................................................................ 73
3.2.3 eNB User Plane Capacity & Dimensioning Computation............................................. 74
3.2.3.1 Main Inputs Required for eNB Dimensioning ........................................................... 74
3.2.3.2 eNB Dimensioning Principle ..................................................................................... 76
3.2.3.3 Number of User Connections ................................................................................... 77
3.2.3.4 Number of User Data Bearers .................................................................................. 80
3.2.3.5 Required Throughput ................................................................................................ 82
3.2.4 Control Plane Capacity Considerations ....................................................................... 82
3.2.5 eNB Paging Rate .......................................................................................................... 83
3.2.5.1 eNB Paging Rate Computation Example ................................................................. 83
3.2.6 ENB Capacity Licensing Functionality ......................................................................... 85
3.2.6.1 Licensing Tokens Computation ................................................................................ 86
3.3 LTE OAM CAPACITY ELEMENTS ................................................................................................ 88
3.3.1 Overview....................................................................................................................... 88
3.3.2 5620 SAM Platform Description ................................................................................... 89
3.3.2.1 5620 SAM Capacity Figures for X86 Platforms ........................................................ 91
3.3.2.2 OAM Bandwidth Dimensioning ................................................................................. 93
3.3.2.3 SAM Scaling Guideline for Call Trace .................................................................... 112
3.3.3 Overview on NPO Platform ........................................................................................ 114
3.3.3.1 NPO Software Performance ................................................................................... 114
3.3.3.2 NPO Hardware Capacity Figures on HP platforms ................................................ 115
3.3.3.3 Description of the NPO interfaces .......................................................................... 117
3.3.3.4 NPO Network Bandwidth Dimensioning ................................................................. 118
3.4 MME DIMENSIONING ............................................................................................................... 119
3.4.1 MME Configuration & Capacity .................................................................................. 119
3.4.2 MME Call Model Overview ......................................................................................... 123
3.4.3 MME Paging Rate ...................................................................................................... 125
3.5 LTE EUTRAN INTERFACES DIMENSIONING .............................................................................. 126
3.5.1 eUTRAN Interfaces Overview .................................................................................... 126
3.5.2 eUTRAN Dimensioning Process ................................................................................ 127
3.5.3 IPsec Considerations ................................................................................................. 128
3.5.4 S1 Interface Dimensioning ......................................................................................... 129
3.5.4.1 S1 Interface Protocol Stack .................................................................................... 130
3.5.4.2 S1 Interface IP Transport Headers ......................................................................... 131
3.5.4.3 S1-U Interface Dimensioning .................................................................................. 134
3.5.4.4 S1-MME Interface Dimensioning ............................................................................ 139
3.5.5 X2 Interface Dimensioning ......................................................................................... 144
3.5.5.1 X2 Interface Protocol Stack .................................................................................... 145
3.5.5.2 X2 Interface IP Transport Headers ......................................................................... 146
3.5.5.3 X2-U Interface Dimensioning .................................................................................. 147
3.5.5.4 Example of Bandwidth Calculation for X2-U .......................................................... 150
3.5.5.5 X2-C Interface Dimensioning .................................................................................. 150
3.5.6 Bandwidth Calculation for EUTRAN Interface............................................................ 151
3.6 MOBILE GATEWAY (S-GW, P-GW) DIMENSIONING ................................................................... 154
3.6.1 Mobile Gateway Configuration & Capacity................................................................. 154
3.6.1.1 Mobile Gateway Common System Configuration ................................................... 156
3.6.1.2 Mobile Gateway Static Capacity ............................................................................. 156
3.6.1.3 Mobile Gateway Dynamic Capacity ........................................................................ 157
3.6.1.4 Mobile Gateway Base System (SR derived) Features and Capacity ..................... 157
3.6.2 S-GW Dimensioning ................................................................................................... 159
3.6.2.1 S-GW Intra-Node Resiliency Dimensioning ........................................................... 159
3.6.2.2 S-GW Geo-Resiliency Dimensioning ...................................................................... 159
3.6.2.3 S-GW Interfaces and Supported Protocols ............................................................ 160
3.6.2.4 S-GW Capacity and Performance .......................................................................... 160
Page 3/273
3.6.3 P-GW Dimensioning ................................................................................................... 163

3.6.3.1 P-GW Intra-Node Resiliency Dimensioning ........................................................... 164
3.6.3.2 P-GW Interfaces and Supported Protocols ............................................................ 164
3.6.3.3 P-GW Capacity and Performance .......................................................................... 165
3.7 PCRF DIMENSIONING .............................................................................................................. 168
3.7.1 5780 DSC Configuration & Capacity .......................................................................... 168
3.7.1.1 5780 DSC Hardware............................................................................................... 168
3.7.1.2 SPR Dimensioning Impact ...................................................................................... 169
3.7.1.3 5780 DSC Software Licensing ................................................................................ 169
3.8 EPC INTERFACES DIMENSIONING ............................................................................................. 170
3.8.1 GN Interface ............................................................................................................... 170
3.8.1.1 Gn Interface Description ......................................................................................... 170
3.8.1.2 Gn Interface Dimensioning ..................................................................................... 171
3.8.1.3 Gn Throughput Figures Example ........................................................................... 173
3.8.2 Gx Interface ................................................................................................................ 174
3.8.2.1 Gx Interface Description ......................................................................................... 174
3.8.2.2 Gx Interface Dimensioning ..................................................................................... 175
3.8.2.3 Gx Throughput Figures Example ............................................................................ 178
3.8.3 M1 Interface ............................................................................................................... 178
3.8.3.1 M1 Interface Description ......................................................................................... 178
3.8.3.2 M1 Interface Dimensioning ..................................................................................... 179
3.8.3.3 M1 Throughput Figures Example ........................................................................... 179
3.8.4 M3 Interface ............................................................................................................... 179
3.8.4.1 M3 Interface Description ......................................................................................... 179
3.8.4.2 M3 Interface Dimensioning ..................................................................................... 180
3.8.4.3 M3 Throughput Figures Example ........................................................................... 180
3.8.5 S3 Interface ................................................................................................................ 180
3.8.5.1 S3 Interface Description ......................................................................................... 180
3.8.5.2 S3 Interface Dimensioning ..................................................................................... 181
3.8.5.3 S3 Throughput Figures Example ............................................................................ 181
3.8.6 S4 Interface ................................................................................................................ 182
3.8.7 S5 Interface ................................................................................................................ 183
3.8.7.3 S5-c Throughput Figures Example ......................................................................... 187
3.8.8 S6A Interface .............................................................................................................. 187
3.8.8.1 S6A Interface Description ....................................................................................... 187
3.8.8.2 S6A Interface Dimensioning ................................................................................... 188
3.8.8.3 S6A Throughput Figures Example ......................................................................... 190
3.8.9 S8 Interface ................................................................................................................ 190
3.8.10 S9 Interface ................................................................................................................ 191
3.8.11 S10 Interface .............................................................................................................. 192
3.8.11.1 S10 Interface Description ....................................................................................... 192
3.8.11.2 S10 Interface Dimensioning ................................................................................... 192
3.8.11.3 S10 Throughput Figures Example .......................................................................... 192
3.8.12 S11 Interface .............................................................................................................. 192
3.8.13 S12 Interface .............................................................................................................. 196
Page 4/273

3.8.14 S13 Interface .............................................................................................................. 197
3.8.15 SBc Interface .............................................................................................................. 200
3.8.15.1 SBc Interface Description ....................................................................................... 200
3.8.15.2 SBc Interface Dimensioning ................................................................................... 201
3.8.15.3 SBc Throughput Figures Example .......................................................................... 201
3.8.16 SGi Interface .............................................................................................................. 201
3.8.16.1 SGi Interface Description ........................................................................................ 201
3.8.16.2 SGi Interface Dimensioning .................................................................................... 202
3.8.16.3 SGi Throughput Figures Example .......................................................................... 202
3.8.17 SGs Interface ............................................................................................................. 202
3.8.17.1 SGs Interface Description ....................................................................................... 202
3.8.17.2 SGs Interface Dimensioning ................................................................................... 203
3.8.17.3 SGs Throughput Figures Example ......................................................................... 207
3.8.18 Sm Interface ............................................................................................................... 207
3.8.18.1 Sm Interface Description ........................................................................................ 207
3.8.18.2 Sm Interface Dimensioning .................................................................................... 208
3.8.18.3 Sm Throughput Figures Example ........................................................................... 208
3.8.19 Sv Interface ................................................................................................................ 208
3.8.19.1 Sv Interface Description ......................................................................................... 208
3.8.19.2 Sv Interface Dimensioning ...................................................................................... 209
3.8.19.3 Sv Throughput Figures Example ............................................................................ 211
4 LTE INTERFACE MONITORING: TROUBLESHOOTING & CAPACITY GROWTH ACTIONS

212
4.1 CAPACITY MONITORING & TROUBLESHOOTING PRINCIPLE ......................................................... 212
4.2 AIR INTERFACE CAPACITY MONITORING.................................................................................... 214
4.2.1 available Indicators for Air Interface Capacity Evaluation .......................................... 214
4.2.2 Monitoring Method & Critical Triggers ........................................................................ 218
4.2.2.1 Average aggregate cell Throughput ....................................................................... 218
4.2.2.2 PRB Consumption .................................................................................................. 219
4.3 ENB CAPACITY MONITORING ................................................................................................... 221
4.3.1 eNB Capacity Limits ................................................................................................... 221
4.3.2 Available Monitoring Indicators for eNB Capacity Evaluation .................................... 221
4.3.2.1 Monitoring Indicators for User Plane Blocking Evaluation...................................... 221
4.3.2.2 Monitoring Indicators for User Plane Load Evaluation ........................................... 223
4.3.3 Monitoring Method & Critical Triggers ........................................................................ 225
4.3.3.1 Number of User per Cell/Modem Connections Monitoring & Troubleshooting ...... 225
4.3.3.2 Number of Bearers per Cell/Modem Monitoring & Troubleshooting ...................... 227
4.3.4 Other eNB Capacity Monitoring Aspects .................................................................... 228
4.3.4.1 eNB Control Plane Processor Occupancy.............................................................. 228
4.4 MME CAPACITY MONITORING .................................................................................................. 231
4.4.1 Maximum Number of Registered Users ..................................................................... 231
4.4.1.1 Counters ................................................................................................................. 231
4.4.1.2 Monitoring Method & Critical Triggers .................................................................... 232
4.4.2 External Message Throughput ................................................................................... 232
4.4.2.1 Counters ................................................................................................................. 233
4.4.2.2 Monitoring Method & Critical Triggers .................................................................... 245
4.5 LTE INTERFACES MONITORING ................................................................................................ 247
4.5.1 EUTRAN Interfaces .................................................................................................... 247
4.5.1.1 Scenario 1 (Telecom Traffic / OAM Traffic) ............................................................ 248
Page 5/273
4.5.1.2 Scenario 2 (S1, X2, OAM Traffic) ........................................................................... 253

4.5.1.3 Additional Indicators ............................................................................................... 258
4.5.1.4 S-GW and P-GW Interface Statistics...................................................................... 259
4.5.2 KPI and KCI Performance Monitoring ........................................................................ 262
4.5.2.1 System KPI ............................................................................................................. 263
4.5.2.2 Bearer Management KPI ........................................................................................ 264
4.5.2.3 Bearer Traffic KPI ................................................................................................... 266
4.5.2.4 Path Management KPI ........................................................................................... 266
4.5.2.5 System KCI ............................................................................................................. 267
4.5.2.6 Bearer Management KCI ........................................................................................ 267
5 LTE SYSTEM CAPACITY PLANNING .................................................................................... 268

5.1 CAPACITY PLANNING PRINCIPLE ............................................................................................... 268
6 ABBREVIATIONS ..................................................................................................................... 270
Page 6/273
TABLES
Table 1 : 3GPP Defined LTE UE categories .................................................................................................. 20
Table 2 : LTE Bandwidth vs. Physical Resource Blocks (UL & DL) ........................................................... 23
Table 3 : Call Model Parameters – Aggregate Values .................................................................................. 39
Table 4 : General and User Plane Parameters by Call Type ....................................................................... 42
Table 5 : Subscriber Loading and Data Usage Profile .................................................................................. 43
Table 6: Detailed Data Call Model for the Example Traffic Model .............................................................. 44
Table 7 : eNBs Paged per MME Terminating Call......................................................................................... 47
Table 8 : LTE Uplink Air Interface Capacities ................................................................................................ 53
Table 9 : LTE Downlink Air Interface Capacities ........................................................................................... 55
Table 10 : Capacity Sectorization Factor ........................................................................................................ 56
Table 11 : Call Model to Air Interface Dimensioning Elements Conversion Table ................................... 60
Table 12 : Recommended Power Amplifier Sizing ........................................................................................ 65
Table 13 : Peak Throughput per Cell/Sector .................................................................................................. 66
Table 14 : Number of Digital Boards per 9926 BBU ..................................................................................... 68
Table 15 : LA6.0 eNB Max Capacity Figures Targeted in LA6.0 - eCEM .................................................. 71
Table 16: LA6.0 eNB Max capacity Figures Targeted in LA6.0 - bCEM .................................................... 72
Table 17 : Main Call Model Elements for eNB Dimensioning ...................................................................... 75
Table 18 : Call Model to eNB Dimensioning Elements Conversion Ttable ................................................ 76
Table 19 : eNB Resources and Associated Token Units ............................................................................. 86
Table 20 : 5620 SAM Capacity Figures for Solaris on X86 Machines ........................................................ 92
Table 21 : Matrix of the OAM Traffic Flow ...................................................................................................... 95
Table 22 : Total eNodeB OAM Operational Bandwidth ................................................................................ 98
Table 23: Total MME OAM Operational Bandwidth in LA6.0 ....................................................................... 99
Table 24: eNodeB Bandwidth for OAM Maintenance in LA6.0 ................................................................ 100
Table 25 : Bandwidth Requirement for eNodeB Counters in LA6.0 ......................................................... 102
Table 26 : Percentage of Time Connected / Time Attached for a Users in a BH ................................... 102
Table 27 : Nbr_PCMD_UE .............................................................................................................................. 103
Table 28: Total Number of User Doing PCMD During the BH and per eNB ........................................... 103
Table 29 : Total PCMD Message per Call Model at BH and per eNB ...................................................... 103
Table 30 : Average Throughput for PCMD Traffic Over S1-MME ............................................................. 104
Table 31 : Average Throughput for PCMD Traffic Over MME OAM Interface ........................................ 105
Table 32 : Throughput Calculation for eNodeB OAM Software Upgrades Application .......................... 105
Table 33 : Throughput Calculation for eNodeB OAM Software Upgrade at Physical Layer ................. 106
Table 34 : Percentage of Time Connected / Time Attached for a Users in a BH ................................... 106
Table 35: Total Number of Call Trace User /eNB / BH ............................................................................... 106
Table 36: eNodeB Total Signalling Procedure per BH and per UE .......................................................... 107
Table 37 : Bandwidth Throughput for Call Trace Traffic ............................................................................. 108
Table 38 : Maximum Throughput Required per eNodeB for the DDT Traffic ......................................... 109
Table 39 : Bandwidth Requirement for eNodeB Post Mortem File LA6.0 ................................................ 109
Table 40 : eNodeB Application Restart Context Bandwidth Requirement LA6.0 ................................... 110
Table 41 : L3 Snapshot Bandwidth Requirement inLA6.0 ......................................................................... 110
Table 42: On-Demand Snapshot Bandwidth in LA6.0 ................................................................................ 111
Table 43: OAM SAM Bandwidth Dimensioning with ePC and Transport Network Elements ............... 111
Table 44 : OAM SAM Bandwidth Dimensioning Elements ......................................................................... 112
Table 45 : Disk Space Requirement for Call Trace ..................................................................................... 113
Table 46 : NPO Performance for LA5.0 ........................................................................................................ 115
Table 47 : NPO Capacity Figures in LA5.0 on HP Machines .................................................................... 116
Table 48 : NPO OAM Bandwidth Requirement............................................................................................ 118
Table 49 : MME WM6.0 Capacity Figures (for Maximum Configuration) ................................................. 121
Table 50 : Call Model Parameters for MME Dimensioning ........................................................................ 123
Table 51 : MME WM6.0 Message Load Estimates ..................................................................................... 124
Table 52: S1-U Transport Headers and Size details................................................................................... 132
Table 53 : Aggregate S1-U Transport Header Size details ........................................................................ 133
Table 54: Aggregate S1-MME Transport Headers and Size details ......................................................... 133
Table 55: Aggregate S1-MME Transport Header Size ............................................................................... 134
Table 56: Attach Procedure ............................................................................................................................ 141
Page 7/273
Table 57: Detach Procedure ........................................................................................................................... 141

Table 58: Connection Request Procedure ................................................................................................... 141
Table 59: Inter-eNB (X2) Handover Procedure ............................................................................................ 141
Table 60 : Paging eNodeB Procedure........................................................................................................... 142
Table 61 : UE Requested PDN Connectivity Procedure ............................................................................ 142
Table 62 : Characteristics of TAU Procedure ............................................................................................... 142
Table 63 : Characteristics of the Inter eNB (X2) HO Procedure ................................................................ 151
Table 64: eNB Throughput (IPv4, w/o OAM Maintenance Traffic, w/o IPsec) ........................................ 153
Table 65 : eNB Bandwidth Calculation (IPv4 w Additional OAM Maintenance Traffic) ......................... 154
Table 66 : 7750 SR Mobile Gateway System Configurations .................................................................... 156
Table 67 : 7750 SGW Static Capacity Figures (per MG-ISM) ................................................................... 156
Table 68 : 7750 PGW/GGSN Static Capacity Figures (per MG-ISM) ...................................................... 157
Table 69 : 7750 Mobile Gateway Static Capacity Figures (S-GW) ........................................................... 157
Table 70 : 7750 Mobile Gateway Static Capacity Figures (P-GW/GGSN) .............................................. 157
Table 71 : 7750 Mobile Gateway Dynamic Capacity Figures .................................................................... 157
Table 72 : S-GW Supported Interfaces and Related Protocols ................................................................. 160
Table 73 : HO Rates Supported on S-GW.................................................................................................... 162
Table 74 : P-GW Supported Interfaces and Related Protocols ................................................................. 165
Table 75 : Gn Interface Main Procedures ..................................................................................................... 172
Table 76: Gx Interface Main Procedures ...................................................................................................... 176
Table 77: S5-C Interface Main Procedures .................................................................................................. 185
Table 78: S6a Interface Main Procedures .................................................................................................... 188
Table 79: S11 Interface Main Procedures ................................................................................................... 194
Table 80: S13 Interface Main Procedures .................................................................................................... 198
Table 81: SGs Interface Main Procedures.................................................................................................... 205
Table 82: Sv Interface Main Procedures ....................................................................................................... 210
Table 83 : Air Interface Average Cell Throughput Engineering Targets .................................................. 219
Table 84 : Nb of User Connections Critical Trigger Values – eCEM Case .............................................. 226
Table 85 : Paging Failure Rate Thresholds .................................................................................................. 246
Page 8/273
FIGURES
Figure 1 : Alcatel Lucent LTE Releases mapping ......................................................................................... 11
Figure 2 : Frequency-Domain View of the LTE Multiple-Access Technologies ........................................ 16
Figure 3 : Fast Scheduling and Link Adaptation ............................................................................................ 17
Figure 4 : EPS Architecture Evolution ............................................................................................................. 18
Figure 5 : System Architecture for LTE E-UTRAN & EPC Network ............................................................ 19
Figure 6 : Physical Resource Block (PRB) General View ............................................................................ 21
Figure 7 : DL PRB Structure ............................................................................................................................. 22
Figure 8 : UL PRB Structure ............................................................................................................................. 22
Figure 9 : Coverage vs. Capacity Analysis Feedback Loop ........................................................................ 24
Figure 10 : eNodeB – Remote Radio Configuration ...................................................................................... 25
Figure 11 : E-UTRAN Overall Architecture ..................................................................................................... 26
Figure 12 : Initial Engineering & Dimensioning: Generic Inputs & Outputs ............................................... 37
Figure 13: MME Paging Strategy Recommended for non-CSFB (Data Traffic) Mobile in LE6.0 ........... 46
Figure 14 : Capacity Analysis & Troubleshooting Example ......................................................................... 49
Figure 15 : Air Interface Capacity Dimensioning Inputs and Outputs ......................................................... 52
Figure 16 : LTE Air Interface Capacity Assessment ..................................................................................... 56
Figure 17 : Air Interface Equivalent Bandwidth Computation ...................................................................... 58
Figure 18 : Alcatel-Lucent 9926 eNB Architecture ........................................................................................ 67
Figure 19 : LTE Call State Definitions ............................................................................................................. 69
Figure 20 : eNB Dimensioning principle .......................................................................................................... 76
Figure 21 : Dimensioning of a Multi Service Resource Principle ................................................................ 77
Figure 22 : Dimensioning of Number of User Connections .......................................................................... 77
Figure 23 : eNB Capacity Licensing Principle ................................................................................................ 85
Figure 24 : OAM Solution for LA6.0 ................................................................................................................. 89
Figure 25 : 5620 SAM Deployment Scenarios ............................................................................................... 91
Figure 26 : OAM Transport Encapsulation Headers ................................................................................... 101
Figure 27 : NPO Network Interface ................................................................................................................ 117
Figure 28 : 9471 MME WM6.0 Hardware Configurations ........................................................................... 120
Figure 29 : 9471 MME Signaling Interfaces for WM6.0 .............................................................................. 123
Figure 30 : E-UTRAN Traffic Split .................................................................................................................. 127
Figure 31 : E-UTRAN security architecture .................................................................................................. 129
Figure 32: IPsec overhead header ................................................................................................................ 129
Figure 33 : S1-U Protocol Stack ..................................................................................................................... 130
Figure 34 : S1-MME Protocol Stack .............................................................................................................. 131
Figure 35: S1-U Bandwidth Computation ..................................................................................................... 134
Figure 36: Equivalent bandwidth computation ............................................................................................. 135
Figure 37: S1-U bandwidth assignment depending upon service types .................................................. 136
Figure 38 : Non GBR service required bandwidth to meet GoS expectations ........................................ 136
Figure 39: X2-based Handover without S-GW Relocation ......................................................................... 145
Figure 40: X2-U Protocol Stack ...................................................................................................................... 146
Figure 41: X2-C Protocol Stack ...................................................................................................................... 146
Figure 42 : X2-U Traffic vs. S1-U Traffic ....................................................................................................... 147
Figure 43 : Mobile Gateway HW Structure ................................................................................................... 155
Figure 44 : Paging Handling at S-GW Level ................................................................................................ 163
Figure 45 : Gn interface protocol stack ......................................................................................................... 171
Figure 46 : Gx interface protocol stack ......................................................................................................... 174
Figure 47 : M1 interface protocol stack ......................................................................................................... 178
Figure 48 : M3 interface protocol stack ......................................................................................................... 179
Figure 49: S3 interface protocol stack ........................................................................................................... 181
Figure 50 : S4 interface protocol stack .......................................................................................................... 182
Figure 51: S5 interface protocol stack ........................................................................................................... 183
Figure 52 : S6a interface protocol stack ....................................................................................................... 188
Figure 53 : S9 interface protocol stack ......................................................................................................... 191
Figure 54 : S12 interface protocol stack ....................................................................................................... 197
Figure 55: SBc interface protocol stack ........................................................................................................ 200
Figure 56 : SGi interface protocol stack ........................................................................................................ 202
Page 9/273
Figure 57: SGS interface protocol stack ....................................................................................................... 203

Figure 58: Sm interface protocol stack .......................................................................................................... 207
Figure 59 : Sv protocol stack .......................................................................................................................... 209
Figure 60 : Capacity Monitoring & Troubleshooting Principle .................................................................... 213
Figure 61 : Air Interface Capacity Monitoring Decision Tree ..................................................................... 220
Figure 62 : Cell/Modem Capacity Monitoring Decision Tree (Nb. of User connections) ....................... 225
Figure 63 : Cell/Modem Capacity Monitoring Decision Tree (Nb. of Bearers) ........................................ 227
Figure 64 : Example of S-GW S11 Peer Status and S11 Peer Statistics Outputs ................................. 259
Figure 65 : Example of S-GW S1U Peer Statistics and S1U Peer Status Outputs ................................ 260
Figure 66 : Example of P-GW S5 Peer Status and S5 Peer Statistic Outputs ........................................ 261
Figure 67 : Example of S-GW Active Bearer Context Snapshot ............................................................... 262
Figure 68 : Capacity Planning Principle ........................................................................................................ 268
Figure 69 : Capacity Monitoring vs. Capacity planning ............................................................................... 269
Page 10/273
1 INTRODUCTION
1.1 OBJECT
The objective of the LTE Network Capacity Monitoring and Engineering (LNCME) is to
provide an engineering view of the Alcatel-Lucent LTE interfaces dimensioning &
monitoring aspects.
The primary goals for this document are:

 Provide engineering dimensioning rules for LTE NEs interfaces.
 Introduce the monitoring elements & solutions for the LTE resources load
evaluation.
 Provide how to measure critical targets for LTE interface load and
troubleshooting recommendations.
The LTE NCME document can be used as an aid to initial network dimensioning and
monitoring, capacity analysis, and troubleshooting for the Alcatel-Lucent LTE network.
1.2 SCOPE OF THIS DOCUMENT

The eUTRAN & ePC releases names & numbers mapped on the LTE E2E LE6.0
release are captured in the following table:
LTE E2E Release LE6.0

ALU FDD eNodeB 9926 d2U /9442 RRH LA6.0
ALU 9412 Compact eNodeB: LA6.0
ALU NPO R5.1
ALU 9471 MME WM6.0.0
ALU 8650 SDM (HSS): 3.1
ALU P-GW / SGW (7750 SR) 4.0 R9
ALU 5780 DSC (PCRF) 5.0 R5
ALU 5620 SAM 10.0 R5
Figure 1 : Alcatel Lucent LTE Releases mapping
This document is focused on LTE FDD deployments and only covers LTE Network
Elements and/or interfaces within the LTE wireless scope, which includes UE, air
interface, eNodeB, MME, S-GW and P-GW.
The interfaces with EPC network elements like PCRF and HSS-AAA will be discussed
briefly in this document.
The interfaces with other external network elements (such as IMS, other Application)
will not be discussed in this document.
Page 11/273
1.3 AUDIENCE FOR THIS DOCUMENT

This information product assumes that anyone using the information in this manual
has a general familiarity with LTE System specifications, and has specific experience
working with, and operating, the Alcatel-Lucent LTE system.
The intended audience of this document is engineers who work with the Alcatel-
Lucent LTE network and need to know how to plan and expand an LTE network using
network statistics.
Therefore, the audience for this manual consists of:

• Field support personnel
• Network planners
• Network architect
• Network operators
1.4 CHANGE CONTROL

Sections
Version Date Reason for Re-issue
Modified
Rev 05.00 31/May/2013 All LE6.0 document creation from previous

LNCME document (v04.02 for LE5.0)
Rev 05.01 28/June/2013 All LE6.0 Draft version ready for formal review
Rev 05.02 25/July/2013 All Approved-Preliminary version
Rev 05.03 06/September/2013 All Approved-Standard version
Page 12/273
1.5 NOMENCLATURE
Engineering rules (mandatory to be followed) are presented as the following:
Rule:
Current known system/documentation restrictions are presented as the following:
Restriction:
Engineering recommendations (Alcatel-Lucent recommendation for optimal system

behavior) are presented as the following:
Engineering Recommendation:
The difference between Release n and Release n-1 are presented as the following:
LAn-1-LAn Delta:
1.6 RELATED DOCUMENTS
1.6.1 REFERENCE DOCUMENTS

[R01] 3GPP TS 36.306 (840), "Evolved Universal Terrestrial Radio Access (E-
UTRA); User Equipment (UE) radio access capabilities"
[R02] RFC 4960 Stream Control Transmission Protocol (SCTP) @

http://tools.ietf.org/html/rfc4960
1.6.2 CUSTOMER DOCUMENTS

[C01] LTE/DCL/APP/ 031078, FDD eNodeB LTE Parameters User Guide
[C02] LTE/DCL/APP/031106, LA6.0 eNodeB Product Engineering Guide
[C03] LTE/DCL/APP/031077, LE6.0 LTE OAM Product Engineering Guide

[C04] LTE/DCL/APP/031096, 9471 Wireless Mobility Manager Product Engineering
Guide
[C05] LTE/DCL/APP/031092, 9471 Wireless Mobility Manager Model Offer

Provisioning Guide
Page 13/273
[C06] LTE/DCL/APP/031094, 9471 Wireless Mobility Manager LTE Parameters

User Guide
[C07] LTE/DCL/APP/034072, LTE Transport Engineering Guide – (T)LE6
[C08] Multi-Rate Models for Dimensioning and performance Evaluation - Cost 242
Report (Michael Ritter and Phuoc Tran-Gia)
[C09] Equivalent Capacity and its Application to Bandwidth Allocation in High-Speed

Networks (R. Guérin, H. Ahmadi, M. Naghshineh)
[C10] LTE Dimensioning Guidelines – Outdoor Link Budget (Alcatel-Lucent External
documentation)
[C11] LTE Dimensioning Guidelines – Air Interface Capacity (Alcatel-Lucent

External documentation)
[C12] Alcatel-Lucent 7750 Service Router Mobile Gateway Integrated Services

Module (MG-ISM) – Data Sheet
[C13] Alcatel-Lucent 7750 Service Router Input/Output Module – Data Sheet
[C14] Alcatel-Lucent 7750 and 7710 Service Routers Ethernet Media Dependent
Adapter-XP (Ethernet MDA-XP) – Data Sheet
[C15] Release 4.0 7750 SR OS MG Basic System Configuration Guide
[C16] Release 4.0 R9 7750 SR Mobile Gateway Configuration Guide
[C17] Alcatel-Lucent 8650 SDM_HSS LTE_Feature_Overview_R3.1.doc
[C18] 8560 SDM R3.1 Product Description
[C19] Alcatel-Lucent 8950 AAA Release 8.0 User’s guide
[C20] Alcatel-Lucent 5780 DSC 5.0 R5 User Guide
[C21] 9YZ-03991-0007-RKZZA, Network Performance Optimizer Release

Operational Impact (ROI) FDD Reference Guide.
Page 14/273
2 LTE OVERVIEW
This chapter provides a high level overview of the LTE system architecture,
functionalities & interfaces.
2.1 LTE NETWORK OVERVIEW
2.1.1 REQUIREMENTS AND TARGETS FOR LTE

The work towards 3GPP Long Term Evolution (LTE) started in 2004 with the definition
of the LTE targets. Following these targets, LTE is supposed to be able to deliver
superior performance compared to existing 3GPP networks based on High Speed
Packet Access (HSPA) technology.
The LTE performance targets in 3GPP (defined relative to HSPA in Release 6) are
listed below:
 spectral efficiency two to four times more than with HSPA Release 6;
 peak rates exceed 100 Mbps in downlink and 50 Mbps in uplink;
 round trip time <10 ms;
 Simplified network architecture;
 high level of mobility and security;
 optimized terminal power efficiency;
 Frequency bandwidth flexibility from below 1.4 MHz up to 20 MHz allocations.
In addition, one important goal was the co-existence with legacy standards. LTE users
should be capable to start a call or data transfer in an area using an LTE standard,
and, if LTE coverage becomes unavailable, continue the operation without any action
on their part using GSM/GPRS or W-CDMA-based UMTS or 3GPP2 networks such as
CDMA2000.
In order to reach the above mentioned targets, several elements were

modified/evolved comparing to existing UMTS/HSPA standards.
2.1.1.1 AIR INTERFACE EVOLUTION
2.1.1.1.1 MULTI-CARRIER TECHNOLOGIES
The multiple access schemes in LTE downlink use Orthogonal Frequency Division
Multiple Access (OFDMA) and uplink uses Single Carrier Frequency Division Multiple
Access (SC-FDMA). These multiple access solutions provide orthogonality between
the users, reducing the interference and improving the network capacity.
The resource allocation in the frequency domain takes place with a resolution of 180
kHz resource blocks (12 sub-carriers x 15 KHz) both in uplink and in downlink. The
frequency dimension in the packet scheduling is one reason for the high LTE capacity.
Page 15/273
The uplink user specific allocation is continuous, enabling single carrier transmission
while the downlink can use resource blocks freely from different parts of the spectrum.
The uplink single carrier solution is also designed to allow efficient terminal power
amplifier design, which is relevant for the terminal battery life.
The multiple access schemes are illustrated in the following figure:
From 1.4 to 20 Mhz
Uplink ….
SC- FDMA
UE1 UE2 UE3
Downlink ….
OFDMA
Frequency
Figure 2 : Frequency-Domain View of the LTE Multiple-Access Technologies
2.1.1.1.2 FLEXIBLE TRANSMISSION BANDWIDTH
The LTE solution enables spectrum flexibility where the transmission bandwidth can
be selected between 1.4 MHz and 20 MHz depending on the available spectrum.
2.1.1.1.3 MULTIPLE ANTENNA TECHNOLOGY
The use of multiple antenna technology also allows the exploitation of the spatial-
domain as another dimension. This becomes essential in the quest for higher spectral
efficiencies
For example, 20 MHz bandwidth can provide up to 150 Mbps downlink user data rate
with 2 × 2 MIMO, and 300 Mbps with 4 × 4 MIMO.
2.1.1.1.4 PACKET-SWITCHED RADIO INTERFACE
LTE has been designed as a completely packet-oriented multi-service system, without

the reliance on circuit-switched connection-oriented protocols prevalent in its
predecessors.
The route towards fast packet scheduling over the radio interface was already opened
by HSPA, which allowed the transmission of short packets having a duration of the
same order of magnitude as the coherence time of the fast fading channel, as shown
in Figure below:
Page 16/273
Figure 3 : Fast Scheduling and Link Adaptation
In LTE, in order to improve the system latency, the packet duration was further
reduced from the 2 ms used in HSDPA down to just 1ms. This short transmission
interval, together with the new dimensions of frequency and space, has further
extended the field of cross-layer techniques between the MAC and physical layers to
include the following techniques in LTE:
 Adaptive scheduling in both the frequency and spatial dimensions;

 Adaptation of the MIMO configuration including the selection of the number of
spatial layers transmitted simultaneously;
 Link adaptation of modulation and code-rate, including the number of

transmitted code words;
 Several modes of fast channel state reporting.
These different levels of optimization are combined with very sophisticated control
signaling in order to ensure a good inter-working.
2.1.1.2 CORE NETWORK ARCHITECTURE EVOLUTION
The high network capacity requires efficient network architecture in addition to the
advanced radio features. The 3GPP target was to improve the network scalability for
traffic increase and to minimize the end-to-end latency by reducing the number of
network elements.
In LTE, all radio protocols, part of mobility management, header compression and all
packet retransmissions are located in the base stations called eNodeB (also called
eNB). The eNodeB includes all those algorithms that are located in Radio Network
Controller (RNC) in 3GPP UMTS architecture.
Also the core network is streamlined by separating the user and the control planes.
The Mobility Management Entity (MME) is just the control plane element while the
Page 17/273
user plane bypasses MME directly to System Architecture Evolution (SAE) Gateway
(GW).
The LTE architecture evolution is illustrated in Figure 4. This LTE core network is also
often referred to as Evolved Packet Core (EPC) while for the whole system the term
Evolved Packet System (EPS) is used.
UMTS LTE
GGSN SAE GW
SGSN MME
EPC
RNC
eNodeB
NodeB
Control Pla ne
User Pla ne
Figure 4 : EPS Architecture Evolution
A key feature of the EPS architecture is the clean separation in the core network of
control plane (MME) and the user plane (EPS gateway), allowing for independent
scaling of these two planes.
 Capacity of user plane depends on aggregate data throughput required.
 Control plane functionality depends on number of mobiles and their mobility

patterns.
2.1.2 LTE NETWORK ARCHITECTURE OVERVIEW

The following figure shows the division of the LTE architecture into three main high
level domains: User Equipment (UE), Evolved UTRAN (E-UTRAN) and Evolved
Packet Core Network (EPC).
Note that network elements and interfaces presented in this part of the document are
generic LTE elements and may not all be supported in the LE6.0 release. The external
NEs not describe in the LNCME are backgrounded in grey color.
Page 18/273
Figure 5 : System Architecture for LTE E-UTRAN & EPC Network
The development in E-UTRAN is concentrated on one node, the evolved NodeB

(eNodeB). All radio functionality is collapsed there, i.e. the eNodeB is the termination
point for all radio related protocols. As a network, E-UTRAN is simply a mesh of
eNodeBs connected to neighboring eNodeBs with the X2 interface.
In the LTE core network (EPC), the UMTS equivalent SGSN has been split into MME
(Mobility Management Entity), which handles control functions, and Serving SAE GW
(S-GW), which handles User Plane traffic. There is one anchor MME and S-GW per
UE. MME and S-GW may be collocated.
The UMTS GGSN equivalent is PDN SAE GW (P-GW), which may or may not be
collocated with S-GW. The P-GW is the inter-system anchor point for each UE. It
provides access to PDNs.
For details on Alcatel-Lucent LTE implementation of eNodeB and MME products and
LE6.0 solutions & configurations please refer to [C02] & [C04] in Section 1.6.
Page 19/273
2.1.3 LTE FUNCTIONS & INTERFACES - EUTRAN

This section introduces LTE network elements and Interfaces that are part of the basic
System Architecture configuration (with particular focus on elements involved on
Capacity & Dimensioning exercises).
2.1.3.1 USER EQUIPMENT (UE)
Functionally the UE is a platform for communication applications, which exchange

signal with the network for setting up, maintaining and removing the communication
links for the end user needs. This signalization includes mobility management
functions such as handovers, reporting terminal’s location, and in these, the UE
performs as instructed by the network.
The supported data ranges run from 5 to 75 Mbps in the uplink direction and from 10
to 300 Mbps in the downlink direction. All devices support the 20 MHz bandwidth for
transmission and reception.
Only a category 5 device will do 64QAM in the uplink, others use QPSK and 16QAM.
The receiver diversity and MIMO are implemented in all categories, except in category
1, which does not support MIMO.
The UE categories are shown in the following table:

User equipment UE category
1 2 3 4 5
Maximum downlink data rate (Mbps) 10 50 100 150 300
Maximum uplink data rate (Mbps) 5 25 50 50 75

Number of receive antennas required 2 2 2 2 4
Number of downlink MIMO streams 1 2 2 2 4

supported
Support for 64QAM modulation in downlink Yes Yes Yes Yes Yes
Support for 64QAM modulation in uplink No No No No Yes
Table 1 : 3GPP Defined LTE UE categories
The UE capacity aspects will not be detailed in this document. Only UE Category will
be referenced to characterize the UE capacity & performance limitations.
The UE behavior (number of UEs handled by a NE, UEs spatial repartition, mobility
patterns) is an important call model element that will be considered in the LTE
dimensioning exercises.
Page 20/273
2.1.3.2 LTE FDD RADIO INTERFACE
The LTE FDD Radio Interface relies on OFDMA and SC-FDMA multiple access
techniques on the DL and UL, respectively. In an LTE system, many users of one LTE
carrier can be active at the same time. All such users share the UL and DL air
interface resources. These resources comprise of a number of Physical Resource
Blocks (PRBs), each of which is made up of twelve 15 kHz sub carriers and 14
modulation symbols.
Resource Element (RE)

is a single subcarrier in
an OFDM symbol
14
s ym
bo
ls (
T ch
un
k =1
.0 m
s) 12 sub-carriers
(180 kHz)
Figure 6 : Physical Resource Block (PRB) General View
The Physical Resource Block (PRB) is the minimum unit of radio resources allocation
in LTE.
The PRB structure is the same for UL and DL, but the resource element (RE) usage
(and implicitly the space available for user data) is different on the two directions.
2.1.3.2.1 DL PHYSICAL RESOURCE BLOCK STRUCTURE
Not all 168 Resources Elements (REs) available in a DL PRB (14 OFDM Symbols x
12 Sub-carrier) are used for user data traffic (for PDSCH).
Up to 3 OFDM symbols (on all 12 carriers) are reserved for signaling channels
(PCFICH, PDCCH, PHICH).
In addition to the control symbols, some PRB space is used for the Reference Signal
(RS). The number of RS blocked for reference signals depends on the cell MIMO
configuration (8 REs for 1 antenna transmission, 16 REs for 2 antenna transmission).
For details on LTE DL Physical Channels structure please refer to [R01].
Page 21/273
first 1..3 OFDM symbols

reserved for control
signaling (PCFICH, Reference
PDCCH, PHICH) Symbols
12 subcarriers
Slot = 0.5ms Slot = 0.5ms
14 OFDM symbols
(1 ms sub-frame)
Figure 7 : DL PRB Structure
In the Figure 7, we can see that the DL PRB space for user data is reduced from 168
to 120 REs. This is a typical cell configuration case: 3 OFDM symbols used for
signaling channels (3x12=36 REs) and MIMO 2x2 cell configuration (16 REs for RS).
2.1.3.2.2 UL PHYSICAL RESOURCE BLOCK STRUCTURE
As with the DL PRB, the UL PRB space for user data is also impacted by the REs
reserved for reference signals:
DM-RS SRS
12 subcarriers
Slot = 0.5ms Slot = 0.5ms
14 SC-FDMA symbols
(1 ms sub-frame)
Figure 8 : UL PRB Structure
Page 22/273
Data demodulation reference signal (DM-RS) is sent with each packet transmission in
order to demodulate data. It occupies center SC-FDMA symbol of the slot.
Sounding reference signal (SRS) is used to sound uplink channel to support frequency
selective scheduling.
For details on LTE DL Physical Channels structure please refer to [R01].
Due to reference signals, we can see in the Figure 8 that the UL PRB space for user
data is reduced from 168 to 132 REs (24 REs for DM-RS and 12 REs for SRS).
The PRB available space for User data (nb. of user data REs) is one of the main
elements impacting the radio interface dimensioning. It is the main input for the DL/UL
peak cell & user throughput, the dimensioning elements of the radio interface.
The number of Physical Resource Blocks (PRBs) and their associated sub-carriers is
dependent upon the carrier bandwidth which can be 1.4, 3, 5, 10, 15 or 20MHz:
Bandwidth NPRB
1.4MHz 6
3MHz 15
5MHz 25
10MHz 50
15MHz 75
20MHz 100
Table 2 : LTE Bandwidth vs. Physical Resource Blocks (UL & DL)
Considering the above mentioned dimensioning elements (available PRB space for
user data and the number of PRBs for specific bandwidth) we can compute the peak
cell throughput for a given cell (details in next chapters).
2.1.3.2.3 CAPACITY VS. COVERAGE
For a given LTE scheduling instance, each LTE user has one or more PRBs dedicated
for their sole use. As each PRB within an LTE system is dedicated to a specific user at
given instant in time, individual users don’t interfere with other users simultaneously
scheduled in nearby PRBs in the same cell. As a consequence, the internal
interference experienced by users can only emanate from other LTE cells.
In terms of radio network dimensioning, we can say that LTE coverage and capacity
are closely related, in a similar way to that of CDMA and WCDMA systems: The
capacity supported by a given cell will impact the interference level generated in other
cells, especially adjacent cells. A higher PRB loading on one cell will result in a
reduction in the coverage/capacity of adjacent cells.
However, a key difference between an LTE system and a CDMA/WCDMA system is
that there is no intra-cell interference (much like a GSM system). As the user traffic
Page 23/273
increases the effect of increasing interference is experienced by the adjacent cells

rather than on the loaded cell itself.
For WCDMA and CDMA systems it is best practice to consider a feedback loop linking
coverage and capacity analysis to match both constraints (as illustrated below):
Multi-service Traffic
Cell Range
captured in the cell
Tra ffic
Covera ge a na lysis
a na lysis Generated
Interference
Figure 9 : Coverage vs. Capacity Analysis Feedback Loop
Such feedback is not considered mandatory in the dimensioning process for an LTE
system, given that loading and coverage are less strongly linked.
Another consideration for the LTE air interface (compared to WCDMA and CDMA) is
the lack of soft handoff functionality, which reduces the capacity losses due to multiple
radio-links per UE.
2.1.3.3 E-UTRAN NODE B (ENODEB)
The only node in the E-UTRAN is the Evolved NodeB (eNodeB). The eNodeB is a
radio base station that is in control of all radio related functions in the fixed part of the
system.
Functionally eNodeB acts as a layer 2 bridge between UE and the EPC, being the
termination point of all the radio protocols towards the UE, and relaying data between
the radio connection and the corresponding IP based connectivity towards the EPC.
The eNodeB is responsible for the Radio Resource Management (RRM) which
controls usage of the radio interface. This includes, for example, allocating resources
based on requests, prioritizing and scheduling traffic according to required Quality of
Service (QoS), and constant monitoring of the resource usage situation.
In addition, the eNodeB has an important role in Mobility Management. The eNodeB
controls and analyzes radio signal level measurements carried out by the UE, makes
similar measurements itself, and based on those measurements, makes decisions to
handover UEs between cells. This includes exchanging handover signaling with other
eNodeBs and the MME.
In Alcatel-Lucent solution the eNB is implemented as a distributed solution composed

of two distinct parts: the digital unit (9926) and the radio heads.
Page 24/273
Digital Radio
Radio
9926 Optical link RRH
RRH
ControllerModule
Modem
CEM Remote
RemoteRadio Head
Radio Head
Radio
Core Controller
Optical link
Modem
CEM RRH
RRH
Remote
RemoteRadio Head
Radio Head
Optical link Radio

Modem RRH
RRH
Remote
RemoteRadio Head
Radio Head
Backhaul (S1/X2)
Figure 10 : eNodeB – Remote Radio Configuration
For details on eNB HW configurations and SW functions supported in LA6.0 please

refer to 1.6.2 and [C02].
The eNB elements considered in the eNB dimensioning exercise (Modem board(s)
and Controller board) are the two main boards of the digital unit (9926).
The main dimensioning elements for these two boards are
 Number of Active users handled by the board (for Modem and/or Controller board)
 The board decoding throughput (for modem boards) and the backhaul throughput
(for controller board)
2.1.3.4 EUTRAN INTERFACES
The E-UTRAN consists of a set of eNodeBs (eNBs) connected to the Evolved Packet
Core (EPC) through interface S1. eNBs can be interconnected through interface X2
(source eNodeB to target eNodeB) when X2 is used for intra-E-UTRAN handover. E-
UTRAN supports in addition M1 and M3 interfaces, for the purpose to enable
Multimedia Broadcast/Multicast Service (MBMS).
E-UTRAN overall architecture is depicted in Figure 11 below.
Page 25/273
MBMS GW
e-UTRAN
Sm
M1 MME
eNodeB
S1-MME
M3
X2-U
X2-C
S11
S1-U
eNodeB S-GW
Figure 11 : E-UTRAN Overall Architecture
S1 & X2 interfaces are further divided into control plane related part (S1-MME & X2-C)
and user plane related part (S1-U & X2-U).
S1-MME is the reference point for the control plane protocol between E-UTRAN and
the EPC Mobility Management Entity (MME). S1-MME uses S1 Application layer
Protocol (S1AP) to provide the signalling service between E-UTRAN and the MME.
S1AP services are divided into two groups:
 Non UE-associated services are related to the whole S1 interface instance

between the eNB and MME utilising a non UE-associated signalling
connection.
 UE-associated services are related to one UE. S1AP functions that provide
these services are associated with a UE-associated signalling connection that
is maintained for the UE in question.
S1-MME enables as well source / target eNBs handover for X2-based and / or S1-
based handovers. S1AP is carried over SCTP/IP which provides reliable, in-sequence
transport of messages with congestion control over IP. S1-MME protocol stack is
depicted in section 3.5.4.1.
S1-U is the reference point between E-UTRAN and the EPC (Serving GW) for the per
bearer user plane tunnelling and inter eNodeB path switching during handover. S1-U
is based on GTP-U protocol and is transported over UDP/IP as depicted in section
3.5.4.1.
X2-C is the reference point for the control plane protocol between eNBs (source and
target eNBs) when inter eNBs handover is to be supported. X2-C uses X2 Application
layer Protocol (X2AP) to provide the signalling service between source and target
Page 26/273
eNBs, which are involved in inter eNB handover. X2AP services are divided into two
groups:
 X2AP basic mobility procedures are used to handle the UE mobility within E-
UTRAN.
 X2AP global procedures are not related to a specific UE and are used to
enable E-UTRAN inter eNBs communication.
X2AP is carried over SCTP/IP which provides reliable, in-sequence transport of

messages with congestion control over IP. X2AP protocol stack is depicted in section
3.5.5.1.
X2-U is the reference point between source and target eNBs, for bearer inter eNodeB
path switching during handover. X2-U enables data forwarding from source eNB
toward target eNB, while handing over between eNBs, when radio interface is already
established in the target cell. X2-U is based on GTP-U protocol and is transported
over UDP/IP as depicted in section 3.5.5.1.
S1 & X2 dimensioning depends very much about the amount of traffic carried by
eNBs. This is directly related to the traffic profile which is used as the input for the
dimensioning exercise. S1 & X2 require being carefully engineered and monitored in
order to avoid capacity shortage which would affect end user quality of service.
M1 interface is the reference point between MBMS GW and E-UTRAN for MBMS data
delivery. M1 interface is a bearer interface. It relies on GTPv1-U.
M3 interface is the reference point between the MME and the eNodeB embedded
Multi-cell/multicast Coordination Entity (MCE). M3 interface features an application
part (M3-AP) for the purpose to allow MBMS Session Control Signaling on E-RAB
level (i.e. it does not convey radio configuration data). The procedures comprise e.g.
MBMS Session Start and Stop. M3-AP is carried over SCTP.
Page 27/273
2.1.4 LTE FUNCTIONS & INTERFACES - EPC

2.1.4.1 MME
Mobility Management Entity (MME) is the main control element in the Evolved Packet
Core (EPC). MME handles the Control Plane, and it is not involved in the User Plane,
excepted for bearer management functions (bearer set up, release, etc).
In addition to the interfaces that are shown in the 3GPP standards, please note that
the MME does provide a direct control plane connection to the UE through S1-
AP/NAS, to enable UE / MME control plane connection.
The MME manages subscription profile and service connectivity. When the UE
registers to the network, the MME is responsible for retrieving UE subscription profile
from the home network. This profile determines which Packet Data Network (PDN)
connection(s) has to be allocated to the UE at network attachment. The MME
automatically sets up the default bearer, giving the UE the basic IP connectivity.
From a mobility management perspective, the MME keeps track of the location of all
UEs in its service area. The MME manage also the cooperation with other radio
access technology (2G / 3G), also known as “Inter Radio Access Technology IRAT” as
it enables handovers, reselection and redirections in case 4G/LTE coverage is weak
or missing. The MME controls as well Circuit Switching Fall Back (CSFB) functionality
for voice and SMS services.
The MME functionalities are hosted by the Alcatel-Lucent 9471 WMM. Further details
regarding the 9471 WMM product can be found in reference [C04]. The main MME
functionalities, with regards to the 3GPP base system architecture, are:
 Authenticates and authorizes a UE at the time of initial attachment, and

subsequent attachments.
 Terminates Non-Access Stratum (NAS) signaling from the UE.
 Assigns temporary identities (GUTI) to UEs.
 Selects S-GW at the time of initial attachment and during relocation.
 Selects P-GW based on subscriber profile or provisioned data.

 Performs idle-mode paging.
 Manages tracking-area lists.
 Performs bearer management functions such as activation and deactivation of

bearer when requested by UE or the network.
 Provides lawful intercept support.
 Selects S-GW for intra-LTE handover.

 Supports intra-LTE handover.
 Supports inter- Radio Access Technology (RAT) handovers.
 Supports 9471 WMM and S-GW pooling.

 Supports Location-based Services to assist subscribers who place emergency
calls.
Page 28/273
 Supports Warning Message Delivery to UEs in a particular area.

 Supports Multimedia Broadcast/Multicast Service, a broadcast service in which
data is transmitted form a single source entity to multiple recipients.
The 9471 WMM supports the following interfaces:

 S1-MME to the EUTRAN.
 S3 to release 8 SGSN (so called S4 capable SGSN).
Please note as the Alcatel-Lucent S-GW does not support so far S4 interface, S3
interface is not supported from LE6 solution release perspective.
 Gn to pre-release 8 SGSN.
 S6a to HSS.
 S10 to other(s) MME(s).
 S11 to S-GW.
 S13 to Equipment Identity Register (EIR).
 SBc to Cell Broadcast Center (CBC).
 SGs to the MSC/VLR that supports coordinating the location of UEs that are IMSI
attached to both EPS and non-EPS services for the purpose to enable Circuit
Switch Fall Back (CSFB) service for voice and/or SMS.
 SLg to Gateway Mobile Location Center (GMLC). This interface will be described
in a further release of the document.
 SLs to EPC-Serving Mobile Location Center (E-SMLC). This interface will be

described in a further release of the document.
 Sm to Multimedia Broadcast/Multicast Service (MBMS) Gateway.
 Sv to MSC server that supports UMTS hand down of IMS-anchored voice

sessions to the CS domain in the UTRAN/GERAN for the purpose to enable
Single Radio Voice Call Continuity (SRVCC).
 M3 to the Multicast Control Entity (MCE) in the eNB nodes.
 Lawful intercept interfaces (X1_1 and X2_IRI).
 Interface to the management system (please refer to section 3.3).
2.1.4.2 HSS
The LTE Home Subscriber Server (HSS) manages the EUTRAN Mobile Subscribers
and all the associated standardized subscription information which are needed to
setup LTE (so called 4G) calls.
In a 3GPP inter-working configuration, the HSS is associated with GSM/UMTS Home

Local Register HLR, in order to manage the GERAN/UTRAN Mobile Subscribers and
all associated standardized subscription information needed to setup GSM, SMS,
UMTS HSPA+ or GPRS calls.
Page 29/273
In a non-3GPP inter-working configuration, the HSS is associated with the

Authentication, Authorization and Accounting (AAA) server. The AAA manages
Trusted and non-Trusted non-3GPP Mobile Subscribers and respectively all related
subscription information which needs to setup CDMA, HSPD, WIMAX and WLAN
calls.
The main HSS functionalities, in a basic system architecture configuration, are:
 Storage of subscriber data Authentication and Security.

 Enhanced Presence Service (EPS) QoS subscriber profile.
 Roaming restrictions list.
 Address of current serving mobility management entity (MME).
 Accessible Access Point Names (APNs).
 Current Tracking Area (TA) of user equipment (UE).
 Authentication vectors and security keys per UE.
The 3GPP-LTE HSS and HLR functionalities are hosted by the Alcatel-Lucent 8650
SDM. Further details regarding the 8650 SDM product can be found in reference [C17]
and [C18].
In the scope of EPC, the 8650 SDM supports the following interfaces:
 S6a to the MME.
 S13 to the MME, when the EIR functionality is embedded to the 8650 SDM.
 Interface to the management system. Interface to the management system will be

2.1.4.3 AAA
3GPP-AAA component is introduced in the core LTE architecture to perform

authentication of the non-3GPP user (from both trusted and un-trusted networks)
accessing the LTE network services.
Non-3GPP networks can either be a 3GPP2 network such as the CDMA, which
operates in a licensed radio spectrum (trusted non 3GPP networks) or a network such
as WiFi, which operates in unlicensed spectrum (un-trusted non-3GPPnetwork).
3GPP standards have defined procedures for interoperability of these networks with
the LTE network.
3GPP-AAA supports the following features:

 Provides authentication services for trusted non-3GPP network
interconnections. For example, with CDMA or EVDO.
 Provides authentication services for un-trusted non-3GPP network

interconnections through the ePDG. For example, WiFi offload, WiMax
interconnection, and so on.
 Proxy the authentication requests to and from other 3GPP-AAA in roaming

scenarios.
Page 30/273
 Obtains authentication vectors and session encryption keys from the HSS.
 Indicates user session state changes to the HSS.
 Retrieves the user service profile data from the HSS and provides it to the
PGW / ePDG.
 Notifies HSGW / PGW / ePDG about an abort user session request initiated
by the HSS.
 Notify user profile changes initiated by the HSS (Push-Profile request from
HSS) to HSGW, PGW, and ePDG. This notification causes are authorization
(in a trusted access) or a full re-authentication (in an un-trusted access) of the
user session.
 Cache HSS authentication vectors and user profiles for fast re-authentication.
The Alcatel-Lucent non 3GPP-LTE AAA functionalities are hosted by the 8950 AAA.
Further details regarding the 8950 AAA product can be found in reference [C19].
In the scope of non 3GPP-LTE AAA, the 8950 AAA supports the following interfaces:
 S6b to the P-GW.
 STa to non-3GPP IP Access.
 SWa to the un-trusted non-3GPP IP Access.
 SWd between 3GPP AAA Server and 3GPP AAA proxy.
 SWm to the ePDG.
 SWx to the HSS.
2.1.4.4 S-GW
The Serving GW (S-GW) is the gateway which terminates the interface towards E-
UTRAN. For each UE associated with the EPS, at a given point of time, there is a
single Serving GW.
The S-GW provides local mobility anchor point for inter-eNodeB handover. The S-GW
provides mobility anchoring for inter-3GPP mobility, downlink packet buffering and
initiation of network triggered service request procedure (when an UE is in idle mode,
eNodeB resources only are released, but resources are maintained at S/P-GW levels,
when S-GW receives data packets from P-GW for that UE, the S-GW buffers the
received packets, and requests the MME to page the UE, so that the UE re-connects,
and when the resources are re-established, buffered packets are forwarded to the UE
through the E-UTRAN). The S-GW provides packet routing and forwarding along with
transport level packet marking in the uplink and the downlink, e.g. setting the DiffServ
Code Point, based on the QCI of the associated EPS bearer.
The S-GW functionalities are hosted by the Alcatel-Lucent 7750 SR OS MG, which
provides the 7750 Service Router Serving Gateway functionalities by use of dedicated
Mobile Gateway - Integrated Services Module (MG-ISM).
Further details regarding the 7750 SR OS MG product can be found in [C12] and
[C13].
Page 31/273
When it operates as an S-GW, the 7750 SR OS MG supports the following interfaces:

 S1-U to the E-UTRAN
 S2a to the Trusted non-3GPP IP Access
 S11 to the MME

 S12 to UTRAN (in case of release 8 SGSN)
 S5 / S8 to the P-GW
 Ga to the charging Gateway function

 Gz / Rf to the Offline Charging System (OFCS)
 X1, X2, X3 lawful intercept.
2.1.4.5 P-GW
The Packet Data Network Gateway (PDN-GW or P-GW) is the gateway which
terminates the EPC interface towards the PDN (SGi reference point). This is the
highest level mobility anchor in the EPC, and it provides the UE with IP point of
attachment. If a UE is accessing multiple PDNs, there may be more than one PDN
GW for that UE.
P-GW features UE IP address allocation, per user service based uplink/downlink

traffic gating, per user service based uplink/downlink rate enforcement,
uplink/downlink per APN rate enforcement, per user based packet filtering (by means
of deep packet inspection), uplink/downlink transport level packet marking (setting the
DiffServ Code Point, based on the QCI of the associated EPS bearer), accounting for
inter-operator charging, offline charging system interfacing, DHCP functions.
The P-GW functionalities are hosted by the Alcatel-Lucent 7750 SR OS MG, which
provides the 7750 Service Router Serving Gateway functionalities by use of dedicated
Mobile Gateway - Integrated Services Module (MG-ISM).
Further details regarding the 7750 SR OS MG product can be found in [C12] and
[C13].
When it operates as a P-GW, the 7750 SR OS MG supports the following interfaces:
 S2a to the trusted non-3GPP IP access
 S6b to 3GPP AAA Server / Proxy.
 S5 / S8 to the S-GW
 Gn/Gp to Gn/Gp SGSN
 SGi to the packet data network (PDN)
 Gx to the PCRF
 Ga to the charging Gateway function
 Gz / Rf to the Offline Charging System (OFCS)
 Ro / Gy to the Online Charging System (OCS)

Page 32/273
 Lawful intercept.
 Interface to the management system (please refer to section 3.3.)
Please note that the 7750 SR OS MG, can operate as an S-GW or a P-GW or both.
When it supports P-GW functional role, the 7750 SR OS MG can feature as well
GGSN type of functionalities. As the scope of this document is LTE only, GGSN type
of capability is not addressed in this document.
Please note in addition, that capacity and engineering limits which are described in
section 3.6.1, apply to the 7750 SR OS MG regardless of whether the product
operates as an S-GW or a P-GW.
2.1.4.6 PCRF
The PCRF features policy control decision and flow based charging control
functionalities. It provides network control regarding the service data flow detection,
gating, QoS and flow based charging (except credit management) towards the Policy
and Charging Enforcement Function (PCEF); in the scope of LTE EPC architecture
the PCEF is hosted by the P-GW.
The PCRF applies the security procedures, as required by the operator, before
accepting service information from the Application Function (AF); which can be IP
Multimedia Subsystem (IMS) or any other policy enabled applications.
The PCRF decides whether application traffic detection is applicable, as per operator
policies, based on user profile configuration, received within subscription information.
The PCRF decides how certain service data flow/detected application traffic shall be
treated in the PCEF (traffic gating, traffic enforcement, filtering, QoS control, etc), and
ensure that the PCEF user plane traffic mapping and treatment is in accordance with
the user's subscription profile.
PCRF operates throughout the user interaction duration with the EPC i.e. at User
Equipment (UE) attachment, upon resource request to support application session
establishment, or upon session resources modification resulting from subscriber
profile updates in the database.
The PCRF is hosted by the Alcatel-Lucent 5780 DSC. Further details regarding the
5780 DSC product can be found in reference [C20].
The 5780 DSC operating as a PCRF supports the following interfaces:
 Gx to the P-GW.
 S9 between V-PCRF and H-PRF (in case of roaming architecture).
 Sp. So far this interface is not in the scope of this document.

 Rx. So far this interface is not in the scope of this document.
 Sy to the Online Charging System
Page 33/273
2.1.4.7 EPC INTERFACES
 Ga: Interface between S-GW or P-GW and Offline-Charging System (OFCS).

Ga relies on GTP’. Charging interfaces will be described in a further release of
the document.
 Gn: Interface between MME and pre-release 8 SGSN. Gn relies on GTP

tunnels (GTP-U for user plane and GTP-C for control plane).
 Gx: Interface between P-GW and PCRF. Gx relies on Diameter protocol.
 Gz/Rf: Interface between S-GW / P-GW and Offline-Charging System

(OFCS). Gz/Rf relies on Diameter protocol. Charging interfaces will be
 M1: Interface between eNodeB and Multicast Broadcast/Multicast Service

(MBMS) Gateway. M1 relies on GTP-U.
 M3: Interface between the eNodeB embedded Multicast Control Entity (MCE)
and MME. M3 relies on M3 Application Protocol (M3AP) and is transported
over SCTP.
 Ro/Gy: Interface between the P-GW and Online Charging System (OCS)
Ro/Gy interface relies on Diameter protocol. Charging interfaces will be
 Rx: Interface between PCRF and IMS application function or any other policy
enabled applications. Rx relies on Diameter protocol. So far this interface is
not in the scope of this document.
 S2a: Interface between trusted non-3GPP IP access and S-GW / P-GW. S2a
relies upon PMIPv6 (it is used for user plane on 3GPP2 enhanced High Rate
Packet Data (eHRPD) hand over purpose). So far this interface is not in the
scope of this document.
 S2b: Interface between PDN GW/S-GW and ePDG for trusted non-3GPP
access with GTP or PMIPv6. So far this interface is not in the scope of this
document.
 S2c: Interface between P-GW and non 3GPP UE. So far this interface is not in
the scope of this document.
 S3: Interface between MME and release-8 SGSN. It enables the MME to
support handovers between a 3GPP UMTS or GERAN network and an LTE
network. S3 relies on GTP tunnels (GTPv2-C). Though this interface is
supported at MME level, S3 interface is not supported from an end to end
Alcatel-Lucent perspective as S4 interface is not supported at S-GW level.
 S4: Interface between S-GW and release-8 SGSN. It enables the MME to
support handovers between a 3GPP UMTS or GERAN network and an LTE
network. S4 relies on GTP tunnels (GTP-U). This interface is not supported so
far at S-GW level.
 S5: Interface between S-GW and P-GW within the same Public Land Mobile
Network (PLMN). S5 relies on GTP tunnels (GTP-U for user plane and
GTPv2-C for control plane).
Page 34/273
 S6a: Interface between MME and HSS (hosting subscriber profile database).
S6a allows transfer of subscription and authentication data. S6a relies on
Diameter protocol.
 S6b: Interface between P-GW and 3GPP AAA Server / Proxy. S6b relies on
Diameter. This interface is specified in TS 29.273. This interface will be
 S8: Interface between S-GW and P-GW which is located in a different PLMN
(in case of roaming). S8 relies on GTP tunnels (GTP-U for user plane and
GTPv2-C for control plane).
 S9: Interface between PCRF in the HPLMN (H-PCRF) and PCRF in the
VPLMN (V-PCRF) (in case of roaming). S9 relies on Diameter protocol.
 S10: Interface between MMEs in the same or different MME pools. S10 relies
on GTP tunnels (GTPv2-C).
 S11: Interface between MME and S-GW to enable bearer session creation
and deletion. S11 relies on GTP tunnels (GTPv2-C).
 S12: Interface between 3G UTRAN and S-GW. It enables user-plane direct

tunnel capability. S12 relies on GTP tunnels (GTP-U). In line with S3 and S4
interfaces, so far this interface is not supported at S-GW level.
 S13: Interface between MME and EIR to enable transfer of Mobile Equipment
Identity (MEI). S13 relies on Diameter protocol.
 SBc: Interface between MME and Cell Broadcasting Center (CBC) (for the
purpose to enable warning messages delivery in the Commercial Mobile Alert
System (CMAS) context). SBc relies on SBc Application Protocol (SBcAP)
and is transported over SCTP.
 SGi: Interface between P-GW and Packet Data Network (PDN). SGi relies on
IP.
 SGs: Interface between MME and MSC/VLR (to support UEs location
coordination for the purpose to enable CSFB). SGs relies on SGs Application
Protocol (SGsAP) and is transported over SCTP.
 SLg: Interface between MME and Gateway Mobile Location Center (GMLC).
SLg relies on Diameter protocol. This interface will be described in a further
release of the document.
 SLs: Interface between MME and the EPC-Serving Mobile Location Center
(E-SMLC). SLs relies on SLs Application Protocol (SLsAP) and is transported
over SCTP. This interface will be described in a further release of the
document.
 Sm: Interface between MME and Multicast Broadcast/Multicast Service

(MBMS) Gateway. In the current EPC solution, Sm relies on GTPv2-C.
 Sp: Interface between the Subscription Profile Repository (SPR) and the
PCRF. So far this interface is not in the scope of this document.
Page 35/273
 STa: Interface between Trusted non-3GPP IP Access and 3GPP AAA

Server/proxy. This interface is specified in TS 29.273. This interface will be
 Sv: Interface between MME and MSC/VLR (to enable SRVCC support). Sv
relies on GTPv2-C.
 SWa: Interface between un-trusted non-3GPP IP Access and 3GPP AAA

Server/proxy. This interface is specified in TS 29.273. This interface will be
 SWd: Interface between 3GPP AAA Server and 3GPP AAA proxy. This
interface is specified in TS 29.273. This interface will be described in a further
release of the document.
 SWm: Interface between ePDG and 3GPP AAA Server/proxy. This interface is
specified in TS 29.273. This interface will be described in a further release of
the document.
 SWx: Interface between HSS and 3GPP AAA Server. This interface is
specified in TS 29.273. This interface will be described in a further release of
the document.
 Sy: Interface between PCRF and Online Charging System (OCS). Sy relies on
Diameter protocol. This interface will be described in a further release of the
document.
 S102: Interface between3GPP2 1xCS IWS and MME. This interface will be
2.2 LTE NETWORK CAPACITY AND DIMENSIONING OVERVIEW

Designing & operating an LTE network requires two different activities related to
capacity:
- Initial Engineering and Dimensioning
- Capacity Monitoring and Troubleshooting

These two activities are presented in this document.
A third activity may be required for the network capacity evolution. This activity is
specific to mature networks impacted by unexpected traffic growth (generated by
commercial offers or massive subscriber migration):
- System Capacity Planning
This third activity principle is described in this document (see Chapter 5), but the
detailed methods will be provided in a future release.
2.2.1 INITIAL ENGINEERING AND DIMENSIONING

This activity is required for the deployment preparation. The proposition is to correctly
configure (from HW and SW perspective) each network element and interface that will
be deployed in a specific area, avoiding over or under-dimensioning.
Page 36/273
Another goal of this activity is to correlate the different dimensioning constraints of

different network elements in order to obtain a coherent LTE Network design.
The main inputs and outputs of the initial engineering and dimensioning phase are
presented in the following figure:
Traffic profile Inputs

• # Subscribers per NE NE / Interface configuration
• Traffic Profile per Subscriber • Number of Processing boards
Dimensioning • Nb of Interface boards & ports

NE / Interface Capability
exercise • Interface configuration
• Board capacity (CP/UP)
•…
• # Boards / NE
• Interface capacity
•…
Figure 12 : Initial Engineering & Dimensioning: Generic Inputs & Outputs
The Initial Engineering and Dimensioning aspects are addressed in Chapter 3.

2.2.1.1 LTE CALL MODEL ELEMENTS
One of the most important inputs for a dimensioning exercise is the Traffic profile.
Traffic profile (or Traffic Model, or Call Model) represents a set of traffic parameters
that characterize the UE activity from User & Control Plane perspective:
 User Plane Call Model parameters

o Metrics relating to call activity (BHCA), throughputs, packet rates and
sizes, volumes, connection percentage, bearers
 Control Plane parameters
o General parameters for call activity (BHCA), attach/detach, handover,

TAU, paging
o Signaling message counts per control procedure for each NE
For the initial engineering & dimensioning exercise the call model can be:
 Either provided by the operator, based on marketing inputs
 Or, if operator call model is not available, a generic Alcatel-Lucent call model
can be obtained through the CTA organization
2.2.1.1.1 AN EXAMPLE TRAFFIC MODEL
The following example traffic model assumes 50% data cards and 50% smart phones
with Circuit Switch Fall Back (CSFB) for SMS and voice. This traffic model is used as
Page 37/273
an example throughout the document and is sometimes referred to as the “CSFB

model”.
o CSFB Voice
From signaling perspective, a CSFB voice call includes Page (for MT

calls), BHCA (Service Request + S1 release), and TAU. From traffic
perspective, a CSFB call includes only the period a voice call stays on the
LTE network; its call duration is very short (<1 second). The short voice
call duration has impact on the aggregate metrics.
o CSFB SMS
CSFB SMS messages are delivered similar to a regular LTE data call.
The main difference is that CSFB SMS are delivered via NAS messaging
to/from MME (which relays the SMS to/from 3G NEs). In ‘pure LTE’, SMS
are delivered via dedicated bearer for IMS signaling.
The main elements of the call model (with specific values for the example traffic
model) are presented in the following tables. Note that the tables show an example
and do not represent any specific field configuration. The example call model is used
as a basis to explain dimensioning and monitoring in later chapters. For all customer-
specific use cases, the example in this document will require updates to reflect the
true customer network.
Table 3 shows aggregate values for some key parameters.
Page 38/273
Per attached subscriber @

busy hour
Example
Customer
Call Model Parameter Traffic
Value
Model Value
General BHCA 20.1
% Orig. / Term. calls 72% / 28%
Call duration (seconds) 17.1
Duty cycle (on-time/call duration) 52%
User Packet size – DL (bytes) 582
Plane Packet size – UL (bytes) 186
kBytes per call - DL 244
kBytes per call - UL 52
Control Attach 0.12
Plane Detach 0.12
PDN Session request 0.13
Connection request (w/o CSFB) (16.3)
S1 release (w/o CSFB) (16.3)
Dedicated Bearer activation 0
Inter-eNB (X2) handover 7.6
Intra-eNB (RRC Only) handover 3.9
Inter-RAT handover 0.24
TAU with MME relocation 0.1
TAU with SGW relocation 0.1
TAU w/o MME/SGW relocation 1.5
TAU SGSN relocation 1.4
RAU with MME Relocation 1.0
CSFB SMS 2.9
CSFB voice 0.9
CSFB S1 release 3.4
Terminating calls non-CSFB 4.3
Terminating calls Voice 0.54
Terminating calls SMS CSFB 2.03
Paging eNBs Data / Term Call 13.3
Paging eNBs Voice / Term Call 64.2
Paging eNBs SMS CSFB / Term Call 10
Paging eNBs / BH / Subs [9471
WMM] 112
TA size (# eNBs) 50
TA List size (# eNBs) 60
Table 3 : Call Model Parameters – Aggregate Values
Some clarification of the above mentioned call Model parameters:
 paging-related parameters:
o Terminating calls: This is used in MME and eNB paging rate

calculations. It is equal to (BHCA * %Terminating calls). For CSFB,
terminating calls include SMS and voice calls. The percentage of
terminating calls may be different for SMS and voice calls.
Page 39/273
o Paging - eNB: This is the number of paging events per subscriber per
hour, at fully-loaded eNB. Its value is higher than ‘Terminating calls’
because the MME pages multiple eNBs for each terminating call at
MME. The Alcatel-Lucent estimated value is based on MME paging
implementation in LE6.0. Please refer to section 2.2.1.2 for more
details.
 The data call duration includes one or more “On” periods (transactions) where
UE sends/receives data, and a final period of dormancy just before the
connection is released. In the Alcatel-Lucent Call model, this dormancy period
is considered to be 10 sec.
This dormancy period is controlled through Traffic Based Context Release
functionality configuration at eNB level. This functionality is automatically
disconnecting dormant users after a preconfigured UE Inactivity timer
(timeToTrigger timer), allowing an optimal eNB resource usage. For Traffic
Based Context Release configuration parameters details please see Volume 5
in [C01].
Engineering Recommendation: Traffic Based Context Release functionality in LE6.0
In LE6, the Traffic Based Context Release functionality can be activated in the eNB through
the OAM parameter isTrafficBasedContextReleaseAllowed (in ActivationService MO). In
LTE networks handling commercial traffic it is strongly recommended to set this parameter to
“true“.
The OAM parameter that controls the dormancy period in the eNB is timeToTrigger (in
TrafficBasedReleaseConf MO). In order to ensure a good balance between User plane and
Control plane load, it is strongly recommended not to go below 10000 ms value for this
parameter (equivalent to a dormancy period of 10 s). For details of this parameter and its
LE6.0 default value, please refer to [C01][R01].
 The Duty Cycle parameter is defined as the ratio of on-time to call duration,
where on-time is the period during which the UE is in a transaction having
some data to be sent or received.
Rule: Control Plane
The Control Plane parameters are counted in number of procedures (Attach, Detach,…) per
subscriber and per Busy Hour.
The following table provides a further breakdown, by call type, of the general and user
plane parameters from Table 4.
Alcatel-Lucent projects that user traffic in LE6.0 deployments will be primarily Best
Effort data. However, the Alcatel-Lucent LE6.0 End-to-end network solution supports
the other call types listed (VoIP, SMS, GBR data), in addition to Best Effort data.
Page 40/273
Page 41/273
Per attached subscriber @

busy hour
Example
Call Model Parameter Traffic Model Customer
Value Value
VoIP BHCA 0.9
% Orig. / Term. Calls 60%
Packet size – DL (bytes) 0
Packet size – UL (bytes) 0
kBytes per call – DL 0
kBytes per call – UL 0
SMS CSFB BHCA 2.9
% Orig. / Term. Calls 70%
kBytes per call – DL 0.37
kBytes per call – UL 0.18
Aggregate BHCA 16.1
nonGBR % Orig. / Term. Calls 26%
Data Call duration (seconds) 15.2
GBR Data BHCA 0.17
(VT, RT- % Orig. / Term. Calls 14%
Gaming, Call duration (seconds) 540
RT-Video)
Table 4 : General and User Plane Parameters by Call Type
Table 5 provides some additional dimensioning parameters for subscriber loading and data usage
per cell.
Page 42/273
Example
Item Traffic Customer Notes
Model Value
Value
3MHz Average number of
155
subscribers per cell per BH
BH Activity Ratio Possibility of a subscriber being
14,2%
calculated @ 3MHz active in a busy hour.
5MHz Average number of
330
subscribers per cell per BH
12,4%
The maximum number of
10MHz Average number of subscribers on busy hour per ENB
825*
subscribers per cell per BH including 3 sectors is:
3x825 = 2475 subs/BH
11%
Subscriber Monthly Data Estimated monthly data usage per
Usage (Gigabytes) 2.1 subscriber.
Number of days in a month that the
Counted Days per Month 30
subscriber will use the network.
Percentage of the "per" busy hour
traffic among the daily traffic. This
BH Traffic Ratio value is equal to the total daily busy
14.4 equivalent hour traffic divided by the total daily
6.9%
BH per Day traffic and then divided by the
number of busy hours per day
Ratio of downlink to uplink cell data
DL to UL Load Ratio 5.1
load.
Table 5 : Subscriber Loading and Data Usage Profile
Note (*) Number of subscribers (idle mode + active mode) per cell per Busy Hour
(BH). These number are calculated with the hypothesis developed in the chapter 0,
where L2 of air interface is fully loaded (90% of the frame) by connected users in
active mode, during the peak traffic of Busy hours, for a 10MHz bandwidth
Table 6 shows the detailed call model for data traffic in the example traffic model. In
this model the CSFB SMS are not included in the Small message LTE. Numbers in
black color are aggregated in Table 4 in the category non GBR Data.
Page 43/273
Voice Small
non- message
1
Application Web GBR Streaming Online Without
2
Category Download Upload Browsing Email GBR Gaming CSFB SMS
Data
0,59 0,42 1,7 2,6 0,05 0,17 0,02 11
BHCA
Data
Volume per
1219 2,23 356 70,5 96 14506 5526 0.28
call DL
(kBytes)
Data
Volume per
0,74 766 2,7 50,2 96 1668 2974 0,27
call UL
(kBytes)
Packet
Size DL 608 351 1307 1266 35 1099 236 155
(Bytes)
Packet
Size UL 74 350 117 496 35 857 127 150
(Bytes)
Table 6: Detailed Data Call Model for the Example Traffic Model
2.2.1.2 PAGING AND TAU LOAD
This document will also address dimensioning aspects related to the Paging and
Tracking Area Update (TAU) load.
As the Paging and TAU procedures are handled by several LTE Network elements
(eNB & MME), the capacity impact and induced load will be analyzed separately in
different sections of the document (eNB part and MME part).
2.2.1.2.1 PAGING STRATEGY & TRACKING AREA SIZE
When a UE is in idle state, its location may not be exactly known. A Tracking Area
(TA) represents an area in which the UE was last registered, and it is necessary to
page the UE in the TA to locate the UE in a particular eNodeB. A TA update (TAU) is
generated when the UE crosses the boundary from one TA to another TA.
The LTE system has defined two TA operational schemes: the “multiple-TA
registration” scheme and the “overlapping TA” scheme.
 With multiple-TA registration, MME sends to the UE a TA List containing the

current TA and one or several neighbor TAs. UE will request TAU only when it
moves to a TA that is not in current list. This avoids ping-pong scenarios at
the TA border areas. MME will automatically include the previous (old) Last
Seen TA as a neighbor in the TA list and is capable of updating the TA List
automatically in order to track cyclic movement between 2 and 3 TAs.There is
1 ALU traffic model assumes streaming uses GBR in LE6.0

2 Alcatel-Lucent traffic model assumes Online Gaming uses Best Effort flows in LE6.0
Page 44/273
no need to provision/configure TA neighbor lists in MME. On average, it is

estimated that TA list size is ~1.2 TAs.
 In overlapping scheme, the eNodeB is configured to broadcast more than one

TA.
The following paging strategy is used as an example throughout this document as a
realistic strategy for the example traffic model described in Section 2.2.1.1.1. MME
supports different paging methods for CSFB Voice, CSFB SMS and (LTE) data calls.
 For CSFB Voice calls: 2 pages, where both will be TA list due to the delay
sensitive nature of voice calls.
 For CSFB SMS calls: 2 pages, where first is Last seen ENB and second is TA
list.
 For non-CSFB data calls: three pages, where first is Last seen eNB, second is
Last seen TA, and third is TA list.
Note that this strategy is similar to what is currently seen in the field and is not the
recommended paging strategy. Please see recommendation below.
Page 45/273
Engineering Recommendation: MME paging strategy for LE6.0
 For Best Effort data applications, the recommended paging strategy is:
1. Last Seen eNB
2. Last Seen eNB List (List Size = 5 eNBs)

3. TA List (Last Seen TA plus Neighboring TAs)
 For CSFB voice calls (applicable to 3GPP only for paging), the recommended paging strategy
is:
1. Last Seen eNB List (List Size = 5 eNBs)
2. TA List (Last Seen TA plus Neighboring TAs)
 For CSFB SMS calls (applicable to 3GPP only for paging), the recommended paging strategy
is:
 Last Seen eNB
 Last Seen eNB List (List Size = 5 eNBs)
 TA List (Last Seen TA plus Neighboring TAs)
Figure 13: MME Paging Strategy Recommended for non-CSFB (Data Traffic) Mobile in LE6.0
Page 46/273
Engineering Recommendation: Tracking Area size for LE6.0
Considering the above MME paging strategy and in order to simplify eNB TA provisioning, the
recommended approach is to provision the eNBs into tracking areas with ~40-50 eNBs per TA. This
value is in line with most of the current 3G RA configurations. For impact on eNB & MME paging rate
please refer to sections 3.2.5 & 3.4.3
The page response rate assumptions for each of the paging method are as follows:
Cumulative Cumulative
Page Success rate
Paging success rate success rate
Response after 1st page
Strategy after 2nd page after 3rd page
Assumption attempt
attempt attempt
TA list
CSFB Voice 93% 95% -
TA list
Last Seen eNB

CSFB SMS 85% 95% -
TA list
Last Seen eNB

Non-CSFB
Last Seen TA
Data 85% 92% 95%
TA list
Table 7 : eNBs Paged per MME Terminating Call
Based on the above paging strategy, the paging response rates and the TA/TA list
sizes, the eNBs paged per MME terminating call can be calculated as following:

st
eNBs paged / MME terminating Data call = 1 (for 1 paging attempt)
nd
+ numberEnbsTA * ( 1 - SucessRateAfter1stPage ) (for 2 paging attempt)
rd
+ numberEnbsTAList * ( 1 - CumulSucessRateAfter2ndPage ) (for 3 paging)
Example with TAsize = 50 eNBs and TAlistsize=60 eNBs in average for all subscribers
in the entire network:
 For all data calls:
eNBs paged / MME term. Data call = 1 + 50 *15% + 60 *8% =~13.3 eNBs.
 eNBs paged / MME terminating Voice call

st
= numberEnbsTAList (for 1 paging attempt)
nd
+ numberEnbsTAList * ( 1 - SucessRateAfter1stPage ) (for 2 paging attempt)
Page 47/273
Example with same hypothesis as the previous calculation:

 For CSFB voice calls:
eNBs paged / MME terminating Voice call = 60 + 60 *7%= ~64.2 eNBs.

st
eNBs paged / MME terminating CSFB SMS call = 1 (for 1 paging attempt)
nd
+ numberEnbsTAList * ( 1 - SucessRateAfter1stPage ) (for 2 paging attempt)
Example with same hypothesis as the previous calculation:
 For CSFB SMS calls:
eNBs paged / MME terminating SMS call = 1 + 60 *15% = 10 eNBs.
2.2.2 CAPACITY MONITORING AND TROUBLESHOOTING

This activity is generally launched once the network is deployed and handling
commercial traffic.
The purpose is to evaluate the load and the consequences of this load on Key
Performance Indicator, on all critical network elements and to rapidly detect/predict
any resource shortage issue (and take appropriate actions).
To evaluate this, the capacity monitoring is based on two main elements:
 Call Admission blocking (due to lack of resources labeled Failure)
 Resource loading (which may be evaluated at different levels: Control/User

plane).
Based on the above mentioned indicators, some capacity troubleshooting
decisions/actions may be triggered as indicated in the following example:
Page 48/273
=0 Status Green
Blocking?
No action required
>0
Low Status Yellow

Load
Capacity analysis/tuning
High
Status Red
Capacity analysis/tuning
and/or
Resources addition
Figure 14 : Capacity Analysis & Troubleshooting Example
The Capacity Monitoring & Troubleshooting aspects are addressed in Chapter 4.
Page 49/273
3 INITIAL ENGINEERING & DIMENSIONING

This section describes initial network dimensioning based on LTE Network Element
(NE) capabilities and traffic requirements, and provides specific capacity and
connectivity guidelines.
The initial dimensioning evaluates the network element count as well as the
associated capacity of those elements and interfaces. Specific architecture design
requirements, such as redundancy, and MME and SGW pooling strategy are not
presented in the LNCME. Using the estimated site configurations for the area of
interest and based on a certain traffic distribution, the initial dimensioning allows us to
calculate capacity and required configuration, and to estimate the amount of hardware
needed for each Network Element.
The mix of applications supported, traffic density, traffic growth estimates and QoS
(Quality of Service) requirements are important elements in the initial dimensioning
exercise. Service Quality is considered in terms of blocking probability and/or
nominal/guaranteed throughput per subscriber. Calculations are carried out for each
service and the tightest requirement determines the hardware needed for each NE.
For the EPC dimensioning, the guidelines are applicable only for “overlay networks”,
i.e. when the mobile operator deploys a network elements dedicated for LTE/EPC
only.
Capacity and Connectivity
Once RF Network Planning exercise is done and the coverage area is known (number
of sites, site distribution pattern, cell size…), the site configurations in terms of LTE
bandwidth, Antenna system (MIMO scheme), DL Power, number of modem
resources… have to be selected so that the traffic density supported by the chosen
configuration can fulfill the traffic requirements.
Note that the RF Network Planning is not in the scope of this document
Traffic Distribution
Traffic distribution and service requirements form the basis for network planning and
deployment. These parameters are required for evaluating the resources required at
each NE for a specific planning/deployment scenario.
Bearer service and traffic distribution should also be taken into consideration. The
more accurate the traffic estimate, the more realistic the results achieved.
Scope of Network Elements and Network Interfaces
The LTE network elements covered in this document include (see chapter 1.2 for
specific restrictions):
 eNodeB (eNB)
 OAM (eUTRAN & ePC)
 MME
Page 50/273
 S-GW
 P-GW
 HSS
 AAA
 PCRF
The LTE network interfaces covered in this document include:
 Air Interface
 S1 & X2 interfaces (User & Control Plane)
 EPC Control plane interfaces : S10, S11, S6A, S13, GN, S3, SGS, GX, Sv, S5
Please refer to 2.1.4.7 and Section 3.8.
3.1 LTE AIR INTERFACE DIMENSIONING

3.1.1 OVERVIEW
Air interface capacity is not an element that is considered by default in the Call
Admission Control (CAC) algorithm. This means that the Air interface capacity will not
directly limit the number of users that may be accepted in a cell (this will be indirectly
done by the number of users that can be accepted per eNB modem & controller board
– see 3.2 for details).
A CAC defense mechanism with CPU overload control and calls preemption was
implemented since LA5.0, in order to limit the CPU utilization in critical situation. The
CAC mechanisms that limit the number of simultaneous users and Bearers per cell,
depending on the real time PRB resource usage, still exist. The strategy used by CAC
is to preserve stable calls and maintain the QoS for existing services within the cell.
In LA6.0 and in overload situation, some RRC Connection Request messages may be
outdated when treated by the Call Processing function. In order to avoid unnecessary
processing and signaling these messages shall be discarded when the time spent in
the eNb is greater than the contention resolution timer.
Admission control has been enhanced to rely on many real-time measurement reports
from other functions or layers, such as # of users, real-time PRB consumption reports
from UL and DL schedulers, status of ongoing served QoS for existing calls, and UE
radio condition. This mechanism is based on consumption rules for the different types
of calls. This consumption per type of call values are fixed through OAM configuration
parameters (not dynamically updated) – see [R01] for details on the LA6.0 CAC
configuration parameters.
We consider that air interface dimensioning will take into account first about call
blocking limitations. To do this we evaluate the number of simultaneously connection
necessary. To do this we used the ErlangB law that gives a number of simultaneously
connected users, considering a blocking probability and a traffic intensity hypothesis.
This traffic intensity is derived from the traffic model. After all we will just use the max
available cell throughput to determine the required LTE bandwidth considering the
amount of throughput generated by this simultaneously connected users for a given
Page 51/273
traffic model and according to Antenna system (MIMO scheme) and cell/sector RF
output power.
According to the traffic requirements in terms of number of subscribers and traffic per
subscriber during the busy hour, the computed traffic per sector shall be compared to
the capacity per sector of one LTE carrier to determine the number and type of
resources that are needed considering distinctly GBR and non GBR type. These 2
types of traffic are considered regular and bursty traffic. For bursty traffic, a peak to
average method is used.
We will not present the detail CAC mechanism based on the measurement of PRB
resources consumed by the traffic generated by the current connected users. This
evaluation exercise needs to know the amount of GBR and NonGBR bearer used to
carry traffic and the average PRB consumption per kbps. Basically the CAC
mechanism checks for the acceptance of a new user by verifying the availability of
PRBs every second to deliver an amount of throughput.
The following figure illustrates the main inputs and outputs associated with an LTE air
interface dimensioning analysis.
Network/Site Information
• Site sector configuration
• LTE Frequency eNB RF Configuration
• LTE Maximum BW Air • LTE Bandwidth
LTE Cell Performances Interfa ce
• Antenna system (MIMO
•Achievable VoIP capacity /cell Dimensioning Scheme)
•UL & DL Throughput /cell
exercise • Output Power
Traffic Inputs
• # Subscribers
• Traffic Profile
Figure 15 : Air Interface Capacity Dimensioning Inputs and Outputs
Rule: Air Interface capacity & dimensioning vs. RF planning
Note that in this chapter only the Air interface capacity aspects will be addressed. Some
hypothesis/inputs used for Air interface capacity analysis are based on RF Network Planning outputs.
The RF Network Planning guidelines dealing with the Link Budget & Radio coverage aspects (cell size,
number of eNB sites & site positioning…) are provided in separate documents. See [C09].
3.1.2 AIR INTERFACE CAPACITY FIGURES

As a result of Alcatel-Lucent contribution to different working groups, such as 3GPP
Performance Verification or NGMN initiative, different air interface ‎capacity figures are
available based on an extensive set of system simulations results with wide ranging
simulation assumptions.
Page 52/273
The air interface capacity figures presented in this document are based on a set of
results coming from the Multi-Techno White Paper case (generally used for
contractual capacity commitments), a summary of these figures being presented in
‎3.1.2.1 & 3.1.2.2.
Additional capacity figures from other sets of results (NGMN Case1 & Case 3) can be
found in 3.1.2.1 & 3.1.2.2.
These figures depend on the radio assumptions, features and algorithms deployed
(e.g. MIMO scheme, interference coordination, scheduler algorithms) and the system
bandwidth.
The capacity analysis consists in determining the required bandwidth (e.g. 3MHz,
5MHz, 10MHz, etc) and the right features (e.g. is MIMO 2x2 required? is a high power
configuration required?) to be deployed to support the traffic per sector. If some
limitations are reached, the last resort is to add sites to support the traffic demand.
More details on this process are presented in ‎0.
3.1.2.1 UPLINK AIR INTERFACE CAPACITY
Table 8 summarizes the uplink air interface capacities for 1 LTE carrier for 1 sector for
air interface bandwidths supported in LA6.0: 1.4MHz, 3MHz, 5MHz, 10MHz & 20MHz.
Capacities are provided for both 2 branch receive diversity as well as 4 branches
receive diversity.
VoIP Data
FDD Configuration
CVoIP _UL CData _ UL
1.4 MHz - 2RxDiv 39.0 Erl 0.63 Mbps
3 MHz - 2RxDiv 100.0 Erl 1.64 Mbps
2 0MHz - 2RxDiv 648.0 Erl 12.3 Mbps
1.4 MHz - 4RxDiv 54 Erl 0.88 Mbps
3 MHz - 4RxDiv 140 Erl 2.3 Mbps

Multi-techno Whitepaper Figures

Extrapolated Figures
Table 8 : LTE Uplink Air Interface Capacities
Page 53/273
Restriction: Receive diversity configurations supported in LA6.0
The 4RXDiv configuration is supported in LA6.0 only for 5 MHz bandwidth. For the dimensioning
exercise only the 2RxDiv values will be used.
It is important to note the following:
 UL Capacity figures are for a mono-service traffic scenario, i.e. the VoIP
capacities are applicable assuming the carrier is supporting voice traffic only
 The UL data capacities are average aggregate air interface throughputs
 UL Capacity figures are for a regular deployment of 3 sector sites
 These UL values are illustrative examples only, and may vary in field
deployments depending upon specific deployment conditions (e.g., variations
in radio channel conditions, overlay and antenna constraints, per-user
performance requirements, etc).
For VoIP services over an LTE system, the grade of service on the air interface is not
defined by blocking requirements as was the case for GSM, WCDMA and CDMA
systems. 3GPP evaluation and NGMN simulations used the following requirement to
derive the VoIP capacity:
 A VoIP user is in outage (not satisfied) if 98% radio interface tail latency of this
user is greater than 50 ms. This assumes an end-to-end delay below 200 ms
for mobile-to-mobile communications.
 The system capacity is defined as the number of users in the cell when more
than 98% of the users are satisfied.
3.1.2.2 DOWNLINK AIR INTERFACE CAPACITY
Table 9 summarizes the downlink air interface capacities for 1 LTE carrier for 1 sector
for air interface bandwidths supported in LA6.0: 1.4MHz, 3MHz, 5MHz, 10MHz and
20MHz. Capacities are provided for SIMO-1x2, MIMO-2x2 and MIMO-4x2
configurations.
Page 54/273
VoIP Data
Configuration
CVoIP _DL CData _ DL
1,4 MHz - SIMO 1x2 60,3 Erl 1.3 Mbps
3 MHz - SIMO 1x2 142 Erl 3.1 Mbps
1.4 MHz - MIMO 2x2 61,5 Erl 1.42 Mbps

3 MHz - MIMO 2x2 153 Erl 3.6 Mbps
5MHz - MIMO 2x2 229 Erl 6.0 Mbps
1,4 MHz - MIMO 4x2 62 Erl 1.56 Mbps
Multi-techno Whitepaper Figures

Extrapolated Figures
Table 9 : LTE Downlink Air Interface Capacities
Restriction: MIMO schemes supported in LA6.0
The SIMO 1x2 and MIMO 4x2 configurations are not supported in LA6.0 (grey cells in Table 9). The
SIMO 1x1 is supported as a degraded mode. For the dimensioning exercise only the MIMO 2x2
values will be used.
It is important to note the following:
 DL Capacity figures are for a mono-service traffic scenario, i.e. the VoIP
capacities are applicable assuming the carrier is supporting voice traffic
 The DL data capacities are average aggregate air interface throughputs
 DL Capacity figures are for a regular deployment of 3 sector sites
 These DL values are illustrative examples only, and may vary in field
deployments depending upon specific deployment conditions (e.g., variations
in radio channel conditions, overlay and antenna constraints, per-user
performance requirements, etc).
3.1.2.3 SECTORIZATION GAIN
All the capacity figures quoted in 3.1.2.1 & 3.1.2.2 implicitly assume a uniform
deployment of 3 sector sites. In order to apply these figures to other site configurations
Page 55/273
the capacities must be scaled accordingly. Next table summarizes the sectorization
factors (SF) to be applied for Omni, bi-sector, tri-sector and hexa-sector site
configurations. These factors are based on system level simulations results.
No. Sectors, NSect Sectorization Factor (SF)
1 1.13
2 1
3 1
6 0.85
Table 10 : Capacity Sectorization Factor
The capacity figures from Table 8 and Table 9 must be multiplied by the sectorization
factor to get the corresponding air interface capacity for a given sector configuration:
CapacityNSect = Capacity3Sect x SFNSect
3.1.3 AIR INTERFACE CAPACITY & DIMENSIONING COMPUTATION

The following figure presents the air interface dimensioning process:
Traffic Inputs Required Traffic per Sector

Traffic
• # Subscribers / Sector computation • VoIP Erl
• Traffic Profile / Subscriber • UL & DL GBR/nonGBR Data Throughputs
LTE Performances
Find the minimum
Achievable VoIP capacity per sector required configuration
And UL & DL Throughput per sector
• For different bandwidths • Bandwidth
-1.4, 3, 5,10, 15, 20 MHz

• DL MIMO Scheme
• For different configurations
-DL SIMO, MIMO 2x2,4x2, 4x4
• UL RxDiv Scheme
- UL 2RxDiv, 4RxDiv, MU-MIMO
Figure 16 : LTE Air Interface Capacity Assessment
Page 56/273
3.1.3.1 MAIN INPUTS REQUIRED FOR AIR INTERFACE

DIMENSIONING
The main inputs required for performing an interface capacity analysis include:
 Number of Subscribers, NSubs(i)
o After performing the RF network planning analysis the number of

attached subscribers to be supported per sector should be known for
each service “i”.
The number of attached subscribers may be also determined from the

Cell surface information and the subscriber density per Km² (input
provided by the customer):
NSubs = Cell_Surface * Subs_Density
 Traffic Profile per subscriber

VoIP services
o VoIP Traffic Intensity, AVoIP(i), in Erl
 Traffic intensity is a typical input in the dimensioning

procedure that is computed from Call model inputs – see
 Table 11
o Nominal UL and DL VoIP services Rates, RVoIP(i)_Nom UL/DL.

Associated blocking probability BlGBR(i), to get a connection at this
rate in %.
 The nominal VoIP rates when actively transmitting during on

time taking into account of VAF (voice activity factor), in Kbps,
see
 Table 11 for definition. This services that guarantee the bit

rate could be used for VoIP like in the call model example
described in the Table 4 General and User Plane Parameters
by Call Type
GBR services
o Nominal UL and DL for GBR Data services Rates, RGBR(i)_Nom UL/DL.

Associated blocking probability BlGBR(i), to get a connection at this
rate in %.
 The nominal GBR rates when actively transmitting during on

time, in Kbps, see
 Table 11 for definition. This services that guaranteed the bit
rate could be used for VoIP services but also premium
services like video streaming in the call model example
Page 57/273
describe in the Table 4 General and User Plane Parameters

by Call Type
o GBR Traffic Intensity, AGBR(i), in Erl
 Traffic intensity is a typical input in the dimensioning

procedure that is computed from Call model inputs – see
 Table 11
NonGBR Data services

o Nominal UL and DL non-GBR Data services Rates, Rnon-GBR(i)_Nom
UL/DL
 The nominal non GBR rates when actively transmitting, in

Kbps, see
 Table 11 for definition.
o UL and DL non-GBRData Traffic Volume, Vnon-GBR(i)_UL/DL, in kBytes
o Mean UL and DL non GBR Data Rates, Mnon-GBR(i) UL/DL in Kbps
 The average rates in a BH per subs, in Kbps, see Table 12 for

definition.
o Peak to Average Ratio, PtA(i) apply for the non-GBR data traffic globally for the
aggregated non-GBR data traffic define in Table 4.
 PtA is an overflow factor that is used to estimate the

equivalent bandwidth for an ensemble of variable bit rate calls
(Equivalent bandwidth (i) = PtA(i) * Mean bit rate).
PtA factor
Equivalent
∑ Mean UE bit rate bandwidth
Figure 17 : Air Interface Equivalent Bandwidth Computation
 The Equivalent bandwidth and implicitly the PtA depend on

many factors like:
 the user mean rate used by non Mnon-GBR(i)
 peak data rate Rnon-GBR(i)_Nom UL/DL
 The acceptable packet loss PLoss in % (typical 1%)
 Also the available link rate for non-GBR defined as :

Cnon-GBR_UL/DL = CData_UL/DL - CGBR_UL/DL
Where CGBR_UL/DL is the capacity consume by all the GBR
services (data and voice), CData_UL/DL defined as Data Air
interface sector throughput define in Table 8 & Table 9 give
by from system simulation.
Page 58/273
CGBR_UL/DL is then calculated with the input defined in the

following formula.
CGBR_UL/DL=REquiv VoIP Air UL/DL + REquiv GBR Air UL/DL
The PtA computation can be performed based on different methods that are
detailed in [R08] & [R09] (these are equivalent methods providing similar results).
The PtA value may either be provided as part of a call model, or a standard value
can be used instead (A PtA value up to 1.4 is acceptable):
Engineering Recommendation: PtA Value used in Air Interface Dimensioning Exercises

(PtA_R)
Considering the available link rate provided by the Air interface (see CData_UL/DL values provided
in Table 8 and Table 9), the example traffic model description in 2.2.1.1.1, and all the
parameters defined in 3.1.3.1 and Table 11 calculated with 10 MHz cell capacity limit assuming
825 subscribers:
PtA(i) =[1-0.02*LOG(PLoss)][1-6*LOG(PLoss)*(Rnon-GBR_Nom(i)–Mnon-GBR(i) )/Cnon-GBR_UL/DL)]
< MIMO 2x2 3MHz on air:
PtA(i)_R_DL=45, PtA(i)_R_UL=1.75, DL is out of limit
PtA(i)_R_DL=45, PtA(i)_R_UL=1.33, DL is out of limit
PtA(i)_R_DL=1.4, PtA(i)_R_UL=1.16
PtA(i)_R_DL=1.16, PtA(i)_R_UL=1.1
 UL and DL VoIP and Data Air Interface Sector throughput, as defined in

3.1.2.1 & 3.1.2.2.
o CVoIP _UL/D capacity for VoIP in ERL, and the capacity for data CData_ UL/DL
Mbps,
o These inputs are dependent upon:
 Carrier Bandwidth
 MIMO/RxDiv configuration
Above mentioned Traffic profile per subscriber requires some inputs that can be
derived from the Call model presented in Chapter 2.2.1.1.
Page 59/273
Table 11 : Call Model to Air Interface Dimensioning Elements Conversion Table
3.1.3.2 AIR INTERFACE DIMENSIONING METHOD & EXAMPLE
As shown in Figure 16 the method used for Air interface dimensioning consist in
comparing the VoIP , GBR Data and nonGBR Data resources required by a specific
number of subscribers with the VoIP and data capacity offered by LTE cell (figures
provided in Table 8 & Table 9).
For the VoIP and GBR data, the capacity resources required per cell represents the
number of subscribers multiplied by the traffic load per subscriber (Erlang).
For data non GBR services, required capacity per cell is computed using a traffic
aggregation model. This model allow to derive what is the required capacity (in this
case, a throughput, Mbps) required for a given number of users, with a given traffic
mix. Different types of traffic aggregation models can be applied:
 Overbooking factor or Peak to Average factor applied to average Data traffic

throughput.
o This is the preferred model due to its simplicity
 Other models (more precise, but also requiring more complicated

computation) where some grade of service (GoS) constraints are imposed.
Page 60/273
Such GoS requirements can consist of dimensioning the system not to exceed
specific blocking rate or transmission delay:
o ErlangC if (delay, probability of delay) defined as GoS (see [C08])
o Multiservice Erlang (based on Kaufman-Roberts – see [C08]) if some

blocking requirements
Note: these models based on GoS are good approaches if more accurate
traffic modeling is required (particularly when there is a single measure of
air interface capacity). Using these methods implies a fastidious
computation (requiring specific dimensioning tools).
In this document only the first option (based on overbooking factor) will be presented.
Note: The Air Interface dimensioning method described below is well adapted to a mix
of VoIP, GBR and Best Effort data traffic (see section 2.2.1.1).
In a first step, the total number of Erlangs of VoIP services (AVoIP) and the total
number of Erlangs of GBR services (AGBR) are computed as follows:
AVoIP   N Subs( i )
i Voice Services
 AVoIP (i )  , AGBR   N Subs( i )
i GBR Services
 AGBR (i ) 
In a second step, the equivalent guaranteed throughput (Kbps) for VoIP services
(REquiv_Voip_Air_UL/DL), the equivalent guaranteed throughput (Kbps) for GBR data
services (REquiv_GBR_Air_UL/DL), and the equivalent “peak” non-GBR data throughput
(Kbps) for data services (RNonGBR_Equiv_Peak_Air_UL/DL) are computed as follows:
R  ERL ( Avoip @ Min ( BlVoIP ( i ) ))  RVoIP ( i ) _ UL / DL

Equiv _ VoIP _ Air _ UL / DL
R
Equiv _ GBR _ Air _ UL / DL
  N Subs( i )
i GBR Data Services
 ERL ( AGBR ( i ) @ Bl GBR ( i ) )  RGBR ( i ) _ UL / DL 
R
NonGBR _ Equiv _ Peak _ Air _ UL / DL
 PtA _ R N Subs( i )
i  nonGBR Data Services
 M nonGBR( i ) _ UL / DL
Based on the VoIP, GBR/non-GBR data traffic to support, and the multi-service VoIP,
GBR/non-GBR Data capacity figures for a given bandwidth and MIMO/RxDiv
configuration, CVoIP_UL/DL, CData_UL/DL (provided in Table 8 & Table 9), the next step
is to determine whether the VoIP, GBR/non-GBR Data capacity can be supported and
which bandwidth and MIMO/RxDiv configuration is required.
A simple linear rule can be used to derive the system capacity in mixed VoIP, GBR
/non-GBR Data traffic conditions.
The air interface load is computed on the UL and DL independently for VoIP and Data
traffic: LVoIP_UL/DL and LData_UL/DL.
Page 61/273
LVoIP_UL/DL (%) = AVoIP / CVoIP_UL/DL

LData_UL/DL (%) = (RnonGBR_Equiv_Peak_Air_UL/DL+ REquiv_GBR_Air_UL/DL)/ (1000 x CData_UL/DL )
For a given bandwidth and MIMO/RxDiv configuration we compute the total UL and
DL air interface loadings, LUL and LDL:
LUL/DL (%) = LVoIP_UL/DL + LData_UL/DL
The capacity check is performed to ensure the air interface capacity is not exceeded:
Max(LUL, LDL) ≤ 90%

If the capacity is exceeded then:
 Consider to increase bandwidth (if possible)
 Otherwise, if Minimum bandwidth required is higher than the maximum

bandwidth allocated to the operator, then increase the number of sites
(capacity limitation)
 Another solution would be to choose an enhanced MIMO/RxDiv configuration

– option available with restriction in LA6.0. - see 3.1.2.1 & 3.1.2.2.
Note: Based on the above mentioned algorithm, a recursive computation may be

foreseen in order to obtain the maximum number of Users supported on the Air
interface. For a given LTE Bandwidth and a given traffic profile we can increase the
number of users per cell until the limit of 90% load is reached (Max(LUL, LDL) = 90%).
We use 90% until 100% of the bandwidth in order to leave resources for high priority
call like: Emergency Call and Handovers. The LTE bandwidth used will be no more
an unknown in the equation, but an input (the recursive computation being run for a
given LTE bandwidth).
This kind of exercise (for the Max Number of users per cell computation) is not a
specific dimensioning item, thus it will not be detailed in this document.
3.1.3.2.1 NUMERICAL EXAMPLE
The following example will be based on the example call model as presented in
Chapter 2.2.1.1, including the CSFB traffic, without VoIP traffic
Example (CSFB circuit switch fall back)
Assuming the cell/Modem has to support Nsubs = 825 subscribers at BH with the
following call model characteristics:
 VoIP (this is just an VoIP profile for signaling in CSFB mode example):
o BHCA = 0.9 ( Voice call over CSFB per BH )
o Call Duration = 1,68 s

 SMS (this is just an SMS profile for signaling in CSFB mode example):
o BHCA = 2.9 ( SMS call over CSFB per BH )
o Call Duration = 1.68 s
Page 62/273
o kBytes per SMS – DL = 0.37

o kBytes per SMS – UL = 0.18
 Aggregate non GBR Data(info from example call model Chapter 2.2.1.1 Table
4:
o Non-GBR Data BHCA = 16.10 ( non GBR-data calls per BH)
o Call Duration = 15.2 s

o kBytes per call – DL = 102
o kBytes per call – UL = 33
 GBR Data (Info from Alcatel-Lucent standard call model)
o GBR BHCA = 0,17 (GBR data calls per BH)
o Call Duration = 539,5s
o Duty cycle (on-time/call duration)=98.1%
o kBytes per call – DL = 14506
o kBytes per call – UL = 1668
Which means (according to
Table 11) that:
AVoIP = 0.9 * 1.68 /3.6 = 0.42 mErl/subs
VnonGBRData_DL = 16.10 * 102 + 2.9 * 0.37= 1643.3 kBytes
VnonGBRData_UL = 16.10 * 33 + 2.9 * 0.18 = 531.8 kBytes
A GBR(i) = 0,17 * 539.5 / 3,6 = 25.9mErl
RGBR(i) DL= 8* 14506 / (539.5 * 98.1%) = 219.2 Kbps
RGBR(i) UL= 8 * 1668 / (539;5 * 98.1%) = 25.2 Kbps
Bl GBR(i) = 2%
The total number of VoIP Erlang is computed for the entire cell:
Total AVoIP = 825 * 0.42 / 1000 = 0.345 Erl
REquiv_VoIP_Air_DL/UL= Inv_ErlangB( 0.345@2%) * 0 = 3 * 0 = 0 Kbps
Note that Inv_ErlangB( 0.2@2%) = 3 simultaneous VoIP connections on the

cell for signaling CSFB call to MME to initiate 3GPP call with signaling on
SGS.
The equivalent guaranted rates for GBR data are then computed for the entire cell:
Total AGBR = 825 * 25.9 / 1000 = 21.403 Erlang
Page 63/273
REquiv_GBR_Air_DL= Inv_ErlangB( 21.4@2%) *219.2 = 30 * 219.2 = 6575 Kbps

REquiv_GBR_Air_UL= Inv_ErlangB( 21.4@2%) *25.2 = 30 * 25.2 = 756 Kbps
Note that Inv_ErlangB(21.4@2%) = 30 GBR connections on the cell.
The equivalent peak rates for non-GBR data are then computed for the entire cell:
o PtA_R_Dl= 45 for a 5MHz bandwidth considering CGBR_DL

=110%CData_DL (110% = (6575)/6000).
o PtA_R_Ul= 1.33 for a 5MHz bandwidth considering CGBR_UL
=25%CData_UL (25% = (756)/2970),
5MHz -> Rnon-GBR_Equiv_Peak_Air_DL = 825* 45 * 1643.3 * 8 /3600 = 135.480 Mbps

5MHz -> Rnon-GBR_Equiv_Peak_Air_UL = 825 * 1.33 * 531.8 * 8 /3600 = 1297 Kbps
o PtA_R_Dl= 1.4 for a 10MHz bandwidth considering CGBR_DL

=55%CData_DL (55% = (6575)/12000).
o PtA_R_Ul= 1.16 for a 10MHz bandwidth considering CGBR_UL

=12,6%CData_UL (12,6% = (756)/6020),
10MHz ->Rnon-GBR_Equiv_Peak_Air_DL = 825 * 1.4 * 1643.3 *8 /3600 = 4218 Kbps

10MHz ->Rnon-GBR_Equiv_Peak_Air_UL = 825 * 1.16 * 531.8 *8 /3600 = 1131 Kbps
The Air interface load per bandwidth for MIMO2x2 and 2RXDiv will be:
5MHz ->LVoIP_DL + LData_DL = 0.35 / 229 + (6.525+135.48) / (6Mbps) = 2368%
5MHz ->LVoIP_UL + LData_UL = 0.35 / 162 + (0.756+1.297) / (2.97Mbps) = 69%
Dimensioning condition: Max(2368%, 69%) = 2368% >> 90%

 Dimensioning NOK for DL 5 MHz Bandwidth due to GBR video
10MHz->LVoIP_DL + LData_DL = 0.35 / 452 + (6.525+4.218 / (12 Mbps) = 90%

10MHz-> LVoIP_UL + LData_UL = 0.35 / 324 + (0.756+1.1131) / (6.02 Mbps) = 32%
Dimensioning condition: Max(90%, 32%) = 90%
 Dimensioning OK for 10 MHz Bandwidth
3.1.3.3 DOWNLINK OUTPUT POWER
Once the carrier bandwidth is found, it is important to size the downlink power
amplifier to ensure sufficient DL power resources to match the targeted imposed by
the uplink coverage.
Page 64/273
The required Power Amplifier (PA) sizing recommendation is based on a series of

system simulation studies. The simulated scenarios were performed on the cases
presented in bold in the following list, composed by the LTE frequencies supported in
LA6.0:
 700 MHz (5 MHz, 10 MHz)
 800MHz (5 MHz, 10 MHz)
 1.8 GHz (5 MHz, 10MHz, 20MHz)

 1.9 GHz (3MHz, 5 MHz)
 AWS 1.7 GHz / 2.1 GHz (1.4MHz ROCM, 3 MHz, 5 MHz, 10MHz, 20MHz)
 2.6 GHz (10MHz, 20 MHz)
All scenarios considered 2x2 MIMO on the DL and 2RxDiv on the UL.
Restriction: Receive diversity configurations supported in LA6.0
The 4RXDiv configuration is supported in LA6.0 only for :
 1.9 GHz frequencies support a 4RxDiv on UL with 5 MHz Carrier BW per

eCEM or bCEM.
 1.7 and 2.1 GHz frequencies support a 4RxDiv on UL with 5 MHz Carrier
BW per bCEM
In principle, all the studies concluded that spectrum efficiency for “reasonable” cell
sizes is relatively invariant to the choice of PA sizes and that edge rates become much
more sensitive to the choice of power at large cell radiuses. For details please refer to
[C09].
Table 12 summarizes the recommended PA sizing based on the observations from

the above mentioned study (the grey lines in the table corresponds to LTE bandwidths
not supported in LA6.0).
These PA sizing recommendations are independent of the frequency band.
Carrier Bandwidths PA Power

1.4 MHz 2 x 10 W
3 MHz 2 x 10 W
5 MHz 2 x 20 W
10 MHz 2 x 30 W
15 MHz 2 x 40 W
20 MHz 2 x 40 W
Table 12 : Recommended Power Amplifier Sizing
Page 65/273
3.1.3.4 OTHER AIR INTERFACE CAPACITY CONSIDERATIONS
Some specific dimensioning exercises may require reaching the peak throughput (per
sector or per site or per user).
In this case the required throughput shall be checked against the peak throughput
supported per cell/sector (with the minimum bandwidth and MIMO configuration used).
The Table 13 presents the theoretical L2 peak cumulative for all users’s data
throughputs that may be reached per cell/sector for the supported LA6.0 bandwidth
and MIMO scheme configurations.
The hypothesis of PUCCH occupation is 2RB, 4RB, 4RB, 6RB and 8RB respectively
for 1.4MHz, 3 MHz, 5 MHz, 10 MHz and 20 MHz channel bandwidth.
1.4 MHz 3 MHz 5 MHz 10 MHz 20 MHz

Cell DL configuration Frame DL peak rates (Kbps)
MIMO 2x2, 64 QAM (MCS27) CFI3 4 894 16 769 28 765 60 174 123 215
Cell UL configuration Frame UL peak rates (Kbps)
2RxDiv, 16 QAM (MCS22) 1 678 4 360 8 926 18 202 41 920
Table 13 : Peak Throughput per Cell/Sector
Example: an L2 peak throughput of 45Mbps on DL direction cannot be reached with a

5MHz bandwidth (10MHz bandwidth is needed)
3.2 ENB CAPACITY & DIMENSIONING

3.2.1 OVERVIEW
In LA6.0, the following Controller and Modem boards are supported within the 9926
eNodeB digital module (also called Baseband Unit) for full compliancy with 3GPP
standards:
 Controller board eCCM-U, Providing:
o Backhaul Interface
o Call Processing
o Data switching & routing
o OA&M (alarms, restore)
o Frequency and Timing
 Modem board eCEM-U, Providing:
o Base-band signal processing
o Capacity of 1 cell per eCEM
o Supports data, control, and timing interfaces to the BTS

Page 66/273
 Modem board bCEM-U, Providing:
o Base-band signal processing
o Capacity of up to 3 cells per bCEM
o Supports data, control, and timing interfaces to the BTS
•Digital Module
•Digital
9926 Remote Radio

•Radio
ControllerModule
modem
•CEM RRH
•RRH
•Remote Radio Head
•Core Controller
modem
•CEM
Cabinet based
modem
•CEM •TRDU
TRDU
•Transmit/Receive/Duplexer Unit
•Backhaul
Figure 18 : Alcatel-Lucent 9926 eNB Architecture
As it can be seen in the Figure 18, the baseband unit of the LTE eNB is equipped with:
 1 Controller board providing interface to the backhaul (through GigE

interface) and to the radio modules (CPRI links). It also handle most of the
Control Plane eNB activity
 Up to 3 Modem boards ensuring the User Plane processing
Rule: Number of LTE cells vs. number of modem boards in LA6.0
In LA6.0, two configurations exist:
 eCEM Configuration: Each LTE cell of an ENB is handled on a unique Modem (3 modems are
required for a 3 Cell eNB), with up to 3 eCEM modems per BBU.
 bCEM Configuration: 3 cells of the ENB can be handled on a unique Modem (1 modem is
required for a 3 Cell eNB), with up to 2 bCEM modems per BBU.
The Dimensioning of the Alcatel Lucent eNB will be mainly based on the dimensioning
of the 9926 digital module and the dimensioning of eNB backhaul interfaces (S1 &
X2). The interface dimensioning is addressed in Chapter 3.5. This chapter will focus
on the baseband unit dimensioning.
The 9926 baseband unit has two possible configurations in LA6.0 (1 controller per
eNB + 1 eCEM per cell / 1 controller per eNB + 1 bCEM for up to 3 cells), the
dimensioning of this digital module in terms of number of board will be driven by the
number of cells the eNB need to handle (see Table 14). The Number of LTE cells to
be supported on a given eNB is an input coming from Radio Planning/Design.
Page 67/273
LTE Cells to be
# of Controller # eCEM of Modem boards # of bCEM Modem boards
supported per
boards / eNB / eNB / eNB
eNB
1 1 1 1
2 1 2 1
3 1 3 1
4 1 - 2
5 1 - 2
6 1 - 2
Table 14 : Number of Digital Boards per 9926 BBU

Once the eNB configuration in terms of number of digital boards is chosen, additional
capacity analysis need to be performed in order to check that eNB digital boards are
capable to handle the target number of users and data bearers (for a given call model)
while ensuring the required performance/throughput targets.
These capacity limitations (Number of Users, Data Bearers and Throughput) are
directly related to the traffic that the Controller and Modem are supporting:
 Nb. of Users / Connections

o maximum number of Active users
o maximum number of Connected users
 Nb of Bearers
o Maximum number of data bearers (VoIP + GBR + Non-GBR)
 Throughput
o UL/DL peak L1 throughput

In LA6.0, modem and controller throughput capacity are significantly higher than the
maximum throughput of the air interface (see tables 15 & 16). Thus throughput will
not be the subject of dimensioning exercise.
In this document we will focus on the number of active users & connected users that
the controller and the modem can support (and associated capacity & dimensioning
rules). The Number of Bearers limit will also be addressed, as a derived limit coming
from the number of users.
3.2.2 LTE ENB CONFIGURATIONS & CAPACITIES

3.2.2.1 ALCATEL-LUCENT CALL STATE DEFINITIONS
In order to address, in a dimensioning exercise the number of Active and Connected

users and understand the LA6.0 specific hypotheses, it is necessary to explain the
definition of Active and Connected Users. The following figure illustrates the Alcatel-
Lucent LTE call state definitions:
Page 68/273
Detached User
Attach to EPS Detach from EPS
Idle user
Establish RRC RRC Connection

Connection Released
Dormant user
Activate the RF Deactivate the RF

monitoring monitoring
Data-Free user
Data Arrival No Data
Enter scheduler queue

Sideline user Scheduler
eligible user
Exit scheduler queue
Competing user
Active user
Connected User
Attached User
LTE Subscriber
Figure 19 : LTE Call State Definitions
Note that above figure presents all the different states possible for an LTE User.
From capacity perspective we will only deal with Active and Connected users.
Connected User:
A Connected user is a LTE attached UE that has established a RRC connection with
the eUTRAN. The UE that are “Connected Users” maintains following properties:
 The UE has established SRB1 with the eUTRAN. SRB1 is for RRC messages,
as well as NAS messages prior to establishment of SRB2.
 Except for the transition during the RRC connection setup, the UE has
activated AS security and established SRB2 with eUTRAN.
 The UE has established at least one default data radio bearer with the
eNodeB. The UE may also establish multiple data radio bearers with the
eNodeB.
 The UE maintains NAS a signaling connection with MME, and an EPS bearer
connection with the serving gateway and PDN gateway. The UE may also
establish multiple EPS bearers with the gateways.
 The eUTRAN tracks the UE within the serving eNodeB. Intra-eNodeB and
Inter-eNodeB procedures can be performed for mobility management (i.e.
handoff).
Note that a Connected User may be either in “Dormant User” state or Active user state.
Page 69/273
Restriction: Dormant user State support in LA6.0
In LA6, dormant user state is not supported (due to the availability of DRX mode which is a feature
planned for a later release). Without dormant state being supported, the number of active users is the
same as the connected users.
Active User:
An active user is a RRC connected UE that maintains an active RF connection with

the eNodeB. The UE of a RF active user maintains following properties:
 The UE monitors the PDCCH and is able to decode the DCIs addressed to
itself.
 If configured periodic UCI, the UE is able to transmit on PUCCH.
 The eNodeB can send the DL data to the UE over PDSCH, if any.
 The eNodeB maintains time synchronization with the UE, and is able to send
Time Adjustment to UE to correct the UE transmission timing.
The UE can send Schedule Request to eNodeB for any pending UL data
transmission.
Rule: Number of Connected Users vs. Active Users
In LA 6.0, due to above mentioned limitation, the Number of Connected Users will be equal to the
number of Active Users (each Connected User is seen as an Active User by the system)
Thus, from now on we will use only the notion of User connection to define the resources needed for
1 user in Connected or Active state.
3.2.2.2 ENB DIMENSIONING ELEMENTS
As mentioned in chapter 3.2.1 three main elements need to be analyzed and

dimensioned for the 9926 eNB:
 Nb of User Connections
 Nb of Data bearers (VoIP + GBR + Non-GBR)
 Peak L1 Throughput
The LA6.0 maximum values of each of these three limits are presented in the following
tables:
Page 70/273
LA6.0 capacity figures (LA6.0 FDD eCEM) 1.4 3 MHz 5 MHz 10 MHz 20 MHz
Total Users 48 100 167 200 54

Modem/cell
Number of VoIP Users - - 100 100 40
Users
Connections Total Users 144 300 501 600 162
Controller/eNB
VoIP Users - - 300 300 120
Total Bearers 156 325 542 650 176
Modem/cell Default
Number of (1bearer
48 100 167 200 54
Bearers default for
service data )
Total Bearers 468 975 1625 1950 528
Controller/eNB
Default 144 300 501 600 162
Modem/cell 150 Mbps DL & 45 Mbps UL

Peak L1
Throughput
Controller/eNB 350 Mbps DL & 100 Mbps UL
Table 15 : LA6.0 eNB Max Capacity Figures Targeted in LA6.0 - eCEM
Page 71/273
LA6.0 capacity figures (LA6.0 FDD bCEM) 5 MHz 10 MHz 20 MHz
54 (in CL1)
Total Users 167 250
/cell 167 (in CL2)
Number of VoIP Users 100 100 100
Users
Connections Total Users 501 750 501
Controller/eNB
VoIP Users 300 300 300
Total Bearers 650 813 543
/cell Default
Number of (1bearer
167 250 54/167
Bearers default for
service data )
1950 2439 1629
Controller/eNB Total Bearers
Default 501 750 501
Modem 315 Mbps DL & 156 Mbps UL

Peak L1
Throughput
Controller/eNB 350 Mbps DL & 100 Mbps UL
Table 16: LA6.0 eNB Max capacity Figures Targeted in LA6.0 - bCEM
3.2.2.3 ENB CAPACITY CONFIGURATIONS
As seen in previous chapter (3.2.2.2), in LA6.0, different capacity configurations are

supported for the 9926 eNB.
eNB capacity is also impacted by specific features and parameter settings, some of
which are:
 UL/DL Bandwidth configured through parameters dlBandwidth and

ulBandwidth. Different capacity figures are available depending on the LTE
bandwidth used
 The usage of 700 MHz Upper C band (US specific) controlled through
ul700MHzUpperCBlockEnabled activation flag.
 UL MIMO activation controlled through parameter ulMIMOenabled

parameter.
Page 72/273
Restriction: UL MIMO
The following restrictions apply to UL MIMO in LA6.0:
 UL MIMO is only supported in 5MHz, 10MHz and 20MHz system BWs.
 UL MIMO is not supported in 700MHz Upper Block C
 UL MIMO is only supported for demo purposes with a capacity of 2 UEs per cell.
Engineering Recommendation: Parameter ul700MHZUpperCBlockEnabled
The setting of this parameter depends on whether the customer operates their network in the
700 MHz Upper Block C or not. It is only significant when the system operates in a 10 MHz
bandwidth (i.e. ulBandwidth si set to “n50-10MHZ”), otherwise the flag is ignored by the
system.
3.2.2.4 NEW ENB CONFIGURATIONS IN LA6.0
3.2.2.4.1 DUAL-CARRIER ENB ON ONE BAND, WITH TWO MODEMS
- The objective is to support two carriers (up to 3 cells each) in a single eNB; in
LA6.0, each carrier is supported on one bCEM modem; therefore two bCEM
modems are required in the BBU for this configuration.
- FDD configuration: 5 MHz + 5MHz - 1900 MHz
- The capacity objectives of this configuration are the following:
o Modem capacity: bCEM capacity in LA6.0
o Controller capacity: eCCM-U capacity in LA6.0
o FDD radio configuration is: 2x2 MIMO, 4Rx, 5MHz
3.2.2.4.2 DUAL-BAND ENB WITH TWO MODEMS
- The two modems will support up to 6 cells (up to 3 cells per modem). All cells on
the same modem need to be on the same band, carrier and have the same
bandwidth.
- Dual-band configurations shall support the AntennaCrossConnect (ACC) feature,

insofar as the two bands are cabled identically, i.e. have the same number of
sectors and the same cross-connect scheme. Dual-band with non-identical cabling
scheme will be introduced by a separate feature in a later release (e.g. one band
cross-connected, the other without cross-connect).
- The following dual-band configurations are supported:
o Lower 700 MHz (band 12/17) / AWS

o 1600 MHz / 1900 MHz, in this configuration, up-to two carriers may be
used in PCS band
o 800 MHz / 2.6 GHz

Page 73/273
- The carrier bandwidths supported in a Dual 700MHz - AWS eNB configuration are:
o 5MHz in band 12/17, 5MHz in band 4
- The carrier bandwidths supported in a Dual 1900/1600 MHz eNB configuration

are:
o 5MHz (single or dual carrier) in band 1900, 5MHz (single or dual carrier) in
band 1600
- The carrier bandwidths supported in a Dual 800MHz - 2.6GHz eNB configuration

are:
o 10MHz in 800MHz band 12/17, 20MHz in 2.6GHz band
o 5MHz in 800MHz band 12/17, 20MHz in 2.6GHz band
- The capacity of a dual-band BBU configuration is as follows: total number of users

(active and RRC) is the sum of the respective max number of users for each
single-band configuration. Peak throughput at BBU level is the sum of the peaks in
each band.
3.2.3 ENB USER PLANE CAPACITY & DIMENSIONING

COMPUTATION
3.2.3.1 MAIN INPUTS REQUIRED FOR ENB DIMENSIONING
The main inputs required for performing eNB capacity & dimension exercise include:
 Number of Subscribers, Nsubs. After performing the Radio Design/Coverage of

the network area, the number of attached subscribers to be supported per
cell/sector and eNB should be known.
 Traffic Profile per Subscriber
o VoIP Traffic Intensity, AVoIP, in mErl. Traffic intensity is a typical input

in the dimension procedure that is computed from Call model inputs –
see in Table 21
Note that a data traffic intensity (AData(i)) can also be estimated for
some specific resources (resources not impacted by the data traffic
burstiness) – see details in 3.2.3.2
o Voice activity factor, αVoIP: ratio, over one call duration, of "speaking"
periods over silence periods (60% is the typical value used for voice
calls)
o UL and DL Data Traffic Volume, VData(i)_UL/DL, in kBytes

o Blocking Requirements, Bl(i) – depending on operators QoS policy.
Note: In general, the Bl considered for data services is different/higher
than the Bl considered for VoIP (see example in section 3.2.3.3.1)
Page 74/273
o Nominal UL and DL Data Rates, RData(i)_Nom UL/DL for the i data

services described in the call model. These are the nominal rates
when actively transmitting, in Kbps
Above mentioned Traffic Profile elements can be recovered from the Call
model presented in Chapter 2.2.1.1 as follows:
Call Model Parameter

BHCA
% Orig. / Term. Calls
Call duration
Duty cycle (on-time/call duration)
kBytes per call – DL
kBytes per call – UL
Table 17 : Main Call Model Elements for eNB Dimensioning
Page 75/273
Dimensioning input element Conversion rule

Nsubs Operator input
Rdata(i)_Nom UL/DL in Kbps 8 * kBytes per call/ (Call duration * Duty cycle/100)
Operator input (QoS policy)
Bl(i), in %
Define for each services BlVOIP, BlGBR, BlnonGBR
Avoip (per subs) BHCA VoIP * Call duration /3600
AGBR (per subs) BHCA GBR * Call duration /3600
AnonGBR (per subs) BHCA nonGBR * Call duration / 3600 + ASMS-CSFB
ASMS-CSFB (per subs) BHCA SMS CSFB * Call duration / 3600
Table 18 : Call Model to eNB Dimensioning Elements Conversion Ttable
Note: Some of the above inputs are subsets of those used for the air interface
dimensioning in1.3‎.
In the next sub-chapters only a part of these dimensioning inputs will be used (the rest
being presented for future use).
3.2.3.2 ENB DIMENSIONING PRINCIPLE
The eNB (Modem & Controller) dimensioning principle is summarized in the following
figure:
Traffic profile Inputs

• # Subscribers per modem & eNB Modem configuration verification
• Traffic Profile per Subscriber • Nb. of User connections required

Controller/ vs. Max Nb. of User connections
available
Modem Capability
Modem
Dimensioning • Nb of Bearers required vs. Max
• Max Nb. of User connections Nb. of Bearers available
available exercise
• Max Nb. of Date Bearers • Peak throughput required vs.
available Peak throughput available
• Peak throughput available
Figure 20 : eNB Dimensioning principle
As the eNB configuration in terms of number of modems is fixed (1 modem per LTE
cell and 1 Controller per eNB), the eNB dimensioning exercise purpose is just to verify
that for the given number of users per Modem & Controller, the number of required
resources is not exceeding the Max number of available resources (for the Max
number of available resources please refer to 3.2.2.2 & 3.2.2.3).
Page 76/273
If the number of resources required exceeds the number of resources available, a new
modem or controller boards need to be added which automatically implies a new eNB
to be added into the network.
Each of the three dimensioning elements of the eNB will be addressed in the following
subchapters.
3.2.3.3 NUMBER OF USER CONNECTIONS
Number of User connections is a resource considered in the eNB Call Admission

Control Algorithm (CAC): no additional user connection can be accepted in the
cell/eNB if the maximum number of User connections is reached (blocking resource).
The usage of this resource is Call Model dependant.
Performing a dimensioning exercise on this resource, means to find the number of

user connections required in order to accept a specific multi-service traffic (Aservice(i))
coming from a specific number of subscribers (Nsubs) without exceeding a target
blocking rate for each service (Bl(i)).
In order to address the dimensioning of a multi-service resource, the most suitable

model is an Erlang Multi-service law:
• # Subscribers (at Busy Hour)

Erla ng
• Aservice(1) , Aservice(2), … Aservice(n) Multi- Service Nb. of resources
required
• Bk(1)%, Bk(2)%, … Bk(n)% La w
Figure 21 : Dimensioning of a Multi Service Resource Principle
The computation of number of required resources following this method implies a

fastidious method based on the recursive algorithm defined by Kaufman-Roberts - see
details in [C08].
Fortunately, all the different types of services are using the same resource unit (1 User
connection) which allows simplifying the dimensioning computation by reducing it to a
simple Erlang law formula (as used in the mono-service circuit switch networks):
• # Subscribers (at Busy Hour)

• ATotal = ΣAservice(i) Erla ng La w Nb. of resources
required
• Bk% = Min[Bk(1)%, … Bk(n)%]
Figure 22 : Dimensioning of Number of User Connections
Page 77/273
In the specific case of LA6.0 eNB, the traffic intensity for VoIP, GBR and nonGBR
Data services (for a number of attached subscribers per cell/Modem = Nsubs) can be
computed based on the traffic model inputs:
 AVoIP_Total = Nsubs * AVoIP
 AGBR_Total = Nsubs * AGBR
 Anon-GBR _Total = Nsubs * Anon-GBR
Where,
 AVoIP = VoIP BHCA * VoIP call_Duration / 3600 ;
 AGBR = GBR BHCA * GBR call_Duration / 3600 ;
 Anon-GBR = non-GBR BHCA * non-GBR Call_Duration / 3600 + ASMS-CSFB
Note: as long the Connected user is using the User Connection resource during the
entire call duration (independent of traffic activity or On Time periods), the GBR or
non-GBR Data traffic intensity per subscriber will be computed based on entire
connection duration and will be called: AGBR and Anon-GBR.
With the above mentioned hypotheses, the number of User Connections resources
required per Modem board will be:
Nb_User_Conn._req_Modem = Inv_Erl (AVoIP_Total + Anon-GBR_Total + AGBR_Total ; Blocking rate Bl)
Where the blocking rate is Bl = Min [Bl(i)]
Rule: Number of User connections dimensioning rule
if Nb_User_Conn._req_Modem > Max_Nb_User_Conn._Modem

Then add new Modem capacity resources (implicitly a new cell or new eNB to be added in the
network)
Where Max_Nb_User_Conn._Modem for different LA6.0 capacity configurations is defined in
Table 15 and Table 16.
For the number of User connections per Controller board (or eNB), the Modem result
multiplied by the Number of Modems per eNB shall be inferior or equal to the Max number of
User connections per eNB/Controller board (as per Table 15 and Table 16)
#Modems * Nb_User_Conn._req_Modem ≤ Max_Nb_User_Conn._Controller (eNB)
Note that the controller dimensioning condition will be always fulfilled if the modem
condition is fulfilled (the Max Number of User connections per controller is
specified as being 3 * Max Number of User connections per cell/modem)
Page 78/273
3.2.3.3.1 NUMERICAL EXAMPLE
As it was seen in 3.2.2.3, different capacity configurations are available for the
Number of User Connections. The following example is based on 10MHz capacity
figures where the capacity of an eCEM based eNB is limited by (max 200 Users per
eCEM and 600 per eNB with max 100 VoIP Users per eCEM and 300 per eNB).
This example is developed for example call model as presented in Chapter 2.2.1.1,
including the CSFB traffic, without VoIP traffic.
Example (CSFB)
Assuming the cell/Modem has to support 825 attached users (Subscribers in idle +
active mode) at BH with the following call model characteristics:
 Voice:
 BHCA = 0.9 Voice CSFB call per BH)
 Call Duration = 1 s used just for signaling CSFB
 Data (info from Alcatel-Lucent standard Call model):
 nonGBR BHCA = 16.1 ( NonGBR data aggregate traffic /BH/Subs)
 nonGBR Call Duration = 15.2 s
 SMS BHCA = 2.9 (SMS CSFB /BH/Subs)
 SMS Call Duration = 1.68 s
 GBR BHCA = 0.17 ( GBR video streaming data calls /BH/Subs)
 GBR Call Duration = 539.53 s
 Call admission blocking target:
 BlVoIP = 2% (typical voice blocking target in wireless networks)
 BlGBR = 2% (GBR assume as a premium services like voice)
 BlnonGBR=10% (typical Data BE blocking target in wireless networks)
VoIP traffic intensity: AVoIP_Total = Nsubs * AVoIP = 825 * (0.9*1)/3600 = 0.35 Erl
GBR traffic intensity: AGBR_Total = Nsubs * AData = 825 * (0.17*539.5)/3600 = 21.4 Erl
Non-GBR traffic intensity: AnonGBR_Total = Nsubs * AData = 825 *(16.1*15.2+2.9*1.68) /
3600 = 57.1 Erl
Blocking target for both services: Bl = Min[2% ; 10%] = 2%
Nb_User_Conn._req_Modem = Inv_ErlangB (0.35 Erl + 21.4 Erl + 57.1 Erl @ 2%) = 91
Nb_User_Conn._req_Modem (91) < Max_Nb_User_Conn._Modem (200)
Nb_VoIP_Conn._req_Mdm =Erl(0.35@2%) = 3 <Max_VoIP_User_Conn._Mdm(100)

In case 3 cells/Modems are configured in the eNB, the number of User connections
per controller condition will be:
3 * Nb_User_Conn._req_Modem = 3*91 < Max_Nb_User_Conn._Controller (600)
Page 79/273
=> dimensioning OK for 10MHz
3.2.3.4 NUMBER OF USER DATA BEARERS
Note: this entire chapter makes reference only to User data bearers (voice GBR
and/or nonGBR bearers included default bearer), signaling bearers being out of the
scope of User Plane dimensioning. Thus, from now on this dimensioning element will
be simply called Number of Bearers.
As for the number of Users connections, the number of bearers per modem or per
controller is a resource considered in the eNB Call Admission Control Algorithm
(CAC): no additional bearer setup request or call setup is accepted in the cell/eNB if
the maximum number of Bearer is reached (blocking resource).
The Number of bearers dimensioning process will be then similar to the Number of
user connections (see 3.2.3.2) except that a new call model elements have to be
considered:
 The average number of data traffic bearers per subscriber (NbBRSub).

This NbBRSub include all types of bearer (default and dedicated) used by
subscriber.
 The dedicated bearers distinguish 2 categories labeled GBR and non-GBR

bearers. The call model evaluates the average number of GBR and non-GBR
per subscriber. The average numbers NbGbrBRSub and NbnonGbrBRSub
depend on :
o each application usage : 1 or more bearer (VoIP, data, video calls)
o application relatives traffic intensity in the call model (BHCA*Call

Duration time) compare to the total BHCA and aggregate call Duration
time,
o the status of the subscriber himself as a premium user or not.
o NbnonGbrBRSub can be deducting from the bearer parameters:

NbBRSub, NbGbrBRSub.
 One Default bearer is assigned automatically for each active users during the
attached process NbBRDefaultSub=1. This default bearer has the minimum
QCI=9 so this is a nonGBR bearer. Some additional dedicated bearer could
also be assigned during the attach process they are called static-dedicated
bearer and are in used as long as the PDN session exist.
These Call Model elements (NbBRSub, NbGbrBRSub and NBnonGbrBRSub) need to

be worked and agreed with the operator, as it depends on the PDN allocation strategy
(and more general, data services usage strategy). Consider that 1 default bearer and
1 dedicated bearer for IMS signaling are allocated systematically in the ePC for SMS
and Presence Applications during UE power on/attach time (and will be setup on eNB
side for each UE connection ).Consider that 20% of users are premium and are
susceptible to allocate 1VPN additional dedicated bearer. Consider VoIP and
streaming video Users could have 4 even 5 bearers.
Page 80/273
This hypothesis leads to the following number of bearers per connected subscriber:
 CSFB NbBRSub=2.116 , NbGbrBRSub =0.016
With the above mentioned hypotheses, the number of Bearer resources required
per Modem board will be computed in the same way as the Number of User
connections (in 3.2.3.3):
Nb_Total_Bearers_req_Modem = NbBRSub * Nb_User_Conn._Modem
Nb_Default_Bearers_req_Modem = Nb_User_Conn._Modem
Nb_GBR1_Bearers_req_Modem = NbGbrBRVoIP * Nb_User_Conn._Modem
Where:
 Nb_User_Conn._Modem=Inv_ErlangB((AVoIP_Total + AGBR_Total + AnonGBR_Total);Bl)
 AVoIP_Total = Nsubs * AVoIP
 AGBR_Total = Nsubs * AGBR
 AnonGBR_Total = Nsubs * AnonGBR
 Bl = Min [Bl(i)]
Rule: Number of Bearers dimensioning rule
if Nb_Bearers_req_Modem > Max_bearers_Modem

or Nb_DefaultBearers_req_Modem > Max_Defaultbearers_Modem
or Nb_GBR1Bearers_req_Modem > Max_GBR1bearers_Modem
Then add new Modem capacity resources (implicitly a new cell or new eNB to be added in
the network)
Where Max_xxxxbearers_Modem for different LA6.0 capacity configurations is defined in
Table 15
Rule: Number of Bearers dimensioning rule
For the number of Bearers per Controller board (or eNB), the Modem result multiplied by the
Number of Modems per eNB shall be inferior or equal to the Max number of bearers per
eNB/Controller board (as per Table 15)
# Modems * Nb_Bearers_req_Modem ≤ Max_Bearers_Controller (eNB)
# Modems * Nb_DefaultBearers_req_Modem ≤ Max_DefaultBearers_Controller

(eNB)
# Modems * Nb_GBR1Bearers_req_Modem ≤ Max_GBR1Bearers_Controller

(eNB)
Page 81/273
Note that the controller dimensioning condition will be always fulfilled if the modem
condition is fulfilled (the Max Number of Bearers per controller is specified as being
3 * Max Number of Bearer per cell/modem)
3.2.3.5 REQUIRED THROUGHPUT
The peak throughput supported by the modem and the controller boards in LA6.0 is
presented in Table 15 .
Note that the Modem peak throughput represent the max decoding processing
capacity of the modem board, whereas the controller peak throughput represents also
the max throughput supported by the eNB toward the S1 & X2 interfaces and can be
subject of additional dimensioning exercise related to the transport interfaces
dimensioning/architecture (see details in Chapter 3.5). In this chapter only the eNB
dimensioning considerations will be addressed.
The Modem & Controller peak throughput is not a blocking resource (not considered in
the CAC) which means that new calls will not be rejected in case the peak throughput
limit is reached, but service degradation for the existing users may be observed.
Performing a dimensioning exercise on this resource, means to compute the

throughput required by a specific number of attached subscribers (Nsubs) transferring
a specific volume of date (VData(i)_UL/DL) spread over several traffic services
characterized by different traffic intensities (AVoIP, AData(i)), and compare it with the
controller & modem LA6.0 peak throughput figures (given in Table 15).
The process for computation of the UL and DL throughput required in order not to
exceed the Modem & controller specific throughput constraints consist in:
 Compute the traffic intensity (in Kbps) per subscriber for all services
 Apply traffic model to compute the total Throughput required. Two approaches
are possible:
o Using an overbooking factor or Peak to Average ratio applied to Data
o Using more complicated / precise methods if some grades of service

(GoS) constraints are imposed. Such GoS requirements can consist
in dimensioning the system not to exceed specific blocking rate or
transmission delay:
 Erlang C if (delay, probability of delay) defined as GoS
 Multi-service Erlang if some blocking constraints.
3.2.4 CONTROL PLANE CAPACITY CONSIDERATIONS

Most of the LA6.0 eNB capacity figures presented in Table 15 and Table 16 are limited
by the SW (lower capacity figures than the Modem & Controller HW can support) and
are mainly driven by User Plane processing.
The main purpose of this User plane SW limitation is to obtain the best Capacity –
Performance trade-off (allowing reaching the maximum number of users per eNB that
can get the best performance for their data services). This limitation will be removed in
Page 82/273
future release when additional features and SW optimization will allow exploiting the
maximum capacity of current eNB HW.
Engineering Recommendation: eNB Control Plane dimensioning in LA6.0
Considering the above mentioned implementation choice, and based on the first capacity test results,
we can say that the eNB Control Plane (both Modem and Controller boards) is not a limiting factor for
the eNB capacity. Thus, no engineering rule is provided for eNB Control Plane dimensioning in LA6.0.
3.2.5 ENB PAGING RATE

Paging rate at eNB depends on both pages for terminating calls received at this eNB
(for the Nsubs under the eNB coverage), and pages to UEs camped on other eNB but
whose TA includes this eNB.
The eNB Paging rate can then be calculated by the following formula:
eNB_Paging_Rate (paging events/sec) = Nsubs * Terminating_calls(/sub) *

eNB_Paging_Efficiency / 3600
Where:
 The Terminating_calls(/sub) is an element that can be directly obtained from

the traffic model parameters:
Terminating_calls(/sub) = BHCA(/sub) * % Terminating calls
 The eNB_Paging_Efficiency is the number of paging events at eNB per

terminating call received at eNB. It depends on the paging strategies, paging
area sizes and page response rates. This can be approximated as:
eNB_Paging_Efficiency = eNBs paged per MME termination
3.2.5.1 ENB PAGING RATE COMPUTATION EXAMPLE
Considering the Traffic model hypothesis in Table 3, the Terminating_calls(/sub) for

the main traffic type CSFB can be estimated as follows:
CSFB: directly extracted from Table 3:
Non CSFB ( Data) Terminating_calls = 4.27 terminating data calls /BH/sub

Voice-CSFB Terminating_calls = 0.54 terminating Voice CSFB calls /BH/sub
SMS-CSFB Terminating_calls = 2.03 terminating SMS CSFB calls /BH/sub
The eNB_Paging_Efficiency with the recommended MME paging policy can be

computed according to above mentioned hypotheses (section 3.2.5).
eNB_Paging_Efficiency = 13.3 for terminating data calls /BH/sub

Page 83/273
eNB_Paging_Efficiency = 64.2 for terminating Voice CSFB calls /BH/sub
eNB_Paging_Efficiency = 10 for terminating SMS CSFB calls /BH/sub
This means, for an Nsubs of 2202 attached subscribers on idle mode using CSFB
traffic model per eNB, an eNB paging rate of:
CSFB eNB_Paging_Rate = 2202 * (4.27*13.3 + 0.54*64.2 + 2.03*10) /3600
CSFB eNB_Paging_Rate = 2202 * (56.7 + 34.7 + 20.3) / 3600
With (56.7 + 34.7 + 20.3) = 111.7 paging events /subs/BH
CSFB eNB_Paging_Rate = 68.3 ENB paging events /sec
Remark: If MME does not use optimized and recommended paging policy for data
calls such as TA list for all 3 paging attempts (in which case ENB_Paging_Efficiency
= 67.2), then the paging rate calculation on ENB is:
NonOptimized-CSFB eNB_Paging_Rate = 2202 * (13.3+0.54+ 2.03)*67.2 /3600
NonOptimized-CSFB -eNB_Paging_Rate= 208.9 ENB paging events /sec
Conclusion: eNB paging rate in this example does not exceed the eNB paging
capacity.
LA6-LA5 Delta:
In order to support traffic growth, the LA6.0 maximum theoretical paging rate achievable by the
ENB is improved to 600 paging events / second.
Engineering Recommendation: practical eNB maximum paging rate
Due to random distribution of the IMSIs in the network, and the fact that ENB is paging them on 32
paging occasions defined by 32 different IMSI ranges; the practical maximum paging achievable is
70%-80% of the theoretical limit.
Page 84/273
3.2.6 ENB CAPACITY LICENSING FUNCTIONALITY

Capacity Licensing feature allows the operator to order some eNB HW components
with a reduced SW capacity and subsequently purchase licenses for additional
capacity.
The principle consists of converting the required capacity for some specific eNB
resources to Licensing Tokens (also called RTUs – Right To Use) that can be
associated to commercial ordering codes allowing to control the eNB capacity usage
from contractual perspective. Same Token concept is also implemented in the eNB
configuration allowing to technically applying the capacity constraints imposed by the
commercial side.
Based on the sum of all Licensing tokens required for all eNBs under a specific SAM
machine, a capacity license key (encrypted file) containing the tokens information is
generated per SAM. Once the license file is installed in the SAM (via the newly
available SW tool called WLM – Wireless Licensing Manager), the operator can
distribute capacity tokens between all controlled eNB(s) via specific Licensing
parameters (licensing parameters that are also configured in Tokens).
The SAM will permanently monitor the coherence between the number of Tokens
provided by the License file and the sum (per SAM) of the Licensing parameters
values configured on each eNB. If the Sum of Licensing parameters (for a given
resource) reaches the limit given by the License file, the SAM will block the
configuration related to these resource (no additional resources can be configured)
Following figure summarizes the Licensing configuration process:
SAM/WLM
Capacity Tokens (RTUs) License file created and

purchased by operator entered into SAM/WLM
eNB(s) capacity controlled via

specific licensing parameters
configured at SAM
eNodeB eNodeB eNodeB eNodeB
Figure 23 : eNB Capacity Licensing Principle

The following eNB capacity elements are managed in LA6.0 via this feature:
 Transmission Power (per cell)
 Number of Active users per eNB (per eNB)

Page 85/273
 Allocated Operating Bandwidth (per cell)
Engineering Recommendation: Capacity Licensing feature configuration
For complete information on Capacity Licensing configuration (parameters settings and Engineering
recommendations) please see Volume 4 of LPUG document [R01].
Restriction: eNB Capacity Licensing impact on LA6.0 eNB dimensioning
As the main commercial deployments in LA6.0 are using the entire eNB SW & HW capacity (not
limited by licensing parameters), the eNB dimensioning methods & engineering rules in this document
will not consider the licensing limitations.
Yet, Licensing Tokens computation rules will be provided for customers that want to estimate the
resources usage cost in terms of Licensing (see section next section).
3.2.6.1 LICENSING TOKENS COMPUTATION
Considering that the three main eNB dimensioning elements presented in previous
chapters (Allocated bandwidth, Transmission Power and Nb. of User Connections) are
subject of Licensing in LA6.0, it is important to understand the conversion rules from
the elementary measurement unit of each resource (5/10/20 MHz, W/dBm, Nb of
users) into licensing tokens. In this way, once the dimensioning exercise is performed,
the network planning engineer may also compute the number of associated licensing
tokens (allowing a shorter time for Licensing Tokens ordering and License file
generation)
The following table summarizes the different eNB capacity elements considered in
licensing scheme and the number of elementary units required for each Licensing
token:
Licensed resource Capacity licensing token

Resource Unit
step unit
RRH/TRDU
Transmission
allocated power in 10W/PA (**) 1 token
Power
W per PA (*)
Number of
Connected users
connected 8 (users) 1 token
per eNB
users
Allocated Radio Bandwidth 1 token (per type of

N.A.
bandwidth per cell (MHz) bandwidth)
Table 19 : eNB Resources and Associated Token Units

(*) One RRH2x or TRDU2x is considered to contain 2 PA(s)
Page 86/273
(**) 20W (2 Tokens) are provided by default in LA6.0 (10 W per PA). They can be
used as 2x10W for a MIMO 2x 2 configurations. 1 Token (10 W cannot be split
between two PAs)
3.2.6.1.1 TRANSMISSION POWER TOKENS
The transmission power is dimensioned in W which makes easier the Token

conversion:
10 W = 1 Power_Token (on a PA basis)
In case of MIMO (2 PAs/Sector) => 2 x 10 W = 2 Power_Token
As this resource is dimensioned/configured per cell, the total number of Power-Tokens

required for a given eNB is computed as the sum of tokens required for each cell:
Power_Token_eNB = ∑ Power_Token_Cell
Example: if 2 x 30 W are required for each cell of a 3 sector eNB, the

Power_Token_eNB will be:
Power_Token_eNB = 2 x 3 + 2 x 3 + 2 x 3 = 18 Power_Token
Note: A particular attention has to be provided to the Transmission power

configuration parameter (cellDlTotalPower) that is configured in dBm, thus it needs
an additional conversion to W in order to correctly associate it to the Power_Token.
For details on the Transmission Power Licensing configuration please refer to Volume
4 of LPUG document [R01].
3.2.6.1.2 NUMBER OF ACTIVE USERS TOKENS
The Number of Active Users (also called the Number of User connections in the
section 3.2.3.3) is dimensioned as an integer directly providing the number of
simultaneous connections allowed in en eNB. According the Table 19, the Token
conversion rule for Number of active users will be:
8 Active Users = 1 Active_Users_Token
In other words, in order to compute the number of required Active_Users_Token for

a given eNB, the following formula has to be used:
Active_Users_Token eNB = Roundup[#Modems * Nb_User_Conn._req_Modem / 8]
For the definition of Nb_User_Conn._req_Modem please refer to section 3.2.3.3.
Example: For an eNB requiring 48 simultaneous connections, the

Active_Users_Token eNB will be:
Page 87/273
Active_Users_Token eNB = 48 / 8 = 6 Active_Users_Token
3.2.6.1.3 ALLOCATED BANDWIDTH TOKENS
The Bandwidth tokens are a little nit special comparing to the other two types of tokes
because that can take only one value for a give cell and for a given LTE bandwidth
value: 0 or 1 (false or true)
The bandwidth tokes for a given LTE band will be then computed according to the
following algorithm:
If Bandwidth xx MHz is used in CellY then

Bandwidth_Token_xxMHz_CellY = 1
Else
Bandwidth_Token_xxMHz_CellY = 0
End If
Where xx MHz can be one of the supported LTE bandwidths in LA6.0: 3MHz, 5MHz,
10 MHz or 20MHz.
At the eNB level, the number of Bandwidth_Token_xxMHz_eNB will then be:
Bandwidth_Token_xxMHz_CellY = ∑ Bandwidth_Token_xxMHz_Cell
Example: if 10 MHz bandwidth is configured in all three cells of an eNB, then:
Bandwidth_Token_10MHz_eNB = 3 * 1 = 3 Bandwidth_Token_10MHz
And:
3.3 LTE OAM CAPACITY ELEMENTS

3.3.1 OVERVIEW
The global OA&M solution for LTE Network in LA6.0consists in a framework based
mainly on the SAM (Service Aware Management) Release 10.0R6 end to end
management system and provides OA&M functionality for both Radio Access Network
(eUTRAN) and evolved Packet Core network (ePC).
Additional following tools (Figure 24) provision and optimize the network configuration:
 9959 NPO Release 5.1 (Network Performance Optimizer): a Server and client
platforms to optimize the Network configuration based on PM counters using
ad-hoc metrics and reports.
Page 88/273
 9452 WPS Release 2.0 (Provisioning System) a standalone PC application for

Network Design activity. This application permits to prepare configuration for
new equipments to be deployed in the network and to reconfigure the network
as capacity increase.
Figure 24 : OAM Solution for LA6.0
3.3.2 5620 SAM PLATFORM DESCRIPTION

The 5620 SAM has evolved as an element management system integrating fault
management, configuration, accounting performance and security functions to tightly
integrate equipment routing, service and network management and provisioning
system. The 5620 SAM release integrates eUTRAN and Core Network Element
including following releases:
 ALU 9926 d2U+9442 RRH eNodeB/ALU 9412 Compact eNodeB: LA6.0

 ALU 9471 MME: WM6.0.0
 ALU P/S-GW (7750 SR): MG4.0 R8
 ALU 5780 DSC (PCRF) 5.0 R2
The 5620 SAM solution can be deployed with five different functional entities:
1. The 5620 SAM Server which is the main platform for all the network
management aspects
2. The 5620 SAM Database which is the Server running Oracle
database to store all the data management files, network objects,
network analysis, alarms and reports.
3. The 5620 SAM GUI Client workstation where we install the GUI for
Front End Access.
Page 89/273
4. 5620 SAM GUI Client Delegate Workstation(s). This workstation

enables customers to launch multiple 5620 SAM GUI Clients from just
one point
5. 5620 SAM Auxiliary Statistics Collector which is the server used to

collect and process performance and accounting statistics
The Figure 25 summarizes the global architecture for the different deployments and
the interaction between the different SAM modules and the other systems such as the
Network elements, GUI client and OSS system. This diagram presents three
architectural levels:
 The higher level is composed of GUI interface, OSS system and the third-party
system such other Management systems used to access to the SAM Main server
functions. The SAM client is installed in this part of network and is accessible
through the NBI (Northbound Interface).
 The median level integrates the complete SAM solution into different deployment
mode and modules, the communication between each module use the East-West
interface and require dedicated bandwidth. Four different architecture are
possible :
 Collocated server (SAM Main server and DB Database server installed on

the same machine). This configuration is composed of one machine for
the two functions
 Collocated and redundant servers: This configuration is based on two

machines, the Primary one and the secondary used for redundancy. Each
one of these two machines is installed in collocated mode with the two
modules 5620 SAM server and SAM DB.
 Distributed servers which means that all SAM main elements are installed
in standalone mode .This configuration should include in mandatory one
SAM server and one SAM DB and optionally two Auxiliary servers in
minimum and two Delegate servers .
 Distributed and redundant servers: mean the two applications (SAM server &
SAM DB) are mandatory installed in standalone mode and in redundancy
configuration. Two auxiliary servers in minimum are optionally deployed in
the network for the collection of call traces, performance and accounting
files. Up to two Delegate servers can be deployed in the OA&M solution,
one connected to the 5620 SAM Primary server and the second one to the
5620 SAM Secondary server.
 The lower level consists in the Network Elements management functions running
on the EMS SAM Server (Element Management System). This function
communicates with the NE(s) through the southbound interface.
Page 90/273
Figure 25 : 5620 SAM Deployment Scenarios

Different Redundancy configurations are available for the three types of servers. For
details please refer to [C03]
3.3.2.1 5620 SAM CAPACITY FIGURES FOR X86 PLATFORMS
The following table summarize the capacity figures for 5620 SAM platforms in Release
9.0 R5 with Solaris Operating system and for x86 machines.
Page 91/273
SAM COLLOCATED SAM DISTRIBUTED

SAM
CONFIGURATION CONFIGURATION
5 GUI / 5 OSS
Max # of OAM for 1875 MDA
SAM 5 GUI / 5 OSS
users(simultaneous) / or
10.0 R6 for 675 MDA (**)
Max # OSS client 25 GUI /25 OSS
for 1275 MDA
Number of Generic
SAM
Network elements 1000 5000
10.0 R6
(GNE)
Maximum # of SAM
Not Communicated 50.000
outstanding alarms 10.0 R6
200.000 (for 4 CPU and

no Auxiliary Server)
Maximum # of 400.000 (for 8 CPU and
SAM 100.000 for 4 CPU no Auxiliary server)
Accounting statistic
10.0 R6 200.000 for 8 CPU 800.000 (for 4 CPU and
records per 15mn
Auxiliary server)
10,000,000 (for 8 CPU
and Auxiliary server) (*)

no Auxiliary server)
Maximum # of
PM statistics records SAM 50.000 for 4 CPU 200.000 (for 4 CPU and
per 15mn 10.0 R6 or greater Auxiliary server)
Auxiliary server)
Maximum
SAM 60 60
simultaneous
10.0 R6
software upgrade
Maximum # of
simultaneous SAM 30 50
10.0 R6
Call trace session
Maximum # of
simultaneous SAM
Dynamic Debug -- 2
10.0 R6
Trace
SUN x4140, x4200, SUN x4140, x4200,
Example of Supported SAM x4170, x4270, x4470 x4170, x4270, x4470
servers 10.0 R6 HP Proliant DL380 G6 HP Proliant DL380 G6
DL580 G6 DL580 G6
Table 20 : 5620 SAM Capacity Figures for Solaris on X86 Machines
(*) Customized disk configuration required. Please contact Alcatel-Lucent for the most
current layout, appropriate to your configuration
(**) MDA: MEDIA Dependant Adapter : network physical interface card of ALU 72xx,
77xx IP products or equivalence.
NOTE: the number of MDA is not used for eNodeB OAM throughput calculation. MDA is used for
SAM system dimensioning, out of scope of LNCME.
Page 92/273
3.3.2.2 OAM BANDWIDTH DIMENSIONING
3.3.2.2.1 DESCRIPTION OF THE OA&M TRAFFIC FLOW
In order to effectively manage the LTE network element and perform efficient OAM
operation, we need to guarantee the minimum required bandwidth on the 5620 SAM
interface of the whole SAM solution which can be deployed in the network including
the following SAM elements:
 5620 SAM server (Primary and secondary server) ,
 5620 SAM database (primary and secondary) ,
 5620 SAM Delegate
 5620 SAM Auxiliary servers (Preferred and reserved).
This bandwidth is consumed by the traffic generated internally between the SAM
elements to perform internal SAM system functionalities .In case no sufficient
bandwidth is available , the SAM system functionalities will be altered and must lead
to the dysfunction of some OAM or system functions within the global SAM solution.
In most of operational cases, this bandwidth is statistically stable and defined to the
operator in order to design efficiently the OAM network architecture and to control the
congestion of carried traffic.
In addition to the bandwidth described above for the SAM elements, more critical
issue concerns the OAM bandwidth which should be available for the OAM traffic
generated to or from the network element deployed in the eUTRAN network (eNodeB)
and in the ePC network (MME, PGW, SGW, PCRF) .This OAM traffic carried to these
NE(s) are more difficult to determinate because it depends on the OAM configuration
of these network elements. The more illustrated example is the activation of the
monitoring traffic which can increase the required OAM bandwidth.
3.3.2.2.1.1 CATEGORY
The different OAM traffic flows are categorized, from a telecom manager point of view,
into:
 OPERATIONAL OAM traffic:
o Configuration Management (CM)
o Fault Management (FM)
o Performance Management (PM)
o Per Call Measurement Data (PCMD)
 MAINTENANCE OAM (standard) traffic

o Software Management
 MAINTENANCE OAM (DEBUG) traffic

o Dynamic Debug Trace (DDT)
o Call Trace (CT)
o Post Mortem Files
o Snapshots
Page 93/273
Note: Except Call Trace and PCMD, OAM traffic is independent of call Traffic.
3.3.2.2.1.2 CLASS
The OAM traffic flows in the DCN network are classified as follows:
 DCN Traffic for Dialog Applications
Traffic flows due to User interactions on a GUI (user request/system
answer): for example CM (Configuration commands).
Traffic flows due to Applications transferring a small volume of data in a non

deterministic order: for example, FM (fault) alarm messages sent from the
Network Element to the NMS.
 DCN Traffic for bulk transfer (periodic)
Traffic flows due to Applications transferring data at a regular period (every n
minutes, hour or day). Typical Application is the transfer of PM (performance
measurements or counters) data.
 DCN Traffic for bulk Transfer (non recurring)
Traffic flows due to Applications transferring big amount of data,
occasionally. Typical examples are software upgrade on the Network
Elements, upload or download bulk configuration.
The Dialog Applications represents a small-sized traffic. The calculation is user

dependant.
The Bulk Transfers represent a medium-sized traffic. The calculation is most of the
time deterministic. The bandwidth required can be easily determined and calculated
based on a maximum fixed length and a period.
The non-recurring Bulk Transfers represent an extra-large-sized traffic. The operator,

in this case, should take care of the large amount of OAM traffic flow generated
specially on the eUTRAN network, as far as it impacts widely the reserved bandwidth
at the eNodeB side. These traffic flows are described in the following sections and are
the PCMD files, Call trace files, DDT (Dynamic Debug Trace) files, Post-mortem files,
L3 snapshot files, on-Demand snapshot and eNodeB software downloads.
The operational traffic is mainly classified on the first class of traffic “Dialog
application” and corresponds to the traffic usually exchanged between the user
interface and the server and between the Network Element and the server for small
amount of traffic exchanged for FM, CM process.
The Traffic bulk transfer is considered as the second class of traffic in term of the
volume exchanged with the server and which is most of the time limited for fixed
length and for recurrent period The bandwidth required for this traffic at the EMS and
the network element side can be easily determined and calculated based on the
maximum volume exchanged .The typical example can be defined for PM, statistic
and accounting files generated by an eNodeB.
For this example, the only files considered are the Counters file or PM file stored in the
EMS in XML files. The EMS initiates the transfer of PM counters from the eNB on
specific reporting interval. This interval is configurable and can have the following
values: 5, 15, 30, 60 min.
Page 94/273
The considered heavy traffic in term of the volume exchanged between the EMS and
the other resources is classified as Bulk transfer for nonrecurring traffic .The operator
in this case should consider OAM traffic flow generated specially on the eUTRAN
network and which can impact the reserved bandwidth at the eNodeB side.
These traffic flow occurs occasionally for maintenance on the LTE network elements
specially the eNodeB and are described in the following sections .These traffic are
typically the PCMD files, Call trace files, DDT (Dynamic Debug Trace) files, Post-
mortem files, L3 snapshot file, on-Demand snapshot and eNodeB software download.
3.3.2.2.1.3 APPLICATION / INTERFACE / PROTOCOL
The following table summarizes the OAM flows and the impacted, Network Elements,
clients, SAM servers, NPO servers and introduces the main protocol/interfaces (see
detail in [C03].
OAM traffic flow Application From/To Interface /protocol

SAM client <-> SAM main NBI interfaces on dedicated
SAM Client
SAM client -> SAM Delegate ports
NBI interface on dedicated
NPO Client NPO client -> NPO Server ports
Dialog application Wips Wips-> SAM NBI Interface
NBI interface /
SAM-O XML SAM XML client -> SAM XML/SOAP/HTTPS over
TCP
SAM-O 3GPP OSS 3GPP OSS ->SAM CORBA over TCP
eNodeB -> SAM server

PM eNodeB ->SAM auxiliary SNMPv3 over TCP
Bulk transfer statistics
(Periodic)
eNodeB-> SAM server Downlink: NETCONF for
Call trace
eNodeB ->SAM auxiliary for de/activation,
(Signaling) Uplink: Streaming / UDP
call trace
Downlink: NETCONF for
Dynamic Debug eNodeB-> SAM server
de/activation,
trace (DDT) eNodeB-> SAM Uplink: Streaming / UDP
Bulk transfer enodeB -> MME Sctp over TCP on S1-MME

PCMD
(non recurring) MME <- NPO auxiliary (1) SSH over TCP
Downlink: SNMP for
Software SAM client & server -> triggering eNodeB SW
upgrade eNodeB, MME, X-GW, PCRF download from a Code
server"
Network From NE to the

1588 UDP
synchronization Synchronization server
Table 21 : Matrix of the OAM Traffic Flow

(1) MME is collected by NPO directly, not by SAM
Page 95/273
3.3.2.2.1.4 PCMD FILES:
Per Call Measurement Data (PCMD) contain UE connection level measurement data
(UE connection or context parameters, bearer parameters (including SDU traffic
volume), UE measurements, context disposition). PCMD traffic is a signaling traffic
sent from the eNodeB on S1-MME in S1AP Private Messages to the MME then to the
EMS (SAM system)
PCMD is activated from the EMS to indicate following PCMD capability:
 to start PCMD collection in the eNodeB

 to stop PCMD collection in the eNodeB
 to send collected data to the MME after UE Context Release Complete, RRC
Connection Reconfiguration Complete, X2 UE Context Release
The volume of PCMD message depends on the traffic model (number of users,
number of connections, number of calls, and number of handovers)
The eNodeB can be connected to several MME(s) so the PCMD messages can be
sent from 1 eNodeB to several MMEs
3.3.2.2.1.5 CALL TRACE
5620 SAM manages up to 100 CT sessions. Only one CT session is active per
eNodeB. Each session traces a list of Cells (1 up to the maximum # of cells that
eNodeB can manage) on RRC, S1-MME and/or X2 interfaces
There are 3 types of Call Trace:
 Cell Traffic Trace. The eNodeB starts a Trace Recording Session whenever a
call is started in the monitored cell(s).
 Event-Based Trace. The eNodeB starts a Trace Recording Session whenever

any threshold condition is met in the monitored cell(s). Once triggered, any UE
call that is started on the monitored cell(s) will be traced.
 Signalling based Trace. The eNodeB starts tracing the monitored UE as soon
as it receives any of the following messages with a Trace Activation
parameter:
 S1AP: TRACE START
 S1AP: INITIAL CONTEXT SETUP REQUEST
 S1AP: HANDOVER REQUEST
 X2: HANDOVER REQUEST
These 3 types of Call Trace generate the same Call Trace information. The Call Trace
report messages contain information on the RRC, X2, S1-MME signaling messages.
It is possible to configure the eNodeB to get either Call Trace with maximum depth
(whole signaling messages are reported in Call Trace messages) or minimal depth
(only some parameters of the signaling messages are reported in Call Trace
messages) and this configuration applies for all the cells of the eNodeB.
Page 96/273
The activation of the Cell Traffic Trace or Event based Trace is done from the EMS.
The activation of signaling based Trace is done from the EMS of the EPC through the
MME with an S1-MME message.
The Call Trace traffic is a stream like traffic. The Call Trace messages are sent from
the eNodeB to the EMS in UPOS messages in UDP datagram. There can be several
UPOS messages in a UDP datagram. They are sent either when one of the following
conditions is met:
 The maximum size of the datagram is reached.
 5 seconds spent after the last sending
The volume of Call trace messages depends on the traffic model and the maximum
number of simultaneous trace sessions at the eNodeB is 100.
3.3.2.2.1.6 DYNAMIC DEBUG TRACE
The Dynamic Debug Trace (DDT) messages contain information for debug and
information on the signalling messages received.
There are several profiles for Dynamic debug Traces depending on the layers that are
monitored for the dynamic debug traces (L1, L2, L3) and on the depth of the
monitoring (light, medium, deep). It is possible to configure which profile to use for the
DDT. The activation of the DDT is done from the EMS.
The DDT traffic is a stream like traffic. The Dynamic Debug Trace messages are sent
in UDP datagram from the eNodeB to the EMS, for L1 and L2 DDT messages.
The maximum size for the payload of a datagram containing UPOS messages is 7500
bytes, so the datagram is fragmented when transferred over Ethernet.
The volume of L1 DDT does not depend on the traffic model and does not depend on
the number of UEs.
The volume of L2 and L3 DDT depend on the traffic model.
The Dynamic Debug Trace is exclusive with the Call Trace at the eNodeB level.
Note: The maximum number of UEs that can be monitored at the same time is about
320 but some information can only be given for 16 to 20 UEs.
3.3.2.2.1.7 POST-MORTEM FILE
There are 2 kinds of post-mortem files:
 ENodeB board restart context file; created in case of an unplanned eNodeB

board restart (either partial or full); set of files useful for the investigation:
crash dump, log files, etc.
 ENodeB application restart context: created in case of an unplanned eNodeB

applications restart (bCEM only); set of files useful for the investigation: L1/L2
crash dump.
The enabling of the Post-Mortem file transfer is done from the EMS.
Page 97/273
The Post-Mortem traffic is file transfer traffic. After the restart of the board or the
application, the eNodeB notifies the EMS that a post-mortem file is available with
SNMPv3.
The eNodeB transfers the Post-Mortem file to the EMS with SFTP.
3.3.2.2.1.8 L3 SNAPSHOT
The eNodeB L3 Snapshot file is created in case of a telecom procedure failure. It

contains context dump data. The enabling of the L3 snapshot file transfer is done from
the EMS.
The L3 Snapshot traffic is file transfer traffic.
The eNodeB notifies the EMS that a L3 Snapshot file is available with SNMPv3 then
the eNodeB can start transfers the L3 Snapshot file to the EMS with SFTP.
3.3.2.2.1.9 ON-DEMAND SNAPSHOT
The On-Demand Snapshot file contains debug data from application or from platform
software. The On-Demand Snapshot traffic is file transfer traffic.
The generation of the On-Demand Snapshot file is done from the EMS on operator
request.
The eNodeB notifies the EMS that an On-Demand Snapshot file is available with
SNMPv3. Then the eNodeB transfers the On-Demand Snapshot file to the EMS with
SFTP.
3.3.2.2.1.10 SOFTWARE DOWNLOAD
The Software download traffic is file transfer traffic. The EMS transfers the software
file to the eNodeB with SFTP on operator request.
3.3.2.2.2 OAM BANDWIDTH REQUIREMENTS PER ENODEB
3.3.2.2.2.1 TOTAL OPERATIONAL OAM BANDWIDTH
The minimum bandwidth for OAM traffic (DownLink and UpLink) takes into
consideration dialogue traffic and bulk transfer recurring traffic including PM files and
PCMD files.
eNodeB OAM Operation (standard) on VLAN OAM 0,7 Mbps

Downlink Uplink total
PM traffic 0 kbps 3,0 kbps 3,0 kbps
FM traffic 0 kbps 29 kbps 29 kbps
Event traffic 0 kbps 5,0 kbps 5,0 kbps
CM traffic 600 kbps 0,0 kbps 600 kbps
eNodeB OAM Operation (standard) on VLAN TELECOM 0,03 Mbps

PCMD traffic on S1-eNB-MME interface 0,00 kbps 34 kbps 34 kbps
Table 22 : Total eNodeB OAM Operational Bandwidth
Page 98/273
9471 MME OAM Operation (standard) on VLAN TELECOM 0,03 Mbps

PCMD traffic on S1-eNB-MME interface 0 kbps 34 kbps 34 kbps
OAM Operation (standard) on VLAN OAM 0,3 Mbps

PCMD traffic 0 kbps 70 kbps 70 kbps
FM+PM traffic 0 kbps 200 kbps 200 kbps
Table 23: Total MME OAM Operational Bandwidth in LA6.0
3.3.2.2.2.2 TOTAL MAINTENANCE OAM BANDWIDTH
Most of maintenance interventions are done during a “maintenance window”, out of

busy hours. The 2 types of maintenance, preventive and corrective maintenances
needs additional bandwidth for
 the traffic generated by equipment or network after each failure (post-mortem,

snapshots). These received files help diagnosis. Analysis could request
launch of Call Trace or deeper DEBUG.
 the traffic generated by Call Trace or by Dynamic Debug Trace.
Restriction: eNodeB - Maintenance - Call Trace & Dynamic Debug Trace
On eNodeB, different exclusive scenarios are possible:
 Call trace is activated

 Dynamic Debug Trace L1/L2 is activated + Call Trace is activated
 Dynamic Debug Trace L1/L2+L3 is activated (Call Trace is L3 embedded)
Dynamic Debug Trace L1/L2 is activated (means wo Call Trace)
Restriction: 5620 SAM - Maintenance - Dynamic Debug Trace
5620SAM manage up to 2 simultaneous DDT.
The following table summarizes the example of the maximum required bandwidth in
downlink and uplink during maintenance window, with the worse datagram overhead
(IPSEC and 802.1q). As these operations are not occurring at the same time, we
practically reserve the maximum required bandwidth for the most consuming traffics:
DDT (L1+L2+L3 Dynamic Debug Trace) for Uplink traffic and Software upgrade for
Downlink traffic.
Page 99/273
eNodeB OAM Maintenance (standard) on VLAN OAM 6,9 Mbps

Software Download traffic on OAM-eNB interface 6,9 Mbps 0 kbps 6,9 Mbps
OAM Maintenance (DEBUG) on VLAN OAM 45 Mbps
(CT) Call Trace traffic 0 kbps 0,54 Mbps 0,54 Mbps
(DDT) Dynamic Debug Trace traffic 0 kbps 39 Mbps 39 Mbps
(PMD) Post Mortem Debug Tracetraffic (Board restart) 0 kbps 2,3 Mbps 2,3 Mbps
(PMD) Post Mortem traffic (Application restart) 0 kbps 2 Mbps 2 Mbps
(Snapshot) L3 snapshot traffic 0 kbps 0,0033 Mbps 0,0033 Mbps
(Snapshot) On-demand Snapshot traffic 0 kbps 0,9 Mbps 0,9 Mbps
Table 24: eNodeB Bandwidth for OAM Maintenance in LA6.0

Note: Post mortem and snapshot are peak traffic generated once with an average
300s transfer delay (TD).
Considering the calculation result given in the table and making the assumption that
not all the operation can be performed simultaneously on the same eNodeB we
deduce that the most consuming OAM traffic is the DTT (Dynamic Debug Trace) with
a maximum of 37 Mbps of throughput.
Engineering Recommendation: OAM DDT bandwidth consumption
 ALU does not recommend to activate the DDT during busy hours.
 ALU recommends to activate DDT only during the maintenance window.
 ALU recommends to activate DDT for 45 minutes maximum.
When some OAM operations are critical and require additional bandwidth out of the
maintenance windows, we need to configure the OAM interface with the appropriate
QoS to avoid any impact on the telecom traffic. Further control can be performed to
avoid any congestion on the network by deploying the correct network design that
should take into consideration the maximum bandwidth resource. Additional
mechanisms on the transport level can be performed for the traffic engineering to
permit the reservation of the required bandwidth or the shaping and policing of the
maximum throughput.
Rule: QOS attribution for eNodeB interface
The less consuming OAM operations in term of bandwidth could be scheduled out of the maintenance
window and during busy hours if congestion is controlled on the Network.
For some exception and for very critical maintenance operation which needs more bandwidth, traffic
shaping and QOS parameters can be modified during this operation but needs the reboot of the
eNodeB.
Page 100/273
The calculation details of previous tables are described in the following sections.
Assumption on the OAM transport encapsulation headers as showed in the figure
below.
Figure 26 : OAM Transport Encapsulation Headers
3.3.2.2.2.3 DETAILED OPERATIONAL OAM BANDWIDTH
3.3.2.2.2.3.1 Dialog Traffics (CM, FM)
The dialog traffics have a non deterministic behavior:

- Configuration (CM) traffic is dependant of the way that Telecom Manager
interacts with the Network Element (via GUI or OSS interface).
- Alarms / Faults (FM) traffic is dependant of the health of the Network Element
and the Network it is connected to the EMS.
DL UL
CM Throughput 600 Kbps (1) N/A
(1)This value is an estimation. This value includes:

- eNodeB SNMP polling (periodic)
- eNodeB Backup (periodic)
This value does not include bandwidth required for
- eNodeB discovery (on-demand)
- eNodeB resynchronization (on-demand)
- eNodeB Bulk provisioning WIPS tool.
Page 101/273
3.3.2.2.2.3.2 Performance Counters (PM)
5620 SAM collects (via SNMP), per eNodeB, a PM file (in a compressed XML format)
at a periodic interval (granularity period with a 300s minimum value) and the following
capacity figures:
PM file size = Nb of counter instances * instance size * (1- compression ratio)
* ( 1 + XML ratio)
Considering values
19393 instances of counters (in the .gz file)
instance size = 13 Bytes (13 characters for value maw = 232-1)
compression ratio = 80%
XML = xml header size : value size = 1
PM file size = 19393 * 0,013 kBytes * 0,2 * 2
= 101 kBytes compressed (402 kBytes not compressed) per eNodeB
Considering a minimum reporting interval of 5 minutes (300s), the bandwidth

requirement and the transport header size for the PM files through SNMP session is
calculated in bytes as following:
o Transport_Header (Ethernet_Null, No IPSec) = 30 (SNMP) + 8 (UDP) + 20 (IP

inner) + 18 (Ethernet L2) + 20 (Ethernet L1) = 96 Bytes
o Transport_Header (Ethernet_802.1Q, No IPSec) = 30 (SNMP) + 8 (UDP) + 20 (IP
inner) + 22 (Ethernet L2) + 20 (Ethernet L1) = 100 Bytes
o Transport_header_Size (Ethernet_Null, IPSec) = 30 (SNMP) + 8 (UDP) + 20 (IP
Inner) + 60 (IPSEC) +18 (Ethernet L2) + 20 (Ethernet L1)= 156 Bytes
o Transport_header_Size (Eternet_802.1Q, IPSec) = 30 (SNMP) + 8 (UDP) + 20
(IP inner) + 22 (Ethernet L2) + 20 (Ethernet L1) + 60 (IPSec) = 160 Bytes
Considering that application packet size is estimated to 1500 then the bandwidth
calculation is calculated as following:
Transport mode Ethernet null Ethernet 802.1Q Ethernet Null Ethernet 802.1Q
No IPSec No IPSec IPSec IPSec
Transport header 96 bytes 100 bytes 156 Bytes 160 bytes
101 x 8 x (1+ 101 x 8 x (1 + 101 x 8 x (1 + 101 x 8 x (1 +
96/(1500-96)) 100/(1500-100)) 156/(1500-156)) 160/(1500-160))
Throughput for /300 = /300 = /300 = /300 =
counters
2,873 Kbps 2,881 Kbps 3,001 Kbps 3,01 Kbps
Table 25 : Bandwidth Requirement for eNodeB Counters in LA6.0
3.3.2.2.2.3.3 PCMD
According the Call model (see Table 5), the average percentage of time an attached
subscriber is in connected state during the busy hour is given as following
CSFB
% Time connected /Attached for a user 11 %
Table 26 : Percentage of Time Connected / Time Attached for a Users in a BH

Page 102/273
From the same call model we can estimate the total number of message per attached
subscriber is:
CSFB
Nbr_PCMD_Msg (PCMD messages / attached UE/ eNB) 31
Table 27 : Nbr_PCMD_UE
In PCMD the maximum number of simultaneous UE(s) is MIN(200;Users_Modem)
per cell, so LA6.0 supports 600 UE on PCMD per eNodeB. The maximum number of
UEs in PCMD during busy hour for one eNodeB is then calculated as following:
Nbr_eNB_PCMD_UE= 3 x MIN(200;Users_Modem) / % (time connected / time attached user)

CSFB
Nbr_eNB_PCMD_UE (Nbr PCMD users / BH / eNB) 273 / 0,11 = 2475
Table 28: Total Number of User Doing PCMD During the BH and per eNB
The total PCMD messages per ENB eNodeB_(PCMD UE) is calculated as following :
eNodeB_(PCMD UE) = Nbr_eNb_PCMD_UE x Nbr_PCMD_Msg
The total volume of PCMD for one eNodeB per BH is presented in the table below:
CSFB
eNodeB_(PCMD 2475 x 31 = 76
UE) 725
Table 29 : Total PCMD Message per Call Model at BH and per eNB
The Volume of PCMD message is 108 Bytes, then Total volume per ENB at
application level is calculated as following:
Total_Volume_PCMD_App = Nbr_eNB_PCMD_UE x Nbr_PCMD_Msg x 108 bytes
The transport header for SCTP packet in IPV4 may have four different values:
o Header size (Frame Ethernet Null) = 28 + 20 + 18 + 20 = 86 bytes

o Header size (Frame Ethernet-802.1q) = 28 + 20 + 22 + 20 = 90 bytes
o Header size (Frame Ethernet Null, IPSec) = 28 +20+ 60 + 18 + 20 =146 bytes
o Header size (Frame Ethernet-802.1q,IPSec) = 28 +20+ 60 + 22 + 20= 150 bytes
The throughput at physical layer can therefore be calculated with the following
formulas:
PCMD-S1-MME_Throughput_Phy = eNodeB_(PCMD_UE) x (Size_Msg_Phy) x 8/3600
Where: Size_Msg_Phy = Size_Msg_App + Transport _Header_Size

Page 103/273
The PCMD traffic collected on the MME is sent over the OAM interface to the SAM
server through SSH/SFTP protocol. The transport header application is in this case
case calculated as following:
o Transport_header_Size (Ethernet_Null,No IPSec) = 160 (SSH/sftp) + 20(TCP) +
20 (IP inner) + 18 (Ethernet L2) + 20 (Ethernet L1) = 238 Bytes
o Transport_header_Size (Eternet_802.1Q, No IPSec) = 160 (SSH/sftp) +20(TCP)

+ 20 (IP inner ) + 22 (Ethernet L2) + 20 (Ethernet L1) = 242 Bytes
o Transport_header_Size (Ethernet Null, IPSec) = 160 (SSH/sftp) + 20 (TCP) + 20

(IP Inner) + 60 (IPSEC) +18 (Ethernet L2) + 20 (Ethernet L1) = 298 Bytes
o Transport_header_Size (Ethernet_802.1Q, IPSec) = 160 (SSH/sftp) + 20 (TCP) +
20 (IP inner) + 22 (Ethernet L2) + 20 (Ethernet L1) + 60 (IPSec) = 302 Bytes
The average throughputs for PCMD traffic on S1-MME for different transport size are
resumed in the following table:
PCMD traffic CSFB

PCMD
(108+86) x 31
throughput
x2475 x 8/3600
(Ethernet no
= 23,86 Kbps
IPSEC)
PCMD
Throughput (108+90) x 31
(Ethernet x2475 x 8/3600
802.1Q, no = 24,35 Kbps
IPSEC)
PCMD
throughput (108+146) x 31 x2475x8/3600 =
(Ethernet , 31,23 Kbps
IPSEC)
PCMD
throughput (108+150) x31 x
(Ethernet 2475x8/3600 =
802.1Q , 31,73 Kbps
IPSEC)
Table 30 : Average Throughput for PCMD Traffic Over S1-MME
The average throughput for PCMD traffic on OAM from MME to SAM for different
physical layer and IP header is resumed in the following table:
Page 104/273
PCMD traffic CSFB

PCMD throughput (108+238) x 31 x 2475x 8/3600
(Ethernet , no IPSEC) = 42,55 Kbps
PCMD Throughput (108+242) x 31 x 2475 x 8/3600

(Ethernet 802.1Q, no IPSEC) = 43,04 Kbps
PCMD throughput (108+298) x 31 x 2475 x 8/3600

(Ethernet , IPSEC) = 49,92 Kbps
PCMD throughput (108+302) x 31 x 2475 x 8/3600

(Ethernet 802.1Q, IPSEC) = 50,42 Kbps
Table 31 : Average Throughput for PCMD Traffic Over MME OAM Interface
3.3.2.2.2.4 DETAILED MAINTENANCE OAM BANDWIDTH (STANDARD)
3.3.2.2.2.4.1 Software Downloads
There are several software file required for eCCM, eCEM , bCEM cards and one for
the RRH. These files have fixed length. The software upgrade is done in downlink
through SSH or SFTP protocol.
The transport header size is calculated as following:
o Transport_header_Size (Ethernet_Null, No IPSec) = 160 (SSH/sftp) + 20 (TCP) +

20 (IP inner ) + 18 (Ethernet L2) + 20 (Ethernet L1) = 238 Bytes
o Transport_header_Size (Ethernet_802.1Q, No IPSec) = 160 (SSH/sftp) + 20

(TCP) + 20 (IP inner) + 22 (Ethernet L2) + 20 (Ethernet L1) = 242 Bytes
o Transport_header_Size (Ethernet_Null, IPSec) = 160 (SSH/sftp) + 20 (TCP) + 20

(IP Inner) + 60 (IPSEC) + 18 (Ethernet L2) + 20 (Ethernet L1) = 298 Bytes
o Transport_header_Size (Ethernet_802.1Q, IPSec) = 160 (SSH/sftp) + 20 (TCP) +

20 (IP inner) + 22 (Ethernet L2) + 20 (Ethernet L1) + 60 (IPSec) = 302 Bytes
Bandwidth calculation is done with a practical example for average software download
duration of 5mn (300 s). This calculation for time duration was based on the
assumption validated by tested measurement of 15mn. including Time for reboot
(5mn) + Time for activation (5mn) + download duration (5mn or 300s).
eCCM eCEM
bCEM RRH TR MR MT
card card
44 23 37 71 28 10 10
Software size / board
Mbytes Mbytes Mbytes Mbytes Mbytes Mbytes Mbytes
Software size / eNodeB 231 Mbytes
Max APP throughput for
6,2 Mbps
OAM software upgrade
Table 32 : Throughput Calculation for eNodeB OAM Software Upgrades Application
Page 105/273
The eNodeB in LA5.0 supports eCEM, bCEM software. Only one software upgrade is
possible for one eCEM or bCEM, so considering the greeter software load the total
maximum throughput can be estimated and calculated in the following table:
Ethernet Null Ethernet 802.1Q Ethernet Null Ethernet 802.1Q

Max Physical 6,2 x (1 + 6,2 x (1 + 6,2 x (1 + 6,2 x (1 +

Throughput for 238/(1500-238)) 242/(1500-242)) 298/(1500-298)) 302/(1500-302))
OAM SW = 7,3 Mbps = 7,3 Mbps = 7,7 Mbps = 7,7 Mbps
Table 33 : Throughput Calculation for eNodeB OAM Software Upgrade at Physical Layer
3.3.2.2.2.5 DETAILED MAINTENANCE OAM BANDWIDTH (DEBUG)
3.3.2.2.2.5.1 Call Trace (CT)
According the Call model (see Table 5), the average percentage of time an attached
subscriber is in connected state in LA6.0and during the busy hour is given as following
CSFB
% Time connected /Attached for a user 11,0 %
Table 34 : Percentage of Time Connected / Time Attached for a Users in a BH
The maximum of simultaneous UE(s) in call trace inLA6.0 is = MIN( 200 ;

Users_Modem) per eNodeB. The volume of data for call trace is 80 Kbytes for PC and
200 Kbytes for Smart phone.
The number of attached UEs that can be in call trace during a busy hour is
eNodeB(Call-trace UE) = MIN( 200 ;Users_Modem) / % (Time connected /attached user)
The number of attached UEs is presented in the table below:
CSFB
Nbr_eNB_CLT_UE ( Nbr users for call trace / BH / eNB) 91 / 0,11 = 825
Table 35: Total Number of Call Trace User /eNB / BH
The calculation of the maximum bandwidth for call trace procedures according the call
model would depend of the maximum number of call trace procedure estimated when
the maximum trace are taken for the all signaling events This number would be
equivalent to the maximum of the total number of the signaling events per BH
including S1-MME, RRC and X2 traffic .These values are taken from the call model for
LE/LA6.0.
Call Model CSFB
Page 106/273
Nbr_Sig_Proc (Per attached UE) 712,5
Table 36: eNodeB Total Signalling Procedure per BH and per UE
The calculation of average size of call trace message will depend if fragmentation is
done or not and the number of UPOS message in a call trace event according the
following formula:
Average size for Call_trace message = [Size-UPOS_Msg(360bytes) x

Nbr-UPOS_Msg + Nbr(Fragment) x Transport-header_size] / Nbr(Fragment)
Considering the case where there is no fragmentation for the call trace
message and no concatenation for the UPOS messages which correspond to the
most critical case where we can maximum bandwidth is consumed, then the average
Call Trace _message at application layer can be estimated to minimum value of 285
bytes.
Based on these assumptions, the bandwidth for Call trace at physical layer is
calculated based on the transport header size given as example here for IPV4
packets. The transport header size may have four different values depending of the
used transport protocol at layer3 and Layer 2
o Header size (Frame Ethernet Null) =8(UDP)+ 20(IP) + 18(Ethernet-Null) + 20

(Eth FPG) = 66 bytes
o Header size (Frame Ethernet-802.1q) = 8(UDP)+20(IP) + 22(Eth 802.1Q) + 20
(Eth FPG+)= 70 bytes
o Header size (Frame Ethernet Null,IPSec) = 8(UDP)+20(IP)+ 60(IPSEC) + 18
(Ethernet L2) + 20 (Ethernet L1)= 126 bytes
o Header size (Frame Ethernet-802.1q,IPSec) = 8(UDP)+20 (IP)+ 60(IPSEC) + 22
(Ethernet 802.1q) + 20 (Ethernet FPG)= 130 bytes
The bandwidth for call trace is calculated with following formula
Bandwidth_Call_trace_Phy= Nbr_eNB_CLT_UE x Nbr_CLT_Proc x

(Size_CLT_Proc + Transport_Header_size) x 8/3600
Where the Nbr_CLT_Proc is the total call_trace procedure per attached UE during BH
and Size_CLT_Proc is the average size of CLT procedure at physical layer: Then the
different calculation for call trace traffic is:
Page 107/273
Bandwidth for Call Trace traffic at

CSFB
the physical layer
BW_CLT_Phy 825 x 712,5 x (360+66) x
(Ethernet Null , no IPSEC) 8/3600/1000000 = 0,56 Mbps
BW_CLT_Phy 825 x 712,5 x (360+70) x
(Ethernet 802.1Q , no IPSEC) 8/3600/1000000 = 0,56 Mbps
BW_CLT_Phy 825 x 712,5 x 360+126) x
(Ethernet-Null , IPSEC) 8/3600/1000000 = 0,64 Mbps
BW_CLT_Phy 825 x 712,5 x (360+130) x
(Ethernet 802.1Q , IPSEC) 8/3600/1000000 = 0,64 Mbps
Table 37 : Bandwidth Throughput for Call Trace Traffic
3.3.2.2.2.5.2 Dynamic Debug Trace (DDT)
L1 Dynamic Debug Trace message size is constant and independent from the call
model. The same L1 message is carried by 2 reports per ms. The L1 message Size
depends of the card type:
 eCEM (per cell):
o CE: 716 bytes/ms
 bCEM (per cell): 796 bytes detailed in
o DSP: 292 bytes/ms
o ULT: 504 bytes/ms
L2 Dynamic Debug trace depends on the traffic and radio conditions. The L2 message
Size depends of the card type:
 eCEM (per cell):
o UPA: variable, will not exceed 700 bytes/ms
 bCEM (per cell):
o DLT: variable, will not exceed 700 bytes/ms
Note: L3 Dynamic debug trace is not usable in loaded deployed environment

because it requires too much CPU on eNodeB.
The required bandwidth for only L1/L2 trace per cell is calculated as following:
DDT_L1/L2_Throughput= (Volume DDT (L1/L2)_Message + Transport_Header size) x 8 x (1/1000)
The DDT traffic is a streaming traffic sent over UDP port.

The transport Header size is calculated as following:
o Transport_header_Size (Ethernet Null, No IPSec) = 20+18+ 20+8 = 66 Bytes
o Transport_header_Size (Ethernet_802.1Q, No IPSec) =20+22+20+8= 70 Bytes
o Transport_header_Size (Ethernet Null, IPSec) = 20+18+ 60+20+8 = 126 Bytes
o Transport_header_Size (Ethernet_802.1Q, IPSec) = 20+22+60+20+8= 130

Bytes
Page 108/273
The average OAM throughput on Dynamic debug trace for different physical layer and
IP header is resumed in the following table:
Dynamic debug Ethernet-Null Ethernet 802.1Q Ethernet Null Ethernet 802.1Q

Trace No IPSec No IPsec with IPSec IPSec
(796+66) x 8 x (796+70) x 8 x (796+126) x 8 x (796+130) x 8 x
BW DDT (L1) 1000 = 1000 = 1000 = 1000 =
6,896 Mbps 6,928 Mbps 7,376 Mbps 7,408 Mbps
(700+66) x 8 x (700+70) x 8 x (700+126) x 8 x (700+130) x 8 x
BW DDT (L2) 1000 = 1000 = 1000 = 1000 =
Total BW DDT
(L1+L2) per cell
Total BW DDT
(L1+L2) / eNB
Total BW DDT
(L1+L2) / eNB 78,144 Mbps 78,528 Mbps 83,904 Mbps 84,288 Mbps
dual-band
Table 38 : Maximum Throughput Required per eNodeB for the DDT Traffic
3.3.2.2.2.5.3 Post Mortem File
There are 2 kinds of post-mortem files:
ENodeB board restart context file
ENodeB application restart context file
3.3.2.2.2.5.3.1 ENodeB Board Restart
The maximum size for eNodeB board restart context is 70 Mbytes. The transfer is
done from the eNodeB to the EMS system through SSH and SFTP protocol.
The transport header size is same as described in the point 3 for SW. In case
considering the required duration time for the transfer of the files is 300 s we obtain
the estimation of the required bandwidth for the transfer of Mortem files.
Ethernet 802.1Q , Ethernet Ethernet Null, Ethernet Null, No

IPSec 802.1Q,NO IPSec IPSec IPSec
Max APP
Throughput 70 x 8 X (1/300)= 1,87 Mbps
for OAM SW
Max Physical
1,87 ( 1+ 302/1500- 1,87 (1+242/(1500- 1,87(1+298/(1500- 1,87(1+238/(1500-
Throughput
302)=2,34 Mbps 242))= 2,23 Mbps 298))= 2,33 Mbps 238))= 2,22 Mbps
for OAM SW
Table 39 : Bandwidth Requirement for eNodeB Post Mortem File LA6.0
Page 109/273
3.3.2.2.2.5.3.2 ENodeB Application Restart
The maximum size for eNB application restart context is 60 Mbytes. The transfer is
done from the eNodeB to the EMS system through SSH and SFTP protocol. Taken
into consideration same transfer duration of 300 s .The bandwidth calculations will be
calculated as presented following Table 40.

Max APP
Throughput for 60 x 8 X (1/300) = 1,6 Mbps
eNodeB APP restart
Max Physical 1,6 (1+ 1,6 (1 + 1,6 (1 + 1,6 (1 +

Throughput for eNB 238/(1500-238))= 242/(1500-242))= 298/(1500-298 ))= 302/(1500-302))=
APP restart 1,90 Mbps 1,91 Mbps 1,99 Mbps 2 Mbps
Table 40 : eNodeB Application Restart Context Bandwidth Requirement LA6.0
3.3.2.2.2.5.4 Snapshots
3.3.2.2.2.5.4.1 L3 Snapshot
The maximum size for L3 snapshot is 100 Kbytes, considering the same estimation
time 300 s for file transfer the bandwidth requirement would be as following.

No IPSec no IPSec IPSec IPSec
APP throughput
100 x 8 X (1/300)= 2,66 Kbps
L3 snapshot
2,66 (1 + 2,66 (1 + 2,66 (1 + 2,66 (1+

Phy throughput 238/(1500-238))= 242/(1500-242))= 298/(1500-298 ))= 302/(1500-302)) =
L3 snapshot
3,2 Kbps 3,2 Kbps 3,3 Kbps 3,3 Kbps
Table 41 : L3 Snapshot Bandwidth Requirement inLA6.0
3.3.2.2.2.5.4.2 On-demand Snapshot
The maximum size for on –demand snapshot is 26 Mbytes Same estimation as above
the total bandwidth for on-demand snapshot is calculated as following :
Page 110/273

APP Throughput
On-demand 26 x 8 X (1/300)= 693 Kbps
snapshot
693 (1 + 693 (1 + 693 (1 + 693 (1 +
Phy Throughput
238/1500-238)= 242/1500-242)= 298/1500-298 )= 302/1500-302)=
On-Demand
823,68 Kbps 826,06 Kbps 864,86Kbps 867,63 Kbps
snapshot
Table 42: On-Demand Snapshot Bandwidth in LA6.0
3.3.2.2.3 OAM BANDWIDTH REQUIREMENTS PER EPC AND BACKHAUL
The following table describes the bandwidth requirements for each network element.
Number of Network Element Example Bandwidth requirement

MDAs/CMAs from 5620 SAM Server(s) to
the Network Element
2 7450 ESS-1, Telco T5C, 7250 200 kbps
N/A OmniSwitch 6400, 6850, 6855,9000 series 600 kbps
N/A 9500 MPR 200 kbps
10 7450 ESS-7 (fully loaded) 1 Mbps
8 7705 SAR (fully loaded) 200 kbps – 400 kbps
20 7750 SR-12 (fully loaded) 2 Mbps
12 7710 C-12 (fully loaded) 600 kbps
1 7210 SAS E 200-300 kbps
N/A 9471 MME 200 kbps
N/A 5780 DSC 200 kbps
Table 43: OAM SAM Bandwidth Dimensioning with ePC and Transport Network Elements
3.3.2.2.4 OAM BANDWIDTH REQUIREMENTS PER SAM SERVER
The following table summarizes the required bandwidth for the SAM interfaces:
Page 111/273
Recommended Bandwidth between SAM Modules

SAM elements (excluding statistics Bandwidth requirements)
5620 SAM Server to a 5620 SAM Database (*) 5 to 10 Mbps (3 Mbps Min)
5620 SAM Server to a 5620 SAM Client 512 Kbps per client
5620 SAM Server to a 5620 SAM-O Client ( The bandwidth will

1 Mbps per client
depend on the OSS application)
Between a primary and a standby 5620 SAM Server (*) 1 Mbps
5620 SAM Server to a 5620 SAM Auxiliary 1 Mbps
6 Mbps ( 3 Mbps minimum)
Between primary and secondary SAM database 15-25Mbps Peak(during re-

instanciation or DB backup
synchronization)
NBI interface per GUI and OSS system >3 Mbps
Table 44 : OAM SAM Bandwidth Dimensioning Elements
(*) distributed configuration

3.3.2.3 SAM SCALING GUIDELINE FOR CALL TRACE
5620 SAM provides the ability to collect call trace and debug trace files from eNodeB
network elements through the use of 5620 SAM Auxiliary Call Trace Collector
workstations.
Call Trace scale support in 5620 SAM is dependent upon the following dimensions:
 The network bandwidth required between the 5620 SAM Auxiliary Call Trace
server and the eNodeB. This will be determined by the size of the call Trace
files and the frequency in which they are collected.
 The network bandwidth required between the Preferred 5620 SAM Auxiliary
Call Trace server and the Reserved 5620 SAM Auxiliary Call Trace server.
 The network bandwidth required between the Preferred 5620 SAM Auxiliary
Call Trace server and the WTA.
 Disk I/O on the 5620 SAM Auxiliary Call Trace server.

 Disk space on the 5620 SAM Auxiliary Call Trace server to meet the retention
requirements.
Call Trace Scaling guidelines are based upon the FDD Outdoor call model (described
in Section 2.2.1.1.1) which uses a traffic mix of 50% data and 50% voice.
A pair of 5620 SAM Auxiliary Call Trace Collector workstation can collect up to 50 call
traces and two dynamic debug traces at a time. A call trace, in this context, represents
the data collected from a single 3 cell eNodeB with 100 calls.
Page 112/273
3.3.2.3.1 DISK SPACE REQUIREMENTS FOR CALL TRACE AND DEBUG

TRACE
Call Traces and debug Traces retrieved from eNodeB are stored as files on the 5620
SAM Auxiliary Call Trace Collector.
The table below lists the required disk space to store one hour worth of Call Trace and
Debug Trace data from a single 3 cell eNodeB with 100 calls. The disks containing the
call trace and debug Trace data must be configured with RAID.
Disk space requirement with trace collection

for single 3 Cell eNodeB with 100 calls for 1 Required Disk space
hour of Data
Call Trace 650 MB
Debug Trace 9200 MB
Table 45 : Disk Space Requirement for Call Trace
Page 113/273
3.3.3 OVERVIEW ON NPO PLATFORM

9959 NPO monitor and optimize the performance of the radio access part of their
wireless networks. The 9959 NPO is available for GSM/EDGE, W-CDMA/HSPA and
LTE radio access technologies.
From collection of performance measurements to identification of problems and

solutions, 9959 NPO helps wireless service providers to:
Efficiently store,
post process,
analyze the vast amount of data collected by the network elements.

As a result, the 9959 NPO is able to characterize the behavior of - the RAN elements
and end-user devices in order to improve the efficiency of the network and maintain
the high quality of service required to meet subscriber’s expectations.
9959 NPO Release 4.1 R7 offers a full range of multi-standard QOS Monitoring and
radio network optimization facilities:
 QOS analysis
 QOS decrease cause diagnosis
 Radio resource configuration tuning
 Cartographic telecom management
 Manage hardware inventory
 Customizing.
9959 NPO Release 4.1 R7 supports the OMC managing:

 LTE network (SAM)
 GSM network (OMC-R)
 WCDMA network (WMS)
3.3.3.1 NPO SOFTWARE PERFORMANCE
LTE NPO supports post-process of performance-management data generated by the

eNodeB(s) and the MME.
1 NPO for 1 SAM is the only supported case.
1 NPO supports MME (no maximum number).
The NPO supports GSM, W-CDMA, WiMAX and LTE Radio Access Networks (RAN).
The NPO supports simultaneously 2 Radio technologies on the same machine in the 3
following configurations:
 2G + 3G or,
 3G + 4G or,
 2G + 4G
Page 114/273
The NPO supports 2 technologies (2G or 3G or 4G) simultaneously in LA6.0
Counters
Description Format Protocol polling period
name
Counters values observed on the 3GPP XML
eNodeB PM FTP every 5 min
eNodeB R5
3GPP XML
MME PM Counters values observed on MME FTP every 15 min
32.401 R5
Description of network configuration every day at
NPO CM (Periodic QoS analysis scripts) CM XML FTP
0:30 AM
3GPP XML every 15 min
Other nodes Counters observed on SNMP
TS 32.401 SNMP (Not activated
PM interface
R5 by default)
Table 46 : NPO Performance for LA5.0
3.3.3.2 NPO HARDWARE CAPACITY FIGURES ON HP PLATFORMS
9959 NPO is a client/server application which server runs on HP server technology.

Three architectures are foreseen:
 Small server: The based hardware is the HP DL 380 (1 CPU) server.
 Medium server: The based hardware are the HP DL 380 (2 CPU) server
 Large configuration: The based hardware are the HP DL 580 G7 server
9959 NPO provides options that impact the hardware configuration as Auxiliary
server: the HP DL 380 (2 CPU) for :
 NPO with PCMD option (for LTE): is used for the processing of the PCMD
data coming from MME.
 NPO with WCT option (for WCDMA): is used for the processing of the
CTN/CFT call trace data coming from RNC (via WMS).
 NPO additional server for QoS
For more details on NPO HW Architecture and supported configurations please refer
to [C03].
The NPO scalable platform model depends of the maximum number of weighted Cell
for each wireless technologies given by :
Cell = [0.75* nb of 2G cells + 1 * nb of 3G cells + 1 * nb of 4G Cells]
Page 115/273
DL 380 DL 380 DL 580 G7

(Small) (Medium) (X-Large)
Max # simultaneous 7 (QoS + PCMD)
NPO Users 45 (QoS + PCMD) 120 (QoS + PCMD)
15 (if QoS only)
1000 eNodeB 4000 eNodeB 16000 eNodeB
Max # of NEs
3000 cells (if QOS only) 12000 cells 48000 cells
Max # of Cells
1500 cells (QOS + PCMD)
PM collection
granularity
15 minutes 15 minutes 15 minutes
period
(NE counters)
1- Monthly indicators 1- Monthly indicators 1- Monthly indicators
25 months 25 months 25 months
PM, FM, CM & 2- Daily & Weekly 2- Daily & Weekly 2- Daily & Weekly
HW/SW indicators indicators indicators
inventory data 400 days 400 days 400 days
Storage 3- Hourly indicators 3- Hourly indicators 3- Hourly indicators
Duration + ¼ indicators + ¼ indicators + ¼ indicators
period 32 days 32 days 32 days
(4G) 4- Raw PCMD and 4- Raw PCMD and 4- Raw PCMD and
Call trace Call trace Call trace
7 days 7 days 7 days
1 Main server 1 Main server 1 Main server
1 DL380 G7 DL380 G7 HP DL580 G7
- 1 CPU - 2 CPU - 4 CPU
- 36 GB RAM - 72 GB RAM - 256 GB RAM
Hardware
- 3,6TB (12*300GB) - 10,8TB Disk on: - >28,8TB Disk on:
Servers
HD  3,6TB (12*300GB) HD  6*120GB HD
CPU + 1 HP 2600 Storage + 4 HP 2600 Storage
RAM  7,2TB(12*600GB)  28,8TB(4*12*600GB)
Internal Disk
External Storage + 1 Auxiliary server option + 1/2/3 Auxiliary servers options
for WCT or PCMD for QoS, WCT or PCMD
HP DL380 G7 HP DL380 G7
- 2 CPU - 2 CPU
- 36GB RAM - 36GB RAM
- 3,6TB (12*300GB) HD - 3,6TB (12*300GB) HD
9300 W
1348 W 2700 W (DL580 1161W-100VAC or
Power DL380 930W-100VAC or 2 DL380 930W-100VAC or 1598W-200/240VAC
1348W-200/240VAC) 1348W-200/240VAC + 4 ST2600 2* 285W-100VAC or
consumption + ST2600 2* 285W-100VAC or 2* 460W-200/240VAC
2* 460W-200/240VAC) + 3 DL380 930W-100VAC or
1348W-200/240VAC)
6U 18U
Total Height 2U (2* 2U DL380
(4U DL580
DL380 8U Disk storage
2U Disk storage)
3*2U DL380)
Table 47 : NPO Capacity Figures in LA5.0 on HP Machines
Page 116/273
3.3.3.3 DESCRIPTION OF THE NPO INTERFACES
The NPO server is communicating with the other systems through specific
interface presented in the Figure 27 .These interfaces has specific functions and
use dedicated protocols and are described in the following:
 Interface (a) used on the NPO Auxiliary server to communicate with the
eNodeB Network Elements .The traffic carried over this interface is SSH and
SFTP protocol used to download the PM files.
 Interface (b) used on the NPO. Auxiliary server to communicate with the
MME Network Elements .The traffic carried over this interface is SSH and
SCP protocol used to download the PCMD files.
 Interface (c) used between the NPO Auxiliary server and the NPO main
server .The traffic carried over this interface is CORBA for synchronization
between the servers and SFTP protocol used for the PM and PCMD file
download. .
 Interface (d) is used between the NPO client and the NPO main server .the
traffic carried over this interface use HTTPS and CORBA protocol.
Figure 27 : NPO Network Interface
Page 117/273
3.3.3.4 NPO NETWORK BANDWIDTH DIMENSIONING
The OAM servers including NPO must be located within the same Ethernet LAN that
operates at Giga bits Ethernet and the 1000 Mbps capabilities should be extended to
all the Routing Switch. This requirement covers:
 Communication between NPO main server and auxiliary server

Communication between NPO and SAM.
Recommended bandwidth
Between the NPO server and the
1 Mbps is minimum required
NPO client through Citrix solution
Between the NPO server and the
100/1000 Mbps
NPO client
(Only when PCMD option is used)
NPO auxiliary with MME PCMD file: 250 MB at BH (per minute, per MME)
Bandwidth : 4MB/s/MME (at BH)
PM file: 180 kBytes/eNB (3 cells/eNB, uncompressed)
NPO auxiliary and SAM server
So 3.4 Mbytes/s for 48K cells updates every 15mn
NPO auxiliary with NPO main 1 Gb/s dedicated Ethernet assumed. Needed for high speed
server data loading in NPO database.
Table 48 : NPO OAM Bandwidth Requirement
Page 118/273
3.4 MME DIMENSIONING

3.4.1 MME CONFIGURATION & CAPACITY
The 9471 MME WM6.0 configuration is a scalable configuration that includes one or
two ATCA chassis and from one to ten pair of MAF blades. The minimum
configuration consists of a single chassis with one active MAF blade (one MAF blade
pair). The maximum configuration consists of two chassis with ten MAF blade pairs.
The first ATCA chassis can hold up to four MAF blade pairs. The second ATCA
chassis must be added/used when a fifth MAF blade pair is needed. The two MAFs in
a MAF blade pair must be populated in adjoining odd/even slots, but pairs do not have
to be populated sequentially within the chassis.
Pooling/grouping is also supported in WM6.0. There can be up to eight 9471 MME

pools in the network with a maximum of 8 MME(s) per pool.
WM6.0 hardware includes:

 1 – 2 ATCA chassis
 1 – 2 pair: Shelf Management Controllers (ShMC’s), 1 pair per ATCA chassis
 1 pair: OAM Server blades, on shelf 0 (16G RAM, 300G HDD)

 1 – 2 pair: Ethernet Hubs, 1 pair per ATCA chassis (w/ HSPP4 AMC hosting
MPH service on shelf 0)
 1 pair: Optical RTMs, on shelf 0 hubs

 1 pair: MME Interface Function blades (MIF) w/ SS7 AMC & SS7 RTM
 1 – 10 pair: MME Application Function blades (MAF) w/ HSPP4 AMC
 Unused slots are filled by front and rear fillers
Page 119/273
MME WM6.0.0 MME WM6.0.0

Minimum Configuration: Maximum Configuration:
•PDU •PDU
Shelf 1
ShMC
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
ShMC
HUB
HUB
RTM
RTM
RTM
RTM
RTM
RTM
RTM
RTM
Shelf 0 Shelf 0
ShMC
ShMC
OAM Server
OAM Server
OAM Server
OAM Server
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MAF
MIF
MIF
MIF
MIF
HUB/MPH
HUB/MPH
HUB/MPH
HUB/MPH
ShMC
ShMC
Figure 28 : 9471 MME WM6.0 Hardware Configurations
For additional details regarding MME hardware and software architecture, please refer
to: [C04] and [C06].
For additional details regarding MME supported configurations, please refer to: [C05].
The 9471 MME WM6.0 has been designed to work efficiently within the limits shown in
Table 49 below. These limits are based on customer input and engineering judgment
for WM6.0.
The table shows the limits for a fully configured MME. Code has been developed and
tested to work within these limits. In particular, the provisioning GUI and associated
databases have been designed using these capacities.
The GUI will not allow a user to exceed these capacities. Please note that BHCA is
dependent upon the call model. Therefore a strict maximum BHCA cannot be quoted
per release.
Capacity Parameter WM6.0

Maximum number eNB 12000
Maximum number TAs 1024
Page 120/273
Capacity Parameter WM6.0

Maximum number eNBs paged for a single paging event 180
Maximum number MME pools 8
Maximum number MMEs per pool 8
Maximum number S-GW pools 16
Maximum number S-GWs per pool (manual provisioning) 16
Maximum number S-GWs per pool (using DNS) 80
Maximum number P-GWs per MME 40
Maximum number PLMNs (home, shared, equivalent, roaming) 512
Maximum number registered users per MME 5,000,000
Maximum number registered users per MAF pair 500,000
305,000 msg/sec
Maximum external message throughput per MME (MPH)
(150K in & out)
305,000 msg/sec
Maximum message throughput per MIF Board pair
(150K in & out)
40,000 msg/sec (20K
Maximum message throughput per MAF Board pair
in & out)
Maximum number of bearers per UE (any combination of default &
11
dedicated)
Average number of bearers per UE (any combination of default &
4
dedicated)
Maximum number of APNs 6
Maximum number of P-GW IP addresses in HSS 6
Maximum message throughput to/from HSS 15,000 msg/sec
Maximum number of MIF Board pairs (for MME-only configuration) 1
Maximum number of MAF Board pairs 10
Table 49 : MME WM6.0 Capacity Figures (for Maximum Configuration)
Rule: MME Configuration Rule
In WM6.0, additional MAF boards may be added to accommodate increased capacity. The two MAFs
in a MAF blade pair must be populated in adjoining odd/even slots, but pairs do not have to be
populated sequentially within the chassis.
Rule: MAF Capacity Limits
An individual MAF pair can support up to 40K external message per second and up to 500K registered
users.
Capacity extension actions include adding an additional MAF pair to the MME until the 10-pair limit is
reached.
Rule: Hardware Capacity Limits
The LTE network must be architected such that the above capacity limits (
Table 49) are not exceeded for an individual MME. The SAM Provisioning GUI will not allow
provisioning beyond these capacity limits.
Capacity extension actions include adding an additional MAF pair to the MME until the 10-pair limit is
Page 121/273
reached.
Rule: Tracking Area Code Limit
The LTE network must be architected such there are not more than 1024 TAs in the network. The
SAM Provisioning GUI will not allow provisioning beyond this capacity limit.
Large networks must be divided into sets of MME groups where one set does not know about the other
set(s).
Page 122/273
3.4.2 MME CALL MODEL OVERVIEW

The 9471 MME WM6.0 supports the external interfaces as shown in the figure below.
There are no new interfaces for WM6.0.
SBc-AP
GMLC SCTP
IP CBC
DIAMETER (ELP) SLg GigE
SCTP AAA /
IP SBc 5620 SAM
HSS
GigE ADMF
S1-AP E-SMLC X1_1 DIAMETER
SCTP SLs SNMPv3 SCTP
IP DF2 IP
Provisioning
GigE via XML GigE
LCS-AP S6a
X2_IRI EIR
SCTP
94xx/99xx S1-MME IP
GigE DIAMETER
eNB SCTP
M3 9471 MME S13 IP
M3-AP GigE
SCTP 9471 MME
IP GTP-c (GTPV2)
GTP-c (GTPV1) S11 UDP
UDP GigE
S10 Sm SGs IP
IP Gn GigE
GigE S3 GTP-c (GTPV2) Sv SGW /
UDP
GTP-c (GTPV2) PDN-GW
IP
UDP
wCDMA
GigE
IP MSC
SGsAP
GTP-c (GTPV2) GigE GTP-c (GTPV2)
SGSN MBMS SCTP
UDP UDP IP
IP GW IP GigE
GigE GigE
Figure 29 : 9471 MME Signaling Interfaces for WM6.0
In LE6.0, user traffic is expected to be a mix of best effort data, CSFB voice, and
CSFB SMS as shown in Table 50. The Alcatel-Lucent LE6.0 end-to-end network
solution also supports VoIP and GBR data call types.
Expected Value Per Attached

Call Model Parameter Subscriber @ Busy Hour
CSFB (50% data, 50% smart phones)
VOIP 0.90 BHCA
SMS 2.90 BHCA
Best Effort Data 16.10 BHCA
GBR Data (VT, RT-gaming) 0.17 BHCA
Table 50 : Call Model Parameters for MME Dimensioning
Page 123/273
The following table shows a capacity & dimensioning calculation using the call model
presented in Chapter 2.2.1.1 as an example. The “MME Procedure” column
represents the unique mix of procedures that affects busy hour in the example. The
“MME Message Count/ Event” column is constant for the set of procedures shown.
MME Message Count/ Event values could be updated if call model analysis of a user
call model showed a different mix of MME procedures affecting the busy hour. The
operator can also tailor this calculation to a different call model by substituting different
values in the “Events/ Subscriber/ Busy Hour” column of the table.
CSFB
MME
MME Procedure Message Events/ Total Messages/
Count/ Event Subscriber/ Busy Subscriber/
Hour Busy Hour
Attach (Session Setup) 21 0.12

2.52
Detach (Session
12 0.12
Release)
1.44
PDN Session Request 10 0.13
1.30
Connection Request 16.27 Data +
14
(Setup & Release) 3.4 CSFB
275.38
Inter-eNB Handover 8 7.6
60.80
Inter-RAT Mobility 16 2.4
38.40
Tracking Area Update 8 2.0
16.00
Paging – MME on
terminating call event 25.5 4.27
(Data)
108.89
Paging – MME on
2.03 SMS +
terminating call event 31
0.54 Voice
(SMS + Voice)
79.67
Total 584.40
Table 51 : MME WM6.0 Message Load Estimates

The call models yield a total of 584.40 messages/ subscriber/ busy hour for the CSFB
call model. This figure is then used in the following equation to yield the maximum
number of subscribers supported by this model:
“Total Messages/Subscriber/BH” x Nsubs / 3600 = “Total Messages/Second”
In WM6.0, each MAF pair is able to support at least 40K msg/sec without pushing the
CPU into overload. The total message throughput for the MME is limited to 305K
msg/sec. The equation above shows that the CSFB call model allows support for
approximately 246,400 subscribers per MAF pair and approximately 1.88 million
Page 124/273
simultaneous subscribers per MME without exceeding the WM6.0 message

throughput limits.
3.4.3 MME PAGING RATE

Paging rate at the MME is determined by the number of eNBs paged per MME
terminating call.
For UEs in all data calls (not VoLTE, not CSFBvoice, not CSFBsms), the currently
implemented MME paging strategy is expected:
 First page: Last seen eNB (= 1 eNB)
 Second page: Last seen TA (= ~50 eNBs * 15%)

 Third page: TA list (= ~60 eNBs * 8%)
The result is about ~13.3 eNBs paged per MME data terminating call.
The full TA list needs to be paged for the voice terminations (Voice CSFB and
VoLTE). With this strategy, the third page may not be provisioned. The average TA list
is expected to be approximately 60 eNBs. For VoIP calls this results in:
 First Page TA list (= 60 eNBs)
 Second Page: TA list (= 60 eNBS * 7%)
The result is 64.2 eNBs paged per voice (VoLTE and CSFBvoice) terminating call.
Pages for CSFBsms terminations are expected to use a different paging strategy:
 First Page Last seen eNB (= 1 eNB)

 Second Page: TA list (= ~60eNBS * 15%)
The result is 10 eNBs paged per CSFBsms terminating call.
The traffic assumptions on CSFB used for paging on data are 16.10 nonGBR BHCA
and 0.17 GBR BHCA have respectively 26% and 14% termination percentage, which
equals to 4.2 terminations. The CSFB-SMS 2.9 BHCA has a termination percentage of
70% which results in 2.03 terminations. The CSFBvoice 0.9 BHCA has a termination
percentage of 60% which results in 0.54 terminations. The total eNBs paged = 13.3
eNBs * 4.2 (data) + 10 eNBs * 2.03 (CSFB-SMS) + 64.2 eNBs * 0.54 (CSFB voice) =
111 eNBs. To compute the weighted average per terminating BHCA, 111 eNBs / (4.2
+ 2.03 +.54) = 16.4 eNBs paged for all services termination. Note that there are 2
additional messages required for handling the UE response to the page request so the
average messages per page attempt is 18.4.
Page 125/273
3.5 LTE EUTRAN INTERFACES DIMENSIONING

This section is aimed to provide an overview of E-UTRAN functional interfaces, which
builds up the LTE Access Network, from a dimensioning perspective, as it provides
guidelines about how to assess the bandwidth at E-UTRAN interfaces level.
3.5.1 EUTRAN INTERFACES OVERVIEW

From a functional perspective, the eNodeB has two functional interfaces, namely
Telecom and Management interfaces.
Telecom interface supports:
 User traffic with is exchanged between the eNodeB and the S-GW (S1-U) or
between neighboring eNodeBs (X2-U).
 Control traffic with is exchanged between the eNodeB and the MME (S1-
MME) or between neighboring eNodeBs (X2-C).
Details about S1 and X2 interface can be found in section 2.1.3.4.
Management interface supports:
 OAM traffic exchanged between the eNodeB and the Element Management
System (EMS). In the scope of this document, E-UTRAN OAM traffic
dimensioning requirements are described in section 3.3.
 Call trace traffic between the eNodeB and the EMS.
 Standalone PCMD traffic between the eNodeB and the standalone PCMD
collection entity (PCMD applies to Alcatel-Lucent MME only).
 The dynamic debug trace (DDT) between the eNodeB and the DDT collection
entity
In the scope of this document, above mentioned OAM, call trace, PCMD and
DDT traffic dimensioning requirements are described in section 3.3.
 1588 traffic exchanged between the eNodeB and the Master Clock Server.
Depending upon the E-UTRAN transport architecture, eNodeB functional traffic can be
split over different logical interfaces, for the purpose to differentiate and direct the E-
UTRAN traffic to target network elements which are different (neighboring eNodeBs,
MME, S-GW, EMS, etc). eNodeB functional traffic split is performed at layer 2 by
means of virtual LAN feature (Vlan tagging is optional), and at layer 3 by means of
setting up the IP address of network element which are involved in E-UTRAN
transport. Note that E-UTRAN transport architecture is not in the scope of this
document, please refer to transport engineering guide for details about the E-UTRAN
transport architecture [C07].
Please note that since the MME and S-GW aggregate traffic coming from numerous
eNodeBs, S1- MME and S1-U bandwidth requirements at MME and S-GW level must
take into account the number of connected eNodeBs to assess the aggregate
Page 126/273
bandwidth at E-UTRAN interfaces level. The same remark applies to X2 interface and
to OAM traffic, as a single EMS will connect to numerous eNodeBs.
The figure below illustrates E-UTRAN traffic split towards backhaul transport network.
e-UTRAN Backhaul
MME
S1
S1 S1-MME
X2
OAM
e-UTRAN
S1-U S-GW
S1
X2
X2
OAM
e-UTRAN
OAM
S1
OAM OAM
X2
OAM
Figure 30 : E-UTRAN Traffic Split
3.5.2 EUTRAN DIMENSIONING PROCESS

E-UTRAN dimensioning process relies upon the followings steps:
 E-UTRAN dimensioning process is to be carried out initially, or when
extension to the existing network needs to be performed or because of user
traffic increase.
 Select or customize the traffic model which represents the traffic parameters
which characterize the UE activity from user and control plane perspective at
the busy hour. The traffic model provides relevant inputs which enable per
eNodeB interface bandwidth computation based on various traffic types which
can be supported at UE / eNodeB level (VoIP traffic, GBR traffic, non-GBR
traffic, control & signaling traffic). As the user distribution and concentration
can be different from one region to another, per region traffic model might
need to be estimated in order to accurately assess the E-UTRAN interfaces
bandwidth. The E-UTRAN interfaces required bandwidth for a specific
eNodeB has to be computed based on customer traffic model which applies to
this specific eNodeB, if applicable.
Page 127/273
 Apply the traffic model to the eNodeB E-UTRAN interfaces (S1-U, S1-MME,
X2-U, X2-C) and per traffic type (VoIP traffic, GBR traffic, non-GBR traffic,
control & signaling traffic, Management) in order to assess E-UTRAN
respective functional interface required bandwidth. With the following
additional inputs:
 Vlan tagged layer 2 Ethernet backhaul is off or on.
 IPv4 or IPv6 layer 3 backhaul network.

 Trusted or non trusted backhaul network.
eNodeB traffic can be carried over a trusted backhaul network. LTE

network operator will likely send eNodeB traffic over IP network
without encryption and authentication.
eNodeB generated traffic can be carried over a non-trusted network.

LTE network operator will likely send eNodeB traffic over an
authenticated and encrypted IPSec tunnel. Figure 31 below
represents the two modes of operation for the transport of the
eNodeB traffic.
 Per eNodeB interface resulting bandwidth figures can be used to assess the
E-UTRAN backhaul throughput figures towards neighbor eNodeB(s) and EPC
network element (MME and S-GW).
Please note that the following sections provide bandwidth assessment example based
on the reference traffic model which is described in Table 3 and Table 4.
Please note that interfaces bandwidth computations which are described in this
section, show an uplink (UL) and downlink (DL) part. The reasons behind are: uplink
and downlink traffic bandwidth are different for many services carried over the E-
UTRAN interfaces, uplink / downlink traffic split can be required to dimension the
overall layer 2 Ethernet backhaul network, which can further operate full of half duplex.
 Full-duplex configuration: Most significant bandwidth figure needs to be

considered.
 Half duplex configuration: Uplink + Downlink bandwidth figures needs to be

considered.
3.5.3 IPSEC CONSIDERATIONS

The eNodeB supports IPsec tunnel mode i.e E-UTRAN backhaul network supports so
called “host-to-network” IPsec security configuration, i.e the eNodeBs are the hosts
connected to the network Security Gateway (SEG), as depicted in Figure 31. Indeed
eNodeB will generate the IPSec traffic at the source and establish the IPsec tunnel
with the remote security gateway.
Page 128/273
Figure 31 : E-UTRAN security architecture

IPsec tunnel mode is the only IPsec security mode to be supported at eNodeB level.
This security mode adds complementary header to each packet which has to flow
through the E-UTRAN backhaul network. The complementary header size depends
upon the authentication and encryption methods. There is a maximum 72 (IPv4) / 88
(IPv6) overhead bytes to be added to the packet assuming AES-CBC-128 and HMAC-
SHA1-96 tunnel mode and ESP encapsulation is used. IPsec tunnel and ESP
encapsulation overhead are depicted in the figure below:
IP header
Payload
(inner IP)
IP header Initialization Padding Next

ESP header Payload data Padding Integrity data
(outer IP) vector length header
20 bytes IPv4 8 bytes 16 bytes 0/14 bytes IPv4 2 bytes 12 bytes

(HMAC-SH11-96)
40 bytes IPv6 0 /10 bytes IPv6
Figure 32: IPsec overhead header
3.5.4 S1 INTERFACE DIMENSIONING

This section provides details about S1 interface dimensioning and engineering rules.
S1-U and S1-MME dimensioning methods differ, since the type of traffics carried over
these interfaces are different. From a backhauling perspective, overall S1 bandwidth
equals to S1-U + S1-MME.
Page 129/273
3.5.4.1 S1 INTERFACE PROTOCOL STACK
S1-U is the reference point between E-UTRAN and the EPC Serving GW (S-GW) for
the per bearer user plane tunnelling and inter eNodeB path switching during handover.
S1-U protocol stack is depicted in the figure below.
UE eNodeB S-GW
User App
TCP, UDP, …
IP (user) IP (user) IP (user)
GTP-U GTP-U
PDCP PDCP UDP UDP
RLC RLC IP (path) IP (path)
MAC LTE-Uu MAC IPsec/UDP/IP S1-U IPsec/UDP/IP
PHY (L1) PHY (L1) PHY (L1) PHY (L1)
Figure 33 : S1-U Protocol Stack

S1-MME is the reference point for the control plane protocol between E-UTRAN and
the EPC Mobility Management Entity (MME). S1-MME protocol stack is depicted in the
figure below.
Page 130/273
UE eNodeB MME
NAS Relay NAS
RRC RRC S1-AP S1-AP
PDCP PDCP SCTP SCTP
MAC LTE-Uu MAC IPsec/UDP/IP S1-MME IPsec/UDP/IP
Figure 34 : S1-MME Protocol Stack
3.5.4.2 S1 INTERFACE IP TRANSPORT HEADERS
Detailed S1 bandwidth figures depends upon the IP transport stack and the resulting
headers which must be added to the application protocol, according to the backhaul
network architecture. Referring to the S1- U and S1-MME protocol stack described
above, the followings parameters need to be taken into consideration when assessing
the physical bandwidth at S1 interface:
 S1-U / S1-MME protocol header size. Please see details below.
 Transport layer architecture (plain IP or secured IP with encryption &

authentication and tunneling). Please see details in section 3.5.3.
 Layer 2 technology.
eNodeB, MME and S-GW transport layer 1/2 relies upon Ethernet / IEEE
802.3 with optional IEEE 802.1q Vlan tagging capability.
802.3 frame header: 18 bytes (DA/SA/Lengh_Type/FCS)
802.1q Vlan tag: 4 bytes
QinQ tag adds 4 bytes.
 Layer 1 technology (Ethernet / IEEE 802.3).
Start Frame Delimiter (SFD): 1 byte

Frame Preamble: 7 bytes
Inter-Packet Gap (IPG): 12 bytes
S1-U IP transport headers

The table below provides a summary of headers to be accounted for various IP
transport stack configurations.
Page 131/273
Header (3)
IPsec IP VoLTE
Size Phy Vlan 802.3 UDP GTP-U
ESP/IP (path) RTP/UDP/IP
(bytes)
S1-U
(1) (2)
Voice 20 4 18 72 20 8 8 12+8+20
IPv4
S1-U
20 (1) 18 20 8 8 NA
4 72 (2)
Data IPv4
S1-U
20 (1) 18 40 8 8 12+8+20
Voice 4 88 (2)
IPv6
S1-U
20 (1) 18 40 8 8 NA
4 88 (2)
Data IPv6
Table 52: S1-U Transport Headers and Size details
Note 1: Optional Vlan tagging
Note 2: Optional IPsec, please check details in section 3.5.3.
Note 3: S1-U bandwidth computation takes into account the type of services which are
supported by the traffic model. For each service, the bandwidth which is calculated at
application layer needs to take into consideration the overhead with results from the
transport backhaul. The headers which are added to the application packet depend
upon the application itself. For VoIP traffic, the application packet is encapsulated
inside a RTP/UDP/IP packet prior to be forwarded to the transport layer (GTP-U).
Thus additional 12 + 8 + 20 = 40 bytes of RTP/UDP/IPv4 header bytes have to be
added to the initial application packet prior to add the transport backhaul overhead.
This rule does not apply to GBR traffic, though GBR traffic might be transported over
RTP/UDP/IP, it is assumed this overhead is already accounted for in the traffic volume
figures which are given in the reference traffic model of Table 4. For non GBR traffic
such as for example web browsing type of application, the application packet is
already an IP packet, which is then directly forwarded to the transport layer, where the
transport backhaul overhead is added.
Several transport header combinations are thus possible depending upon the
transport backhaul architecture, this leads to different IP transport header sizes.
Examples of possible configuration are given below (non exhaustive list):
 IPv4 w/o IPsec w/o Vlan (GTP-U/UDP/IP/Ethernet/Phy)
 IPv4 w/o IPsec w Vlan (GTP-U/UDP/IP/Ethernet/Vlan/Phy)
 IPv4 w IPsec w/o Vlan (GTP-U/UDP/IP/IPsec)/Ethernet/Phy)

 IPv4 w IPsec w Vlan (GTP-U/UDP/IP/IPsec/Ethernet/Vlan/Phy)
Page 132/273
 IPv6 w/o IPsec w/o Vlan (GTP-U/UDP/IP/Ethernet/Phy)

 IPv6 w/o IPsec w Vlan (GTP-U/UDP/IP/Ethernet/Vlan/Phy)
 IPv6 w IPsec w/o Vlan (GTP-U/UDP/IP/IPsec/Ethernet/Phy)
 IPv6 w IPsec w Vlan (GTP-U/UDP/IP/IPsec/Ethernet/Vlan/Phy

The table below summarizes the different overhead header size according to the E-
UTRAN backhaul transport architecture (S1-U).
E-UTRAN
backhaul
802.3 802.3 w 802.1q 802.3 w IPsec 802.3 w 802.1q w IPsec
architecture
(bytes)
S1-U IPv4 74 78 146 150
S1-U IPv6 94 98 182 186
Table 53 : Aggregate S1-U Transport Header Size details

Note: The table above assumes that when IPsec is in use, inner IP version and outer
IP version are assumed to be the same (IPv4 or IPv6).
S1-MME IP transport headers
The same rules apply to S1-MME. The tables below provide a summary of headers for
various IP transport stack configurations (S1-MME).
Header Phy Vlan 802.3 IPsec IP SCTP
Size (bytes) ESP/IP

(1) (2)
S1-MME IPv4 20 4 18 72 20 28
(1) (2)
S1-MME IPv6 20 4 18 88 40 28
Table 54: Aggregate S1-MME Transport Headers and Size details

Note 1: Optional Vlan tagging
Note 2: Optional IPsec, please check details in section 3.5.3
The table below summarizes the different overhead header size according to the E-
UTRAN backhaul transport architecture.
Page 133/273
E-UTRAN
backhaul 802.3 802.3 w 802.1q
802.3 802.3 w IPsec
architecture w 802.1q w IPsec
(bytes)
S1-MME IPv4 86 90 158 162
S1-MME IPv6 106 110 194 198
Table 55: Aggregate S1-MME Transport Header Size

Note: The table above assumes that when IPsec is in use, inner IP version and outer
IP version are assumed to be the same (IPv4 or IPv6).
3.5.4.3 S1-U INTERFACE DIMENSIONING
The maximum S1-U throughput in downlink and uplink is computed by taking into
account the maximum user plane traffic for the maximum number of attached
subscribers at the busy hour. S1-U bandwidth computation process uses the input
from the traffic model (either Alcatel-Lucent traffic model or customer specific traffic
model), taking into consideration the backhauling network specific architecture. The
figure below depicts this procedure.
Figure 35: S1-U Bandwidth Computation

Traffic model to be used is given in section 2.2.1.1.1. Please note that depending
upon the traffic model some service might not be taken into consideration for S1-U
bandwidth computation. This is the case for example when using a traffic model with
Circuit Switch Fall Back (CSFB) capability, where VoIP service is not taken into
consideration at S1-U interface level.
The Peak to Average ratio (PtA), is an overflow factor that is used to estimate the
equivalent bandwidth for a set of variable bit rate calls. For packet based type of calls,
it has been shown that there is a concept of equivalent bandwidth associated with
calls, the equivalent bandwidth being a number somewhere between the mean and
the peak bandwidth requirement for that call, say K. If a link or a buffer has size C,
then N calls of this type can be accepted at the resource level (buffer or transport
Page 134/273
interface), while maintaining specified grade of service, provided that N x K < C.

Indeed K is the equivalent bandwidth for this type of packet based call, from a
bandwidth reservation perspective.
Equivalent bandwidth (i) = PtA(i) * Mean bit rate.

PtA applies to non GBR service, with the assumption average (or mean) bit rate is
computed from the traffic model. The picture below illustrates the concept of PtA.
Further details about PtA can be found in reference [C08] and [C09].
Figure 36: Equivalent bandwidth computation

Nml: Nominal bandwidth for a service type (VoIP, GBR, non-GBR).
Transport backhaul configuration determines the S1-U transport header size. Various
transport backhaul configuration and corresponding header size are given in section
3.5.4.2 above.
3.5.4.3.1 S1-U BANDWIDTH COMPUTATION
The required S1-U bandwidth is computed according to the following formula:
eNB_S1U_Throughput_Phy_DL/UL =
eNB-S1U_Non_GBR_Throughput_Phy_DL/UL +
eNB_S1U_VoIP_Throughput_Phy_DL/UL +
eNB_S1U_GBR_Throughput_Phy_DL/UL
Depending upon the traffic model, some parts of the above formula are not
considered. This is the case for CSFB traffic model with 100% circuit switch fall back,
where voice service is not carried over the LTE radio access network, but over the 2G
/ 3G radio access network instead.
At S1-U interface level, VoIP and GBR services require bandwidth reservation to
ensure quality of service objectives are met, while non GBR service gets the
remaining part of the aggregate S1-U interface available bandwidth. The figure below
depicts this bandwidth reservation rule.
Page 135/273
Figure 37: S1-U bandwidth assignment depending upon service types
3.5.4.3.1.1 NON-GBR SERVICE BANDWIDTH COMPUTATION
eNB_S1-U_Throughput_Non_GBR_Phy(DL/UL) is basically the equivalent bit rate for

non GBR service, which is a non-guaranteed variable bit rate, to be used for
application such as web browsing, email, etc. The equivalent bit rate is the amount of
bandwidth which is required at the S1-U interface, in order to provide acceptable
grade of service to non GBR services. This is illustrated by the figure below.
Overflow factor (PtA)
interface required
bandwidth
NSubs * User Throughput
Figure 38 : Non GBR service required bandwidth to meet GoS expectations
eNB-S1U_Non_GBR_Throughput_Phy_DL/UL is computed according to the following

formula:
eNB_S1-U_Throughput_Non_GBR_Phy_DL/UL = PtA_B x N_Subs x

Avg_BR_Phy_DL/UL
 PtA_B is the peak to average ratio to apply at the backhaul. PtA is described
in section 3.5.4.3 above. PtA_B is slightly different from PtA_Air (the value in
use at the air interface). The backhaul link rate is higher than the air interface,
PtA_B is less restrictive than PtA_Air. PtA_B value may be provided as part of
the traffic model, or a standard value can be used instead.
 N_Subs is the number of active subscribers per eNodeB at the busy hour
(refer to Table 5 of section 2.2.1.1.1)
 Avg_BR_Phy_DL/UL is the average bit rate for non GBR service.

Avg_BR_Phy is computed as follows:
Avg_BR_Phy_DL/UL(per Sub) =
[Volume_at_BH_(DL/UL) x 8 / 3600] x [1 + %_Transport_Overhead]
Page 136/273
 Volume_at_BH_(DL/UL) is an input from the traffic model (refer to Table 4 of

section 2.2.1.1.1), it represents the aggregated number of bytes which are
exchanged for non GBR service at the busy hour. Note that uplink and
downlink figures are different.
Volume_at_BH_(DL/UL)= (Non_GBR_BHCA x Non_GBR_BHCA_Volume)
 8 to normalize to bit/s.
 3600 is the hour expressed in seconds to normalize to bit/s.
 %_Transport_Overhead is the correction factor to be applied to the computed

throughput to account for transport overhead (GTP-U/UDP/IP/Ethernet plus
optional IPsec header and Vlan tag), refer to section 3.5.4.2.
%_Transport_Overhead = (Overhead size) / (packet size)
Engineering Recommendation: Recommended PtA_B value
Considering the higher link rate provided by the eNodeB Backhaul (3 times the one required
per LTE cell), PtA_B that can be used for the Backhaul dimensioning is estimated to 1.13.
This value is well adapted for tri-sector eNBs handling loaded 10 MHz or 20 MHz bandwidth
Cells. For 5 MHz bandwidth eNBs, a slightly higher value might be needed (1.2)
The resulting throughput at the S1-U interface S-GW side is computed as eNodeB-
S1U_Non_GBR_Throughput_Phy_DL/UL multiplied by the number of eNodeBs
(N_eNBs) which are served by this S-GW.
S-GW_S1-U_Throughput Non_GBR _Phy_DL/UL =

N_eNBs x eNB_S1-U_Throughput_ Non_GBR _Phy_DL/UL
3.5.4.3.1.2 GBR / VOIP SERVICE BANDWIDTH COMPUTATION
GBR services traffic characteristic is such that the application packets are sent at a
fixed rate. GBR service traffic characteristics are retrieved from the traffic model which
provides the amount of bytes which are exchanged through the interface during the
busy hour. The same throughput computation formulas apply to GBR and VoIP
services.
eNB_S1-U_GBR_Throughput_App_Phy_DL/UL =
[ Inv_ErlgB (S1_GBR-traffic-Intensity @ BIGBR) ] x
[ GBR_Nominal_BR_APP_DL/UL] x [1 + %_Transport_Overhead]
S1_GBR-traffic-Intensity represents the maximum number of subscribers which are

expected to send traffic during the busy hour. It is computed as follows:
Page 137/273
S1_ GBR traffic intensity =

(N_Subs x GBR_BHCA x GBR_Call_duration) / 3600
(refer to Table 5 of section 2.2.1.1.1).
 GBR_BHCA is retrieved from the traffic model. It represents the average GBR
busy hour call attempt.
 GBR_Call_duration is retrieved from the traffic model.

 BIGBR is the blocking factor for GBR service i.e the probability of overflow at
S1-U interface level. Typical figure is in the range of 0.01.
 Inv_ErlgB is the inverse ErlangB formula which is used to compute the
amount of required resources at eNodeB S1-U interface level, with the
requested probability of overflow, to ensure the number of active user can
send traffic, assuming a given activity factor.
 GBR_Nominal_BR_APP DL/UL is the nominal GBR service throughput at
busy hour. It is computed as follows:
GBR_Nominal_BR_App_UL/DL(per sub) =
8 x (KByte_GBR_call_UL/DL) / (Call_Duration * Duty_Cycle)
 KByte_GBR_call_UL/DL is an input from the traffic model (refer to Table 4), it

represents the aggregated number of bytes which are exchanged for GBR
service at the busy hour. Note that uplink and downlink figures are different.
 Call-Duration is an input from the traffic model (refer to Table 4)
 Duty_Cycle is an input from the traffic model (refer to Table 4)

throughput to account for transport overhead (GTP/UDP/IP/Ethernet plus
optional IPsec header). Refer to section 3.5.4.2.
The resulting throughput at the S1-U interface S-GW side is computed as eNB-
S1U_GBR_Throughput_Phy_DL/UL multiplied by the number of eNodeBs (N_eNBs)
which are served by this S-GW.
S-GW_S1-U_Throughput_GBR_Phy_DL/UL =
N_eNBs x eNB_S1-U_Throughput_GBR _Phy_DL/UL
Note that if VoIP service is supported, the same formula as above must be used to
account for VoIP services in addition to GBR services.
Page 138/273
3.5.4.3.1.3 EXAMPLES OF S1-U DIMENSIONING
Referring to the call model parameters, as they given in Table 3, the following
throughput is expected at S1-U interface level (on a per eNodeB basis):
IPv4 w Vlan tagging w/o IPsec is assumed, 10 Mhz on air.

S1-U VoIP throughput: 0 Kbit/s (call model parameter assumes CSFB for voice)
S1-U GBR throughput:
 Downlink: 18330 Kbit/s

 Uplink: 2144 Kbit/s
S1-U non GBR throughput:

S1-U SMS traffic throughput (SMS traffic at S1-U interface level follows the same
computation formulas as the non-GBR traffic):
 Uplink: 8 Kit/s
S1-U aggregate throughput:
3.5.4.4 S1-MME INTERFACE DIMENSIONING
S1-MME interface throughput computation (downlink and uplink) is driven by the

number and size of signaling messages per busy hour, which are exchanged at the
control plane level to enable access stratum and non access stratum signaling
support.
In order to keep S1-MME bandwidth computation simple, only main procedures

exchanged over S1-MME interface will be considered further in the computation
exercise i.e procedures which are the most bandwidth consuming. The main
procedures to consider are listed below. For each procedure, the corresponding call
flow is described in 3GPP TS 23.401.
 Attach procedure.
 Detach procedure.
 Connection request (Setup and release).
Assumption is made that it is Service Request procedure and S1 release

procedure (as described in 3GPP TS 23.401).
Page 139/273
 Inter-eNB (X2) handover procedure.

 eNodeB paging procedure.
 PDN session request.
For this procedure, assumption is made that it is UE request PDN connectivity

 Tracking area update.
 Per Call Measurement Data (PCMD).

PCMD contribution to the S1-MME traffic is described in section 3.3 (LTE
OAM capacity elements).
For each of the above procedure, number of procedures per subscribers at the busy
hour that must be considered for S1-MME throughput computation is retrieved from
the traffic model, as described in Table 3. For each procedure, per subscriber BHCA is
used in relation with the number of message and message size to assess the traffic
activity for that procedure at the S1-MME interface.
S1-MME protocol stack is described in section 3.5.4.1 above. S1-MME IP transport

headers are described in section 3.5.4.2 above.
3.5.4.4.1 MAIN S1-MME PROCEDURES
This section is intended to describe the main procedures (those which are the most
bandwidth consuming), that are exchanged over S1-MME interface to assess S1-
MME throughput. These procedures are described in 3GPP TS 23.401. For each
procedure the number of message exchanged downlink / uplink and the aggregate
number of bytes is given. Since SCTP is in use, the number of SCTP
acknowledgement messages is given as well. Worst case figure is given as much as
possible.
1. Attach Procedure
Four different methods are defined to attach the UE:
 Attach with IMSI and without authentication
 Attach with IMSI and authentication
 Attach with GUTI and no authentication
 Attach with GUTI and authentication

Most bandwidth consuming procedure is to be considered for S1-MME throughput
computation. In that scope Attach with GUTI and authentication procedure is assumed
in the throughput computation. The characteristics of this procedure are given in the
table below:
Page 140/273
Attach procedure Downlink Uplink

Nb_msg_Proc(i) 5 messages 8 messages
Volume_Size_Proc(i) 610 Bytes 600 Bytes
Nbr_msg_Ack 5 3
Table 56: Attach Procedure
2. Detach Procedure
Successful UE initiated detach request is considered. The characteristics of this
procedure are given in the table below:
Detach procedure Downlink Uplink

Nbr_msg_Ack 1 1
Table 57: Detach Procedure
3. Connection Request
This procedure comprises UE initiated service request and release (S1 release
procedure). Details about these procedures can be found in 3GPP TS 23.401. The
characteristics of this procedure are given in the table below.
UE service request / S1 release procedure Downlink Uplink

Nbr_msg_Ack 2 2
Table 58: Connection Request Procedure
4. Inter-eNB (X2) Handover
This procedure describes the messages which are exchanged between target eNodeB
and MME during inter-eNodeB (X2) handover. The characteristics of this procedure
are given in the table below:
Inter-eNB HO procedure Downlink Uplink

Nb_msg_Proc(i) 1 message 1 message
Nbr_msg_Ack 0 0
Table 59: Inter-eNB (X2) Handover Procedure
Page 141/273
5. Paging eNB
This procedure describes the messages which are exchanged between MME and
eNodeB when the MME needs to signal to an UE, which is in ECM-IDLE state there is
a network triggered service request. The characteristics of this procedure are given in
the table below (note that we only consider the paging message, as the initial UE
service request message is assumed to be accounted for in the UE service request
procedure described above):
eNodeB paging Downlink Uplink

Nb_msg_Proc(i) 1 message 0
Volume_Size_Proc(i) 44 Bytes 0
Nbr_msg_Ack 0 0
Table 60 : Paging eNodeB Procedure
6. PDN session request
This procedure describes the messages which are exchanged between MME and
eNodeB when UE requests PDN connectivity. The procedure allows the UE to request
for connectivity to an additional PDN over E-UTRAN including allocation of a default
bearer, if the UE already has active PDN connections over E-UTRAN. The
characteristics of this procedure are given in the table below:
Session request Downlink Uplink

Nb_msg_Proc(i) 1 message 3 messages
Nbr_msg_Ack 0 0
Table 61 : UE Requested PDN Connectivity Procedure
7. Tracking Area Update
Tracking area update triggers condition are described in 3GPP TS 23.401 (example is
UE detects it has entered a new TA that is not in the list of TAIs that the UE registered
with the network). The characteristics of this procedure are given in the table below (it
includes all call relocation scenario):
Tracking Area update Downlink Uplink

Nbr_msg_Ack 0 1
Table 62 : Characteristics of TAU Procedure
Page 142/273
3.5.4.4.2 S1-MME BANDWIDTH CALCULATION
The required S1-MME bandwidth is computed according to the following formula

(separate downlink and uplink computation is made as the number and size of
message differs from downlink to uplink):
eNB_S1-MME_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_S1-MME_Throughput_Phy_DL/UL_Subs
in section 3.5.4.3.1.1 above.
(refer to Table 5 of section 2.2.1.1.1)
 Avg_S1-MME_Throughput_Phy_DL/UL_Subs is the average S1-MME
physical throughput per subscriber, which is computed according to the
following formula:
Avg_S1-MME_Throughput_Phy_DL/UL_Subs =
∑i Avg_S1-MME_Proc(i)_Throughput_Phy_DL/UL
 Avg_S1-MME_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the S1-MME interface, which is computed according to the
following formula:
Avg_S1-MME_Proc(i)_Throughput_Phy_DL/UL =
Nb_S1-MME_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
Nb_msg_Proc(i)_DL/UL x Transport_Header] x (8 / 3600)
 Nb_S1-MME_Proc(i) is the number of procedure_#i at busy hour per

subscriber (i.e BHCA figure for attach, detach, connection request, etc). For
each procedure the figure is retrieved from Table 3 and Table 4 except for
paging procedure, where the figure is computed in section 3.4.3.
 Volume_Size_Proc(i)_DL/UL is the amount of bytes which are exchanged for

procedure_#i (at S1-AP level). For each procedure, the figure is retrieved from
table of section 3.5.4.4.1 above.
 Nb_msg_Proc(i)_DL/UL is the number of message exchanged between

eNodeB and MME for procedure_#i. This include SCTP acknowledgement
message. For each procedure, the figure is retrieved from table of section
3.5.4.4.1 above.
 Transport_Header is the correction factor to apply to the computed throughput

to account for transport overhead (SCTP/IP/Ethernet plus optional IPsec
header). Refer to section 3.5.4.2 above.
 8 to normalize to bit/s
Page 143/273
At MME side, the above computed eNodebB throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess S1-MME interface
throughput at MME level.
eNB_S1-MME_Total_Throughput_Phy(DL/UL) =
N_eNBs x eNB_S1-MME_Throughput_Phy(DL/UL)
 N_eNBs is the number of eNodeBs served by the MME.
Note: PCMD throughput is computed in section 3.3 (LTE OAM capacity elements).
3.5.4.4.3 EXAMPLE OF S1-MME DIMENSIONING
Referring to the call model parameters, as they are given in Table 3, the following
throughput is expected at S1-MME interface level:
IPv4 w Vlan tagging w/o IPsec is assumed.
S1-MME throughput
 Downlink: 184.76 Kbit/s
 Uplink: 130.75 Kbit/s
3.5.5 X2 INTERFACE DIMENSIONING

This section is aimed to describe the X2 interface throughput computation method.
Similarly to S1 interface, X2 is split in X2-U which carries user plane traffic and X2-C
which carries control plane traffic. Details about X2 interface can be found in section
2.1.3.4.
X2-U and X2-C dimensioning methods differ, since the type of traffics carried over
these interfaces are different. From a backhauling perspective, overall X2 bandwidth
equals to X2-U + X2-C.
The figure below, which is an extract of 3GPP TS 23.401 depicts the call flow for X2-
based handover. It shows how X2 interface enables handing over from source to
target eNodeB, when active traffic is exchanged between the UE and the EPC.
Page 144/273
Source Target Serving

UE eNodeB eNodeB MME GW PDN GW
Downlink and uplink data
Handover preparation
Handover execution
Forwarding of data
Downlink data Handover completion

Uplink data
1 Path Switch Request
2 Modify Bearer Request
3a Modify Bearer Request
(A)
3b Modify Bearer Response
4 Modify Bearer Response
Downlink data
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
8. Tracking Area Update procedure
Figure 39: X2-based Handover without S-GW Relocation
3.5.5.1 X2 INTERFACE PROTOCOL STACK
X2-U is the reference point between source and target eNodeBs, for bearer inter
eNodeB path switching during handover. X2-U enables data forwarding from source
eNB toward target eNB, while handing over between eNodeBs, when radio interface is
already established in the target cell. X2-U protocol stack is depicted in the figure
below.
Page 145/273
UE eNodeB eNodeB
User App
TCP, UDP, …
IP (user) IP (user) IP (user)
GTP-U GTP-U
PDCP PDCP UDP UDP
MAC LTE-Uu MAC IPsec/UDP/IP X2-U IPsec/UDP/IP
Figure 40: X2-U Protocol Stack
X2-C is the reference point for the control plane protocol between eNBs (source and
target eNBs) when inter eNBs handover is to be supported. X2-C protocol stack is
depicted in the figure below.
UE eNodeB eNodeB
X2-AP X2-AP
RRC RRC
PDCP PDCP SCTP SCTP
MAC LTE-Uu MAC IPsec/UDP/IP X2-C IPsec/UDP/IP
Figure 41: X2-C Protocol Stack
3.5.5.2 X2 INTERFACE IP TRANSPORT HEADERS
Detailed X2 bandwidth figures depends upon the IP transport stack and the resulting
headers which must be added to the application protocol, according to the backhaul
Page 146/273
network architecture. The same rules as those given for S1 interface apply for X2
interface. Please refer to section 3.5.4.2 above.
Several transport header combinations are possible depending upon the transport
backhaul architecture. Figures are similar to those of S1 except for X2-U GTP-U
header size which is 13 bytes as per 3GPP TS 29.281 (it is indeed padded with 3
additional bytes to reach 16 bytes length). In the following section addressing the X2-
U bandwidth computation, same GTP-U header size is assumed.
3.5.5.3 X2-U INTERFACE DIMENSIONING
X2-U interface enables data forwarding from source eNodeB to target eNodeB during
the hand-over procedure. The resulting X2-U throughput depends upon the amount of
active users experiencing handover. Indeed a fraction of the aggregated S1-U traffic is
forwarded to the target eNodeB before the hand-over is complete, as depicted in the
figure below.
S1- U
X2- U
eN B eN B
HO
Figure 42 : X2-U Traffic vs. S1-U Traffic
X2-U interface throughput is computed by taking into account the maximum user
plane traffic for the maximum number of attached subscribers at the busy hour. X2-U
bandwidth computation process uses the input from the traffic model (either Alcatel-
Lucent traffic model or customer specific traffic model), taking into consideration the
backhauling network specific architecture.
X2-U throughput depends upon UEs handover activity. Basically, specific hand-over
parameters related to the cell coverage, the user mobility pattern and velocity are the
main points to be taken into account. These hand-over parameters are used to assess
the number of hand-over procedures per subscriber at Busy Hour. Number of inter
eNodeB (X2) events per subscriber at the busy hour is an input from the traffic model
which is described in Table 3.
The X2-U throughput has to be computed for both X2-U directions (In for the incoming
X2 traffic and Out for the outgoing X2 traffic). However, with the assumption that per
Page 147/273
eNodeB number of subscribers is constant during the busy hour and the percentage of
user experiencing hand-over is equally spread over eNodeBs, we assume that at each
eNodeB, X2-U_Througput_In = X2-U_Througput_Out.
Indeed X2-U throughput computation follows the same principles as those which are
applied for S1-U. But in addition, the handover BHCA and handover duration have to
be taken into consideration. X2-U bandwidth is computed according to the following
formula:
eNB_X2-U_Throughput_Phy_In =
eNB-X2-U_Non_GBR_Throughput_Phy_In +
eNB_X2-U_VoIP_Throughput_Phy_In +
eNB_X2-U_GBR_Throughput_Phy_In
For non-GBR services, the X2-U throughput is computed as follows (similar formula as
for S1-U non-GBR, but with handover ratio taken into consideration and GTP-U
header equal to 16 bytes instead of 8 bytes (as specified in 3GPP TS 29.281, section
5.2.2.2, X2-U GTP-U header size equals to 8 bytes (minimum GTP-U header size + 1
bytes for Next Extension header type + 4 bytes for PDCP PDU number field. But 3
padding bytes are added by most application in order to get 16 bytes GTP-U overhead
with is easier to manage from an implementation perspective).
eNB_X2-U_Throughput_Non_GBR_Phy_In =
PtA_B x N_Subs x Avg_BR_Phy_In (per Sub)
in section 3.5.4.3 above. PtA_B is slightly different from PtA_Air (the value in
use at the air interface). The backhaul link rate is higher than the air interface,
PtA_B is less restrictive than PtA_Air. PtA_B value may be provided as part of
the traffic model, or a standard value can be used instead.
(refer to Table 5 in Section 2.2.1.1.1)
 Avg_BR_Phy_In (per Sub) is computed as follows
Avg_BR_Phy_In (per Sub) =
[Volume_at_BH_(In) x 8 / 3600] x [1 + %_Transport_Overhead]
 Volume_at_BH_(DL/UL) represents the aggregated number of bytes which

are exchanged at X2-U for non GBR service at the busy hour.
Page 148/273
Volume_at_BH_(In) = Inter_eNB_X2_Handover x Handover_duration x

Non_GBR_BHCA_Volume / Call_Duration x Duty_Cycle
 Inter-eNB_(X2)_HO_BHCA is retrieved from the traffic model. It represents

the average inter eNodeB (X2) handover at the busy hour.
 Handover_duration is an Alcatel-Lucent parameter. Typical value is the range

of 0,1 s.
 Non_GBR_BHCA_Volume is retrieved from the traffic model. It represents the
average volume of bytes exchanged for non GBR service at the busy hour.
 Non_GBR_BHCA_Volume represents the average volume of data exchanged

over X2U for non GBR service at the busy hour.
 Call duration for non GBR service at the busy hour.
 Duty cycle for non GBR service at the busy hour.


throughput to account for transport overhead (GTP-U/UDP/IP/Ethernet plus
optional IPsec header and Vlan tag, as described for S1-U)
For GBR services (VoIP or other GBR services), the X2-U throughput is computed as
follows:
eNB_X2-U_GBR_Throughput_App_Phy_In =
[ Inv_ErlgB (X2-U_GBR-traffic-Intensity @ BIGBR) ] x
[ GBR_Nominal_BR_APP_In] x [1 + %_Transport_Overhead]
 Inv_ErlgB is the inverse ErlangB formula which is used to compute the amount of
required resources at eNodeB X2-U interface level, with the requested probability
of overflow, to ensure the number of active user can send traffic, assuming a
given activity factor.
 BIGBR is the blocking factor for GBR service i.e the probability of overflow at X2-U
interface level. Typical figure is in the range of 0.01.
X2-U_ GBR-traffic-intensity =
(N_Subs x GBR_BHCA x Inter-eNB_(X2)_HO_BHCA x HO_duration) / (3600)
Page 149/273
 N_Subs is the number of active subscribers per eNodeB at the busy hour (refer to
Table 5 in Section 2.2.1.1.1.
 GBR_BHCA is retrieved from the traffic model. It represents the average GBR
busy hour call attempt.
 Inter-eNB_(X2)_HO_BHCA is retrieved from the traffic model. It represents the
average inter eNodeB (X2) handover.
 HO_duration is an Alcatel-Lucent parameter. Typical value is the range of 0,1 s.

 GBR_Nominal_BR_APP DL/UL is the nominal GBR service throughput at busy
hour. It is computed as follows:
GBR_Nominal_BR_App_In (per sub) =
8 x (KByte_GBR_call_In) / (Call_Duration x Duty_Cycle)
 KByte_GBR_call_In is an input from the traffic model (refer to Table 4), it

represents the aggregated number of bytes which are exchanged for GBR service
at the busy hour. Note that uplink and downlink figures are different.
 Call-Duration represents the GBR service call duration at the busy hour (traffic
model refer to Table 4).
 Duty_Cycle represents the GBR service duty cycle at the busy hour (traffic model
refer to Table 4).

throughput to account for transport overhead (GTP/UDP/IP/Ethernet plus optional
IPsec header, as described for S1-U).
3.5.5.4 EXAMPLE OF BANDWIDTH CALCULATION FOR X2-U
throughput is expected at X2-U interface level:
X2-U_Througput_In = X2-U_Througput_Out: 900 Kbit/s
3.5.5.5 X2-C INTERFACE DIMENSIONING
The assumptions for X2-C interface throughput computation are the same as for S1-
MME interface throughput computation, as described in section 3.5.4.4.
The main procedure to consider for X2-C bandwidth computation, is the

inter_eNodeB_X2 handover procedure. This procedure is described in 3GPP TS
23.401 and 3GPP TS 36.300. The traffic model provides the BHCA characteristics for
Page 150/273
the inter_eNodeB_X2 handover procedure. The inter_eNodeB_X2 handover

procedure characteristics are given in the table below.
Inter eNB (X2) HO procedure Outgoing (DL) Incoming (UL)

Volume_Size_Proc(i) 192 bytes 428 bytes
Nbr_msg_Ack 0 0
Table 63 : Characteristics of the Inter eNB (X2) HO Procedure
Formulas to compute the resulting X2-C physical throughput are the same as those
used to computed S1-MME throughput; please refer to section 3.5.4.4 above.
The total required throughput for X2-C must take into account both the incoming and
the outgoing handover procedures. Assuming that for each subscriber leaving an
eNodeB source coverage (outgoing HO) there is another subscriber coming from a
neighboring eNodeB (incoming HO) which generates an equivalent X2-C traffic, the
total required X2-C throughput for a given direction (In or Out) is equal to the sum of
the required throughput for each of these two direction (In + Out).
throughput is expected at X2-C interface level:
X2-C: 95.04 Kbit/s
3.5.6 BANDWIDTH CALCULATION FOR EUTRAN INTERFACE

Maximum throughput computation over the backhauling interface depends upon the
transport backhaul configuration. Please refer to section 3.5.4.2 above for examples of
possible configurations.
Maximum eNodeB throughput is computed as follows:
eNB_BW_Total_UL/DL =
eNB_BW_Telecom_UL/DL + eNB_BW_OAM_UL/DL + eNB_BW_SYnc_UL/DL
With
 eNB_BW_Telecom_UL/DL: Throughput resulting from the Telecom interface
S1_UL/DL + X2_UL/DL.
 eNB_BW_OAM_UL/DL: Throughput resulting from OAM interface.

Note about Operational & Maintenance traffic.
Page 151/273
OAM Operational traffic is a fixed throughput equal to 3,5 Mbit/s and the
Maintenance traffic is an additional traffic required only for maintenance
purpose.
 eNB_BW_Sync_UL/DL: Ethernet synchronization throughput.

Resulting throughput when IEEE 1588 synchronization distribution is
deployed. Note: The maximum standard throughput for 1588 protocol is
estimated to 64 Kbps.
The eNodeB interface estimated load eNB_BW_Load can then be assessed with the
following formula:
eNB_BW_load_UL/DL = eNB_BW_Total_UL/DL / AV_eNB_BW_UL/DL
With AV_eNB_BW_UL/DL being the available eNodeB bandwidth which is reserved

by the operator for the OAM traffic and Telecom traffic.
The eNodeB interface load has to be computed for downlink and uplink transmission
path. The resulting maximum load_DL/UL, expressed in % is then compared to the
eNodeB target load (X%). Load will be OK as long as the following is true:
MAX {eNB_load_UL , eNB_load_DL} < = X%
The example below assumes there is no additional OAM maintenance traffic, with no
specific maintenance activity. The table below summarizes the eNodeB interface
throughput for Alcatel-Lucent reference traffic model. Aggregated Telecom throughput
(S1 & X2) is computed as follows:
Telecom_Thput_DL/UL =
S1-U_Thput_DL/UL + S1-MME_Thput_DL/UL +
X2-U_Thput_DL/UP + X2-C_Thput_DL/UL
 S1-U and S1-MME throughput figures are taken from tables of section
3.5.4.3.1.3 and section 3.5.4.4.3 above.
 X2-U and X2-C throughput figure are taken from table of section 3.5.5.4 and
section 3.5.5.5 above.
 OAM Operational and maintenance throughput figures are given in section

3.3.
 IEEE 1588 synchronization throughput figure can take two different values:
Peak throughput and average throughput.
Peak throughput is in a range of 102.37 Kbit/s for downlink and 49.44 Kbit/s
for uplink. These are figures during the synchronization setup phase.
Page 152/273
Nominal throughput is in a range of 28.8 Kbit/s for downlink and 14.5 Kbit/s for
uplink. These are figures while the synchronization is setup i.e. after
synchronization convergence.
Telecom throughput at eNodeB interface is given in the table below.
Traffic type Downlink Uplink
S1 & X2 Throughput (10MHz on air) 30647 Kbit/s 7029 Kbit/s
OAM operational ≈ 600 Kbps 37 Kbps
OAM PCMD 34 Kbps
≈ 102,37 Kbit/s (Peak) ≈49,44 Kbit/s (Peak)

Synchronization 1588
≈ 28,8 Kbit/s (Average) ≈14,5 Kbit/s (Average)
Total bandwidth (max) 31 350 Kbit/s 7 150 Kbit/s
Table 64: eNB Throughput (IPv4, w/o OAM Maintenance Traffic, w/o IPsec)
The table below provides eNodeB interface throughput assuming additional OAM
maintenance traffic. Six different OAM maintenance actions are considered in the
table below. Please note that it is not recommended to carry simultaneously the six
OAM maintenance actions, to prevent overloading the eNodeB backhaul interface. It is
recommended to execute single OAM operation only. Required bandwidth for each
OAM operation is given as an example.
Page 153/273
Board App
Call Software L3 On demand
DDT restart restart
Trace Upgrade snapshot snapshot
Context Context
UL Only DL Only UL Only UL Only
UL Only UL Only
OAM BW 600
600 600 600 600 600 600
DL + 3 670
OAM BW 39000 37 37 37 37 37
37
UL + 37 + 540 + 2 300 + 2 000 + 3,3 + 900
S1 & X2 BW
30647 Kbit/s
DL
S1 & X2 BW
7029 Kbit/s
UL
Synchro DL 102,37 Kbit/s
Synchro UL 49,44 Kbit/s
Max Total
31350 31350 35020 31 350 31 350 31 350 31 350
BW DL
Max Total
46 115 7655 7 116 9 416 9 116 7 120 8 016
BW UL
Table 65 : eNB Bandwidth Calculation (IPv4 w Additional OAM Maintenance Traffic)

Note: Only DDT, call trace operation and software upgrade (downlink without
execution) can be executed in parallel, others OAM operations cannot be executed
simultaneously because this might require eNodeB to be reset.
For a maximum case including maintenance with DDT (10MHz on Air cells) we
consider the network under control if the maximum reserved end to end bandwidth is
as follows:
 Total Maximum bandwidth /Downlink in the range of 35 Mbit/s
 Total Maximum bandwidth /Uplink in the range of 46 Mbit/s
3.6 MOBILE GATEWAY (S-GW, P-GW) DIMENSIONING

This section addresses the engineering capacity limits and guidelines that globally
apply to the 7750 Mobile Gateway, i.e., regardless of whether it is configured as an S-
GW or P-GW/GGSN.
3.6.1 MOBILE GATEWAY CONFIGURATION & CAPACITY

7750 SR Mobile Gateway is based on the 7750 SR hardware platform. A new
hardware module, named Mobile-Gateway Integrated Services Module, has been
introduced to support S-GW, and P-GW/GGSN functions. Please refer to [C12] for
more information.
Page 154/273
Figure 43 : Mobile Gateway HW Structure
The 7750 SR Mobile gateway (implemented as either an S-GW or P-GW/GGSN) is a

single chassis system that consists of a set of IO Module cards (IOMs), one Switch
Fabric/Control Plane Module (SF/CPM-3), with an optional redundant SF/CPM-3; and
a set of Mobile Gateway - Integrated Services Modules.
7750 SR Mobile Gateway can be based on two different chassis configurations: 7750
SR-12 and 7750 SR-7. One slot holds one Switch Fabric/Control Processor Module
(SF/CPM) and only one SF/CPM is required for operation. A second SF/CPM provides
complete redundancy of the fabric and the control processors.
The remaining 10 slots, in case of 7750 SR-12, are occupied by I/O Modules and
MDAs or Mobile Gateway – Integrated Services Module.
The following I/O Modules and MDAs are supported:

 3HE03622AA 7750 SR 5-port 10GE – IMM XFP
 3HE03624AA 7750 SR 48-port GE – IMM SFP
 3HE03619AA 7750 SR IOM3-XP (iom3-xp)
 3HE03612AA 7750 SR 20-port GE - MDA-XP SFP
 3HE03613AA 7750 SR 20-port 10/100/1000 - MDA-XP RJ45
 3HE03685AA 7750 SR 2-port 10GBASE - MDA-XP XFP
 3HE03686AA 7750 SR 4-port 10GBASE - MDA-XP XFP
 3HE03611AA 7750 SR 10-port GE –MDA-XP SFP
 3HE04274AA 1-port 10GE - MDA-XP XFP
The Alcatel-Lucent Input/Output Module -XP (IOM3-XP) supported by the 7750 Mobile
Gateway delivers up to 50 Gb/s (full-duplex) per-slot performance, with highly scalable
multiservice capabilities. It provides outstanding IP/MPLS routing performance to
enable the convergence of voice, video and data services for a wide range of
business, consumer and mobile network applications.
The Alcatel-Lucent Service Router (SR) Ethernet Media Dependent Adapter -XP
(MDA-XP) delivers high-density, high performance Carrier Ethernet for the all 7750
Page 155/273
Service Router applications including Mobile Gateways. They provide up to 25 Gb/s

(full-duplex) of line-rate throughput per card and supports ITU-T Synchronous
Ethernet, leading port densities, and a rich set of service delivery and OAM features.
Technical details on MG-ISM, IOM3-XP and MDA-XP modules can be found in [C13]
and [C14].
3.6.1.1 MOBILE GATEWAY COMMON SYSTEM CONFIGURATION
The following table gives a summary of the common 7750 SR Mobile gateway system
configuration:
7750 SR-7 7750 SR-12
System Capacity (half-duplex) 500 Gbps 1 Tbps
500G Switch Fabric 500G Switch Fabric
50G per slot capacity 50G per slot capacity
Bandwidth (full-duplex, redundant)
Optional Switch Optional Switch
Fabric/CPU Redundancy Fabric/CPU Redundancy
Slots for MG-ISMs 1 to 3 1 to 8
I/O Slots for IOM3 + MDA or IMM 1 to 5 1 to 10
Media Dependent Adapters (MDAs)
1 to 10 1 to 20
(if IOM3)
AC Power (1 + 1) AC Power (1 + 1)
DC Power (1 + 1) DC Power (1 + 1)
Switch Fabrics/Control Switch Fabrics/Control
Redundancy
Processor Modules Processor Modules
(SF/CPM) (1 + 1) (SF/CPM) (1 + 1)
Cooling Fans (1 + 1) Cooling Fans (2 + 1)
Table 66 : 7750 SR Mobile Gateway System Configurations
Restriction: Number of MG-ISM supported in R4.0 R9
In R4.0 of SROS-MG, up to 4 pairs of MG-ISMs (8 MG-ISMs configured in 1:1 redundancy as 4

active + 4 stand-by) can be configured per 7750 MGW (S-GW or P-GW).
3.6.1.2 MOBILE GATEWAY STATIC CAPACITY
The following tables summarize the 7750 Mobile Gateway static capacity:
Parameter per MG-ISM (S-GW) Release 4.0
Simultaneous bearer/PDP contexts 1 Million
SDF context N/A
Policers (Rate Limiter) N/A
Forwarding Rate 20 Mpps
Throughput (Unidirectional) 30 Gbps
Throughput (DL/ UL) 21 / 9 Gbps
DPI N/A
Table 67 : 7750 SGW Static Capacity Figures (per MG-ISM)
Note: The SGW capacity above is based on a 30 BHCA call model.
Page 156/273
Parameter per MG-ISM (P-GW) Release 4.0

Simultaneous bearer/PDP contexts 1 Million
SDF context 2 Million
Policers (Rate Limiter) 1 Million
Forwarding Rate 20 Mpps
Throughput (Unidirectional) 30 Gbps
Throughput (DL/ UL) 21 / 9 Gbps
DPI Up to 10 GBPS
Table 68 : 7750 PGW/GGSN Static Capacity Figures (per MG-ISM)
Note: The total 7750 Mobile gateway chassis capacity is simply the addition of
individual MG-ISM capacity:
 4 x active MG-ISM per chassis (for SR12)
Maximum number of connected eNB per S-GW (per system) 4000

Maximum number of MME per S-GW (per system) 256
Maximum number of P-GW per S-GW (per system) 256
Table 69 : 7750 Mobile Gateway Static Capacity Figures (S-GW)
Maximum number of S-GW per P-GW (S5/S8) 256
Maximum number of SGSN per P-GW/GGSN (Gn) 256
Maximum number of Direct Tunnels (Gn) per P-GW/GGSN 4000
Table 70 : 7750 Mobile Gateway Static Capacity Figures (P-GW/GGSN)
3.6.1.3 MOBILE GATEWAY DYNAMIC CAPACITY
Parameter per MG-ISM (P-GW & S-GW)

Max number supported PDP-context / EPS-bearer activations (connections per sec) 4000
Max number supported PDP-context / EPS-bearer deactivations (connections per sec) 4000
Max number supported PDP-context / EPS-bearer modifications (connections per
4000
sec)
Table 71 : 7750 Mobile Gateway Dynamic Capacity Figures
Note: The total 7750 Mobile gateway chassis capacity is simply the addition of
individual MG-ISM capacity:
 4 x active MG-ISM per chassis (for SR12)
3.6.1.4 MOBILE GATEWAY BASE SYSTEM (SR DERIVED) FEATURES

AND CAPACITY
The 7750 Mobile gateway supports a number of services and features and directly
inherited from the 7750 Service Router OS. The following most relevant capabilities
Page 157/273
for EPC deployment are supported as part of SR OS MG 4.0 for both S-GW and P-
GW:
 Services
o IES
o VPRN for 3GPP interfaces
Note: for VPRN service, the maximum number of APN applies on P-GW
 Ethernet
o 802.1Q VLAN based interfaces
o 802.3ad LAG interfaces
o 802.1ag & 802.3ah Ethernet OAM

 Routing / forwarding
o Static routing
o OSPFV2
o OSPFv3
o BGP
o ISIS
 QoS
Note: the below capabilities refer to the “transport” level, i.e., when
applied to ingress/egress IOM3. QoS features and capabilities in the
context of PCC rules are given
o QoS filters/policies on network and SAP ingress/egress
o Queues and schedulers with shaping
 Filters and policies
o IPv4 and IPv6 filters
o Route policies
 High availability
o BFD for static, OSPF and BGP
Without explicit notice stating differently, capacity and scalability limits for the
above capabilities can directly be derived from the 7750 Service Router
scalability guidelines, on the basis of Release 9.0 of SROS running in chassis
mode D (e.g., system equipped with IOM3-XP modules only). Although the 7750
Mobile Gateway is based on SF-CPM3, control plane performances listed against SF-
CPM2 apply.
However, it must be noted that the individual limits are mentioned as a theoretical limit
applicable to a given feature/capability taking abstraction from interaction with other
limits. In practice, the actual limit is always a combination of several limits with the
most restrictive one determining the achievable scale. The ability to reach the
maximum scaling limits depends on, but is not limited to, CPU load, network topology,
Page 158/273
etc. These scaling limits have been designed for specific deployments of the 7750
Service Router which does not place high degrees of stress in many areas.
In the context of Mobile Gateway application, it is not expected to reach in any design
such high degrees of scalability/capacity for the base system (SR derived) capabilities
(routing protocols, QoS filters, etc). High scalability/capacity requirements for the
Mobile Gateway application are addressed in the previous sections.
Anyhow, for extreme scaling conditions thorough testing must be performed by the
customer. It is therefore strongly advised to contact Alcatel-Lucent representative for
additional guidance.
3.6.2 S-GW DIMENSIONING

This section addresses the specific engineering capacity limits and guidelines for the
7750 Mobile gateway when configured as an S-GW.
3.6.2.1 S-GW INTRA-NODE RESILIENCY DIMENSIONING
The 7750 S-GW supports 1:1 MG-ISM stateful redundancy. With MG-ISM cards
deployed in such protection mode, the 7750 SR Mobile Gateway provides full internal
application redundancy. Each pair supports an active and a standby MG-ISM that
synchronize all subscriber state between them. A switchover from active to standby
MG-ISM is invisible to the subscriber and therefore will not have any impact on
surrounding EPC nodes/systems: in other words it will not generate any additional
load to the MME or other network nodes and systems. As such the switchover from
standby to active does not require external protocol support.
The 7750 S-GW supports up to 8 x MG-ISMs (up to 4 pairs deployed in 1:1 hot stand-
by mode). When multiple active MG-ISM are provisioned in the S-GW, an internal
load-balancing algorithm that involves the Control Processor Module (CPM) allows to
spread the creation of subscriber/bearer contexts across the active MG-ISM’s.
Subsequently the IOMs direct all the traffic to the appropriate MG-ISM based on the
individual subscriber context. Therefore, no specific dimensioning rule needs to be
applied to take advantage of the full capacity of the system in presence of multiple
MG-ISMs per S-GW.
3.6.2.2 S-GW GEO-RESILIENCY DIMENSIONING
7750 SR S-GW supports geo-resiliency through S-GW pooling (based on S1-Flex).

There is no need to create a specific configuration to activate S1-Flex interfaces in
SGW. Interconnection between eNB/MME and SGW is based on IP routing and SGW
will advertise its configured IP addresses for each 3GPP interface (S1, S11) via IGP
and/or and BGP. Each interface can be associated to a different VPRN instance.
The 9471 MME is provisioned with a set of SGW Pool Id values, where by definition;
the MME is able to communicate with all the SGW nodes in the provisioned Pool. The
maximum number of SGW Pools is 16. The MME is also provisioned with the set of
Tracking Area Identifiers (TAI) that each SGW Pool ID is able to serve. For each SGW
Pool ID, the MME is provisioned with the S11 IP address of each SGW node that is a
Page 159/273
member of that SGW Pool. The maximum number of SGW elements per SGW Pool is
16.
Engineering Recommendation: S-GW pooling
SGW pooling is recommended as Flex interface improves network reliability and simplifies site
disaster recovery. Moreover, it enables network-level dimensioning with more efficient use of nodes
capacity and S-GW load sharing. It also facilitate SGW maintenance with graceful SGW shutdown
3.6.2.3 S-GW INTERFACES AND SUPPORTED PROTOCOLS
The supported interfaces on S-GW and related protocols in R4 are listed hereafter:
Reference Point Involved nodes

S1-U e-NB, S-GW
Protocol(s) to be supported:
 GTPv1-U (TS 29.281)
S11 MME, S-GW
 GTPv2-C (TS 29.274)
S5 S-GW, P-GW
 GTPv1-U (TS 29.281)
 GTPv2-C (TS 29.274)
S8 S-GW, P-GW
GTPv1-U (TS 29.281)
GTPv2-C (TS 29.274)
Rf S-GW, OFCS
Diameter (TS 32.299)
Ga S-GW, OFCS
GTP’ (TS 32.251, 32.295, 32.297,
32.298)
Table 72 : S-GW Supported Interfaces and Related Protocols
3.6.2.4 S-GW CAPACITY AND PERFORMANCE
3.6.2.4.1 USER PLANE HANDLING
S-GW capability in handling user plane traffic and associated capacity figures were
summarized in sections 3.6.1.2 & 3.6.1.3.
3.6.2.4.1.1 FRAGMENTATION AND REASSEMBLY
GTP Traffic arriving at the SGW (from eNB over S1-U or PGW/GGSN over S5/S8)
may have been fragmented (by the backhaul or core network) and therefore require
Page 160/273
reassembly at GTP endpoint before the encapsulated packet can be forwarded

(through another GTP tunnel).
In R4.0 of SROS-MG, IP reassembly is supported on SGW through the second MS-

ISA of the MG-ISM
Restriction:
IP reassembly will cause a performance impact on the basis of functions such as packet copying,
fragment validation, and fragment reorder. This performance impact will vary depending on the
number of concurrent IP datagram that are being reassembled.
Performance benchmarked for R4.0 considers two IP fragments for a single IP

packet of i.e. 2229 bytes of IP payload. The packet is fragmented due to
addition of GTP+UDP + IP header (48 bytes), which result in two IP fragments on
outgoing link having an MTU set of 2229 bytes. With the above configuration the
performance obtained through a single MS-ISA card is the following:
 8Gbps throughput with all packets fragmented
 10Gbps without fragmentation.
In order to scale for bandwidth needs (for instance if more than 8Gbps of throughput are
required), the SGW supports the ability to configure multiple MS-ISAs in one logical group.
The interfaces that are redirected to that group of MS-ISAs are hashed across them based on IP
header information (source/destination IP addresses, source/destination port, and protocol-id).
This allows the incoming S1-u traffic to be spread across multiple MS-ISAs as different
eNodeBs would have different source IP addresses. Similarly, incoming S5-u traffic is
spread across the MS-ISAs on a per PGW basis (or more granular if the PGW is
configured to use multiple source ports).
In R4 it is possible to assign multiple MS-ISA into the logical group that is bound to the
logical interface for which IP reassembly is enabled (e.g., S1-U, S5, and S8)
If multiple MS-ISAs need to be used as part of a logical group, the following rules
apply:
 The MG-ISMs seated in the SGW system must all have a second MS-ISA
installed.
 The MS-ISA of the MG-ISM(s) must be configured to be part of the logical

group before any other MS-ISA installed on an external IOM3 of the 7750
SGW can be used. For instance, if there are 2 MG-ISM installed in the SGW,
it is only possible to create a logical group of 2 MS-ISAs using the MS-ISAs of
the two MG-ISMs. Only if a group of 3 needs to be created a third MS-ISA
installed on an external IOM3 can be used.
 When the SGW is configured with redundant MG-ISMs operating in 1:1 hot
stand-by mode, it is possible to use the MS-ISA installed in the stand-by MG-
ISM for reassembly purposes.
Page 161/273
Network design should emphasize to use Layer 3 hashing mechanisms (instead of Layer
4 hashing mechanisms for ECMP or LAG) in all the network elements to avoid the
fragment packets taking different ip-paths to reach the GTP endpoint.
MS-ISA supports IP reassembly for at-least 3 VRFs (S1-U, S5-U, S8) in a SGW
instance, i.e., IP reassembly for a given MS-ISA or group of MS-ISA can be configured
under 3 distinct interfaces each bound a VRF. The IP reassembly context is managed
per VRF.
Nonetheless, the SGW can support IP reassembly for 4k eNBs GTP-endpoints in a

single VRF for the S1-U interface.
The SGW supports a maximum of 64k IPv4 concurrent reassembly context from a
given GTP end-point.
3.6.2.4.2 HANDOVERS
Maximum handover event rates per MG-ISM are captured in the following table:
S1/X2 HO Rate 1000 events/s Per MG-ISM
Inter S-GW HO Rate 1000 events/s Per MG-ISM
Inter SGSN HO Rate 500 events/s Per MG-ISM
Table 73 : HO Rates Supported on S-GW
3.6.2.4.3 PAGING
The S-GW will initiate Paging when downlink packets are received for a UE that is in
idle mode (i.e. no DL-TEID or eNB address for the bearer)
 A Downlink Data Notification message is sent from S-GW to MME
 S-GW begins to buffer the received DL packets
 MME sends Paging message to each eNB within the tracking area that the
UE is registered. Upon paged, the UE will initiate the UE triggered service
request procedure; hence re-establishing the bearer & the S-GW begins to
empty the buffer
Page 162/273
Figure 44 : Paging Handling at S-GW Level
When DL traffic is received for an idle UE, the ingress forwarding complex of the MG-
ISM on S-GW has a null FIB entry. The DL traffic is then handled by the ISA-MG of
the MG-ISM while a notification is sent to the MME, and the following events take
place:
 A paging queue instance is allocated to this bearer with PIR=0
 When paging response received from MME, the correct FIB entry is installed
 The paging queue is drained at PIR=Max
 Queue is de-allocated by background process
The DL traffic during paging is buffered in the ISA-MG.
The Paging buffer memory is constituted of 8K buffers; each buffer has a size of 3KB.
This gives a memory size dedicated to paging of 24MB. If those buffers are all used,
another 24MB of shared buffer space on the ISA-MG can be used, which gives a total
of up to 48MB of buffers available for paging.
Maximum Paging rate per MG-ISM:

Paging rate 1000 pages/s Per MG-ISM
3.6.2.4.4 S-GW CHARGING
Maximum number of configured charging profiles 255
3.6.3 P-GW DIMENSIONING

This section addresses the specific engineering capacity limits and guidelines for the
7750 Mobile gateway when configured as a P-GW/GGSN.
Page 163/273
3.6.3.1 P-GW INTRA-NODE RESILIENCY DIMENSIONING
The 7750 P-GW supports 1:1 MG-ISM stateful redundancy. With MG-ISM cards
deployed in such protection mode, the 7750 SR Mobile Gateway provides full internal
application redundancy. Each pair sports an active and a standby MG-ISM that
synchronize all subscriber state between them.
A switchover from active to standby MG-ISM is invisible to the subscriber and
therefore will not have any impact on surrounding EPC nodes/systems: in other words
it will not generate any additional load to other network nodes and systems. As such
the switchover from standby to active does not require external protocol support.
The 7750 P-GW supports up to 8 x MG-ISMs (up to 4 pairs deployed in 1:1 hot stand-
by mode).
When multiple active MG-ISM are provisioned in the P-GW, an internal load-balancing
algorithm that involves the Control Processor Module (CPM) allows to spread the
creation of subscriber/bearer contexts across the active MG-ISM’s.
Subsequently the IOMs direct all the traffic to the appropriate MG-ISM based on the
individual subscriber context. Therefore, no specific dimensioning rule needs to be
applied to take advantage of the full capacity of the system in presence of multiple
MG-ISMs per P-GW.
3.6.3.2 P-GW INTERFACES AND SUPPORTED PROTOCOLS
The supported interfaces on P-GW and related protocols in R3.1 are listed hereafter:
Reference Point Involved nodes
S5 S-GW, P-GW
 GTPv1-U (TS 29.281)
 GTPv2-C (TS 29.274)
S8 S-GW, P-GW
GTPv1-U (TS 29.281)
GTPv2-C (TS 29.274)
Gn/Gp P-GW, SGSN
 GTPv1 (TS 29.060)
SGi P-GW
 (TS 29.061, 29.161)
Gx P-GW, PCRF
Page 164/273
 Diameter (TS 23.203, 29.212,
29.213)
Ga P-GW, OFCS
 GTP’ (TS 32.251, 32.295,
32.297, 32.298)
RADIUS P-GW, AAA
Table 74 : P-GW Supported Interfaces and Related Protocols
3.6.3.3 P-GW CAPACITY AND PERFORMANCE
3.6.3.3.1 USER PLANE HANDLING
P-GW capability in handling user plane traffic and associated capacity figures were
resumed in sections 3.6.1.2 & 3.6.1.3.
3.6.3.3.1.1 FRAGMENTATION AND REASSEMBLY
GTP Traffic arriving at the P-GW/GGSN (from SGW or SGSN over S5/S8 or Gn, or
from the PDN network over SGi/Gi) may have been fragmented (by the core or PDN
network) and therefore require reassembly before the encapsulated packet can be
forwarded (as plain I packet or through a GTP tunnel).
In R3.1 of SROS-MG, IP reassembly is supported on P-GW/GGSN through the
second MS-ISA of the MG-ISM
Restriction:
IP reassembly will cause a performance impact on the basis of functions such as packet
copying, fragment validation, and fragment reorder. This performance impact will vary depending
on the number of concurrent IP datagram that are being reassembled.
Performance benchmarked for R4.0 considers two IP fragments for a single IP packet
of i.e. 1500 bytes of IP payload. The packet is fragmented due to addition of
GTP+UDP + IP header (48 bytes), which result in two IP fragments on outgoing link
having an MTU set of 1500 bytes. With the above configuration the performance
obtained through a single MS-ISA card is the following:
 8Gbps throughput with all packets fragmented
 10Gbps without fragmentation.
In order to scale for bandwidth needs (for instance if more than 8Gbps of throughput
are required), the P-GW/GGSN supports the ability to configure multiple MS-ISAs in
one logical group. The interfaces that are redirected to that group of MS-ISAs are
hashed across them based on IP header information (source/destination IP
addresses, source/destination port, and protocol-id).
Page 165/273
This allows the incoming SGi/Gi traffic to be spread across multiple MS-ISAs as
different end points would have different source IP addresses. Similarly, incoming
S5/S8/Gn traffic is spread across the MS-ISAs on a per SGW or SGSN basis.
In R4.0 it is possible to assign multiple MS-ISA into the logical group that is bound to
the logical interface for which IP reassembly is enabled (e.g., SGi, S5, and S8)
If multiple MS-ISAs need to be used as part of a logical group, the following rules
apply:
 The MG-ISMs seated in the P-GW/GGSN system must all have a second MS-
ISA installed.
 The MS-ISA of the MG-ISM(s) must be configured to be part of the logical
group before any other MS-ISA installed on an external IOM3 of the 7750
PGW can be used. For instance, if there are 2 MG-ISM installed in the PGW,
it is only possible to create a logical group of 2 MS-ISAs using the MS-ISAs of
the two MG-ISMs. Only of a group of 3 needs to be created a third MS-ISA
installed on an external IOM3 can be used.
 The MG-ISM for which an MS-ISA is used for IP-reassembly must be active.
In other words, it is not possible to use the 2 MS-ISA of 2 MG-ISMs operating
in 1:1 hot stand-by mode.
Network design should emphasize to use Layer 3 hashing mechanisms (instead of Layer 4 hashing
mechanisms for ECMP or LAG) in all the network elements to avoid the fragment packets taking
different ip-paths to reach the GTP endpoint.
MS-ISA supports IP reassembly for at-least 3 VRFs (SGi/Gi, S5, and Gn) in a P-
GW/GGSN instance, i.e., IP reassembly for a given MS-ISA or group of MS-ISA can
be configured under 3 distinct interfaces each bound a VRF. The IP reassembly
context is managed per VRF.
The PGW/GGSN supports a maximum of 64k IPv4 concurrent reassembly context
from a given GTP end-point.
3.6.3.3.2 IP ADDRESSING
The P-GW IP Address allocation scheme provides simultaneous support for IPv4 and
IPv6, including multiple context for a single subscriber. The following IP allocation
methods are supported in R4.0:
 Local IPv4 address and IPv6 prefix pools – directly assigned via APN
 HSS-static addresses – provided via GTP create
 IP Address Assignment via RADIUS
Page 166/273
The Named Local IP pool supports the inclusion/exclusion of address ranges, as well
as a configurable hold timer (after the closing of a session the hold timer needs to
expire before an address can be returned to the free address pool)
Maximum number of simultaneously configured IP local pools 100
Maximum number of IP pools per APN 8
Maximum number of IP subnets per IP pool 8
3.6.3.3.2.1 IP POOLS SUBNET SIZES
When local IP pools are configured (IPv4 or IPv6), UE IP addresses are allocated
upon PDN connection activation from the IP pool of prefixes associated with the
corresponding APN for that connection. The numbers of UE that can receive an IP
address from the pool depend on the subnet size derived from the subnet mask
length. For instance, up to 254 IP addresses can be allocated from a prefix having a
/24 subnet mask.
Although it is possible to configure subnet masks longer or shorter than /24 for IP pool
prefixes, special caution should be taken when multiple MG-ISMs are used in active
mode in the same PGW/system. Such a configuration inherently enables load-sharing
and therefore allows multiple bearers or PDP context for a given APN to be spread
across multiple MG-ISMs.
Address blocks from any given IP pool prefix are allocated to each MG-ISM on a /24
basis, i.e. per block of 254 addresses. If the subnet length mask of the IP pool prefix is
/24 or longer, all addresses will reside on a single MG-ISM only. Furthermore, as the
internal load balancing algorithm at CPM level for incoming PDN connection will try to
maintain equal load across the 2 MG-ISM (based on a per PDN connection round-
robin), a second PDN connection may never succeed to establish. By creating a /23
prefix for the IP local pool, a /24 block will be allocated to each MG-ISM, allowing
equal spread of PDN connections across the two MG-ISMs for a given APN.
It is recommended whenever possible to use subnet lengths of /23 or shorter for IP pool prefixes. It
is a mandatory requirement when multiple MG-ISMs are active in the PGW/GGSN to ensure proper
operation and load-sharing.
3.6.3.3.3 APN AND VPN INSTANCES
Maximum number of simultaneously configured APNs 2000
Maximum number of simultaneously configured VPRNs 2000
Page 167/273
Maximum number of simultaneously configured APNs per VPRN 100
Note: Multiple APN can be mapped to a single VPRN

3.6.3.3.4 QOS AND PCC RULES
The number of dynamic PCC rules includes the rules that are statically defined on the
P-GW and activated by the PCRF through the Gx interface.
Maximum number of configured (static) PCC rules 256K
Maximum number of dynamic PCC rules 256K
3.6.3.3.5 P-GW CHARGING
Maximum number of configured charging

255
profiles
Maximum Charging Data Records (CDRs)
2000/s at minimum, per MG-ISM
rate
Storage on system compact-
Memory available for temporary storage of 2x
flash: provides 100+h of storage
CDRs 64GB
(configuration dependant)
3.7 PCRF DIMENSIONING

This section covers the 5780 DSC dimensioning guidelines, focusing on deployment
based on the ATCA platform, with external subscriber database (SPR).
For more information on the 5780 DSC planning, please refer to the document “5780
DSC Planning, Installation and Upgrade Guide”.
3.7.1 5780 DSC CONFIGURATION & CAPACITY

3.7.1.1 5780 DSC HARDWARE
The 5780 DSC hardware is composed by two hardware components:
 CSB: the CSB hosts the DPA (Diameter Proxy Agent) of the DSC.
Each DPA instance is capable to handle:
- Up to 6 million (6 000 000) simultaneously attached bearers;
- Proxy up to 6 500 transactions per second (each transaction is a pair of

request-response)
 PCRF Blade: Each PCRF blade can handle:
Page 168/273
- Up to 1.2 million (1 200 000) simultaneously attached bearers;

- Up to 1 300 transactions per second (each transaction is a pair of
request-response)
The number of bearers depends on the number of default and dedicated

bearers.
- One default bearer will always be present from each attached

user
- Dedicated bearers might also be instantiated during the user

attachment (for QoS and charging purposes)
- Dedicated bearers might be instantiated upon AF requests
The number of transactions depends on the call flow scenarios, for

example:
- During the UE attachment, there is one Gx transaction (CCR-
CCA) and one SPR transaction (database query)
- A VoIP call setup involves one Rx transaction, one Gx transaction
NOTES: the 5780 DSC dimensioning is based on the number of attached bearers,
regardless if these bearers are active (i.e. sending / receiving data) in the network.
3.7.1.2 SPR DIMENSIONING IMPACT
In a typical deployment, the 5780 DSC retrieves the subscriber persistent information from an
external database (SPR, or Subscriber Profile Repository).
Part of the information required by the 5780 DSC is specific for the PCRF and the operator
needs to consider an additional 1kB disk space per subscriber entry in the SPR that requires
dynamic policy management (PCRF interactions).
Considering the impact in the dimensioning and typical hard-drive cost; the SPR dimensioning
impact is simplified to:
[SPR-specific Disk space] = [Number of Provisioned Subscribers] x 1kB
3.7.1.3 5780 DSC SOFTWARE LICENSING
The 5780 DSC enforces the software licenses in runtime, i.e. in the case that a license
is breached in the production network; new sessions will not be accepted / initiated by
the 5780 DSC.
The software license components associated with the 5780 DSC are:
Page 169/273
- 5780 DSC base license: for each ATCA blade, one 5780 DSC base license is
required
- 5780 DSC IP-CAN session license: in the LTE context, each default bearer
consumes one IP-CAN session in the 5780 DSC
- 5780 DSC AF session license: in the LTE context, each dedicated bearer
consumes one IP-CAN session in the 5780 DSC
The operator can keep track of the software licenses used in the 5780 DSC through
the 5780 DSC GUI, as presented in the snapshot below:
3.8 EPC INTERFACES DIMENSIONING
3.8.1 GN INTERFACE
3.8.1.1 GN INTERFACE DESCRIPTION
Gn interface is the reference point between MME and pre-release 8 SGSN. Gn relies
upon GTP tunnels (GTP-C for control plane). GTP tunnels are used between two
nodes communicating on a GTP-based interface to separate traffic into different
communication flows. General Packet Radio System (GPRS) Tunneling Protocol
Control Plane (GTPv1-C) is defined in 3GPP TS 23.060.
Gn interface enables handling of mobility and inter Radio Access Technology (I-RAT)
handover from LTE (4G) access network to WCDM (3G) or GSM (2G) access
network. Unlike SGSN which handles both user and control planes for Gn interface,
Page 170/273
MME only handles the control plane part of the Gn interface (the MME does not
support user plane interface to P-GW, SGSN will direct the user plane traffic to the P-
GW through Gn user plane).
Through Gn interface, the MME enables handing over from LTE (4G) to WCDM (3G)
or GSM (2G) radio access technologies. I-RAT features Reselection, Redirection and
PS handover mobility mode.
The figure below depicts Gn interface protocol stack, control part.
SGSN MME
GTPv1-C GTPv1-C
UDP UDP
IP IP
IPsec/UDP/IP Gn IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 45 : Gn interface protocol stack

Please note that LTE (4G) to eHRPD HOs are not supported. Only the configuration
where UE moving out of LTE coverage towards 2G or 3G network is considered.
Maximum Gn interface throughput is computed assuming PS handover mode, which
is the most bandwidth consuming mode.
3.8.1.2 GN INTERFACE DIMENSIONING
Similarly to S1-MME interface maximum throughput computation, number and size of

signaling messages per busy hour, which are exchanged through Gn interface, must
be taken into consideration. To keep Gn interface bandwidth computation simple, only
the main procedures which are exchanged over the interface will be considered further
in the computation exercise i.e procedures which are the most bandwidth consuming.
The main procedures to consider are listed below (details are given in 3GPP TS
23.401).
 Routing Area Update procedure takes place when a UE that is registered with
an MME selects a UTRAN or GERAN cell served by a Gn/Gp SGSN. In this
case, the UE changes to a Routing Area that the UE has not yet registered
with the network. The Routing Area Update procedure consists in the following
Page 171/273
messages exchanges over Gn interface: SGSN Context Request, SGSN

Context Response, SGSN Context Acknowledge
 Tracking Area Update procedure takes place when there is SGSN relocation
from 3G/2G to 4G which trigger SGSN context request from the new MME to
old SGSN. Tracking Area Update procedure consists in the following
messages exchanges over Gn interface: SGSN Context Request, SGSN
Context Response and SGSN Context.
 Inter-RAT PS handover consists in the following messages exchanges over

Gn interface during I-RAT: Forward Relocation Request, Forward Relocation
Response, Forward Relocation Complete and Forward Relocation Complete
Acknowledgement.
The characteristics of these procedures are described in the following table.
TAU MME- Incoming (DL) MME-Outgoing (UL)

Nb_msg_Proc(i) 1 message 2 messages
RAU MME- Incoming (DL) MME-Outgoing (UL)
Nb_msg_Proc(i) 2 messages 1 message
inter RAT 3GPP
MME- Incoming (DL) MME-Outgoing (UL)
(with PS handover)
Table 75 : Gn Interface Main Procedures
The required Gn interface bandwidth is computed according to the following formula

eNB_Gn_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_Gn_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface Gn is computed first.
in section 3.5 above.
 Avg_eNB_Gn_Throughput_Phy_DL/UL_Subs is the average Gn physical

throughput per eNodeB per subscriber (which contributes to Gn throughput),
which is computed according to the following formula:
Avg_eNB_Gn_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_Gn_Proc(i)_Throughput_Phy_DL/UL
Page 172/273
 Avg_eNB_Gn_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the Gn interface, which is computed according to the following
formula:
Avg_eNB_Gn_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_Gn_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_Gn_Proc(i) is the number of procedure_#i at busy hour per

subscriber (i.e BHCA figure for attach, TAU, RAU, etc). For each procedure
the figure is retrieved from Table 3.

procedure_#i (above GTP-C). For each procedure, the figure is retrieved from
the above table.

SGSN and MME for procedure_#i. For each procedure, the figure is retrieved
from the above table.

to account for transport overhead (GTP-C/UDP/IP/Ethernet plus optional
IPsec header). Transport_Header ranges from:
o Transport_Header = 78 bytes (IPv4 w/o Vlan, w/o IPsec)
o Transport_Header = 82 bytes (IPv4 w Vlan, w/o IPsec)
o Transport_Header = 138 bytes (IPv4 w/o Vlan, w IPsec)
o Transport_Header = 142 bytes (IPv4 w Vlan, w IPsec)
At MME side, the above computed eNodebB_Gn throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess Gn interface throughput
at MME level.
MME_Gn_Total_Throughput_Phy(DL/UL) =
N_eNBs x eNB_Gn_Throughput_Phy(DL/UL)
3.8.1.3 GN THROUGHPUT FIGURES EXAMPLE
Referring to the call model parameters, as they are given in Table 3 and Table 4, the
following throughput is expected at Gn-C interface level with the following assumption:
IPv4 w Vlan tagging w/o IPsec (EPC network is a trusted network). Gn-C throughput
figures (on a per eNodeB contribution basis):
Downlink: 5.62 Kbit/s;

Uplink: 6.14 Kbit/s.
Page 173/273
3.8.2 GX INTERFACE
3.8.2.1 GX INTERFACE DESCRIPTION
Gx interface is the reference point between P-GW and PCRF. Gx provides transfer of
(QoS) policy and charging rules from PCRF to the Policy and Charging Enforcement
entity which is embedded in the P-GW (Policy control encompasses gating control,
QoS control, QoS signalling, etc). Gx relies on Diameter protocol. Please refer to
section 2.1.4.6 for details about the PCRF supported features.
A Gx diameter session is established for each IP Connectivity Access Network (IP-
CAN) session. For IP-CAN types that support multiple IP-CAN bearers (applicable to
4G/LTE), the diameter session is established when the first IP-CAN bearer is set up i.e
the Default bearer for that IP-CAN session, is established.
P-GW PCRF
Diameter Diameter
SCTP/TCP SCTP/TCP
IP IP
IPsec/UDP/IP Gx IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 46 : Gx interface protocol stack

For the purpose to support Gx interface, Diameter can be transported either over TCP
or SCTP. So far, Alcatel-Lucent PCRF supports Diameter transport over TCP.
Gx interface Diameter messages which are exchanged between P-GW and PCRF, for
P-GW or UE based initiated use cases are Credit Control Request (CCR) in uplink (P-
GW to PCRF) and Credit Control Answer (CCA) in downlink (PCRF to P-GW) for the
following LTE procedures (details can be found in 3GPP 23.203, 23.401 and 29.213) :
 IP-CAN session establishment (Attach).
 IP-CAN session termination (Detach).

 IP-CAN session establishment (PDN session request/release triggered by
UE).
 IP-CAN Session modification with possible IP-CAN bearer establishment

(PDN session modification).
These procedures are trigged by UE or P-GW in the traffic model.

Page 174/273
Gx interface Diameter message which are exchanged between P-GW and PCRF, for
PCRF or network initiated uses cases are Re-Authorize Request (RAR) in downlink
(PCRF to P-GW) and Re-Authorize Answer (RAA) in uplink (P-GW to PCRF) for the
following LTE procedures:
 IP-CAN session termination (initiated by the network).
 IP-CAN Session modification
These procedures are trigged by Mobile Terminated call Event in the traffic
model. Network initiated procedures are not taken into consideration in the
present release of the document.
Note: IP-CAN session is the association between a UE and an IP network. The

association is identified by one IPv4 and/or an IPv6 prefix together with UE identity
information, if available, and a PDN represented by a PDN ID (e.g. an APN). An
IP-CAN session incorporates one or more IP-CAN bearers. Support for multiple
IP-CAN bearers per IP-CAN session is IP-CAN specific. An IP-CAN session exists as
long as UE IP addresses/prefix are established and announced to the IP network.
3.8.2.2 GX INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at Gx interface, must be
taken into consideration. To keep Gx interface bandwidth computation simple, only the
main procedures which are exchanged over the interface will be considered further in
the computation exercise i.e the procedures which are the most bandwidth
consuming.
The main procedures which are taken into consideration for Gx maximum throughput
computation are:
 IP-CAN session establishment (Attach with GUTI and authentication).
 IP-CAN session termination (Detach).
 IP-CAN session establishment (PDN session request/release triggered by

UE).
 IP-CAN Session modification with possible IP-CAN bearer establishment
(PDN session modification).
Page 175/273
The characteristics of these procedures are described in the table below.

Nbr_msg_Ack 0 0
Volume_Size_Proc(i) 200 bytes 252 Bytes
Nbr_msg_Ack 0 0
UE requested PDN
Downlink Uplink
connectivity
Nbr_msg_Ack 0 0
Dedicated bearer activation Downlink Uplink
Nb_msg_Proc(i) To be completed To be completed
Volume_Size_Proc(i) To be completed To be completed
Nbr_msg_Ack To be completed To be completed
Table 76: Gx Interface Main Procedures
Note that dedicated bearer activation procedure contribution will be provided in a
further release of the document (Network initiated procedures are not taken into
consideration in the present release of the document).
The required Gx interface bandwidth is computed according to the following formula

eNB_Gx_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_Gx_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface Gx is computed first.

 Avg_eNB_Gx_Throughput_Phy_DL/UL_Subs is the average Gx physical

throughput per eNodeB per subscriber (which contributes to Gx throughput),
Avg_eNB_Gx_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_Gx_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_Gx_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the Gx interface, which is computed according to the following
formula:
Page 176/273
Avg_eNB_Gx_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_Gx_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_Gx_Proc(i) is the number of procedure_#i at busy hour per

subscriber (i.e BHCA figure for attach, detach, session request, etc). For each
procedure the figure is retrieved from Table 3.

procedure_#i (at Gx Diameter level). For each procedure, the figure is
retrieved from the above table.
 Nb_msg_Proc(i)_DL/UL is the number of message exchanged between P-GW

and PCRF for procedure_#i. For each procedure, the figure is retrieved from
the above table.

to account for transport overhead (TCP/IP/Ethernet plus optional IPsec
header). Transport_Header ranges from (TCP header account for 32 bytes):

At P-GW side, the above computed eNodebB_Gx throughput has to multiplied by the
number of eNodeBs which are served by this P-GW to assess Gx interface throughput
at P-GW level.
P-GW_Gx_Total_Throughput_Phy(DL/UL) =
N_eNBs_P-GW x eNB_Gx_Throughput_Phy(DL/UL)
 N_eNBs_P-GW is the number of eNodeBs served by the P-GW.
At PCRF side, the above computed eNodebB_Gx throughput has to multiplied by the
number of eNodeBs which are served by this PCRF to assess Gx interface throughput
at PCRF level.
PCRF_Gx_Total_Throughput_Phy(DL/UL) =
N_eNBs_PCRF x eNB_Gx_Throughput_Phy(DL/UL)
 N_eNBs_PCRF is the number of eNodeBs served by the PCRF.
Page 177/273
3.8.2.3 GX THROUGHPUT FIGURES EXAMPLE
Referring to the call model parameters, as they given are in Table 3 and Table 4, the
following throughput is expected at Gx interface level with the following assumption:
IPv4 w Vlan tagging w/o IPsec (EPC network is a trusted network).
Gx throughput figures (on a per eNodeB contribution basis):

3.8.3 M1 INTERFACE
3.8.3.1 M1 INTERFACE DESCRIPTION
M1 interface is the reference point between MBMS GW and E-UTRAN/UTRAN for

MBMS data delivery. M1 interface is a bearer interface. It relies on GTPv1-U. Brief
MBMS introduction is given in section 3.8.18. M1 protocol stack is depicted in the
figure below:
eNodeB MBMS-GW
IP (user) IP (user)
GTP-U GTP-U
UDP UDP
IP (path) IP (path)
IPsec/UDP/IP M1 IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 47 : M1 interface protocol stack

MBMS functionality is not commercially supported in release LE6 (only for trials).
At M1 interface level, there is an additional SYNC protocol which is exchanged

between the broadcast Multicast service Center (BM-SC) and the eNodeB to enable
eNodeBs to identify the timing for radio frame transmission and detect packet loss.
Every MBMS service uses its own SYNC entity. The SYNC protocol is applicable to
DL and is terminated in the BM-SC.
Page 178/273
This section will be completed in a further release of the document.
3.8.3.2 M1 INTERFACE DIMENSIONING

3.8.3.3 M1 THROUGHPUT FIGURES EXAMPLE
3.8.4 M3 INTERFACE
3.8.4.1 M3 INTERFACE DESCRIPTION
M3 interface is the reference point between the MME and the eNodeB embedded
Multi-cell/multicast Coordination Entity (MCE). The MCE functions are described in
3GPP TS 36.300. Brief MBMS introduction is given in section 3.8.18. M3 interface
features an application part (M3-AP) for the purpose to allow for MBMS Session
Control Signaling on E-RAB level (i.e. it does not convey radio configuration data).
The procedures comprise e.g. MBMS Session Start and Stop. M3-AP is carried over
SCTP. M3 interface protocol stack is depicted in the figure below.
eNodeB MME
(MCE)
M3-AP M3-AP
SCTP SCTP
IP IP
IPsec/UDP/IP M3 IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 48 : M3 interface protocol stack

Page 179/273
3.8.4.2 M3 INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at M3 interface, must be
taken into consideration. To keep M3 interface bandwidth computation simple, only
in the computation exercise i.e the procedures which are the most bandwidth
consuming.
The main procedures which are taken into consideration for M3 maximum throughput
computation are (MBMS procedures are described in 3GPP TS 23.246):
3.8.4.3 M3 THROUGHPUT FIGURES EXAMPLE
3.8.5 S3 INTERFACE
3.8.5.1 S3 INTERFACE DESCRIPTION
S3 interface is the reference point between MME and release-8 SGSN (S4 SGSN). It
enables the MME to support handovers between a 3GPP UMTS or GERAN network
and an LTE network. S3 interface relies on GTP tunnels (GTPv2-C as described in
3GPP 29.274). S4-SGSN is a Release 8 SGSN featuring:
 S4 interface to the S-GW for user plane (media) while S3 interface provide
control plane to the MME.
 Handles EPS Bearer Contexts (to eliminate the need for the MME to perform
the mapping between the EPS Bearer Contexts and PDP Contexts).
This interface is used to exchange information between S4 SGSN and MME for the
following procedures:
 Tracking area update procedure with or without S-GW change, when UE

moves from UTRAN/GERAN to E-UTRAN coverage.
 Routing area update procedure with or without S-GW change, when UE
moves from E-UTRAN to UTRAN/GERAN coverage.
 Inter RAT handover procedure.
S3 interface protocol stack is the same as shown for Gn in Figure 45 above. Please
note however that Gn uses GTP-C v1 while S3 uses GTP-C v2. The protocol stack of
S3 interface is shown in Figure below:
Page 180/273
S4-SGSN MME
GTPv2-C GTPv2-C
UDP UDP
IP IP
IPsec/UDP/IP S3 IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 49: S3 interface protocol stack
3.8.5.2 S3 INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at S3 interface must be
taken into consideration. To keep S3 interface bandwidth computation simple, only the
the computation exercise i.e procedures which are the most bandwidth consuming.
The main procedures to consider are listed below.
 Routing area / Tracking area update (indeed SGSN context request / context
response / Acknowledgement messages exchanged over S3 during Routing
Area Update or during Tracking Area Update).
 Inter-RAT PS handover (indeed Forward relocation Request / Response /

Complete / Acknowledgement messages exchanged over S3 during I-RAT).
S3 interface is supported at Alcatel-Lucent MME level, but since S4 is not supported

at S-GW level, this interface is not applicable so far from ALU solution release
perspective
The required S3 interface bandwidth is computed according to the following formula

message differs from downlink to uplink): Same formulas as for Gn interface (please
refer to section 3.8.1.2 above.
This section will be completed in a further release of the document (when S3 interface
is supported at Alcatel-Lucent EPC level).
3.8.5.3 S3 THROUGHPUT FIGURES EXAMPLE
Page 181/273
3.8.6 S4 INTERFACE
S4 interface is the reference point between S-GW and release-8 SGSN (so called S4
SGSN). S4 interface enables the EPC to support handovers between a 3GPP UMTS
or GERAN network and an LTE network (it provides related control and mobility
support between GPRS Core and the 3GPP Anchor function of Serving GW). In
addition, if Direct Tunnel interface S12 is not established, S4 interface provides the
user plane tunneling between SGSN and S-GW. S4 interface relies on GTP tunnels
(GTP-U for user plane bearer and GTPv2-C for control plane). S4 interface protocol
stack is depicted in Figure below:
SGSN S-GW SGSN S-GW
GTP-U GTP-U GTPv2-C GTPv2-C
UDP UDP UDP UDP
IP IP IP IP
IPsec/UDP/IP S4-U IPsec/UDP/IP IPsec/UDP/IP S4-C IPsec/UDP/IP
Figure 50 : S4 interface protocol stack
S4-U: Assumption is made that the throughput computation follows the same principle
as described in section 3.5 for S1-U.
S4-C: Similarly to S1-MME interface maximum throughput computation, number and

size of signaling messages per busy hour, which are exchanged at S4-C interface,
must be taken into consideration. To keep S4-C interface bandwidth computation
simple, only the main procedures which are exchanged over the interface will be
considered further in the computation exercise i.e the procedures which are the most
bandwidth consuming.
The main procedures which are taken into consideration for S4-C maximum
throughput computation are:
Page 182/273
3.8.7 S5 INTERFACE
S5 interface is the reference point between S-GW and P-GW within the same Public
Land Mobile Network (PLMN). S5 relies on GTP tunnels (GTP-U for user plane and
GTPv2-C for control plane). Indeed S5-U interface is similar to S1-U interface,
assuming non packet fragmentation applies at S5-U interface level. S5-C interface
relies upon GTPv2-C as described in 3GPP 29.274. S5 interface protocol stack is
S-GW P-GW S-GW P-GW
GTP-U GTP-U GTPv2-C GTPv2-C
UDP UDP UDP UDP
IP IP IP IP
IPsec/UDP/IP S5-U IPsec/UDP/IP IPsec/UDP/IP S5-C IPsec/UDP/IP
Figure 51: S5 interface protocol stack

S5 interface sitting between the S-GW and the P-GW enables:
 Session Creation procedures
 Session Deletion procedures
 Downlink data Notification used for network service request scenario and
associated to MME paging procedures
 Modify bearer on TAU including Update Local Information reporting
as those described in section 3.5 for S1-U, i.e S5-U throughput equals to S1-U
throughput at S-GW level (i.e the resulting throughput figures, on a per eNodeB
contribution basis).
S5-C: Similarly to S1-MME interface maximum throughput computation, number and

size of signaling messages per busy hour, which are exchanged at S5-C interface,
Page 183/273
must be taken into consideration. To keep S5-C interface bandwidth computation

simple, only the main procedures which are exchanged over the interface will be
considered further in the computation exercise i.e the procedures which are the most
bandwidth consuming.
The main procedures which are taken into consideration for S5-C maximum
throughput computation are:
 Attach procedure (Attach with GUTI and authentication).
 Inter-eNB handover (X2 and S1)
 PDN session request
 Tracking area update (for all TAU such as those with location information P-
GW option as well as all voice CSFB use cases). Two different types of
configuration must be taken into account:
o Tracking Area update w/o MME/SGW relocation leads to modify

bearer request message on S5-C.
Note that in case of voice CSFB service activation, while voice CSFB
is in use, LTE resources are suspended, switching back from 2G/3G
to LTE leads to generate a Tracking Area update.
o Tracking Area update with MME or SGW relocation leads to a modify

bearer message on S5 similar in size to an Inter-eNodeB X2
Handover.
Page 184/273
Attach Downlink Uplink

Detach Downlink Uplink
Inter-eNB X2 HO Downlink Uplink
Inter-eNB S1 HO Downlink Uplink
PDN session request Downlink Uplink
TAU w/o MME/SGW
Downlink Uplink
reloc
TAU w/ MME or SGW
Downlink Uplink
reloc
Table 77: S5-C Interface Main Procedures
The required S5-C interface bandwidth is computed according to the following formula
eNB_S5-C_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_S5-C_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface S5-C is computed first.
 Avg_eNB_S5-C_Throughput_Phy_DL/UL_Subs is the average S5-C physical
throughput per eNodeB per subscriber (which contributes to S5-C throughput),
Avg_eNB_S5-C_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_S5-C_Proc(i)_Throughput_Phy_DL/UL
Page 185/273
 Avg_eNB_S5-C_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the S5-C interface, which is computed according to the
following formula:
Avg_eNB_S5-C_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_S5-C_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_S5-C_Proc(i) is the number of procedure_#i at busy hour per

Note that Nb_eNB_S5-C_Proc(i) equals to Nb_eNB_S1-MME_Proc(i) except

for the service activation and service release, as S5 takes care only of non
CSFB service.

the above table.
 Nb_msg_Proc(i)_DL/UL is the number of message exchanged between P-GW

and S-GW for procedure_#i. For each procedure, the figure is retrieved from
the above table.

IPsec header). Transport_Header ranges from (GTP-C v2 header account for
12 bytes):


At S-GW side, the above computed eNodebB_S5-C throughput has to multiplied by
the number of eNodeBs which are served by this S-GW to assess S5-C
interface throughput at S-GW level.
S-GW_S5-C_Total_Throughput_Phy(DL/UL) =
N_eNBs_S-GW x eNB_S5-C_Throughput_Phy(DL/UL)
 N_eNBs_S-GW is the number of eNodeBs served by the S-GW.
At P-GW side, the above computed eNodebB_S5-C throughput has to multiplied by

the number of eNodeBs which are served by this P-GW to assess S5-C
interface throughput at P-GW level.
Page 186/273
P-GW_S5-C_Total_Throughput_Phy(DL/UL) =
N_eNBs_P-GW x eNB_S5-C_Throughput_Phy(DL/UL)
 N_eNBs_P-GW is the number of eNodeBs served by the P-GW.
3.8.7.3 S5-C THROUGHPUT FIGURES EXAMPLE
following throughput is expected at S5-C interface level with the following
assumptions: IPv4 w Vlan tagging w/o IPsec (EPC network is a trusted network).
S5-C throughput figures (on a per eNodeB contribution basis):
3.8.8 S6A INTERFACE

3.8.8.1 S6A INTERFACE DESCRIPTION
S6a interface is the reference point between MME and Home Subscriber Server
(HSS) or a combined Equipment Identity Register (EIR)/HSS server. S6a allows
transfer of subscription and authentication data in order to authorize the users to
access to the evolved packet system network. S6a relies on Diameter protocol. S6a
interface protocol stack is described in the figure below:
MME HSS or combo EIR/HSS
Diameter Diameter
SCTP SCTP
IP IP
IPsec/UDP/IP S6a IPsec/UDP/IP
PHY (L1) PHY (L1)
Page 187/273
Figure 52 : S6a interface protocol stack

Note that in previous release S6a was making use of Diameter transport over TCP.
This is not true anymore, since SCTP is now used (at least from an end to end
solution release LE5).
.
3.8.8.2 S6A INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at S6a interface must be
taken into consideration. To keep S6a interface bandwidth computation simple, only
consuming.
The main procedures which are taken into consideration for S6a maximum throughput
computation are:
 Attach procedure
 Tracking area update
Tracking Area Update with MME relocation


Nbr_msg_Ack 0 0
PDN Session request Downlink Uplink
Nbr_msg_Ack 0 0
Tracking Area update Downlink Uplink
Nb_msg_Proc(i) 1 message 1 Message
Nbr_msg_Ack 0 0
Table 78: S6a Interface Main Procedures
The required S6a interface bandwidth is computed according to the following formula
eNB_S6a_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_S6a_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface S6a is computed first.

Page 188/273
 Avg_eNB_S6a_Throughput_Phy_DL/UL_Subs is the average S6a physical

throughput per eNodeB per subscriber (which contributes to S6a throughput),
Avg_eNB_S6a_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_S6a_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_S6a_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the S6a interface, which is computed according to the
following formula:
Avg_eNB_S6a_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_S6a_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_S6a_Proc(i) is the number of procedure_#i at busy hour per


procedure_#i (at S6a Diameter level). For each procedure, the figure is
 Nb_msg_Proc(i)_DL/UL is the number of message exchanged between MME

and HSS (or combo EIR/HSS) for procedure_#i. For each procedure, the
figure is retrieved from the above table.
header). Transport_Header ranges from (SCTP header account for 28 bytes):


At MME side, the above computed eNodebB_S6a throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess S6a interface throughput
at MME level.
Page 189/273
MME_S6a_Total_Throughput_Phy(DL/UL) =
N_eNBs_MME x eNB_S6a_Throughput_Phy(DL/UL)
 N_eNBs_MME is the number of eNodeBs served by the MME.
At HSS side, the above computed eNodebB_S6a throughput has to multiplied by the
number of eNodeBs which are served by this HSS to assess S6a interface throughput
at HSS level.
HSS_S6a_Total_Throughput_Phy(DL/UL) =
N_eNBs_HSS x eNB_S6a_Throughput_Phy(DL/UL)
 N_eNBs_HSS is the number of eNodeBs served by the HSS.
3.8.8.3 S6A THROUGHPUT FIGURES EXAMPLE
following throughput is expected at S6a interface level, with the following assumptions:
S6a throughput figures (on a per eNodeB contribution basis):
3.8.9 S8 INTERFACE
S8 interface is the reference point between S-GW and P-GW located in different
PLMN: Inter PLMN reference point providing user and control plane between S-GW in
the VPLMN and P-GW in the HPLMN. S8 is indeed a variant of S5.
S8 interface protocol stack is the same as S5 interface which is depicted in Figure 51.
as those described for S5-U interface in section 3.8.7.
S8-C: Assumption is made that the throughput computation follows the same principle
as those described for S5-C interface in section 3.8.7.
The resulting throughput figures, on a per eNodeB contribution basis, are given in
section 3.8.7.
Page 190/273
S8-U: Assumption is made that the throughput figure is similar to S5-U interface
(section 3.8.7), but corrected by a “roaming factor”.
S8-C: Assumption is made that the throughput figure is similar to S5-C interface
(section 3.8.7), but corrected by a “roaming factor”.
The resulting throughput figures, on a per eNodeB contribution basis, are given in
section 3.8.7.
3.8.10 S9 INTERFACE
3.8.10.1S9 INTERFACE DESCRIPTION
S9 interface is the reference point between PCRF located in different PLMN: Inter
PLMN reference point providing transfer of (QoS) policy and charging control
information between the Home PCRF and the Visited PCRF in order to support local
breakout function in roaming scenarios). S9 interface is described in 3GPP TS 29.215
S9 interface protocol stack is depicted in in the figure below (it is similar to Gx
interface protocol stack).
HPCRF VPCRF
Diameter Diameter
SCTP/TCP SCTP/TCP
IP IP
IPsec/UDP/IP S9 IPsec/UDP/IP
PHY (L1) PHY (L1)
3.8.10.2S9 INTERFACE DIMENSIONING

taken into consideration. To keep S9 interface bandwidth computation simple, only the
Page 191/273
the computation exercise i.e procedures which are the most bandwidth consuming.
The main procedures to consider are listed below. S9 messages exchanges are
described in 3GPP TS 29.215.
3.8.10.3S9 THROUGHPUT FIGURES EXAMPLE
3.8.11 S10 INTERFACE

S10 interface is the reference point between MMEs in the same or different MME
pools. S10 relies on GTP tunnels (GTPv2-C). S10 enables MME relocation and MME
to MME information transfer. S10 protocol stack is the same as S3 interface which is
described in Figure 49.

taken into consideration. To keep S10 interface bandwidth computation simple, only
in the computation exercise i.e procedures which are the most bandwidth consuming.
The main procedures to consider are listed below.

S11 interface is the reference point between MME and S-GW. S11 interface relies on
GTP tunnels (GTPv2-C as described in 3GPP 29.274).
S11 interface between MME and S-GW enables:
 Session Creation and Session Deletion
 Session Modification, Bearer modification

 Downlink data Notification used for network triggered service request
Page 192/273
 Indirect Data Forwarding Tunnel Creation and Deletion (Indirect Data

Forwarding Tunnel Request message is sent on S11, if the S-GW selected by
the MME for indirect data forwarding is different from the S-GW used as
anchor in case of S1-based handover, I-RAT handover, etc).
S11 protocol stack is the same as S3 interface which is described in section 3.8.5.
Note that GTP Echo Request and GTP Echo Response messages, which are used to
monitor the GTP tunnels between MME and S-GW, are not taken into consideration
for S11 throughput computation, since the contribution is not significant.

taken into consideration. To keep S11 interface bandwidth computation simple, only
consuming.
The main procedures which are taken into consideration for S11 maximum throughput
computation are:
 Attach procedure (attach with GUTI and authentication is assumed).
 Connection request (Setup and release).
Assumption is made that it is Service Request procedure and S1 release

 Inter-eNodeB Handovers (X2, S1 and Inter RAT)
 Paging procedure for network triggered service request (the service request
procedure )
Assumption is made that this is UE request PDN connectivity procedure (as

described in 3GPP TS 23.401).
 Tracking area update

Tracking Area Update procedure is split in two use cases:
o TAU w/o S-GW and MME relocation.
This comprises basic TAU w/o S-GW and MME relocation, as

described in Table 3 and TAU with SGSN relocation (TAU with SGSN
relocation is triggered when the UE goes from 3G/UTRAN to 4G/LTE
coverage).
Please note that for traffic model which includes Circuit Switch Fall
Back (CSFB), there’s an additional TAU event to take into
consideration since a TAU request message is triggered when the UE
returns back to E-UTRAN (i.e when CS service is terminated, the UE
Page 193/273
moves back to E-UTRAN, if the EPS service was suspended during

the CS service).
o TAU w S-GW and MME relocation

Connection request / release procedure Downlink Uplink
Inter-eNB X2 HO procedure Downlink Uplink
Inter-eNB S1 HO procedure Downlink Uplink
Inter-Rat HO procedure Downlink Uplink
eNodeB paging Downlink Uplink
PDN session request Downlink Uplink
Tracking Area update w/o MME/SGW relocation Downlink Uplink
Tracking Area update with MME or SGW relocation Downlink Uplink
Table 79: S11 Interface Main Procedures
eNB_S11_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_S11_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface S11 is computed first.

Page 194/273
 Avg_eNB_S11_Throughput_Phy_DL/UL_Subs is the average S11 physical

throughput per eNodeB per subscriber (which contributes to S11 throughput),
Avg_eNB_S11_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_S11_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_S11_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the S11 interface, which is computed according to the
following formula:
Avg_eNB_S11_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_S11_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_S11_Proc(i) is the number of procedure_#i at busy hour per


the above table.

and S-GW for procedure_#i. For each procedure, the figure is retrieved from
the above table.
12 bytes):

At MME side, the above computed eNodebB_S11 throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess S11
interface throughput at MME level.
Page 195/273
MME_S11_Total_Throughput_Phy(DL/UL) =
N_eNBs_MME x eNB_S11_Throughput_Phy(DL/UL)
At S-GW side, the above computed eNodebB_S11 throughput has to multiplied by the
number of eNodeBs which are served by this S-GW to assess S11
interface throughput at S-GW level.
S-GW_S11_Total_Throughput_Phy(DL/UL) =
N_eNBs_S-GW x eNB_S11_Throughput_Phy(DL/UL)
 N_eNBs_S-GW is the number of eNodeBs served by the S-GW.
following throughput is expected at S11 interface level, with the following assumptions:
S11 throughput figures (on a per eNodeB contribution basis):

S12 interface is the reference point between 3G UTRAN and the S-GW for user plane
tunnelling when Direct Tunnel is established. S12 interface is based on Iu-u/Gn-u
reference point using the GTP-U protocol as defined between SGSN and UTRAN or
respectively between SGSN and GGSN.
SGSN controls the user plane tunnel establishment and establish a Direct Tunnel
between UTRAN and S-GW as shown in the figure below (extract from 3GPP TS
23.401).
Page 196/273
Application
IP
IP
Relay Relay GTP -U

PDCP
PDCP GTP -U GTP -U GTP -U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
Uu Iu S5/S8 SGi
UE UTRAN Serving GW PDN GW

Referring to the Figure 54 above, S12 interface equals to Iu-u interface to enable
direct tunnel interconnection between 3G UTRAN and S-GW.
To be completed when S12 interface is supported at S-GW level.
Assumption is made that the throughput computation follows the same principle as
described in section 3.5 for S1-U.

S13 interface is the reference point between MME and the Equipment Identity
Register (EIR). S13 enables the UE Identity Check Procedure between the MME and
EIR to check that the UE has not been stolen, or it is operational. S13 Mobile
Equipment (ME) identity check procedures are described in 3GPP TS 29.272. Indeed
S13 protocol stack is similar to S6a protocol stack which is described in section
3.8.8.1. There are basically two procedures to be exchanged between MME and EIR
over S13 interface:
 ME identity check request
 ME identity check answer
These procedures are mapped in the Diameter application.
Page 197/273
When a combined EIR/HSS server is in use, the two above mentioned procedures are
exchanged over S13 interface sitting between the MME and the combined EIR/HSS.
The main procedure to consider for S13 interface is the attach procedure (the
corresponding call flow is described in 3GPP TS 23.401). The characteristics of these
procedures are described in the table below.

Nbr_msg_Ack 0 0
Table 80: S13 Interface Main Procedures
eNB_S13_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_S13_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface S13 is computed first.
 Avg_eNB_S13_Throughput_Phy_DL/UL_Subs is the average S13 physical

throughput per eNodeB per subscriber (which contributes to S13 throughput),
Avg_eNB_S13_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_S13_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_S13_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the S13 interface, which is computed according to the
following formula:
Avg_eNB_S13_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_S13_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
Page 198/273
 Nb_eNB_S13_Proc(i) is the number of procedure_#i at busy hour per


procedure_#i (at S13 Diameter level). For each procedure, the figure is

and EIR (or combo EIR/HSS) for procedure_#i. For each procedure, the figure
is retrieved from the above table.

header). Transport_Header ranges from (SCTP header account for 28 bytes):

At MME side, the above computed eNodebB_S13 throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess S13 interface throughput
at MME level.
MME_S13_Total_Throughput_Phy(DL/UL) =
N_eNBs_MME x eNB_S13_Throughput_Phy(DL/UL)
At EIR (or combo EIR/HSS) side, the above computed eNodebB_S13 throughput has
to multiplied by the number of eNodeBs which are served by this EIR (or combo
EIR/HSS) to assess S13 interface throughput at EIR (or combo EIR/HSS) level.
EIR_S13_Total_Throughput_Phy(DL/UL) =
N_eNBs_EIR x eNB_S13_Throughput_Phy(DL/UL)
 N_eNBs_HSS is the number of eNodeBs served by the EIR (or combo

EIR/HSS).
Page 199/273
following throughput is expected at S13 interface level, with the following assumptions:
S13 throughput figures (on a per eNodeB contribution basis):

3.8.15 SBC INTERFACE

3.8.15.1SBC INTERFACE DESCRIPTION
SBc interface is the reference point between the MME and the Cell Broadcasting
Center (CBC). SBc interface enables warning messages delivery in the Commercial
Mobile Alert System (CMAS) context (CMAS is the main alert system that allows
broadcasting short messages to UEs present in specific cells of the network for the
public warning service purpose).
SBc relies upon SBc Application Protocol (SBc-AP), which is described in 3GPP
29.168. SBc-AP supports Warning Message Transmission function: This functionality
provides the means to start, overwrite and stop the broadcasting of warning message
in support of the Public Warning System (PWS) messages which include Commercial
Mobile Warning System (CMAS) and Earthquake and Tsunami (ETWS) messages.
SBc-AP is carried over SCTP. SBc protocol stack is depicted in the figure below:
MME CBC
SBc-AP SBc-AP
SCTP SCTP
IP IP
IPsec/UDP/IP SBc IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 55: SBc interface protocol stack
Page 200/273
Note that in addition to SBc interface support, MME does require to support S1-AP
enhancements to enable CMAS warning notification transfer to eNodeB. These
enhancements are out of the scope of this document.
3.8.15.2SBC INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at SBc interface, must be
taken into consideration. To keep SBc interface bandwidth computation simple, only
consuming.
The main procedures which are taken into consideration for SBc maximum throughput
computation are:
 Write Replace Warning procedure. The purpose of this procedure is to start,

overwrite the broadcasting of warning message. This procedure comprise,
Write Replace Warning Request, sent from the CBC to the MME, and Write
Replace Warning Response, sent from the MME to the CBC.
 Stop Warning procedure. The purpose of this procedure is to stop the

broadcasting of warning message. This procedure comprise Stop Warning
Request, sent from the CBC to the MME, and Stop Warning Response, sent
from the MME to the CBC.
 Error indication procedure is initiated by a node to report detected errors in

one incoming message, provided they cannot be reported by an appropriate
failure message.
 Write Replace Warning Indication procedure is optionally sent by the MME to

report to the CBC the Broadcast Scheduled Area List, containing the
Broadcast Completed Area List the MME has received from the eNodeB(s).
3.8.15.3SBC THROUGHPUT FIGURES EXAMPLE
3.8.16 SGI INTERFACE

3.8.16.1 SGI INTERFACE DESCRIPTION
SGi interface is the reference point between the P-GW and the packet data network.
Packet data network may be an operator external public or private packet data
Page 201/273
network or an intra operator packet data network, e.g. for provision of IMS services.
SGi relies on IP.
SGi protocol stack is depicted in the figure below (the figure extract from 3GPP TS
23.401 shows UE to P-GW user plane with EUTRAN).
Application
IP IP
Relay Relay
PDCP GTP-U
PDCP GTP-U GTP-U
GTP-U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
LTE-Uu S1-U S5/S8 SGi

a
UE eNodeB Serving GW PDN GW
Figure 56 : SGi interface protocol stack
3.8.16.2SGI INTERFACE DIMENSIONING
3.8.16.3SGI THROUGHPUT FIGURES EXAMPLE
3.8.17 SGS INTERFACE

3.8.17.1SGS INTERFACE DESCRIPTION
SGs interface is the reference point between MME and MSC/VLR to support UEs
location coordination for the purpose to enable Circuit Switch Fall Back (CSFB). SGs
interface relies on SGs Application Protocol (SGsAP), which is described in 3GPP
29.118.
SGs interface supports a set of procedures which enable MME and MSC/VLR to
exchange information in order to allow location management coordination and to relay
certain messages related to circuit switched services over the EPS system:
 Coordinates location information of UEs that are IMSI attached to both EPS
and non-EPS services
 Relays certain messages related to circuit switched services over SGs to the
EPS.
Page 202/273
SGs interface association is applicable to the UEs which CSFB capability is activated
(applicable either to voice service or SMS service i.e SMS delivery via the circuit
switched core network). SGs interface protocol stack is depicted in the figure below.
MME VLR
SGsAP SGsAP
SCTP SCTP
IP IP
IPsec/UDP/IP SGs IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 57: SGS interface protocol stack

As stated in 3GPP 29.118, SCTP is used for the transport of SGsAP messages
between MME and MSC/VLR.
3.8.17.2SGS INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at SGs interface must be
taken into consideration. To keep SGs interface bandwidth computation simple, only
consuming. SGs interface throughput relies upon the exchange of specific messages
for particular CSFB use cases. These use cases are Mobile Originating (MO), Mobile
Terminating (MT) voice and SMS calls and I-RAT.
 Mobile Originating CSFB voice and SMS.
For Mobile Originating voice and SMS use cases, assumption is made that the
UE is in idle mode and camped on eNodeB.
Voice call is initiated via UE triggered Service Request. Service Request is

“Extended Service Request with CS Fallback Indicator”. The Initial Context
Setup Request from MME to eNodeB has “CS Fallback Indicator” set. The
eNodeB then performs voice traffic redirection (to 2G or 3G radio access
network), which results in immediate release of S1 and RRC connections
Page 203/273
while the voice call proceeds on 2G/3G network. Upon completion of voice
call, UE will initiate a Tracking Area Update (TAU) to return back to LTE.
 Mobile Terminating CSFB voice and SMS (network triggered service request)
For Mobile Terminating voice and SMS use cases, a CSFB voice or SMS call
results in: Page, BHCA (Service Request + S1 release) and TAU (for voice
only).
 Inter RAT (for Packet Service Handover MSC/VLR Location update)
For Inter RAT events on implicit Redirection when the UE moves out of LTE
coverage and has registered in UTRAN/GERAN (RRC disconnection applies)
With the above mentioned assumptions, the following procedures (and messages
exchanges over SGs) are the main procedure to take into consideration for SGs
interface throughput computation (interface SGs call flows are described in 3GPP TS
23.272):
 Attach (through location update request and location update accept).
 Detach (through detach indication and detach acknowledgment).
 Paging procedure (SGs paging request message).
 Service request (Extended service CSFB indicator through SGs service

request).
 Tracking area update (Location update request and accept).
 Inter RAT (SGs Location update/accept).
 CSFB SMS.
The characteristics of the main procedures are described in the tables below.
Page 204/273
Attach MME- Incoming (DL) MME-Outgoing (UL)

Nb_msg_Ack 0 0
Detach MME- Incoming (DL) MME-Outgoing (UL)
Volume_Size_Proc(i) 11 Bytes 71 bytes
Nb_msg_Ack 0 0
Paging MME- Incoming (DL) MME-Outgoing (UL)
Nb_msg_Proc(i) 1 message 0
Volume_Size_Proc(i) 69 Bytes 0
Nb_msg_Ack 0 0
Service request w/ extended
MME- Incoming (DL) MME-Outgoing (UL)
request
Nb_msg_Proc(i) 0 1 message
Volume_Size_Proc(i) 0 51 Bytes
Nb_msg_Ack 0 0
TAU (MO SMS and Voice call) MME- Incoming (DL) MME-Outgoing (UL)
Nb_msg_Ack 0 0
CSFB SMS (MT) MME- Incoming (DL) MME-Outgoing (UL)
Nb_msg_Ack 0 0
CSFB SMS (MO) MME- Incoming (DL) MME-Outgoing (UL)
Nb_msg_Ack 0 0
Table 81: SGs Interface Main Procedures
The required SGs interface bandwidth is computed according to the following formula
eNB_SGs_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_SGs_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface SGs is computed first.

Page 205/273
 Avg_eNB_SGs_Throughput_Phy_DL/UL_Subs is the average SGs physical

throughput per eNodeB per subscriber (which contributes to SGs throughput),
Avg_eNB_SGs_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_SGs_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_SGs_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the SGs interface, which is computed according to the
following formula:
Avg_eNB_SGs_Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_SGs_Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_SGs_Proc(i) is the number of procedure_#i at busy hour per

subscriber (i.e BHCA figure for attach, detach, paging, etc). For each

procedure_#i (at SGs-AP level). For each procedure, the figure is retrieved
from the above tables.

MSC/VLR and MME for procedure_#i. For each procedure, the figure is
retrieved from the above tables.

header). Transport_Header ranges from (SCTP header account for 28 byets):


At MME side, the above computed eNodebB_SGs throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess SGs interface
throughput at MME level.
MME_SGs_Total_Throughput_Phy(DL/UL) =
N_eNBs x eNB_SGs_Throughput_Phy(DL/UL)
Page 206/273
3.8.17.3SGS THROUGHPUT FIGURES EXAMPLE
Referring to the call model parameters, as they given in Table 3 and Table 4, the
following throughput is expected at SGs interface level, with the following
assumptions: IPv4 w Vlan tagging w/o IPsec (EPC network is a trusted network).
SGs throughput figures (on a per eNodeB contribution basis):

3.8.18 SM INTERFACE
3.8.18.1SM INTERFACE DESCRIPTION
Sm interface is the reference point between the MME and the Multimedia
Broadcast/Multicast Service (MBMS) Gateway.
Sm interface features Sm Application Protocol (Sm-AP) for the purpose to support

signalling & control functions. The signalling functions include Session Management,
such as start, stop, and update MBMS sessions. Sm-AP is carried over GTPv2-C. Sm
protocol stack is depicted in the figure below.
MME MBMS-GW
Sm-AP Sm-AP
GTPv2-C GTPv2-C
UDP UDP
IP IP
IPsec/UDP/IP Sm IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 58: Sm interface protocol stack
MBMS is a point-to-multipoint service in which data is transmitted from a single source

entity to multiple recipients. Transmitting the same data to multiple recipients allows
network resources to be shared. The MBMS bearer service offers two modes of
Page 207/273
operation: Broadcast Mode where any subscriber which is located in an area served
by the service can receive data and Multicast Mode where only subscribers having
subscribed to the service and having joined the multicast group associated with this
service can receive data.
In the Evolved Packet System a functional entity MBMS GW exists at the edge
between the Core Network and the Broadcast Multicast Service Centre (BM-SC).
The MBMS gateway (MBMS-GW) has the role to broadcast the packets to all
eNodeBs within a service area, as well as MBMS session management (like session
Start and Session Stop). It is also in charge of collecting charging information relative
to the distributed MBMS traffic for each terminal having an active MBMS session
The Broadcast Multicast service Centre (BM-SC), is the functional entity in charge of
providing the service to the end-user. The BM-SC is an entry point for content
providers or any other broadcast/multicast source which is external to the network.
The main functions for BM-SC are providing authorization for terminal requesting to
activate an MBMS service, announcement and scheduling of broadcast/Multicast
sessions with the terminals and the integrity and confidentiality of the MBMS data.
3.8.18.2SM INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at Sm interface, must be
taken into consideration. To keep Sm interface bandwidth computation simple, only
consuming.
The main procedures which are taken into consideration for Sm maximum throughput
computation are (MBMS procedures are described in 3GPP TS 23.246):
3.8.18.3SM THROUGHPUT FIGURES EXAMPLE
3.8.19 SV INTERFACE
3.8.19.1SV INTERFACE DESCRIPTION
Sv interface is the reference point between MME and MSC/VLR to enable Single
Radio Voice Call Continuity (SRVCC). This interface is used to support Inter-RAT
handover from IMS based voice service over EPS to CS domain over 3GPP
UTRAN/GERAN access. Sv interface is used by MME to trigger SRVCC procedure
towards MSC/VLR. The core network must support SRVCC procedures to handover
from E-UTRAN to 3GPP UTRAN/GERAN (as described in 3GPP TS 23.216 the UE
Page 208/273
detects that the network support SRVCC from MME reply to the UE Attach request
message). The UE must support the SRVCC procedures (a SRVCC capable terminal
indicates support for SRVCC in the MS network capability parameter which is set in
the attach message and in the tracking area / routing area update messages). Sv
relies on GTPv2-C which is described in 3GPP 29.274. Sv interface protocol stack is
MME MSC/VLR
GTPv2-C GTPv2-C
UDP UDP
IP IP
IPsec/UDP/IP Sv IPsec/UDP/IP
PHY (L1) PHY (L1)
Figure 59 : Sv protocol stack

Note that MME supports SRVCC capability from 3GPP E-UTRAN to 3GPP
GERAN/UTRAN only. SRVCC through S102 interface to eHRPD (non 3GPP) is not
supported.
3.8.19.2SV INTERFACE DIMENSIONING

signaling messages per busy hour, which are exchanged at Sv interface, must be
taken into consideration. To keep Sv interface bandwidth computation simple, only the
the computation exercise i.e the procedures which are the most bandwidth
consuming.
The main procedure which is taken into consideration for Sv maximum throughput
computation is:
 Inter-RAT SRVCC Ho (with SRVCC PS to CS Request, SRVCC PS to CS

Response, SRVCC PS to CS Complete Notification and SRVCC PS to CS
Complete Acknowledge procedures)
The characteristics of this procedure are described in the table below.
Page 209/273
Inter-RAT SR-VCC
Handover procedure Downlink Uplink

Nbr_msg_Ack 0 0
Table 82: Sv Interface Main Procedures
The required Sv interface bandwidth is computed according to the following formula
eNB_Sv_Throughput_Phy_DL/UL =
PtA_B x N_Subs x Avg_eNB_Gx_Throughput_Phy_DL/UL_Subs
 Per eNodeB contribution to interface Sv is computed first.
 Avg_eNB_Sv_Throughput_Phy_DL/UL_Subs is the average Sv physical
throughput per eNodeB per subscriber (which contributes to Sv throughput),
Avg_eNB_Sv_Throughput_Phy_DL/UL_Subs =
∑i Avg_eNB_Sv_Proc(i)_Throughput_Phy_DL/UL
 Avg_eNB_Sv_Proc(i)_Throughput_Phy_DL/UL is the throughput for

procedure_#i at the Sv interface, which is computed according to the following
formula:
Avg_eNB_Sv _Proc(i)_Throughput_Phy_DL/UL =
Nb_eNB_Sv _Proc(i) x [Volume_Size_Proc(i)_DL/UL +
 Nb_eNB_Sv_Proc(i) is the number of procedure_#i at busy hour per

procedure_#i (at Sv Diameter level). For each procedure, the figure is
and MSC/VLR for procedure_#i. For each procedure, the figure is retrieved
from the above table.
Page 210/273

12 bytes):
At MME side, the above computed eNodebB_Sv throughput has to multiplied by the
number of eNodeBs which are served by this MME to assess Sv interface throughput
at MME level.
MME_Sv_Total_Throughput_Phy(DL/UL) =
N_eNBs_MME x eNB_Sv_Throughput_Phy(DL/UL)
At MSC/VLR side, the above computed eNodebB_Sv throughput has to multiplied by

the number of eNodeBs which are served by this MSC/VLR to assess Sv interface
throughput at MSC/VLR level.
MSC/VLR_Sv_Total_Throughput_Phy(DL/UL) =
N_eNBs_MSC/VLR x eNB_Sv_Throughput_Phy(DL/UL)
 N_eNBs_MSC/VLR is the number of eNodeBs served by the MSC/VLR.
3.8.19.3SV THROUGHPUT FIGURES EXAMPLE
Referring to the call model parameters, as they given in Table 3 and Table 4, the
following throughput is expected at SGs interface level, with following asumptions:
Sv throughput figures (on a per eNodeB contribution basis):
Page 211/273
4 LTE INTERFACE MONITORING:

TROUBLESHOOTING & CAPACITY GROWTH
ACTIONS
This part of the document aims to present:
 Methods for LTE system capacity evaluation based on monitoring information.
 Monitoring information, product capability and target QoS information

(provided by the operators), and some critical triggers that can be used to
support capacity extension decisions and/or troubleshooting actions.
Available capacity monitoring counters as well as monitoring and troubleshooting

methods will be provided for the different LTE Network elements and interfaces
presented in Chapter 3.
4.1 CAPACITY MONITORING & TROUBLESHOOTING PRINCIPLE

In principle, capacity monitoring is looking at two main indicators for each NE:
 Call Admission blocking (due to lack of resources) – this is applicable only

for resources that may block the traffic admission (block new calls for
instance) when the congestion limit is reached.
Call Admission Blocking (%) =1 - # Call_Success / # Call_Request
 Resource load which can be separately evaluated in order to estimate the

current resource load comparing to some critical threshold that may trigger a
capacity/optimization action. This step is particularly important for resources
that are not part of call admission control mechanism (non traffic blocking
resources).
Resource Load (%) = Resources used / Total resources available
The decision of resource capacity extension should be based on a combination of the

two above indicators (as in the diagram below):
Page 212/273
1 Resource type =
2
tra ffic blocking No
Yes
Resource type
dependa nt step
Resource No No corrective No Resource Loa d ≥

is Blocking
action required critica l threshold
the tra ffic
Yes
Yes
Resource Loa d ≥ No Capacity analysis

critica l threshold /tuning is required
Yes
Capacity optim./tuning
and/or
Resources addition
are required
Figure 60 : Capacity Monitoring & Troubleshooting Principle
The two main capacity monitoring elements in the above diagram can be described as
follows:
1. For resources that may generate traffic blocking (resources considered in Call
Admission Control [CAC] algorithm):
 If no blocking is detected => No corrective action is required
 If blocking occurs, an additional level of investigation is needed:
o Load is Low (below a predefined threshold, also called Critical

Threshold) => Capacity analysis and tuning are required
o Load is High (above a predefined threshold) => Capacity analysis and

tuning are required and most probably (depending on tuning results),
new resource needs to be added.
Note: The Critical Threshold is computed for each resource and is

generally based on the engineering dimensioning rules presented in
Chapter 3.
2. For resources not considered in CAC algorithm:
 If low load of resource is monitored => No corrective action is required
Page 213/273
 If resource is loaded above a critical threshold => Capacity analysis and

tuning are required and most probably (depending on tuning results), new
resource needs to be added.
Note: The monitoring indicators presented in this section are either raw counters or
monitoring metrics (computed based on combinations of raw counters).
For the monitoring metrics the current NPO (Network Performance & Optimization
tool) implemented indicators will be presented, with the associated metric name and
identifier. In addition the formula used for the metric computation will be also
presented.
4.2 AIR INTERFACE CAPACITY MONITORING
4.2.1 AVAILABLE INDICATORS FOR AIR INTERFACE CAPACITY

EVALUATION
The following list of LA6.0 counters indicate call blocking due to Physical Radio Block
(PRB) shortage:
 VS_PRB_PoolOverload_CAC_DL_NbEvt (L13213_1_NbEvt) is a NPO

monitoring indicator directly based on the eNB raw counter
VS.DLPRBsPoolOverloadScreened.CAC. This indicator provides the number
of occurrences of the triggered event. The counter is triggered each time that
the Call Admission Control is performed on new call or bearer admission on
the cell and fails due to lack of PRB resource – DL PRB Pool occupancy is
above the MIM parameter DlAdmissionThreshold in RadioCacCellMO.
 VS_PRB_PoolOverload_CAC_UL_NbEvt (L13214_1_NbEvt) is a NPO

VS.ULPRBsPoolOverloadScreened.CAC. This indicator provides the number
of occurrences of the triggered event. The counter is triggered each time that
the Call Admission Control is performed on new call or bearer admission on
the cell and fails due to lack of PRB resource – UL PRB Pool occupancy is
above the MIM parameter DlAdmissionThreshold in RadioCacCellMO.
The following list of LA6.0 counters indicate load usage of Physical Radio Block (PRB)
resource on different scheduling mechanism:
 VS_DynamicScheduling_OnPDSCH_PRBUsed_FreqDiverseUsers
(L12015_0) is a NPO monitoring indicator based on ENB raw counter:
VS.DLPRBUsedWithDynamicSchedulingPerUserCategory.FDUsers. It
provides the total number of PRBs that have been assigned by the uplink
dynamic scheduler on PUSCH for users that have been categorized as
Frequency Diverse users. PRBs used for both initial packet transmissions and
HARQ retransmissions are included.
 VS_DynamicScheduling_OnPDSCH_PRBUsed_FreqSelectUsers
VS.DLPRBUsedWithDynamicSchedulingPerUserCategory.FSUsers. It
Page 214/273
Frequency Selective users. PRBs used for both initial packet transmissions
and HARQ retransmissions are included.
 VS_SPS_OnPDSCH_PRBUsed (L12044) is a NPO monitoring indicator
based on ENB raw counter: VS.DLPRBUsedWithSemiPersistentScheduling.
This indicator provides the total number of PRBs that have been used by the
downlink SPS (Semi-Persistent Scheduler) on PDSCH. The counter is
triggered when downlink semi-persistent scheduler submits initial transmission
data for a SPS user bearer in its PRB allocation. Action: the total number of
downlink PRBs that have been assigned for this SPS user is added to the
counter.
 VS_DynamicScheduling_OnPUSCH_PRBUsed_FreqDiverseUsers
VS.ULPRBUsedWithDynamicSchedulingPerUserCategory.FDUsers. It
Frequency Diverse users. PRBs used for both initial packet transmissions and
HARQ retransmissions are included.
 VS_DynamicScheduling_OnPUSCH_PRBUsed_FreqSelectUsers
VS.ULPRBUsedWithDynamicSchedulingPerUserCategory.FSUsers. It
Frequency Selective users. PRBs used for both initial packet transmissions
and HARQ retransmissions are included.
 VS_SPS_OnPUSCH_PRBUsed (L12048) is a NPO monitoring indicator

based on ENB raw counter: VS.ULPRBUsedWithSemiPersistentScheduling.
This indicator provides the total number of PRBs that have been used by the
downlink SPS (Semi-Persistent Scheduler) on PUSCH. The counter is
triggered when UE makes initial transmission on the allocated PRB for a SPS
bearer. Action: the total number of uplink PRBs that have been actually used
for this SPS user is added to the counter.
In order to get an evaluation of the average rate bandwidth occupation on a DL

channel, including controls channels, and characterized by a maximum number of
PRB/ms, the following formula is proposed:
Page 215/273
Where, PRB_DL_Rate (Value) = PRB_DL_Rate (%) * 100
Example:
For a 10 MHz DL Channel, 50 PRB/ms and BOP of 15 min = 900s:
PRB_DL_Rate_10MHz_50PRB_900s =
{ VS_DynamicScheduling_OnPDSCH_PRBUsed_FreqDiverseUsers +
VS_DynamicScheduling_OnPDSCH_PRBUsed_FreqSelectUsers +
VS_SPS_OnPDSCH_PRBUsed +
900 x [ 1800 + 2 x (VS_UE_RRC_connected_avg_PerCell) ] }
/ ( 50 x 1000 x 900) x 100
Similarly, and in order to get an evaluation of the average rate bandwidth occupation
on a UL channel, including controls channels, and characterized by a maximum
number of PRB/ms, the following formula is proposed:
Page 216/273
Example:
For a 10 MHz UL Channel, 50 PRB/ms and BOP of 15 min = 900s:
PRB_UL_Rate_10MHz_50PRB_900s =
{ VS_DynamicScheduling_OnPUSCH_PRBUsed_FreqDiverseUsers +
VS_DynamicScheduling_OnPUSCH_PRBUsed_FreqSelectUsers +
VS_SPS_OnPUSCH_PRBUsed +
900 x [ 4700 + 1 x (VS_UE_RRC_connected_avg_PerCell)] }
/ ( 50 x 1000 x 900) x 100
The following list of LA6.0 indicators represent the data volume transferred on the air
interface (RLC layer) during the observation period.
Implicitly, an average Throughput may be computed by dividing these values (Kbytes)

to the observation period (seconds):
 VS_ERABs_NonGBR_RLC_PDU_UP_kiByte_DL (L12105_2) is a NPO

VS.DLRlcPduKbytes.NonGBR. It indicates the number of DL Kbytes (RLC
level) transferred during the observation period on the Non Guaranteed Bit
Rate (NonGBR) bearers established in the LTE cell.
 VS_ERABs_NonGBR_RLC_PDU_UP_kiByte_UL (L12106_2) is a NPO

VS.ULRlcPduKbytes.NonGBR. It indicates the number of UL Kbytes (RLC
level) transferred during the observation period on the Non Guaranteed Bit
Rate (NonGBR) bearers established in the LTE cell.
 VS_ERAB_VoIP_RLC_PDU_UP_kiByte_DL (L12105_0) is a NPO

VS.DLRlcPduKbytes.VoIP. It indicates the number of DL Kbytes (RLC level)
transferred during the observation period on the VoIP bearers established in
the LTE cell.
 VS_ERAB_VoIP_RLC_PDU_UP_kiByte_UL (L12106_0) is a NPO

VS.ULRlcPduKbytes.VoIP. It indicates the number of UL Kbytes (RLC level)
transferred during the observation period on the VoIP bearers established in
the LTE cell.
 VS_ERABs_GBR_WithoutVoIP_RLC_PDU_UP_kiByte_DL (L12105_1) is a
NPO monitoring indicator directly based on the eNB raw counter
VS.DLRlcPduKbytes.otherGBR. It indicates the number of DL Kbytes (RLC
Page 217/273
level) transferred during the observation period on the Guaranteed Bit Rate
(GBR) bearers established in the LTE cell.
 VS_ERABs_GBR_WithoutVoIP_RLC_PDU_UP_kiByte_UL (L12106_1)
is a NPO monitoring indicator directly based on the eNB raw counter
VS.ULRlcPduKbytes.otherGBR. It indicates the number of UL Kbytes (RLC
level) transferred during the observation period on the Guaranteed Bit Rate
(GBR) bearers established in the LTE cell.
4.2.2 MONITORING METHOD & CRITICAL TRIGGERS

4.2.2.1 AVERAGE AGGREGATE CELL THROUGHPUT
The above mentioned data volume indicators can be used to compute the average cell
throughput during the observation period. For that the total DL and UL volume will
need to be evaluated with the following new indicators:
 VS_ERABs_all_RLC_PDU_UP_kbyte_DL =
VS_ERABs_NonGBR_RLC_PDU_UP_kbyte_DL +
VS_ERAB_VoIP_RLC_PDU_UP_kbyte_DL +
VS_ERABs_GBR_WithoutVoIP_RLC_PDU_UP_kbyte_DL
 VS_ERABs_all_RLC_PDU_UP_kbyte_UL =
VS_ERABs_NonGBR_RLC_PDU_UP_kbyte_UL +
VS_ERAB_VoIP_RLC_PDU_UP_kbyte_UL +
VS_ERABs_GBR_WithoutVoIPRLC_PDU_UP_kbyte_UL
The two above mentioned indicators will be used to determine the cell Busiest
Observation Period during the day in terms of DL and UL data volume transferred
(Referred to as BOP_DL and BOP_DL) and also to compute the average throughput
for the BOP_DL/UL duration.
Rule: Busiest Observation Period (BOP) duration
In order to obtain a significant value for the average cell throughput, the BOP_DL_duration and
BOP_UL_duration need to be as small as possible. It’s recommended to use the smallest counter
reporting period (15 min = 900 sec)
The DL/UL cell average throughput (in Mbps) will be computed with the following
formulas:
Avg_Cell_Mbps_BOP_DL=
VS_ERABs_all_RLC_PDU_kbyte_DL x 8 / (BOP_DL_duration x 1000)

Page 218/273
Avg_Cell_Mbps_BOP_UL=
VS_ERABs_all_RLC_PDU_kbyte_UL x 8 / (BOP_UL_duration x 1000)
Where BOP_DL/UL_durration is in units of seconds (15 min = 900 sec).
ALU's recommended engineering target is 70% of the capacity limit (Table 8 & 9).
The table below shows engineering target of average cell throughput for the supported
LA6.0 bandwidths and radio configurations:
target value
Radio configuration Bandwidth
(Critical threshold)
3 MHz 1.1 Mbps
5 MHz 2.1 Mbps
UL 2RxDiv
10 MHz 4.2 Mbps
20 MHz 8.6 Mbps
3 MHz 2.5 Mbps
5 MHz 4.2 Mbps
DL MIMO2x2
10 MHz 8.4 Mbps
20 MHz 16.8 Mbps
Table 83 : Air Interface Average Cell Throughput Engineering Targets
4.2.2.2 PRB CONSUMPTION
One of the most important indicators of air interface resource consumption is PRB
utilization. As calculated in chapter 4.2.1 respectively for DL and UL 10MHz, the 2
reference indicators for a Busiest Observation Period of 15mn (BOP=900s) are:
 DL: PRB_DL_Rate_10MHz_50PRB_900s
 UL: PRB_UL_Rate_10MHz_50PRB_900s
ALU recommends 70% PRB utilization as the warning threshold and 90% as the
critical threshold.
The effect of PRB overload can be seen when the following 2 indicators have non-
zero values:
 DL: VS_PRB_PoolOverload_CAC_DL_NbEvt or
 UL: VS_PRB_PoolOverload_CAC_UL_NbEvt
Page 219/273
The Air interface capacity monitoring critical path diagram can be resumed by the
following figure:
Figure 61 : Air Interface Capacity Monitoring Decision Tree
Page 220/273
4.3 ENB CAPACITY MONITORING

4.3.1 ENB CAPACITY LIMITS
As mentioned in Chapter 3.2, the eNB may be limited by the following user plane
resources:
 Number of Users per Modem board (or per cell)
 Number of Bearers per Modem board (or per cell)
A second set of resources can be checked:

 Number of Users per Controller board (or per eNB)
 Number of Bearers per Controller board (or per eNB)
The second set of resources is not the limiting factor as long as parameters are set
appropriately. Both resource blocking and resource load should be considered for the
above indicators.
4.3.2 AVAILABLE MONITORING INDICATORS FOR ENB CAPACITY

EVALUATION
4.3.2.1 MONITORING INDICATORS FOR USER PLANE BLOCKING
EVALUATION
In LA 6.0, following monitoring indicators can be used to detect call admission

blocking problems due to lack of Number of User resources:
 VS_RRC_cnx_fail_CAC (L12304_0) is a NPO monitoring indicator directly

based on the eNB raw counter RRC.ConnEstabFail.CACFailure. It indicates
the number of user connections (RRC connection requests) that were refused
in a cell, during the observation period, due to lack of number of users
resources.
 VS_RRC_cnx_fail_CAC_rate (L12304_21_CI) this is a NPO monitoring

indicator computed based on two other monitoring metrics:
VS_RRC_cnx_fail_CAC_rate = VS_RRC_cnx_fail_CAC / VS_RRC_cnx_req
It indicates the percentage (%) of RRC Connection requests that were

rejected from the total number of RRC Connection requests, due to Lack of
Nb of users resources (it is also computed per cell and during the observation
period)
The two metrics in VS_RRC_cnx_fail_CAC_rate formula are computed based

on eNB raw counters as follows:
VS_RRC_cnx_fail_CAC = RRC.ConnEstabFail.CACFailure
VS_RRC_cnx_req =
Page 221/273
RRC.ConnEstabAtt.EmergencyCallAttempts +
RRC.ConnEstabAtt.HighPriorityAccessAttempts +
RRC.ConnEstabAtt.PageResponsesReceived +
RRC.ConnEstabAtt.MobileOriginatedSignalling
+ RRC.ConnEstabAtt.MobileOriginatedUserBearer
+ RRC.ConnEstabAtt.Other
-
RRC.ConnEstabFail.InterventionOAM
Monitoring indicators for bearer establishment blocking problems due to lack of

bearer resources:
 VS_UE_ctxt_setup_fail_CAC (L12503_0) is a NPO monitoring indicator

directly based on the eNB raw counter
VS.InitialContextSetupFailed.CACFailure. It indicates the number of UE
context setups that failed (in a cell), during the observation period, due to Lack
of Bearer resources. A non null value of this counter is indication that not
enough bearers were available for call setup (leading to call reject).
 VS_ERABs_proc_setup_fail_CAC (L12603_0) is a NPO monitoring indicator

directly based on the eNB raw counter VS.ERABSetupFailed.CACFailure. It
indicates the number of bearer setup procedures that failed (in a cell), during
the observation period, due to Lack of Bearer resources. A non null value of
this counter is indication that not enough bearers were available for new
bearer addition to existing calls (not impacting the current call)
 VS_UE_ctxt_setup_fail_CAC_rate (L12503_21_CI) this is a NPO monitoring

indicator computed based on two other monitoring metrics:
VS_UE_ctxt_setup_fail_CAC_rate = VS_UE_ctxt_setup_fail_CAC /
VS_UE_ctxt_setup_req
It indicates the percentage (%) of UE context setups that are failing the total
number of UE Context setups, due to Lack of Bearer resources (it is computed
per cell, during the observation period). This indicator measures the impact of
lack of bearer resources on the call establishment success.
The two metrics in VS_UE_ctxt_setup_fail_CAC_rate formula are computed

based on eNB raw counters as follows:
VS_UE_ctxt_setup_fail_CAC = VS.InitialContextSetupFailed.CACFailure
VS_UE_ctxt_setup_req = VS_UE_ctxt_setup_req_AfterDLNAS +
VS_UE_ctxt_setup_req_WithoutDLNAS
Where:
VS_UE_ctxt_setup_req_AfterDLNAS =
VS.UEContextSetupRequest.AfterDLNASTransport
VS_UE_ctxt_setup_req_WithoutDLNAS =
VS.UEContextSetupRequest.WithoutPreviousDLNASTransport
Page 222/273
4.3.2.2 MONITORING INDICATORS FOR USER PLANE LOAD

EVALUATION
Monitoring indicators for the load of the Number of User resource:

 VS_UE_RRC_connected_avg_PerCell (L13201_30_CI) this is a NPO
monitoring indicator computed based on two other monitoring metrics:
VS_UE_RRC_connected_avg_PerCell = VS_UE_RRC_connected_cum /
VS_UE_RRC_connected_NbEvt
It indicates the average number of UEs in RRC connected state in a given cell
during the observation period (basically it indicates the average load of the
Number of Users resource)
The two metrics in VS_UE_RRC_connected_avg_PerCell formula are

computed based on eNB raw counters as follows:
VS_UE_RRC_connected_cum = RRC.Conn.Cum
VS_UE_RRC_connected_NbEvt = RRC.Conn.NbEvt
 VS_UE_RRC_connected_max (L13201_Max) is a NPO monitoring indicator

directly based on the eNB raw counter RRC.Conn.Max. It indicates if the max
capacity of the cell/modem in terms of number of RRC connected Users is
reached during observation period.
Monitoring indicators for the load of the Number of bearers resource:
Restriction: Monitoring of Number of bearers resource in LA6.0
Considering that this resource is less critical than the Number of Users (not necessarily generates call
rejects or call drops), the monitoring method proposed will be essentially based on the resource
blocking detection and PRB pool occupancy overload detection.
Page 223/273
LA6.0 eNB monitoring solution is allowing a full evaluation including all traffic type (ie:
VoIP, GBR and NonGBR) of the Number of Bearer resource load.
 VS_ERABs_all_nb_OnCell_max (L13207_Max) is a NPO monitoring indicator

directly based on the eNB raw counter VS.NbBearersPerCell.max. It indicates the
maximum number of simultaneous "on going" bearers in the cell/modem.
 VS_ERABs_all_nb_OnENB_max (L13211_Max) is a NPO monitoring indicator

directly based on the eNB raw counter VS.NbBearersPerENodeB.max. It indicates
the maximum number of simultaneous "on going" bearers in the cell/modem.
 VS_ERABs_GBR_WithoutVoIP_nb_OnCell_max (L13205_Max) is a NPO

VS.NbGBRBearersPerCell.max. It indicates the maximum number of simultaneous
"on going" GBR bearers in the cell/modem..
 VS_ERABs_GBR_WithoutVoIP_nb_OnENB_max (L13209_Max) is a NPO

VS.NbGBRBearersPerENodeB.max. It indicates the maximum number of
simultaneous "on going" GBR bearers in the cell/modem.
 VS_ERABs_NonGBR_nb_OnCell_max (L13206_Max) is a NPO monitoring

indicator directly based on the eNB raw counter
VS.NonNbNonGBRBearersPerCell.max. It indicates the maximum number of
simultaneous "on going" NonGBR bearers in the cell/modem.
 VS_ERABs_NonGBR_nb_OnENB_max (L13210_Max) is a NPO monitoring

VS.NbNonGBRBearersPerENodeB.max. It indicates the maximum number of
simultaneous "on going" NonGBR bearers in the cell/modem.
 VS_ERABs_VoIP_nb_OnCell_max (L13204_Max) is a NPO monitoring

indicator directly based on the eNB raw counter VS.NbVoIPBearersPerCell.max. It
indicates the maximum number of simultaneous "on going" VoIP bearers in the
cell/modem.
 VS_ERAB_VoIP_nb_OnENB_max (L13208_Max) is a NPO monitoring

VS.NbVoIPBearersPerENodeB.max. It indicates the maximum number of
simultaneous "on going" VoIP bearers in the cell/modem.
Page 224/273
4.3.3 MONITORING METHOD & CRITICAL TRIGGERS

The monitoring and troubleshooting method for the eNB user plane resources is
based on the above mentioned monitoring indicators.
4.3.3.1 NUMBER OF USER PER CELL/MODEM CONNECTIONS

MONITORING & TROUBLESHOOTING
As explained in chapter 4.3.1, this resource being used by the CAC mechanism, need
to be monitored for the two aspects: resource blocking and resource load.
Based on the Monitoring indicators described in chapter 4.3.2, the monitoring &
troubleshooting diagram for this resource is described in the following figure:
VS_RRC_cnx_fail_CAC > 0
No
(during the day) No action required
Yes
Add cell in the “congestion
suspect” cell list
(and start monitoring on hour basis)
No No corrective action required, but

VS_RRC_cnx_fail_CAC_rate > target
(during the CAC BH) keep cell in “suspect” cell list
target may be Yes

2% for instance
Capacity analysis /tuning is

VS_UE_RRC_connected_avg ≥ No required to identify blocking cause
Critical threshold
(during the CAC BH) at low load (parameters setting, cell
failures, abnormal cell behavior…)
Yes
Capacity optimization/tuning
and/or
Additional resources
are required
Figure 62 : Cell/Modem Capacity Monitoring Decision Tree (Nb. of User connections)
The monitoring steps are:
 Check on daily basis the VS_RRC_cnx_fail_CAC indicator for each cell in the
network. If it is 0, then no blocking event is observed, so no action is required.
If it is > 0, then go to next step.
Page 225/273
 If VS_RRC_cnx_fail_CAC > 0, user connection blocking events occur and

the cell becomes “suspect” of high load and it shall be added in a “congestion
suspect” cell list, which a list of cells that are to be closely monitored (on hour
basis).
 For the cells in the “congestion suspect” cell list, check if the congestion
condition is reached (VS_RRC_cnx_fail_CAC_rate > target), where the
target is a limit imposed by the operator QoS policy. It may be 2% as usually
considered in 2G & 3G networks (which consider the presence of voice
traffic), or can be higher (5% to 20% for instance) if only data traffic is
performed in the network.
The congestion condition has to be checked at the CAC_BH which represents
the hour of the day when the VS_RRC_cnx_fail_CAC indicator had the
maximum value.
 If the congestion condition is reached (previous step) for a specific cell, the
resource load shall be verified (VS_UE_RRC_connected_avg ≥ Critical
threshold) for the same cell, at the same CAC_BH. The Critical threshold
for the User blocking can be computed with the ErlangB law for different
blocking targets and different cell capacity figures. See examples of Critical
threshold possible values in the table below:
Cell blocking limit Cell capacity

Critical threshold value
(in terms of User connections) (Nb of User connections)
40 31
54 43.9
2% 100 88
(Typical for GBR or VoIP) 167 153,5
200 168
250 236
40 38.8
54 53.8
10% 100 100

(Typical for Best effort Data) 167 167
200 200
250 250
Table 84 : Nb of User Connections Critical Trigger Values – eCEM Case
Page 226/273
Note The above table values are calculated using minimum between eCEM capacity
and ErlangB law with example blocking target for voice and data, that come with the
following formula : Critical Threshold = Min ( 200 , ErlangB [Modem=200;
Blocking=10%)=214.3] ) = 200.
 According to the resource load check (previous step), several actions may be
required:
o If the congestion is confirmed by high load, either parameters tuning

(change cell capacity configuration), or new resources add action are
required – see the red rectangle in Figure 62.
o If the congestion is present but the critical load threshold is not

reached, additional capacity investigation is required (for capacity
parameters coherence, cell abnormal behavior…) – see the orange
rectangle in Figure 62.
 Similar calculations can be performed for the bCEM case with “Maximum Nb
of User connections” = 250.
4.3.3.2 NUMBER OF BEARERS PER CELL/MODEM MONITORING &

TROUBLESHOOTING
As for the Number of User connections, the number of bearer’s resource is also being
used by the CAC mechanism.
Based on the Monitoring indicators described in chapter 4.3.2, the monitoring &
troubleshooting diagram for this resource is described in the following figure:
VS_UE_ctxt_setup_fail_CAC > 0 No
Or
VS_ERABs_proc_setup_fail_CAC > 0 No action required
(during the day)
Yes
Add cell in the “congestion
suspect” cell list
(and start monitoring on hour basis)
VS_UE_ctxt_setup_fail_CAC_rate > No No corrective action required, but

target keep cell in “suspect” cell list
(during the B_CAC BH)
target may be
Yes Capacity optimization/tuning
2% for instance
and/or
Additional resources
are required
Figure 63 : Cell/Modem Capacity Monitoring Decision Tree (Nb. of Bearers)
Page 227/273
The monitoring steps are:
 Check on daily basis the VS_UE_ctxt_setup_fail_CAC and

VS_ERABs_proc_setup_fail_CAC indicators for each cell in the network. If
both are 0, then no blocking event is observed, so no action is required. If it is
> 0, then go to next step.
 If at least one of the two above mentioned indicators is greater than 0, bearer
blocking events occur and the cell becomes “suspect” of high load (in terms of
number of bearers) and it shall be added in a “congestion suspect” cell list,
which a list of cells that are to be closely monitored (on hour basis).
 For the cells in the “congestion suspect” cell list, check if the congestion
condition is reached (VS_UE_ctxt_setup_fail_CAC_rate > target), where the
target is a limit imposed by the operator QoS policy. It may be 2% as usually
considered in 2G & 3G networks (which consider the presence of voice
traffic), or can be higher (5% to 20% for instance) if only data traffic is
performed in the network.
The congestion condition has to be checked at the B_CAC BH which

represents the hour of the day when the VS_UE_ctxt_setup_fail_CAC
indicator had the maximum value.
 The capacity troubleshooting decision will be based on the blocking target

check
o If the congestion rate is lower than the target, then no action is to be

taken (just keep continue monitoring the cell on hour basis).
o If the congestion rate is greater than the target, either parameters

tuning (change cell capacity configuration), or new resources add
actions are required – see the red rectangle in Figure 63
4.3.4 OTHER ENB CAPACITY MONITORING ASPECTS

4.3.4.1 ENB CONTROL PLANE PROCESSOR OCCUPANCY
In LA6.0 eNB monitoring solution provide counters to evaluate the eNB control plane
processor (eNB Ctrl CPU: eCCM PQ3 processor) occupancy and all the overload failure
related counters.
7 counters are triggered with the polling frequency defined by an internal eNodeB
parameter defined in 1.6.2. Every time the overload control updates its view of the
average CPU utilization in order to decide which overload state to be in, the average
utilization is used to select a bin from the vector and that bin is incremented. There are
7 bins from the vector that represent the whole histogram statistic of the control
processor occupancy. The NPO indicators related with these 7 counters are listed
below:
 VS_CPU_usage_eNB_OnCtrlProcessor_Lo (L13220_0) is a NPO

VS.ENodeBControlCpuUtilizationHistogram.0LeCpuLt50. This indicator
Page 228/273
provides the number of utilization of the Ctrl Processor Unit of the eNodeB
inside the bin “from 0% to less than 50%”.
 VS_CPU_usage_eNB_OnCtrlProcessor_LoMed (L13220_1) is a NPO

 VS_CPU_usage_eNB_OnCtrlProcessor_LoHi (L13220_2) is a NPO
 VS_CPU_usage_eNB_OnCtrlProcessor_HiLo (L13220_3) is a NPO

 VS_CPU_usage_eNB_OnCtrlProcessor_HiMed (L13220_4) is a NPO

VS.ENodeBControlCpuUtilizationHistogram 85LeCpuLt90. This indicator
 VS_CPU_usage_eNB_OnCtrlProcessor_Hi (L13220_5) is a NPO

 VS_CPU_usage_eNB_OnCtrlProcessor_VeryHi (L13220_6) is a NPO

 VS_CPU_usage_eNB_OnCtrlProcessor_Full (L13220_7) is a NPO

VS.ENodeBControlCpuUtilizationHistogram.Cpu100. This indicator provides
the number of utilization of the Ctrl Processor Unit of the eNodeB inside the
bin “100%”.
In order to quantify the Ctrl Processor occupancy in average during the Busiest
Observation Period BOP (=15mn) it is possible to calculate a rate in % that
represents the percentage of time that ProcessorOccupancy > 50%, as follow:
 VS_CPU_usage_eNB_OnCtrlProcessor_Avg_Rate>50%= 1 -
VS_CPU_usage_eNB_OnCtrlProcessor_Lo /
VS_CPU_usage_eNB_OnCtrlProcessor_all
Page 229/273
 VS_CPU_usage_eNB_OnCtrlProcessor_all (L13220_00_CI) is an NPO

calculated indicator that provides the sum of all the bins incremented for the
CPU utilization histogram for the Ctrl Processor Unit of the eNodeB.
VS_CPU_usage_eNB_OnCtrlProcessor_all =
VS_CPU_usage_eNB_OnCtrlProcessor_Full +
VS_CPU_usage_eNB_OnCtrlProcessor_VeryHi +
VS_CPU_usage_eNB_OnCtrlProcessor_Hi +
VS_CPU_usage_eNB_OnCtrlProcessor_HiMed +
VS_CPU_usage_eNB_OnCtrlProcessor_HiLo +
VS_CPU_usage_eNB_OnCtrlProcessor_LoHi +
VS_CPU_usage_eNB_OnCtrlProcessor_LoMed +
VS_CPU_usage_eNB_OnCtrlProcessor_Lo
Engineering Recommendation: Ctrl Processor Occupancy in LE6.0
In order to verify that the Ctrl Processor Occupancy doesn’t exceed a reasonable limit during a BOP of
15mn, the recommended target value is 60%:
VS_CPU_usage_eNB_OnCtrlProcessor_Rate < 60% during BOP = 15mn
Page 230/273
4.4 MME CAPACITY MONITORING

The 9471 MME WM6.0 contains capacities that can be categorized into three broad
categories:
 Capacities defined as provisioning limits (These capacities are not monitored

and alarmed via the traditional monitoring methods. Please refer to Section
3.4.1.)
 Capacities due to memory resources on the MAF boards

o Number of registered users
 Capacities due to CPU resources on the MAF boards
o External message throughput
This section captures information for 9471 MME WM6.0.
4.4.1 MAXIMUM NUMBER OF REGISTERED USERS

The MME data structure allocates memory resources for every UE registered to the
MAF. In WM6.0, each MAF pair is able to accommodate 500,000 registered users.
Once this limit is reached, a new registration would cause the oldest registered user to
be dropped.
The MIF distributes new UE Attaches among the MAFs, round robin at first but then
based on overall MAF load and number of registered users in each MAF’s VLR.
When a given MAF reaches its limit of 500,000 registered users, it will delete the
oldest one when a new attach is received.
The distribution on the MIF balances out the load on each MAF. There is no attempt to
coordinate among the MAFs. So, if all MAFs were at 500,000, each new attach (which
would be distributed among the MAFs) would cause an old subscriber to be deleted
and the new attach would proceed.
4.4.1.1 COUNTERS
The MME supports several observation counters to track the average and maximum
numbers of UEs in different states during a PM reporting interval. The counters
include Average and MAX number of registered UE, Average and MAX number of idle
UE, Average and MAX number of connected UE, and percent of maximum registered
UE capacity.
The percent of maximum registered UE capacity counter is of interest here:
 VS.UECapacityUsage (21301) is an MME 3GPP counter that counts the

percent of the maximum Registered UE capacity achieved on a MAF during
the current PM reporting interval. The counter is pegged whenever the
maximum number of registered UEs on a MAF is determined during a
reporting interval. This is a per-MAF count.
Note: This MME 3GPP counter is also seen/handled through the NPO tool, where
the equivalent NPO indicator is VS_UECapacityUsage (LC21301).
Additionally, NPO calculates 2 indicators related to UE capacity:

Page 231/273
 VS_UE_CapacityUsage_OnMaxAttachedUE_rate_max (L21301_CI):
calculates the max of the max value over all MAF whatever the periodicity.
 VS_UE_CapacityUsage_OnMaxAttachedUE_rate_avg (L21301_40_CI):
calculates the average value of all MAF whatever the periodicity.
4.4.1.2 MONITORING METHOD & CRITICAL TRIGGERS
A Critical Performance Indicator (CPI) is associated with the VS.UECapacityUsage

counter. Thresholds are defined for Critical, Major and Minor alarms. Default values
for these indicators are:
 99% capacity = Critical
 95% capacity = Major
 90% capacity = Minor

The valid range for these thresholds is 1% to 99%, in increments of 1%. These
thresholds can be updated using the SAM Provisioning GUI.
A trap is sent to the MI/EMS when any of the provisioned thresholds is crossed in
either direction during a reporting interval. That is, a trap is sent to indicate an alarm
severity of Minor, Major, Critical, or Cleared (Normal) to describe the threshold that
was crossed during the reporting interval.
Rule: Registered User Limits monitoring
In WM6.0, the MME can contain up to 10 MAF pairs, where each pair is limited to 500,000 registered
users. A fully configured MME can accommodate up to 5,000,000 registered users per MME.
In order to avoid exceeding the maximum number of registered users, the VS_UECapacityUsage
counter should be monitored and a capacity extension decision should be made once the counter
reaches the Minor alarm threshold.
Capacity extension actions include adding MAF pairs until the 10 pair limit is reached and/or adding an
additional MME to the network.
4.4.2 EXTERNAL MESSAGE THROUGHPUT

The MAF CPU usage is the limiting factor in determining MME message processing
throughput. In WM6.0, each MAF pair is able to support at least 40K external
messages/second without pushing the CPU into overload. Once the CPU overload
limit is reached, all additional service requests will be ignored/rejected. The total
message throughput for the MME is limited to 305K msg/sec.
The MME supports counters and monitoring for CPU usage and for messaging
between the MIF and MAFs.
Page 232/273
4.4.2.1 COUNTERS
4.4.2.1.1 CPU USAGE COUNTERS
The MME supports several observation counters related to CPU usage in WM6.0. The
MME counters include the following:
 VS.aveCpuUsage (40001_0) indicates the average CPU utilization in the

current interval.
 VS.avePerCoreCpuUsage (40002_0) indicates the average CPU utilization
for a Core processor on a board.
 VS.aveBaseCpuUsage (40003_0) indicates the average CPU utilization for a

set of processes that contribute to CPU Overload calculations.
 VS.peakCpuUsage (40001_1) indicates the peak CPU utilization in the

current interval.
 VS.peakPerCoreCpuUsage (40002_1) indicates the peak per-Core
processing utilization in the current interval.
 VS.peakBaseCpuUsage (40003_1) indicates the peak CPU utilization for a

set of processes that contribute to CPU Overload calculations.
Each of the above counters is pegged every 10 seconds over the reporting interval.
Note: These MME 3GPP counters are also seen/handled through the NPO tool,
where the associated NPO indicators are as follows:
 VS_CPU_usage_PerHost_avg_rate (L40001_0_31_CI) is the equivalent of

the VS.aveCpuUsage (40001_0) 3GPP counter (expressed in percentage).
 VS_CPU_usage_PerCore_avg_rate (L40002_0_31_CI) is the equivalent of

the VS.avePerCoreCPUUsage (40002_0) 3GPP counter (expressed in
percentage).
 VS_CPU_usage_SetOfProcessOnCPUoverload _avg_MAF_rate
(L40003_0_MAF_31_CI) uses the VS.aveBaseCpuUsage (40003_0) 3GPP
counter to calculate average CPU usage on a per-MAF basis (expressed in
percentage).
 VS_CPU_usage_SetOfProcessOnCPUoverload _avg_MIF_rate
(L40003_0_MIF_31_CI) uses the VS.aveBaseCpuUsage (40003_0) 3GPP
counter to calculate average CPU usage on a per-MIF basis (expressed in
percentage).
 VS_CPU_usage_PerHost_max_rate (L40001_1_31_CI) is the equivalent of

the VS.peakCpuUsage (40001_1) 3GPP counter (expressed in percentage).
 VS_CPU_usage_PerCore_max_rate_Savg _Tmax (L40002_1_41_CI) uses

the VS.peakPerCoreCpuUsage (40002_1) 3GPP counter to calculate the
peak per-core processing utilization in the current interval averaged on all
cores on all MAFs in the system (expressed in percentage).
 VS_CPU_usage_SetOfProcessOnCPUoverload _max_MAF_rate
(L40003_1_MAF_31_CI) uses the VS.peakBaseCpuUsage (40003_1) 3GPP
Page 233/273
counter to calculate the peak CPU usage on a per-MAF basis (expressed in

percentage).
 VS_CPU_usage_SetOfProcessOnCPUoverload _max_MIF_rate
(L40003_1_MIF_31_CI) uses the VS.peakBaseCpuUsage (40003_1) 3GPP
counter to calculate the peak CPU usage on a per-MIF basis (expressed in
percentage).
4.4.2.1.2 MAF MESSAGE COUNTERS
The MME supports several observation counters related to CPU usage in WM6.0. The
MME counters include the following:
 VS.TotalMsgsSentToMAF (24105) indicates the total number of messages

sent to the MAF from the MIF. Each MAF reports a separate count.
 VS.TotalMsgsRcvdFromMAF (24107) indicates the total number of

messages received from the MAF. Each MAF reports a separate count.
Each of the above counters is incremented for each Application message

sent/received to/from the MAF.
Note: These MME 3GPP counters are also seen/handled through the NPO tool,
where the equivalent NPO counters are as follows:
 VS_MIF_MAF_total_msg_sent (L24105) is the equivalent of the

VS.TotalMsgsSentToMAF (24105) 3GPP counter.
 VS_MIF_MAF_total_msg_rcvd (L24107) is the equivalent of the

VS.TotalMsgsRcvdFromMAF (24107) 3GPP counter.
 NPO also computes VS_MIF_MAF_total_msg_all (L2410d_30_CI) by adding

VS_MIF_MAF_total_msg_sent (L24105) and
VS_MIF_MAF_total_msg_rcvd (L24107).
4.4.2.1.3 OVERLOAD INDICATORS
The MME supports several counters associated with the number of messages that are
rejected or dropped when the MME attempts to mitigate an overload condition. The
MME counters are pegged for a major or critical overload condition on a MAF service
member and also for number of messages that are dropped per interface type when
an MME attempts to mitigate a critical overload condition on a MIF service member.
Equivalent NPO indicators are provided for each MME counter. These indicators can
be used to analyze message throughput and adjust MME configuration, if necessary.
Additional information regarding NPO indicators can be found in Customer Document
[C21]:
 VS.NbrDetachDropped (22001_0) indicates the number of Detach Request

messages that are dropped during MME overload. A Detach Request cannot
be rejected. The counter is pegged when the MME drops a Detach Request
message (application message) in an attempt to mitigate a Major or Critical
overload condition. The NPO tool uses this 3GPP counter to derive the
Page 234/273
associated NPO indicator:

VS_UE_detach_InitiatedByUE_drop_MMEOverload (L22001_0).
 VS.NbrS11msgsDropped (22001_4) indicates the number of messages that

are dropped per S11 interface type during MME overload. The counter is
pegged when the MME drops messages (application messages) on the S11
interface in an attempt to mitigate a Major or Critical overload condition or if
the MIF exceeds its engineered message capacity limit.The NPO tool uses
this 3GPP counter to derive the associated NPO indicator:
VS_S11_GTPc_AppMsg_drop_MMEOverload (L22001_4).
 VS.NbrS1msgsDropped (22001_6) indicates the number of messages that

are dropped per S1-MME interface type during MME overload. The counter is
pegged when the MME drops messages (application messages) on the S1-
MME interface in an attempt to mitigate a Major or Critical overload condition
or if the MIF exceeds its engineered message capacity limit. The NPO tool
uses this 3GPP counter to derive the associated NPO indicator:
VS_S1MME_GTPc_AppMsg_drop_MMEOverload (L22001_6).
 VS.NbrS6amsgsDropped (22001_7) indicates the number of messages that

are dropped per S6a interface type during MME overload. The counter is
pegged when the MME drops messages on the S6a interface in an attempt to
mitigate a Major or Critical overload condition or if the MIF exceeds its
engineered message capacity limit. The NPO tool uses this 3GPP counter to
derive the associated NPO indicator:
VS_HSS_S6a_GTPc_AppMsg_drop_MMEOverload (L22001_7).
 VS.NbrX1_1msgsDropped (22001_10) indicates the number of X1_1 CALEA

messages that are dropped during MME overload. The counter is pegged
whenever an X1_1 (CALEA) application message is dropped during MME
overload. The NPO tool uses this 3GPP counter to derive the associated NPO
indicator: VS_CALEA_X1_1_msgs_drop_MMEOverload (L22001_10).
 VS.NbrX2msgsDropped (22001_11) indicates the number of X2 CALEA

messages that are dropped during MME overload. This counter is pegged
whenever an X2 (CALEA) application message is dropped during MME
overload. The NPO tool uses this 3GPP counter to derive the associated NPO
indicator: VS_CALEA_X2_msgs_drop_MMEOverload (L22001_11).
 VS.NbrSmmsgsDropped (22001_22) indicates the number of messages that

are dropped per Sm interface type during MME overload. The counter is
pegged when the MME drops messages on the Sm interface in an attempt to
VS_Sm_GTPc_AppMsg_drop_MMEOverload (L22001_22).
 VS.NbrM3msgsDropped (22001_23) indicates the number of messages that

are dropped per M3 interface type during MME overload. The counter is
pegged when the MME drops messages on the M3 interface in an attempt to
Page 235/273

VS_M3_GTPc_AppMsg_drop_MMEOverload (L22001_23).
 VS.NbrS1ReleaseMsgsDropped (22002_16) indicates the number of times a

UE Context Release Request message is dropped at the MME because a
MAF is in Overload. The counter is pegged whenever the MME is in an
Overload state and a UE Context Release Request message is dropped in an
attempt to mitigate the overload condition. The NPO tool uses this 3GPP
counter to derive the associated NPO indicator:
VS_UE_ctxt_rel_drop_MMEOverload (L22002_16).
 VS.NbrAttachMsgsRejected (22002_0) indicates the number of times an

Attach Request message is rejected at the MME because a MAF is in
Overload or has exceeded its engineered message capacity limit. The counter
is pegged whenever the MAF rejects an Attach message because it is in an
Overload state or has exceeded its engineered message capacity limits. The
NPO tool uses this 3GPP counter to derive the associated NPO indicator:
VS_UE_attach_all_fail_ReqRejOnMMEOverload (L22002_0).
 VS.NbrBearerResourceAllocMsgsRejected (22002_1) indicates the number

of Bearer Resource Allocation messages that are rejected during an MME
attempt to mitigate a Major or Critical overload condition. The counter is
pegged whenever the MME is in overload and rejects a Bearer Resource
Allocation message. The NPO tool uses this 3GPP counter to derive the
VS_EB_QCI_all_bearer_rsc_alloc_fail_ReqRejOnMMEOverload
(L22002_1).
 VS.NbrInterRatHOGnMsgsRejected (22002_10) indicates the number of

inter-RAT handover, inter-RAT RAU and inter-RAT TAU messages received
via a Gn interface that are rejected during MME overload. The counter is
pegged whenever an interRAT HO message is received via a Gn interface
and is rejected because the MME is in overload. The NPO tool uses this
3GPP counter to derive the associated NPO indicator:
VS_Mob_LTE_UtraGeran_Gn_msgs_fail_ReqRejOnMMEOverload
(L22002_10).
 VS.NbrPDNconnectMsgsRejected (22002_14) indicates the number of

times a PDN Connectivity Request message is rejected at the MME because
of overload. The counter is pegged whenever a PDN Connectivity Request
message is rejected during MME overload. The NPO tool uses this 3GPP
VS_PDN_connectivity_all_fail_ReqRejOnMMEOverload (L22002_14).
 VS.NbrPDNDisconnectMsgsRejected (22002_15) indicates the number of

times a PDN Disconnect Request message is rejected at the MME because a
MAF is in Overload. The counter is pegged whenever the MME is in an
Overload state, and a PDN Disconnect Request message is rejected in an
attempt to mitigate the overload condition. The NPO tool uses this 3GPP
VS_PDN_disconnect_fail_ReqRejOnMMEOverload (L22002_15).
Page 236/273
 VS.NbrServiceReqMsgsRejected (22002_17) indicates the number of times

a NAS Service Request message is rejected at the MME because a MAF is in
Overload or has exceeded its engineered message capacity limit. The counter
is pegged whenever the MAF rejects a NAS Service Request message
because it is in an Overload state or has exceeded its engineered message
capacity limits. The NPO tool uses this 3GPP counter to derive the associated
NPO indicator: VS_UE_NAS_service_fail_ReqRejOnMMEOverload
(L22002_17).
 VS.NbrSGsPagingReqMsgsRejected (22002_18) indicates the number of

SGs Paging Request messages that are rejected during MME overload. The
counter is pegged when the MME is in overload, and an SGs Paging Request
message is received and rejected. The NPO tool uses this 3GPP counter to
VS_SGsAP_paging_fail_RejOnMMEOverload (L22002_18):
 VS.NbrTAUMsgsRejected (22002_19) indicates the number of times a TAU

Request message is rejected at the MME because a MAF is in Overload. The
counter is pegged whenever the MME is in an Overload state, and a TAU
Request message is rejected in an attempt to mitigate the overload condition.
The NPO tool uses this 3GPP counter to derive the associated NPO indicator:
VS_UE_TAU_all_fail_ReqRejOnMMEOverload (L22002_19).
 VS.NbrBearerResourceModifyMsgsRejected (22002_2) indicates the

number of Bearer Resource Modification messages that are rejected during
MME overload. The counter is pegged whenever a Bearer Resource
Modification message is rejected during MME overload. The NPO tool uses
this 3GPP counter to derive the associated NPO indicator:
VS_EB_QCI_all_bearer_rsc_modif_fail_ReqRejOnMMEOverload
(L22002_2).
 VS.NbrUpdateBearerMsgsRejected (22002_20) indicates the number of

Update Bearer (Modify Bearer) messages that are rejected during MME
overload. The counter is pegged whenever an Update Bearer (Modify Bearer)
message is dropped during MME overload. The NPO tool uses this 3GPP
VS_EB_QCI_all_bearer_modif_fail_ReqRejOnMMEOverload (L22002_20).
 VS.NbrX2HOMsgsRejected (22002_21) indicates the number of times a

Path Switch Request message is rejected at the MME because a MAF is in
Overload. The counter is pegged whenever the MME is in an Overload state,
and a Path Switch Request message is rejected in an attempt to mitigate the
overload condition. The NPO tool uses this 3GPP counter to derive the
VS_HO_IrC_X2_PathSwitch_fail_ReqRejOnMMEOverload (L22002_21).
 VS.NbrContextRequestMsgsRejected (22002_3) indicates the number of

Context Request messages that are rejected during MME overload. The
counter is pegged when the MME is in overload, and the Context Request
message is received and rejected. The NPO tool uses this 3GPP counter to
derive the associated NPO indicator: VS_ctxt_fail_ReqRejOnMMEOverload
(L22002_3).
Page 237/273
 VS.NbrCreateBearerMsgsRejected (22002_4) indicates the number of

Create Bearer messages that are rejected during MME overload. The counter
is pegged when the MME is in overload, and the Create Bearer message is
received and rejected. The NPO tool uses this 3GPP counter to derive the
VS_EB_QCI_all_create_bearer_fail_ReqRejOnMMEOverload (L22002_4).
 VS.NbrDeactDedBearerMsgsRejected (22002_5) indicates the number of

Delete Bearer Request messages received from the SGW that are rejected
during MME overload. The counter is pegged when the MME is in overload,
and the Delete Bearer Request is received from the SGW and the bearer
deactivation is for a dedicated bearer. The NPO tool uses this 3GPP counter
to derive the associated NPO indicator:
VS_EB_QCI_all_ded_del_bearer_fail_ReqRejOnMMEOverload
(L22002_5).
 VS.NbrDLdataNotifyMsgsRejected (22002_6) indicates the number of times

a Downlink Data Notification message is rejected at the MME because of
MME Overload. The counter is pegged whenever a Downlink Data Notification
message is rejected while the MME is in Overload. The NPO tool uses this
3GPP counter to derive the associated NPO indicator:
VS_DL_data_notif_fail_RejOnMMEOverload (L22002_6).
 VS.NbrFwdRelocationReqMsgsRejected (22002_7) indicates the number of

Fwd Relocation Required messages rejected during an MME attempt to
mitigate a Major or Critical overload condition. The counter is pegged when a
Fwd Relocation Required message is rejected during an MME attempt to
mitigate a Major or Critical overload condition. The NPO tool uses this 3GPP
VS_HO_IrC_S1_FwdReloc_fail_ReqRejOnMMEOverload (L22002_7).
 VS.NbrGUTIreallocMsgsRejected (22002_8) indicates the number of times

a GUTI Reallocation message is rejected at the MME because a MAF is in
Overload. The counter is pegged whenever the MME is in an Overload state,
and when a GUTI Reallocation message is rejected in an attempt to mitigate
the overload condition. The NPO tool uses this 3GPP counter to derive the
VS_UE_GUTI_Realloc_fail_ReqRejOnMMEOverload (L22002_8).
 VS.NbrHandoverRequiredMsgsRejected (22002_9) indicates the number of

times a Handover Required message is rejected at the MME because a MAF
is in Overload. The counter is pegged whenever the MME is in an Overload
state, and a Handover Required message is rejected in an attempt to mitigate
the overload condition. The NPO tool uses this 3GPP counter to derive the
VS_HO_IrC_S1_HOrequired_fail_ReqRejOnMMEOverload (L22002_9).
 VS.NbrEmergencyAttachMsgsRejected (22002_26) indicates the number of

times that an Emergency Attach Request message is rejected at the MME
due to an extended period of MAF critical overload. The counter is pegged
whenever the MAF rejects an Attach message for Emergency services
because the MAF is experiencing an extended period of critical overload
Page 238/273
state. The NPO tool uses this 3GPP counter to derive the associated NPO
indicator: VS_UE_attach_all_fail_ReqRejOnMMEOverload_emerg
(L22002_26).
 VS.NbrEmergencyPDNConnectMsgsRejected (22002_27) indicates the

number of times that an Emergency PDN Connectivity Request message is
rejected at the MME due to an extended period of MAF critical overload. The
counter is pegged whenever the MAF rejects a PDN Connectivity message for
Emergency services because the MAF is experiencing an extended period of
critical overload state. The NPO tool uses this 3GPP counter to derive the
VS_PDN_connectivity_all_fail_ReqRejOnMMEOverload_emerg
(L22002_27).
 VS.NbrEmergencyServiceReqMsgsRejected (22002_28) indicates the

number of times that an Emergency Service Request message is rejected at
the MME due to an extended period of MAF critical overload. The counter is
pegged whenever the MAF rejects a Service Request message for
Emergency services because the MAF is experiencing an extended period of
critical overload state. The NPO tool uses this 3GPP counter to derive the
VS_UE_NAS_service_fail_ReqRejOnMMEOverload_emerg (L22002_28).
The NPO tool also calculates several indicators that are useful during message
throughput analysis.
 VS_HO_LTE_to_UTRAN_S3_rej_MMEOverload_MIF (L22002_22_MIF):
This indicator provides the number of interRAT S3 HO messages received
using S3 for handover with UTRAN that are rejected during MME overload.
The indicator is based on the VS.NbrInterRatHOS3UtranMsgsRejected
3GPP counter (22002_22). The counter is pegged on the MIF interface
whenever an S3 interRAT HO with UTRAN is rejected during an MME attempt
to mitigate a Major or Critical overload condition.
 VS_HO_LTE_to_UTRAN_S3_rej_MMEOverload_MAF (L22002_22_MAF):
The indicator is based on the VS.NbrInterRatHOS3UtranMsgsRejected
3GPP counter (22002_22). The counter is pegged on the MAF interface
whenever an S3 interRAT HO with UTRAN is rejected during an MME attempt
 VS_HO_LTE_to_UTRAN_S3_rej_MMEOverload (L22002_22_CI): This

indicator provides the total number of interRAT S3 HO messages received
The indicator is the calculated sum of the counter value on MAF and counter
value on MIF interfaces (L22002_22_MAF + L22002_22_MIF).
 VS_HO_LTE_to_GERAN_S3_rej_MMEOverload_MIF (L22002_23_MIF):
using S3 for handover with GERAN that are rejected during MME overload.
Page 239/273
The indicator is based on the VS.NbrInterRatHOS3GERANMsgsRejected

3GPP counter (22002_23). The counter is pegged on the MIF interface
whenever an S3 interRAT HO with GERAN is rejected during an MME attempt
 VS_HO_LTE_to_GERAN_S3_rej_MMEOverload_MAF (L22002_23_MAF):
The indicator is based on the VS.NbrInterRatHOS3GERANMsgsRejected
3GPP counter (22002_23). The counter is pegged on the MAF interface
whenever an S3 interRAT HO with GERAN is rejected during an MME attempt
 VS_HO_LTE_to_GERAN_S3_rej_MMEOverload (L22002_23_CI): This

indicator provides the total number of interRAT S3 HO messages received
The indicator is the calculated sum of the counter value on MAF and counter
value on MIF interfaces (L22002_23_MAF + L22002_23_MIF).
4.4.2.1.4 NPO PAGING INDICATORS
The NPO tool supports several indicators associated with paging. These indicators
can be used to analyze message throughput and adjust MME configuration, if
necessary. Additional information regarding NPO indicators can be found in Customer
Document [C21]:
 VS_paging_CSFB_MT_all_rsp_succ_rate (L20987_31_CI): This calculated

indicator provides the rate of paging response success. The paging response
success is when MME receives an Extended Service Request message from
the eNodeB during a Mobile Terminating CS Fallback procedure in response
to a paging CS fallback and the CSFB Response IE is set to CS fallback
accepted by the UE. The indicator uses the
VS.NbrMobileTermCSFBCSPagingReq 3GPP counter (20987) and is
calculated with the formula :
VS_paging_CSFB_MT_all_rsp_succ_rate =
VS_paging_CSFB_MT_all_rsp_succ /
VS_paging_CSFB_MT_all_req
 VS_paging_CSFB_MT_all_rsp_succ (L20987_30_CI): This calculated

indicator provides the number of paging response success. The paging
response success is when MME receives an Extended Service Request
message from the eNodeB during a Mobile Terminating CS Fallback
procedure in response to a paging CS fallback and the CSFB Response IE is
set to CS fallback accepted by the UE. The indicator uses the
VS.NbrMobileTermCSFBCSPagingReq 3GPP counter (20987) and is
calculated with the following formula :
VS_paging_CSFB_MT_all_rsp_succ =
VS_UE_NAS_ExtService_req_CSFB_MT_all_accepted
Page 240/273
 VS_UE_NAS_ExtService_req_CSFB_MT_all_accepted (L20988_0): This

indicator provides the number of times that the MME receives an Extended
Service Request message from the eNodeB during a Mobile Terminating CS
Fallback procedure and the CSFB Response IE is set to CS fallback accepted
by the UE. This counter is based on the 3GPP counter:
VS.NbrExtServiceReqCSFBresponse_Accept (20988_0). The counter is
pegged whenever the MME receives an Extended Service Request message
from the eNodeB during a Mobile Terminating CS Fallback procedure and the
CSFB Response IE is set to CS fallback accepted by the UE.
 VS_paging_CSFB_MT_all_req (L20987): This indicator provides the number

of times that the MME sends a CS Paging Request to the eNodeB during a
Mobile Terminating CS Fallback. This counter is based on the 3GPP counter:
VS.NbrMobileTermCSFBCSPagingReq (20987). The counter is pegged
whenever the MME sends a Paging message to an eNodeB and the paging
message CN Domain indicator IE is set to CS to initiate an extended service
request procedure for Mobile Terminating CS Fallback.
 VS_paging_all_req_1stTry (L21101_0): This indicator provides the number

of paging attempts using the Algorithm provisioned for the first paging attempt.
This is based on 3GPP counter: VS.AttPaging_FirstAttempt (21101_0). The
counter is pegged when a Downlink Data Notification arrives, and the UE is
paged using the algorithm provisioned for the first attempt.
 VS_paging_all_req_2ndTry (L21101_1): This indicator provides the number

of paging attempts using the Algorithm provisioned for the second paging
attempt. This is based on 3GPP counter: VS.AttPaging_SecondAttempt
(20010_1). The counter is pegged when paging messages are sent to the
eNB(s) using the second provisioned paging algorithm.
 VS_paging_all_req_3rdTry (L21101_2): This indicator provides the number

of paging attempts using the Algorithm provisioned for the third paging
attempt. This is based on 3GPP counter: VS.AttPaging_ThirdAttempt
eNB(s) using the third provisioned paging algorithm.
 VS_paging_all_req_4thTry (L21101_3): This indicator provides the number

of paging attempts using the Algorithm provisioned for the fourth paging
attempt. This is based on 3GPP counter: VS.AttPaging_FourthAttempt
eNB(s) using the fourth provisioned paging algorithm.
4.4.2.1.5 MME PAGING COUNTERS
The MME supports several observation counters related to paging in WM6.0. The
MME MI counters (3GPP counters) include the following:
 VS.NbrPagingFailures_Timeout (21102_2): This is an MME 3GPP counter

that counts the number of times the Paging procedure is started for a UE and
all provisioned attempts to locate the UE have been tried but the paging
procedure was unsuccessful in reaching the UE. This counter is pegged when
the Paging procedure is started for a UE and all provisioned attempts at
Page 241/273
paging the UE have timed out without locating the UE. The equivalent NPO
indicator is VS_NbrPagingFailures_Timeout (LC21102_2).
 VS.NbrFailedSGsPageCSbySTMSI_Other (20861_4): This is an MME

3GPP counter that counts the number of failures that occur in the handling of
the SGs Paging Request message received from the MSC, where the UE is
IDLE and the UE Context is known at the MME and the CS service indicator is
set in the request message. This counter is pegged whenever the MME
processing of the SGsAP-Paging-Request results in a failure for the case
where the UE is IDLE and the UE Context is known at the MME and where
the request has the CS service indicator set in the request message. The
equivalent NPO indicator is VS_NbrFailedSGsPageCSbySTMSI_Other
(LC20861_4).
 VS.NbrFailedSGsPagePSbySTMSI_Other (20861_1): This is an MME 3GPP

counter that counts the number of failures that occur in the handling of the
SGs Paging Request message received from the MSC, where the UE is IDLE
and the UE Context is known at the MME and the SMS service is indicated in
the request message. This counter is pegged whenever the MME processing
of the SGsAP-Paging-Request results in a failure for the case where the UE is
IDLE and the UE Context is known at the MME and where the SMS service
indicator is set in the request message. The equivalent NPO indicator is
VS_NbrFailedSGsPagePSbySTMSI_Other (LC20861_1).
 VS.NbrFailedSGsPageIMSIandLAI_Other (20861_3): This is an MME 3GPP

counter that counts the number of failures that occur in the handling of the
SGs Paging Request message received from the MSC where the UE Context
is not known at the MME and the LAI value is in the request message. This
counter is pegged whenever the MME processing of the SGsAP-Paging-
Request results in a failure for the case where the UE Context is not known at
the MME and where the request contains an LAI value to guide the paging.
The equivalent NPO counter is VS_NbrFailedSGsPageIMSIandLAI_Other
(LC20861_3).
 VS.NbrFailedSGsPageIMSIandVLR_Other (20861_2): This is an MME

3GPP counter that counts the number of failures that occur in the handling of
the SGs Paging Request message received from the MSC where the UE
Context is not known at the MME and the LAI value is not contained in the
request message. This counter is pegged whenever the MME processing of
the SGsAP-Paging-Request results in a failure for the case where the UE
Context is not known at the MME and where the request does not contain an
LAI value to guide the paging. The equivalent NPO counter is
VS_NbrFailedSGsPageIMSIandVLR_Other (LC20861_2).
 VS.AttPaging (21101): This is an MME 3GPP counter that counts the total
number of Paging sequences started at the MME in the reporting interval. This
counter is pegged when the AttPaging_FirstAttempt counter is pegged. The
equivalent NPO indicator is VS_AttPaging (LC21101).
 VS.AttSGsPageCSbySTMSI (20849_0): This is an MME 3GPP counter that

counts the number of SGs Paging Request messages received by the MME
from the MSC, where the UE Context is known at the MME and where the
Page 242/273
request indicates that the page is for a CS service. This counter is pegged
whenever the MME receives the SGsAP-Paging-Request message from the
MSC, where the UE Context is known at the MME and the message indicates
a CS call service. The equivalent NPO indicator is
VS_AttSGsPageCSbySTMSI (LC20849_0).
 VS.AttSGsPagePSbySTMSI (20849_3): This is an MME 3GPP counter that

from the MSC where the UE Context is known at the MME and where the
SMS service indicator is set in the request message. This counter is pegged
whenever the MME receives an SGsAP-Paging-Request message from the
MSC where the UE Context is known at the MME and where the SMS service
indicator is set in the message. The equivalent NPO indicator is
VS_AttSGsPagePSbySTMSI (LC20849_3).
 VS.AttSGsPageIMSIandLAI (20849_1): This is an MME 3GPP counter that
from the MSC where the UE context is not known at the MME and where the
request indicates an LAI value for paging purposes. This counter is pegged
whenever the MME receives an SGsAP-Paging-Request from the MSC and
the UE Context is not known and the request contains an LAI value. The
equivalent NPO indicator is VS_AttSGsPageIMSIandLAI (LC20849_1).
 VS.AttSGsPageIMSIandVLR (20849_2): This is an MME 3GPP counter that

from the MSC where the UE Context is not known at the MME and where the
request does not indicate an LAI value. This counter is pegged whenever the
MME receives an SGsAP-Paging-Request from the MSC where the UE
Context is not known at the MME and where the message does not indicate
an LAI value for Paging (The MME uses a provisioned set of TACs for the
MSC/VLR that sends the paging message.) The equivalent NPO indicator is
VS_AttSGsPageIMSIandVLR (LC20849_2).
 VS.NbrSuccessSGsPageCSbySTMSI (20851_0): This is an MME 3GPP

counter that counts the number of successes that occur in the handling of the
SGs Paging Request message received from the MSC where the UE is IDLE
and the UE Context is known at the MME and the CS service indicator is set
in the request message. This counter is pegged whenever the MME
processing of the SGsAP-Paging-Request results in a success for the case
where the UE is IDLE and the UE Context is known at the MME and where
the request has the CS service indicator set. The equivalent NPO indicator is
VS_NbrSuccessSGsPageCSbySTMSI (LC20851_0).
 VS.NbrSuccessSGsPagePSbySTMSI (20851_3): This is an MME 3GPP

SGs Paging Request message received from the MSC where the UE is IDLE
and the UE Context is known at the MME and the SMS service is indicated in
the request message. This counter is pegged whenever the MME processing
of the SGsAP-Paging-Request results in a success for the case where the UE
is IDLE, and the UE Context is known at the MME, and where the SMS
service indicator is set in the request message. The equivalent NPO indicator
is VS_NbrSuccessSGsPagePSbySTMSI (LC20851_3).
Page 243/273
 VS.NbrSuccessSGsPageIMSIandLAI (20851_1): This is an MME 3GPP

is not known at the MME and the LAI value is in the request message. This
counter is pegged whenever the MME processing of the SGsAP-Paging-
Request results in a success for the case where the UE Context is not known
at the MME and where the request contains an LAI value to guide the paging.
The equivalent NPO counter is VS_NbrSuccessSGsPageIMSIandLAI
(LC20851_1).
 VS.NbrSuccessSGsPageIMSIandVLR (20851_2): This is an MME 3GPP

is not known at the MME and the LAI value is not contained in the request
message. This counter is pegged whenever the MME processing of the
SGsAP-Paging-Request results in a success for the case where the UE
Context is not known at the MME and where the request does not contain an
LAI value to guide the paging. The equivalent NPO counter is
VS_NbrSuccessSGsPageIMSIandVLR (LC20851_2).
The NPO tool could use the above counters to calculate the following indicators:
 Total Paging Timeout Failures = VS_NbrPagingFailures_Timeout /

VS_AttPaging
 CSFB Voice Failures = VS_NbrFailedSGsPageCSbySTMSI_Other /

VS_AttSGsPageCSbySTMSI
 CSFB SMS Failures = VS_NbrFailedSGsPagePSbySTMSI_Other /

VS_AttSGsPagePSbySTMSI
 LTE Data-Only Failure Ratio = [VS_NbrPagingFailures_Timeout –

(VS_NbrFailedSGsPageCSbySTMSI_Other +
VS_NbrFailedSGsPagePSbySTMSI_Other +
VS_NbrFailedSGsPageIMSIandLAI_Other +
VS_NbrFailedSGsPageIMSIandVLR_Other)] / [VS_AttPaging –
(VS_AttSGsPageCSbySTMSI + VS_AttSGsPagePSbySTMSI +
VS_AttSGsPageIMSIandLAI + VS_AttSGsPageIMSIandVLR)]
 Total Paging Success Ratio = (VS_NbrSuccessSGsPageCSbySTMSI +

VS_NbrSuccessSGsPagePSbySTMSI +
VS_NbrSuccessSGsPageIMSIandLAI +
VS_NbrSuccessSGsPageIMSIandVLR) / (VS_AttSGsPageCSbySTMSI +
VS_AttSGsPagePSbySTMSI + VS_AttSGsPageIMSIandLAI +
VS_AttSGsPageIMSIandVLR)
Page 244/273
4.4.2.2 MONITORING METHOD & CRITICAL TRIGGERS
4.4.2.2.1 CPU USAGE MONITORING
The LSS_cpuOverload alarm is associated with the CPU usage counters. The alarm
indicates that the CPU utilization on a service has exceeded a threshold. The three
severity levels indicate the degree of CPU overload. Thresholds are defined for
Critical, Major and Minor alarms and are hard-coded into the platform software. The
hard-coded values for these indicators are:

A trap is sent to the MI/EMS when any of the thresholds is crossed in either direction
during a reporting interval. That is, a trap is sent to indicate an alarm severity of Minor,
Major, Critical, or Cleared (Normal) to describe the threshold that was crossed during
the reporting interval.
Rule: External Message Throughput Limit
The LTE network must be architected such that the CPU capacity on the MAF is not overloaded. In
WM6.0, the MME can have up to 10 MAF pairs and external message throughput is expected to be at
least 40K messages/second/MAF, with an individual MME throughput of at least 305K
messages/second.
In order to avoid exceeding the external message throughput limit, the alarm mentioned above should
be monitored and a capacity extension decision should be made once any of the Average CPU
counters (See 4.4.2.1.1) reaches the Minor alarm threshold. Peak CPU counters should also be
monitored, but do not require immediate action.
Capacity extension actions include adding MAF pairs until the 10 pair limit is reached and/or adding an
additional MME to the network.
4.4.2.2.2 MAF MESSAGE MONITORING
The LSS_cpiMAFCommunicationFailureRate alarm is associated with the MAF

message counters. The alarm indicates that the MAF communication failure rate on a
per-MAF service basis has exceeded a threshold in the last 5 minute interval. The
failure rate is calculated from the measurement count VS.TotalMsgsRcvdFromMAF
and VS.TotalMsgsSentToMAF. The formula for calculating the failure rate is:
100 * (1 – (VS.TotalMsgsRcvdFromMAF / VS.TotalMsgsSentToMAF))
The formula assumes that for every message sent from MIF to MAF, 1 or more
messages should be returned back to the MIF.
The alarm resource indicates which MAF service in the MAF pool is associated with
the alarm.
The three severity levels indicate the CPI value. Thresholds are defined for Critical,
Major and Minor alarms and are hard-coded into the platform software. The hard-
coded values for these indicators are:
Page 245/273

An alarm is raised only once for a component with a CPI at a specific severity. The
alarm clears if no severity threshold is met in one of the subsequent intervals.
4.4.2.2.3 OVERLOAD MONITORING
There is no alarm associated with these counters. When troubleshooting requires

knowledge of MAF messaging, these counter values must be investigated manually
using MI/EMS.
4.4.2.2.4 MME PAGING MONITORING (FUTURE)
When the following indicators (detailed in Section 4.4.2.1.5) are supported by NPO,
they can be monitored:
 Total Paging Timeout Failures

 CSFB Voice Failures
 CSFB SMS Failures
 LTE Data-Only Failure Ratio

The expected long term average, minor, and major thresholds are provided in the
following table:
Value Long Term Minor Major

Average Threshold Threshold
Total Paging Timeout Failures 6% 11% 16%
CSFB Voice Failures 5% 10% 15%
CSFB SMS Failures 5% 10% 15%
LTE Data-Only Failure Ratio 6% 11% 16%
Table 85 : Paging Failure Rate Thresholds
These thresholds are for indicators only. They should not be alarmed as they can be
affected by UE behavior.
The observational period for minor and major thresholds should be 15 minutes. These
values should not be exceeded at any time during the week, with the exception of
maintenance intervals.
The long term average is the expected value when the failure rate is averaged over a
24 hour period. It will vary over hours in the day depending on mobility of the UEs.
Page 246/273
4.5 LTE INTERFACES MONITORING

4.5.1 EUTRAN INTERFACES
LTE EUTRAN interface monitoring relies upon the measurement of the average
and/or maximum throughput for S1, X2 and OAM interface. The measured throughput
enables easy evaluation of the S1, X2 and OAM interface load.
Depending upon how the throughput is measured (average of maximum value)

corresponding interface load threshold is defined to engineer the throughput at S1, X2
and OAM interfaces, in order to keep the load below congestion limit, and thus
ensures quality of service objectives are met from an end to end transport network
perspective.
EUTRAN monitoring method relies upon separate monitoring of S1, X2 and OAM
interface throughput and comparison of these figures with the computed throughput
figures (refer to section 3.5), as the computed throughput figures have to be used as
the input figures to configure bandwidth reservation for interface S1, X2 and OAM
respectively. Per interface bandwidth reservation is a network operation which results
from the initial dimensioning (per interface computed throughput figures). The
reserved bandwidth figures are being labeled as
Interface#i_Available_Throughput(DL/UL), with Interface#i being equal to S1, X2,
OAM, or Telecom (S1 + X2).
Please note that since Interface#i_Available_Throughput(DL/UL) is the result of the
per interface physical throughput computation which is provided at physical layer, it is
required to account for additional 20 bytes (Ethernet frame preamble + inter-packet
gap) at the monitored throughput level, since the monitored figures are performed at
layer 2 Ethernet level.
Multiple EUTRAN transport network architectures are supported at the Alcatel-Lucent

eNodeB level: no Vlan, multiple Vlans, no IPsec, IPsec, IPv4, IPv6, as described in
reference [C07].
This section will address only two EUTRAN transport network architectures.
 Scenario 1:
o Reserved bandwidth for telecom traffic (aggregated S1 & X2 traffic)
o Reserved bandwidth for OAM traffic

Note: that telecom traffic (S1 /X2) must be assigned to a different Vlan
than OAM traffic.
 Scenario 2:
o Reserved bandwidth for S1 traffic

o Reserved bandwidth for X2 traffic
o Reserved bandwidth for OAM traffic
Page 247/273
Support of Vlan(s) at eNodeB EUTRAN interface is described in reference

[C07].
4.5.1.1 SCENARIO 1 (TELECOM TRAFFIC / OAM TRAFFIC)
For this configuration, downlink and uplink throughput for either Telecom (S1 + X2) or
OAM interfaces are monitored independently, i.e. a set of downlink and uplink
monitoring counters are available for Telecom and OAM interfaces respectively.
Since no downlink and uplink throughput counters are available at eNodeB level,
Telecom and OAM interfaces throughput monitoring relies upon the following
computation formula: (Measured volume of traffic) / (Observation period). Please note
in addition that since the traffic volume matches to layer 2, additional layer 1 overhead
must be added to get throughput figures at physical layer level.
4.5.1.1.1 TELECOM INTERFACE TRAFFIC
Telecom interface available indicators to be used to compute the monitored Telecom

traffic throughput are:
 VS_traf_eNB_telecom_kbyte_rcvd (L13318) is a NPO monitoring indicator

directly based on the eNobeB raw counter VS.TelecomInOctets. It indicates
the number of Telecom Kbytes (Ethernet layer 2) received by an eNodeB on
S1 + X2 interfaces (DL) during the observation period.
 VS_traf_eNB_telecom_kbyte_sent (L13320) is a NPO monitoring indicator

directly based on the eNodeB raw counter VS.TelecomOutOctets.It indicates
the number of Telecom Kbytes (Ethernet layer 2) sent by an eNodeB on S1 +
X2 interfaces (UL) during the observation period.
 VS_traf_eNB_telecom_pkt_rcvd (L13319) is a NPO monitoring indicator

directly based on the eNodeB raw counter VS.TelecomInPackets. It indicates
the number of Telecom packets (Ethernet layer 2) received by an eNodeB on
S1 + X2 interfaces (DL) during the observation period. This indicator is used
to evaluate the contribution of physical overhead to the DL Telecom interface
throughput.
 VS_traf_eNB_telecom_pkt_sent (L13321) is a NPO monitoring indicator
directly based on the eNodeB raw counter VS.TelecomOutPackets. It
indicates the number of Telecom packets (Ethernet layer 2) sent by an
eNodeB on S1 + X2 interfaces (UL) during the observation period. This
indicator is used to evaluate the contribution of physical overhead to the UL
Telecom interface throughput.
Monitoring is carried out independently at downlink and uplink level.
 Downlink monitoring
The average Telecom throughput (S1 + X2) in the downlink direction is
computed as follows:
Page 248/273
Avg_Tel_Thpt_DL =
[(VS_traf_eNB_telecom_kbyte_rcvd x 8 x 1024) /
(Tel_BOP_DL_duration)] +
[(VS_traf_eNB_telecom_pkt_rcvd x 20 x 8) / (Tel_BOP_DL_duration)]
With:
o 8 to normalize to bit/s.
o 1024 to normalize to bit/s (number of Kbytes are measured at
counter/NPO indicator level)
o Tel_BOP_DL_duration is the Telecom interface busiest observation

period, i.e period of the day during which
VS_traf_eNB_telecom_kbyte_rcvd indicator has the maximum
value.
o 20 bytes to account for physical Ethernet header
Rule: Tel_BOP_DL_duration
To get a significant average Telecom throughput figure, Tel_BOP_DL_duration needs to be small

enough. Recommended figure equals to the smallest counters reporting period i.e
15 min or 900 sec.
Downlink Telecom interface traffic adjustment is required when:
Avg_Tel_Thpt_DL ≥
Engineering_Margin x (Telecom_available_Throughput_DL / 1.2)
With:
o Telecom_available_Throughput _DL is the provisioned downlink

bandwidth for Telecom interface (S1 + X2), resulting from initial
dimensioning.
o 1.2 is the peak to average factor (PtA), to compensate the lack of

maximum monitored throughput. PtA is described in section 3.5.4.2
o Engineering_Margin (%) is an operator defined parameter aimed to

enable the network operator to control transport network probability of
congestion. This parameter varies in a range from 80% to 100%,
(80% leads to low probability of congestion, but the interface load
might not be optimum).
 Uplink monitoring
The average Telecom throughput (S1 + X2) in the uplink direction is computed
with a same type of formula as for the downlink direction:
Page 249/273
Avg_Tel_Thpt_UL =
[(VS_traf_eNB_telecom_kbyte_sent x 8 x 1024) / (Tel_BOP_UL_duration)]

+
[(VS_traf_eNB_telecom_pkt_sent x 20 x 8) / (Tel_BOP_UL_duration)]
Elements of the above formula are described in the downlink monitoring part
Uplink Telecom interface throughput adjustment is required when:
Avg_Tel_Thpt_UL ≥
Engineering_Margin x (Telecom_available_Throughput_UL / 1.2)

Elements of the above formula are described in the downlink monitoring part.
4.5.1.1.2 OAM INTERFACE TRAFFIC
OAM interface available indicators to be used to compute the monitored Telecom

traffic throughput are:
 VS_traf_eNB_OAM_kbyte_rcvd (L13314) is a NPO monitoring indicator

directly based on the eNodeB raw counter VS.OAMInOctets. It indicates the
number of Kbytes (Ethernet layer 2) received by an eNodeB on OAM interface
(DL) during the observation period.
 VS_traf_eNB_OAM_kbyte_sent (L13316) is a NPO monitoring indicator

directly based on the eNodeB raw counter VS.OAMOutOctets. It indicates the
number of Kbytes (Ethernet layer 2) sent by an eNodeB on OAM interface
(UL) during the observation period.
 VS_traf_eNB_OAM_pkt_rcvd (L13315) is a NPO monitoring indicator

directly based on the eNodeB raw counter VS.OAMInPackets. It indicates the
number of packets (Ethernet layer 2) received by an eNodeB on OAM
interface (DL) during the observation period. This indicator is used to evaluate
the contribution of physical overhead to the DL OAM throughput.
 VS_traf_eNB_OAM_pkt_sent (L13317) is a NPO monitoring indicator directly

based on the eNodeB raw counter VS.OAMOutPackets. It indicates the
number of packets (Ethernet layer 2) sent by an eNodeB on OAM interface
(UL) during the observation period. This indicator is used to evaluate the
contribution of physical overhead to the UL OAM throughput.
Monitoring is carried out independently at downlink and uplink level.
Page 250/273
Engineering Recommendation: OAM traffic monitoring
Due to its relatively constant time distribution and constant volume transferred (triggered by
specific OAM procedures), the OAM traffic does not require permanent monitoring activity.
It is recommended to perform traffic monitoring only after a network deployment phase, a major
LTE SW release upgrade, or in case specific OAM procedures are launched (Call trace for
example, etc).
The average OAM throughput in the downlink direction is computed as

follows:
Avg_OAM_Thpt_DL =
[(VS_traf_eNB_OAM_kbyte_rcvd) x 8 x 1024) / (OAM_BOP_DL_duration)]

+
[(VS_traf_eNB_OAM_pkt_rcvd x 20 x 8) / (OAM_BOP_DL_duration)]
With:
o 1024 to normalize to bit/s (number of Kbytes are measured at

counter/NPO indicator level)
o OAM_BOP_DL_duration is the OAM interface busiest observation

period, i.e period of the day during which
VS_traf_eNB_OAM_kbyte_rcvd indicator has the maximum value.
Rule: OAM_BOP_DL_duration
To get a significant average OAM throughput figure, OAM_BOP_DL_duration needs to be small

enough. Recommended figure equals to the smallest counters reporting period i.e 15 min or 900
sec.
Downlink OAM interface throughput adjustment is required when:
Avg_OAM_Thpt_DL ≥
Engineering_Margin x (OAM_available_Throughput_DL / 1.2)
With:
o OAM_available_Throughput _DL is the provisioned downlink

bandwidth for Telecom interface (S1 + X2), resulting from initial
dimensioning.
Page 251/273
o 1.2 is the peak to average factor (PtA), to compensate the lack of

maximum monitored throughput. PtA is described in section 3.5.4.2

The average OAM throughput in the uplink direction is computed as follows:
Avg_OAM_Thpt_UL =
[(VS_traf_eNB_OAM_kbyte_sent) x 8 x 1024) / (OAM_BOP_UL_duration)]

+
[(VS_traf_eNB_OAM_pkt_sent x 20 x 8) / (OAM_BOP_UL_duration)]
With the elements of the above formula are described in the downlink
monitoring part.
Uplink OAM interface throughput adjustment is required when:
Avg_OAM_Thpt_UL ≥
Engineering_Margin x (OAM_available_Throughput_UL / 1.2)
With the elements of the above formula are described in the downlink
monitoring part.
Page 252/273
4.5.1.2 SCENARIO 2 (S1, X2, OAM TRAFFIC)
For this configuration, downlink and uplink throughput for S1, X2 and OAM interfaces
are monitored independently, i.e. a set of downlink and uplink monitored throughput
figures are available for S1, X2 and OAM interface respectively.
Monitored downlink / uplink throughput are compared to:
 S1_Available_Throughput (DL/UL)
 X2_Available_Throughput (DL/UL)
 OAM_Available_Throughput (DL/UL)
With Interface#i_Available_Throughput (DL/UL) (interface#i being equal to

S1, X2 or OAM) being the results from the initial dimensioning (per interface
computed throughput figures)
Unlike Telecom traffic (S1+X2) where no downlink and uplink throughput counters are
available at eNodeB level, there are specific NPO throughput indicators available for
S1 and X2 interfaces. Maximum throughput is monitored during the busiest period of
the day (from a volume of transferred information perspective), and it is further used
as an input to carry S1 and X2 interface monitoring.
Please note in addition that since the traffic volume matches to layer 2, additional
layer 1 overhead must be added to get throughput figures at physical layer level.
4.5.1.2.1 S1 INTERFACE TRAFFIC
S1 interface available indicators to be used to compute the monitored S1 traffic

throughput are:
 VS_traf_eNB_S1_thpt_rcvd_max_PerENB (LC13109_Max) is a NPO
monitoring indicator directly based on the eNodeB raw counter
VS.S1DLThroughput.Max. This counter provides the Max throughput received
on the eNodeB S1 interface during the observation period (including Ethernet
headers at layer 2).
 VS_traf_eNB_S1_thpt_sent_max_PerENB (L13111_Max30I) is a NPO

monitoring indicator directly based on the eNodeB raw counter
VS.S1ULThroughput.Max. This counter provides the Max throughput sent on
the eNodeB S1 interface during the observation period (including Ethernet
 VS_traf_eNB_S1_pkt_rcvd (L13110) is a NPO monitoring indicator directly

based on the eNodeB raw counter VS.S1DLPackets. This counter provides
the number of packets received on the eNodeB S1 interface during the
observation period. It will be used to evaluate the contribution of physical
overhead to the DL S1 throughput.
 VS_traf_eNB_S1_pkt_sent (L13112) is a NPO monitoring indicator directly
based on the eNB raw counter VS.S1ULPackets. This counter provides the
Page 253/273
number of packets sent on the eNB S1 interface during the observation

period. It will be used to evaluate the contribution of physical overhead to the
UL S1 throughput.
 VS_traf_eNB_S1_thpt_rcvd_avg_PerENB (L13109_30_CI) this is a NPO

monitoring indicator computed based on two other monitoring metrics. This
indicator provides the average throughput received on the S1 interface of the
eNodeB (including Ethernet headers).
VS_traf_eNB_S1_thpt__rcvd_avg_PerENB =
VS_traf_eNB_S1_thpt_rcvd_cum / VS_traf_eNB_S1_thpt_rcvd_NbEvt
 VS_traf_eNB_S1_thpt_sent_avg_PerENB (L13111_30_CI) this is a NPO

indicator provides the average throughput sent on the S1 interface of the
eNodeB (including Ethernet headers).
VS_traf_eNB_S1_thpt_sent_avg =
VS_traf_eNB_S1_thpt_sent_cum / VS_traf_eNB_S1_thpt_sent_NbEvt
The two above mentioned monitoring indicators provide information on the

average throughput during the observation period. They are used in this
monitoring method to find out the busiest period of the day in terms of S1 traffic
volume.
Maximum S1 downlink monitored throughput is computed as follows:
Max_S1_Thpt_DL =
[(VS_traf_eNB_S1_thpt_rcvd_max_PerENB) +
(VS_traf_eNB_S1_pkt_rcvd x 20 x 8) / (S1_BOP_DL_duration)]
With:
o S1_BOP_DL_duration is the S1 interface busiest observation period,

i.e period of the day during which
VS_traf_eNB_S1_thpt_rcvd_avg_PerENB indicator has the
maximum value.
Page 254/273
Rule: S1_BOP_DL_duration
To get a significant average S1 throughput figure, S1_BOP_DL_duration needs to be small enough.

Recommended figure equals to the smallest counters reporting period i.e
15 min or 900 sec.
Downlink S1 interface traffic adjustment is required when:
Max_S1_Thpt_DL ≥ Engineering_Margin x
(S1_available_Throughput_DL)
With:
o S1_available_Throughput _DL is the provisioned downlink bandwidth

for S1 interface, resulting from initial dimensioning.

Maximum S1 uplink monitored throughput is computed with the same type of

formula as for the downlink direction:
Max_S1_Thpt_UL =
[(VS_traf_eNB_S1_thpt_sent_max_PerENB) +
(VS_traf_eNB_S1_pkt_sent x 20 x 8) / (S1_BOP_UL_duration)]
Uplink S1 interface throughput adjustment is required when:
Max_S1_Thpt_UL ≥ Engineering_Margin x
(S1_available_Throughput_UL)
Page 255/273
4.5.1.2.2 X2 INTERFACE TRAFFIC
X2 interface available indicators to be used to compute the monitored X2 traffic

throughput are:
 VS_traf_eNB_X2_thpt_rcvd_max (L12909_Max) is a NPO monitoring
indicator directly based on the eNodeB raw counter
VS_X2ReceivedThroughput_Max. This counter provides the Max throughput
received on the eNodeB X2 interface during the observation period (including
Ethernet headers at layer 2).
 VS_traf_eNB_X2_thpt_sent_max (L12911_Max) is a NPO monitoring

VS_X2SentThroughput_Max. This counter provides the Max throughput sent
on the eNodeB X2 interface during the observation period (including Ethernet
 VS_traf_eNB_X2_pkt_rcvd (L12910) is a NPO monitoring indicator directly

based on the eNodeB raw counter VS_X2ReceivedPackets.This counter
provides the Max number of packets received on the eNodeB X2 interface
during the observation period. It will be used to evaluate the contribution of
physical overhead to the DL X2 throughput.
 VS_traf_eNB_X2_pkt_sent (L12912) is a NPO monitoring indicator directly

based on the eNodeB raw counter VS_X2SentPackets. This counter provides
the Max number of packets sent on the eNodeB X2 interface during the
observation period. It will be used to evaluate the contribution of physical
overhead to the UL X2 throughput.
 VS_traf_eNB_X2_thpt_rcvd_avg_PerENB (L12909_30_CI) is a NPO

indicator provides the average throughput received on the X2 interfaces of the
eNodeB equipment (including Ethernet headers).
VS_traf_eNB_X2_thpt_rcvd_avg_PerENB =
VS_traf_eNB_X2_thpt_rcvd_cum / VS_traf_eNB_X2_thpt_rcvd_NbEvt
 VS_traf_eNB_X2_thpt_sent_avg_PerENB (L12911_30_CI) is a NPO

indicator provides the average throughput sent on the X2 interfaces of the
eNodeB equipment (including Ethernet headers).
VS_traf_eNB_S1_thpt_sent_avg_PerENB =
VS_traf_eNB_X2_thpt_sent_cum / VS_traf_eNB_X2_thpt_sent_NbEvt
The two above mentioned monitoring indicators provide information on the

average throughput during the observation period. They are used in this
monitoring method to find out the busiest period of the day in terms of X2 traffic
volume.
Page 256/273
Maximum X2 downlink monitored throughput is computed as follows:
Max_X2_Thpt_DL =
[(VS_traf_eNB_X2_thpt_rcvd_max_PerENB) +
(VS_traf_eNB_X2_pkt_rcvd x 20 x 8) / (X2_BOP_DL_duration)]
With:
o X2_BOP_DL_duration is the X2 interface busiest observation period,

i.e period of the day during which
VS_traf_eNB_X2_thpt_rcvd_avg_PerENB indicator has the
maximum value.
Rule: X2_BOP_DL_duration
To get a significant average X2 throughput figure, X2_BOP_DL_duration needs to be small enough.

Recommended figure equals to the smallest counters reporting period i.e
15 min or 900 sec.
Downlink X2 interface traffic adjustment is required when:
Max_X2_Thpt_DL ≥ Engineering_Margin x
(X2_available_Throughput_DL)
With:
o X2_available_Throughput _DL is the provisioned downlink bandwidth

for X2 interface, resulting from initial dimensioning.

 Uplink Monitoring
Maximum X2 uplink monitored throughput is computed with the same type of

formula as for the downlink direction:
Max_X2_Thpt_UL =
Page 257/273
[(VS_traf_eNB_X2_thpt_sent_max_PerENB) +
(VS_traf_eNB_X2_pkt_sent x 20 x 8) / (X2_BOP_UL_duration)]
Uplink X2 interface throughput adjustment is required when:
Max_X2_Thpt_UL ≥ Engineering_Margin x
(X2_available_Throughput_UL)
4.5.1.2.3 OAM INTERFACE TRAFFIC
Please refer to section 4.5.1.1.2 above.
4.5.1.3 ADDITIONAL INDICATORS
Additional indicators can be used for eNodeB interfaces monitoring In case the eNB
backhaul physical link load monitoring is required (GigE link), the following can be
used:
 VS_traf_eNB_if_link_usage_rcvd_max (L13312_Max) is a NPO monitoring
VS_IfInLinkUtilisation_Max. This indicator provides the maximum eNodeB
backhaul interface load for the DL direction, as compared to maximum Gigabit
per sec physical link capacity.
 VS_traf_eNB_if_link_usage_sent_max (L13313_Max) is a NPO monitoring

indicator directly based on the eNB raw counter VS_IfOutLinkUtilisation_Max.
This indicator provides the maximum eNodeB backhaul interface load for the
UL direction, as compared to maximum Gigabit per sec physical link capacity.
Note that these indicators provide a view of the eNodeB backhaul interface load. They
do not report a congestion status as the available throughput on the backhaul is
always significantly higher than the required Air interface throughput (refer to section
3.2.3.5).
Page 258/273
4.5.1.4 S-GW AND P-GW INTERFACE STATISTICS
Each signaling interface type available for the S-GW and P-GW has detailed statistics
and peer status outputs available. These commands also fall under the “show mobile-
gateway <serving> or <pdn>” context. The outputs include signaling interface peer
status as well as related counters such as bearer create, modify or delete requests
and error counters. Examples of signaling interface outputs are shown below.
4.5.1.4.1 S11 STATISTICS
The first example (below) shows the S-GW S11 peer status and S11 peer statistics
outputs. Similar statistics and peer status are available for the S-GW signaling
interfaces such as the S1-U, S5, and Gx.
Figure 64 : Example of S-GW S11 Peer Status and S11 Peer Statistics Outputs
Page 259/273
4.5.1.4.2 S1-U STATISTICS
The S1-U signaling interface example below provides the S-GW S1-U peer status and
S1-U peer statistics outputs.
Figure 65 : Example of S-GW S1U Peer Statistics and S1U Peer Status Outputs
4.5.1.4.3 S5 STATISTICS
The S5 signaling interface example below shows the P-GW S5 peer status and S5
peer statistic outputs. Similar statistics and peer status are available for the P-GW
signaling interfaces such as the S5, Gx and Rf.
Page 260/273
Figure 66 : Example of P-GW S5 Peer Status and S5 Peer Statistic Outputs
4.5.1.4.4 PER BEARER STATISTICS
Additional show commands are available including detailed per bearer statistics. The
per bearer outputs include bearer IP addressing, packet and bytes counters and QoS
limits. Note that these statistics can also be shown in the context for each signaling
interface type. An example of an S-GW active bearer is shown below.
Page 261/273
Figure 67 : Example of S-GW Active Bearer Context Snapshot
4.5.2 KPI AND KCI PERFORMANCE MONITORING

The 7750 SR MG OS Release 3.1 supports many KPI and KCI performance
monitoring statistics. The KPI/KCI statistics allow the user to collect statistics for
control plane signaling, bearer traffic and system level resources usage. This data can
be used to trend system resource usage; network signaling and bearer activity;
bandwidth demands and other information. The statistics are collected in XML
formatted accounting records on compact flash drives (cf1 or cf2 located on the
SF/CPM).
KPI/KCI statistics include hundreds of individual counters available to the various

accounting record types. Many of the counters shown in the cli examples above will be
available for collection in the KPI/KCI accounting records. Details of the accounting
record contents and configuration will be provided in the 7750 MG R3.1 configuration
manuals.
An overview of the types of record types and stats available include (but are not
limited to):
 KPI:
o system
 cpu and memory utilization, mg-ism resources

o bearer-mgmt
 per system and per mg-ism attach, detach, paging, handover,

attempt/success/failure
o bearer-traffic
Page 262/273
 per bearer UL/DL forward & drop counters

o ref-point
 per peer protocol & type msg stats for Rx reference points
o path-mgmt
 detailed S11, S5, S1u, Gx, RF activity stats
 KCI:
o system
 Memory, cpu, flash memory usage
o bearer-mgmt
 Bearers (def/ded) totals, paging, active, idle, roamers, visitors,

homers
o path-mgmt
 IPv4/v6 S11, S5/S8, S1u, Gx, RF peers, APNs, VPRNs, IP

pools
Recommended parameters to monitor include:
Attach Success Rate, UE Service Request Success Rate, Dedicated Bearer Activation
Success Rate, Paging Success Rate, Intra SGW Handover Success Rate, Inter SGW
Handover Success Rate, Inter SGW S1 based with Indirect Tunnel Handover Success
Rate, Inter SGW S1 based without Indirect Tunnel Handover Success Rate, Intra
SGW Tracking Area Update Success Rate, Inter SGW Tracking Area Update Success
Rate and eHRPD to LTE Handover Success Rate.
Above list of parameters and be calculated from following list of KPI and KCI counters.
4.5.2.1 SYSTEM KPI
4.5.2.1.1 SGW COUNTERS
 VS.maxCpuUtilization (KPISystemCPM) - Maximum CPU utilization per

CPM card.
 VS.maxMemoryUtilization (KPISystemCPM) - Maximum memory utilization
per CPM card.
 VS.maxCpuUtilization (KPISystemCP-ISA) - Maximum CPU utilization per

CP-ISA card.
 VS.maxMemoryUtilization (KPISystemCP-ISA) - Maximum memory

utilization per CP-ISA card.
4.5.2.1.2 PGW COUNTERS
 VS.maxCpuUtilization (KPISystemCPM) - Maximum CPU utilization per

CPM card.
Page 263/273
 VS.maxMemoryUtilization (KPISystemCPM) - Maximum memory utilization

per CPM card.
 VS.maxCpuUtilization (KPISystemCP-ISA) - Maximum CPU utilization per

CP-ISA card.
 VS.maxMemoryUtilization (KPISystemCP-ISA) - Maximum memory
utilization per CP-ISA card.
4.5.2.2 BEARER MANAGEMENT KPI
 VS.attachProcedureSuccessful (KPIBearerManagementCP-ISA) - Number

of Attach procedures served successfully per CP-ISA card
 VS.attachProcedureFailures (KPIBearerManagementCP-ISA) - Number of

Attach procedure failures per CP-ISA card
 VS.ueInitiatedServiceRequestProcedureSuccessful
(KPIBearerManagementCP-ISA) - Number of UE initiated service request
(idle to active) procedures served successfully per CP-ISA card
 VS.ueInitiatedServiceRequestProcedureFailures
(KPIBearerManagementCP-ISA) - Number of UE initiated service request
(idle to active) procedure failures per CP-ISA card
 VS.ueInitiatedDedicatedBearerActivationSuccessful
(KPIBearerManagementCP-ISA) - Number of UE initiated Dedicated Bearer
setup successfully per CP-ISA card
 VS.ueInitiatedDedicatedBearerActivationFailures
(KPIBearerManagementCP-ISA) - Number of UE initiated Dedicated Bearer
setup failures per CP-ISA card
 VS.networkInitiatedDedicatedBearerActivationSuccessful
(KPIBearerManagementCP-ISA) - Number of network initiated Dedicated
Bearer setup successfully per CP-ISA card
 VS.networkInitiatedDedicatedBearerActivationFailures
(KPIBearerManagementCP-ISA) - Number of network initiated Dedicated
Bearer setup failures per CP-ISA card
 VS.pagingAttempts (KPIBearerManagementCP-ISA) - Number of idle user

paging attempts per CP-ISA card
 VS.pagingFailures (KPIBearerManagementCP-ISA) Number of idle user
paging failures per CP-ISA card
 VS.intraSgwRelocationS1X2BasedHandoverSuccessful
(KPIBearerManagementCP-ISA) - Number of Intra SGW handovers (X2-
based and S1-based handovers with and without indirect tunnels) served
successfully per CP-ISA card
 VS.intraSgwRelocationS1X2BasedHandoverFailures
(KPIBearerManagementCP-ISA) - Number of Intra SGW handovers (X2-
Page 264/273
based and S1-based handovers with and without indirect tunnels) failed per
CP-ISA card
 VS.intraSgwRelocationS1BasedWithIndirectTunnelHandoverSuccessful
(KPIBearerManagementCP-ISA) - Number of Intra SGW handovers (S1
based with indirect tunnels) served successfully per CP-ISA card
 VS.intraSgwRelocationS1BasedWithIndirectTunnelHandoverFailures
(KPIBearerManagementCP-ISA) - Number of Intra SGW handovers (S1
based with indirect tunnels) failed per CP-ISA card
 VS.interSgwX2RelocationHandoverSuccessful
(KPIBearerManagementCP-ISA) - Number of Inter SGW handovers (X2
based) served successfully per CP-ISA card
 VS.interSgwX2RelocationHandoverFailures (KPIBearerManagementCP-
ISA) - Number of Inter SGW handovers (X2 based) failed per CP-ISA card
 VS.interSgwS1BasedRelocationWithIndirectTunnelHandoverSuccessful
(KPIBearerManagementCP-ISA) - Number of Inter SGW handovers (S1
based with indirect tunnel) served successfully per CP-ISA card
 VS.interSgwS1BasedRelocationWithIndirectTunnelHandoverFailures
(KPIBearerManagementCP-ISA) - Number of Inter SGW handovers (S1
based with indirect tunnel) failed per CP-ISA card
 VS.idleModeTauWithIntraSgwRelocationSuccessful
(KPIBearerManagementCP-ISA) - Number of idle mode intra SGW TAU
served successfully per CP-ISA card
 VS.idleModeTauWithIntraSgwRelocationFailures
(KPIBearerManagementCP-ISA) - Number of idle mode intra SGW TAU
failed per CP-ISA card
 VS.idleModeTauWithInterSgwRelocationSuccessful
(KPIBearerManagementCP-ISA) - Number of idle mode inter SGW TAU
handovers served successfully per CP-ISA card
 VS.idleModeTauWithInterSgwRelocationFailures
(KPIBearerManagementCP-ISA) - Number of idle mode inter SGW TAU
handovers failed per CP-ISA card
 VS.ehrpdToLteHandoverSuccessful (KPIBearerManagementCP-ISA) –
Number of eHRPD to LTE handovers served successfully per CP-ISA card
 VS.ehrpdToLteHandoverFailures (KPIBearerManagementCP-ISA) -
Number of eHRPD to LTE handovers failed per CP-ISA card
 VS.attachProcedureSuccessful (KPIBearerManagementCP-ISA) - Number

of Attach procedures served successfully per CP-ISA card
 VS.attachProcedureFailures (KPIBearerManagementCP-ISA) - Number of

Attach procedure failures per CP-ISA card
Page 265/273
 VS.networkInitiatedDedicatedBearerActivationSuccessful
(KPIBearerManagementCP-ISA) - Number of Network Initiated Dedicated
Bearer setup served successfully per CP-ISA card
 VS.networkInitiatedDedicatedBearerActivationFailures
(KPIBearerManagementCP-ISA) - Number of Network Initiated Dedicated
Bearer setup failures per CP-ISA card
4.5.2.3 BEARER TRAFFIC KPI
 VS.s1uS5uUlBytes (KPIBearerTrafficMSM) - Throughput UL bytes per MG-

ISM card
 VS.s5uS1uDlBytes (KPIBearerTrafficMSM) - Throughput DL bytes per MG-

ISM card
 VS.s5uGiUlBytes (KPIBearerTrafficMSM) - Throughput UL bytes per MG-

ISM card
 VS.giS5uDlBytes (KPIBearerTrafficMSM) - Throughput DL bytes per MG-
ISM card
4.5.2.4 PATH MANAGEMENT KPI
 VS.s5GtpPathMgmtFailures (KPIPathManagementCPM) – Total number of

S5 peer path management failures detected by loss of GTP keep-alives from
remote peer
 VS.s5GtpPeerRestarts (KPIPathManagementCPM) – Total number of S5

peer restarts detected by change in peer restart value
 VS.s11GtpPathMgmtFailures (KPIPathManagementCPM) – Total number

of S11 peer path management failures detected by loss of GTP keep-alives
from remote peer


remote peer

Page 266/273

remote peer

4.5.2.5 SYSTEM KCI
 VS.maxCpuUtilization (KCISystemCP-ISA) - Maximum CPU utilization per

CP-ISA card
 VS.maxMemoryUtilization (KCISystemCP-ISA) - Maximum memory

utilization per CP-ISA card
 VS.maxCpuUtilization (KCISystemCP-ISA) - Maximum CPU utilization per

CP-ISA card
 VS.maxMemoryUtilization (KCISystemCP-ISA) - Maximum memory

utilization per CP-ISA card
4.5.2.6 BEARER MANAGEMENT KCI
 VS.numberOfUsers (KCIBearerManagementCP-ISA) - Number of UEs
 VS.numberOfBearers (KCIBearerManagementCP-ISA) - Number of

Bearers
 VS.numberOfDedicatedBearers (KCIBearerManagementCP-ISA) -
Number of Dedicated Bearers
 VS.numberOfActiveBearers (KCIBearerManagementCP-ISA) - Number of

Active Bearers
 VS.numberOfPagingRequestInProgress (KCIBearerManagementCP-ISA)
- Number of UE paging requests in progress.
 VS.numberOfBearers (KCIBearerManagementCP-ISA) - Number of

Bearers
 VS.numberOfDedicatedBearers (KCIBearerManagementCP-ISA) -
Number of Dedicated Bearers
Page 267/273
5 LTE SYSTEM CAPACITY PLANNING

Capacity planning enables predicting future capacity issues and anticipating
operational actions needed to avoid them (parameters tuning, network extensions,
network elements re-parenting…).
5.1 CAPACITY PLANNING PRINCIPLE

For Capacity Planning exercise, a customer Traffic model is to be considered
(real/monitored call model) which will be associated to the current monitored
resources usage (load).
By changing the traffic model assumption, a new trend of the load evolution can be
established and an estimated time for reaching the load limits will be defined.
Resources usage
(load) Eng limit (≤ target QoS)
3. Forecast new load evolution

x
2. Update Load with new
assumptions
x
1. Characterise Load evolution
with current assumptions
Today
Past Future Time
Figure 68 : Capacity Planning Principle
By changing the traffic model assumption, a new trend of the load evolution can be
established and a new estimated time for reaching the load limits can be defined.
Capacity Planning is based on Capacity Monitoring results and commercial inputs:
 medium and long term traffic growth,
 new services/features that will be activated,
 Commercial promotions for the existing services…
Page 268/273
Capacity Capacity Planning

Projected Load
Monitoring
Eng’g limit Eng’g limit
Measured load Conclusion: Measured load Conclusion:

No action required Additional resource
to be forecasted
Figure 69 : Capacity Monitoring vs. Capacity planning
The main capacity planning difficulty is to convert the commercial inputs in a traffic
growth estimation and implicit eUTRAN elements load increase estimation. This load
estimation/projection will be compared with the engineering limit (QoS targets) in order
to decide the future action to take (parameters tuning, new resources…)
Restriction: Capacity Planning methods for LE6.x
Capacity Planning documentation is under construction requiring LE6.x monitoring feedback.
This part of the LTE Network Capacity Monitoring & Engineering document is not provided in this
version (it will be delivered in a future version of the document).
Page 269/273
6 ABBREVIATIONS
All terms, definitions and abbreviations used in the present document that are
common across 3GPP TSs are defined in the 3GPP Vocabulary. For the purposes of
the present document, the abbreviations given in following apply:
ACK Acknowledgement
ACLR Adjacent Channel Leakage Ratio
AM Acknowledge Mode
AMBR Aggregate Maximum Bit Rate
ANR Automatic Neighbor Relation
ARQ Automatic Repeat Request
AS Access Stratum
BCCH Broadcast Control Channel
BCH Broadcast Channel
BSR Buffer Status Reports
C/I Carrier-to-Interference Power Ratio
CAZAC Constant Amplitude Zero Auto-Correlation
CMC Connection Mobility Control
CM Configuration Management
CP Cyclic Prefix
C-plane Control Plane
C-RNTI Cell RNTI
CQI Channel Quality Indicator
CRC Cyclic Redundancy Check
CSG Closed Subscriber Group
DCCH Dedicated Control Channel
DDT Dynamic Debug Trace
DL Downlink
DFTS DFT Spread OFDM
DPI Deep Packet Inspection
DTCH Dedicated Traffic Channel
DRB Data Radio Bearer
DRX Discontinuous Reception
DTCH Dedicated Traffic Channel
DTX Discontinuous Transmission
DwPTS Downlink Pilot Time Slot
ECGI E-UTRAN Cell Global Identifier
ECM EPS Connection Management
eHRPD enhanced High Rate Packet Data
EMM EPS Mobility Management
eNB E-UTRAN NodeB
EPC Evolved Packet Core
EPS Evolved Packet System
E-RAB E-UTRAN Radio Access Bearer
ETWS Earthquake and Tsunami Warning System
E-UTRA Evolved UTRA
E-UTRAN Evolved UTRAN
FDD Frequency Division Duplex
FDM Frequency Division Multiplexing
FM Fault Management
GERAN GSM EDGE Radio Access Network
GNSS Global Navigation Satellite System
GSM Global System for Mobile communication (Groupe Spécial Mobile)
GBR Guaranteed Bit Rate
GP Guard Period
GUTI Globally Unique Temporary Identifier
Page 270/273
HARQ Hybrid ARQ

HO Handover
HRPD High Rate Packet Data
HSDPA High Speed Downlink Packet Access
ICIC Inter-Cell Interference Coordination
IP Internet Protocol
LB Load Balancing
LCR Low Chip Rate
LTE Long Term Evolution
MAC Medium Access Control
MBMS Multimedia Broadcast Multicast Service
MBR Maximum Bit Rate
MBSFN Multimedia Broadcast multicast service Single Frequency Network
MCCH Multicast Control Channel
MCE Multi-cell/multicast Coordination Entity
MCH Multicast Channel
MCS Modulation and Coding Scheme
MIB Master Information Block
MIMO Multiple Input Multiple Output
MME Mobility Management Entity
MTCH MBMS Traffic Channel
MSAP MCH Subframe Allocation Pattern
N.A Not Applicable
NACK Negative Acknowledgement
NAS Non-Access Stratum
NCC Next Hop Chaining Counter
NGMN Next Generation Mobile Networks
NH Next Hop key
NR Neighbor cell Relation
NRT Neighbor Relation Table
N.S Not Significant
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
OMC Operations and Maintenance Center
P-GW PDN Gateway
P-RNTI Paging RNTI
PA Power Amplifier
PAPR Peak-to-Average Power Ratio
PBCH Physical Broadcast CHannel
PBR Prioritized Bit Rate
PCCH Paging Control Channel
PCFICH Physical Control Format Indicator CHannel
PCH Paging Channel
PCI Physical Cell Identifier
PDCCH Physical Downlink Control CHannel
PDSCH Physical Downlink Shared CHannel
PDCP Packet Data Convergence Protocol
PDU Protocol Data Unit
PHICH Physical Hybrid ARQ Indicator CHannel
PHY Physical layer
PLMN Public Land Mobile Network
PMCH Physical Multicast Channel
PM Performance Management
PRACH Physical Random Access CHannel
PRB Physical Resource Block
PSC Packet Scheduling
PUCCH Physical Uplink Control CHannel
PUSCH Physical Uplink Shared CHannel
QAM Quadrature Amplitude Modulation
QCI QoS Class Identifier
Page 271/273
QoS Quality of Service

RA-RNTI Random Access RNTI
RAC Radio Admission Control
RACH Random Access Channel
RAT Radio Access Technology
RB Radio Bearer
RBC Radio Bearer Control
RBG Radio Bearer Group
RF Radio Frequency
RIM RAN Information Management
RLC Radio Link Control
RNC Radio Network Controller
RNL Radio Network Layer
RNTI Radio Network Temporary Identifier
ROHC Robust Header Compression
RRC Radio Resource Control
RRM Radio Resource Management
RSRP Reference Signal Received Power
RU Resource Unit
S-GW Serving Gateway
S1-MME S1 for the control plane
SC-RNTI System Information Change RNTI
SI System Information
SIB System Information Block
SI-RNTI System Information RNTI
S1-U S1 for the user plane
SAE System Architecture Evolution
SAP Service Access Point
SC-FDMA Single Carrier – Frequency Division Multiple Access
SCH Synchronization Channel
SDF Service Data Flow
SDMA Spatial Division Multiple Access
SDU Service Data Unit
SFN System Frame Number
SPI Shallow Packet Inspection
SPID Subscriber Profile ID for RAT/Frequency Priority
SR Scheduling Request
SRB Signaling Radio Bearer
SRVCC Single Radio Voice Call Continuity
SU Scheduling Unit
TA Tracking Area
TB Transport Block
TCP Transmission Control Protocol
TDD Time Division Duplex
TFT Traffic Flow Template
TM Transparent Mode
TNL Transport Network Layer
TTI Transmission Time Interval
UE User Equipment
UL Uplink
UM Un-acknowledge Mode
UMTS Universal Mobile Telecommunication System
U-plane User plane
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
UpPTS Uplink Pilot Time Slot
UPOS Unified Procedure Oriented Selective (Trace Service)
VRB Virtual Resource Block
X2-C X2-Control plane
X2-U X2-User plane
Page 272/273
 END OF DOCUMENT 
Page 273/273

Lte DCL App 030940 App-Std Lncme Le6

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lte DCL App 030940 App-Std Lncme Le6

Hochgeladen von

Copyright:

Verfügbare Formate

LTE Network Capacity 05.

LTE Network Capacity Monitoring & Engineering

Copyright © 2011 by Alcatel-Lucent. All Rights Reserved.

2 LTE OVERVIEW ......................................................................................................................... 15

3 INITIAL ENGINEERING & DIMENSIONING .............................................................................. 50

3.2.2 LTE eNB Configurations & Capacities ......................................................................... 68

3.6.3 P-GW Dimensioning ................................................................................................... 163

3.8.13.1 S12 Interface Description ....................................................................................... 196

4 LTE INTERFACE MONITORING: TROUBLESHOOTING & CAPACITY GROWTH ACTIONS

4.5.1.2 Scenario 2 (S1, X2, OAM Traffic) ........................................................................... 253

5 LTE SYSTEM CAPACITY PLANNING .................................................................................... 268

6 ABBREVIATIONS ..................................................................................................................... 270

Table 57: Detach Procedure ........................................................................................................................... 141

Figure 57: SGS interface protocol stack ....................................................................................................... 203

The primary goals for this document are:

1.2 SCOPE OF THIS DOCUMENT

LTE E2E Release LE6.0

ALU 9412 Compact eNodeB: LA6.0

ALU NPO R5.1

ALU 9471 MME WM6.0.0

ALU 8650 SDM (HSS): 3.1

ALU P-GW / SGW (7750 SR) 4.0 R9

ALU 5780 DSC (PCRF) 5.0 R5

ALU 5620 SAM 10.0 R5

Figure 1 : Alcatel Lucent LTE Releases mapping

1.3 AUDIENCE FOR THIS DOCUMENT

Therefore, the audience for this manual consists of:

1.4 CHANGE CONTROL

Rev 05.00 31/May/2013 All LE6.0 document creation from previous

Rev 05.02 25/July/2013 All Approved-Preliminary version

Rev 05.03 06/September/2013 All Approved-Standard version

Current known system/documentation restrictions are presented as the following:

Engineering recommendations (Alcatel-Lucent recommendation for optimal system

1.6 RELATED DOCUMENTS

1.6.1 REFERENCE DOCUMENTS

[R02] RFC 4960 Stream Control Transmission Protocol (SCTP) @

1.6.2 CUSTOMER DOCUMENTS

[C02] LTE/DCL/APP/031106, LA6.0 eNodeB Product Engineering Guide

[C03] LTE/DCL/APP/031077, LE6.0 LTE OAM Product Engineering Guide

[C05] LTE/DCL/APP/031092, 9471 Wireless Mobility Manager Model Offer

[C06] LTE/DCL/APP/031094, 9471 Wireless Mobility Manager LTE Parameters

[C07] LTE/DCL/APP/034072, LTE Transport Engineering Guide – (T)LE6

[C09] Equivalent Capacity and its Application to Bandwidth Allocation in High-Speed

[C11] LTE Dimensioning Guidelines – Air Interface Capacity (Alcatel-Lucent

[C12] Alcatel-Lucent 7750 Service Router Mobile Gateway Integrated Services

[C15] Release 4.0 7750 SR OS MG Basic System Configuration Guide

[C16] Release 4.0 R9 7750 SR Mobile Gateway Configuration Guide

[C17] Alcatel-Lucent 8650 SDM_HSS LTE_Feature_Overview_R3.1.doc

[C18] 8560 SDM R3.1 Product Description

[C19] Alcatel-Lucent 8950 AAA Release 8.0 User’s guide

[C20] Alcatel-Lucent 5780 DSC 5.0 R5 User Guide

[C21] 9YZ-03991-0007-RKZZA, Network Performance Optimizer Release

2.1 LTE NETWORK OVERVIEW

2.1.1 REQUIREMENTS AND TARGETS FOR LTE

 peak rates exceed 100 Mbps in downlink and 50 Mbps in uplink;

 round trip time <10 ms;

 Simplified network architecture;

 high level of mobility and security;

 optimized terminal power efficiency;

 Frequency bandwidth flexibility from below 1.4 MHz up to 20 MHz allocations.

In order to reach the above mentioned targets, several elements were

2.1.1.1 AIR INTERFACE EVOLUTION

2.1.1.1.1 MULTI-CARRIER TECHNOLOGIES