1/123118
114
Document Type
Author
Unit/Dept.
Document Title
Date, Version
For internal use only
Nokia Siemens Networks
Data/MBB Performance Optimisation Guide
For Internal Use Only
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Revision History
Date
Rev.
Summary of Change
25.9.2008
23.12.2008
19.1.2009
28.7.2009
31.12.2009
15.10.2010
17.11.2010
v.0.1
v.0.6
v.0.7
v.1.0
v. 1.1
V.2.0
v.2.1
Document created
First draft for review
Initial reviewed version for RAS06
First version for RAS06/RU10
Updated for RU10
Updated for RU20
Small updates; DC HSDPA etc.
Editor/s:
Date:
Version:
Jarkko Itkonen, Kirsi
Teräväinen, Pekka Ranta
1517.110.2010
v.2.10
Copyright © Nokia Siemens Networks. This material, including documentation and any related
computer programs, is protected by copyright controlled by Nokia Siemens Networks. All rights are
reserved. Copying, including reproducing, storing, adapting or translating, any or all of this material
requires the prior written consent of Nokia Siemens Networks. This material also contains confidential
information which may not be disclosed to others without the prior written consent of Nokia Siemens
Networks
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 2 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Table of contents
1 Introduction............................................................................................... 128
2 PS Data connection signalling ................................................................. 149
2.1 RRC Setup .......................................................................................................................... 149
2.2 SRB on HSPA ................................................................................................................... 1712
2.3 Fast Dormancy .................................................................................................................. 1813
2.4 Packet data connection setup ............................................................................................ 1914
2.4.1 GPRS Attach .................................................................................................................. 1914
2.4.2 Service Request ............................................................................................................. 1914
2.4.3 PDP context setup .......................................................................................................... 2015
2.4.4 Data flow setup ............................................................................................................... 2217
2.4.5 Direct Resource Allocation for HSPA ............................................................................. 2419
2.4.6 RRC state transitions ...................................................................................................... 2520
2.4.7 Packet data connection mobility ..................................................................................... 2823
3 PS RAB QoS parameters ...................................................................... 3126
3.1
3.2
Specification ...................................................................................................................... 3126
Definition of PS RAB QoS in connection setup .................................................................. 3126
4 UE Categories and Monitoring ............................................................... 3227
5 NRT PS RAB performance .................................................................... 3631
5.1
5.2
Accessibility ....................................................................................................................... 3631
Retainability ....................................................................................................................... 3833
6 HSPA bearer performance..................................................................... 4338
6.1 Accessibility ....................................................................................................................... 4338
6.1.1 HSDPA accessibility ....................................................................................................... 4338
6.1.2 HSDPA UL Return Channel ............................................................................................ 4944
6.1.3 HSUPA Accessibility ....................................................................................................... 5146
6.2 HSPA Throughput and RTT (incl. MIMO and DC).............................................................. 5651
6.2.1 HSDPA throughput Optimisation .................................................................................... 5651
6.2.1.1 HSDPA peak performance and configurations ............................................................. 5651
6.2.1.2 HSDPA throughput Monitoring and troubleshooting ..................................................... 6256
6.2.1.3 MIMO throughput performance & monitoring ............................................................... 7671
6.2.1.4 DC HSDPA throughput and Performance .................................................................... 7974
6.2.2 HSUPA throughput optimisation ..................................................................................... 8378
6.2.2.1 HSUPA Peak performance and configuration .............................................................. 8378
6.2.2.2 HSUPA throughput monitoring and troubleshooting ..................................................... 8883
6.2.3 Round Trip Time (RTT) ................................................................................................... 9893
6.3 Mobility .............................................................................................................................. 9994
6.4 Retainability ..................................................................................................................... 10297
7 HSPA & R99 bearer interworking ...................................................... 105100
7.1 Power, Code and CE (HSUPA) sharing ......................................................................... 106101
7.1.1 DL power sharing ....................................................................................................... 106101
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 3 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
7.1.2 Channelisation code tree sharing ............................................................................... 110105
7.1.3 WBTS resource sharing.............................................................................................. 116111
7.2 Effect of HSPA on R99 performance ............................................................................. 121116
References .............................................................................................. 123118
1 Introduction....................................................................................................8
2 PS Data connection signalling ......................................................................9
2.1 RRC Setup .............................................................................................................................. 9
2.2 SRB on HSPA ....................................................................................................................... 12
2.3 Fast Dormancy ...................................................................................................................... 13
2.4 Packet data connection setup ................................................................................................ 14
2.4.1 GPRS Attach ...................................................................................................................... 14
2.4.2 Service Request ................................................................................................................. 14
2.4.3 PDP context setup .............................................................................................................. 15
2.4.4 Data flow setup ................................................................................................................... 17
2.4.5 Direct Resource Allocation for HSPA ................................................................................. 19
2.4.6 RRC state transitions .......................................................................................................... 20
2.4.7 Packet data connection mobility ......................................................................................... 23
3 PS RAB QoS parameters .......................................................................... 26
3.1
3.2
Specification .......................................................................................................................... 26
Definition of PS RAB QoS in connection setup ...................................................................... 26
4 UE Categories and Monitoring ................................................................... 27
5 NRT PS RAB performance ........................................................................ 31
5.1
5.2
Accessibility ........................................................................................................................... 31
Retainability ........................................................................................................................... 33
6 HSPA bearer performance......................................................................... 38
6.1 Accessibility ........................................................................................................................... 38
6.1.1 HSDPA accessibility ........................................................................................................... 38
6.1.2 HSDPA UL Return Channel ................................................................................................ 44
6.1.3 HSUPA Accessibility ........................................................................................................... 46
6.2 HSPA Throughput and RTT (incl. MIMO and DC).................................................................. 51
6.2.1 HSDPA throughput Optimisation ........................................................................................ 51
6.2.1.1 HSDPA peak performance and configurations ................................................................. 51
6.2.1.2 HSDPA throughput Monitoring and troubleshooting ......................................................... 57
6.2.1.3 MIMO throughput performance & monitoring ................................................................... 71
6.2.2 HSUPA throughput optimisation ......................................................................................... 74
6.2.2.1 HSUPA Peak performance and configuration .................................................................. 74
6.2.2.2 HSUPA throughput monitoring and troubleshooting ......................................................... 80
6.2.3 Round Trip Time (RTT) ....................................................................................................... 90
6.3 Mobility .................................................................................................................................. 91
6.4 Retainability ........................................................................................................................... 94
7 HSPA & R99 bearer interworking .............................................................. 97
7.1
Power, Code and CE (HSUPA) sharing ................................................................................. 98
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 4 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
7.1.1 DL power sharing ............................................................................................................... 98
7.1.2 Channelisation code tree sharing ..................................................................................... 101
7.1.3 WBTS resource sharing.................................................................................................... 107
7.2 Effect of HSPA on R99 performance ................................................................................... 112
References .................................................................................................... 114
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 5 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Formatted: Font: Bold
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 6 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
List of Figures
Figure 1. RRC connection setup signalling................................................................................................149
Figure 2. F-DCPCH signalling example, when FDPCHSetup (1) RRC Connection Setup message moves
the UE into Cell_FACH. F-DPCH is then allocated immediately after receiving the RRC connection setup
complete message ...................................................................................................................................1813
Figure 3. GPRS Attach procedure ...........................................................................................................1914
Figure 4. Service Request procedure. .....................................................................................................2015
Figure 5. PDP context setup procedure. ..................................................................................................2015
Figure 6. Capacity request and resource allocation signalling for packet data call. HSDPA+HSUPA ...2217
Figure 7. Comparison of Normal NRT RAB Setup and Direct Resource allocation for HSPA ................2419
Figure 8. RRC states and transitions. RU10 Introduce possibility to use URA_PCH state and fast call
setup directly from URA_PCH/CELL_PCH to Cell_DCH. New transitions supported by RU10, are shown
with black lines. ........................................................................................................................................2520
Figure 9. Transition from CELL_DCH to CELL_FACH with Radio Bearer Reconfiguration procedure. .2621
Figure 10. Transition from CELL_FACH to CELL_PCH (URA_PCH) with Radio Bearer Reconfiguration
procedure. ................................................................................................................................................2621
Figure 11. Transfer of the UE to CELL_DCH and reactivation of the data connection (cause UL data
transmission). ...........................................................................................................................................2722
Figure 12. Fast call setup with direct transition from URA_PCH/CELL_PCH to CELL_DCH. ................2823
Figure 13. Serving HS-DSCH cell change triggered by periodical EcNo measurements. ......................2924
Figure 14. Serving cell change triggered by Event 1B on the serving HSDSCH cell (no NBAP signalling
presented). ...............................................................................................................................................3025
Figure 15. Inter-RNC serving HS-DSCH cell change with hard handover (no NBAP signalling presented).
.................................................................................................................................................................3025
Figure 16 HSDPA and HSUPA UE utilisation within last 100 weeks. .....................................................3429
Figure 17 HSDPA UE category distribution within last 100 weeks. .........................................................3429
Figure 18. HSUPA UE category distribution within last 100 weeks. ........................................................3530
Figure 19 PS RAB setup failure rate statistics (RU10/RU20) .................................................................3833
Figure 20. PS RAB Access failure rate statistics (RU10/RU20) ..............................................................3833
Figure 21. NRT PS RAB retainability analysis .........................................................................................4136
Figure 22 Example of PS NRT RAB Active fail change due to BTS (RU10/RU20).................................4136
Figure 23 Example of PS setup failure rates (RU10/RU20) ....................................................................4237
Figure 24 – HSDPA Accessibility Failure Analysis ..................................................................................4439
Figure 25. Example HSDPA performance (RU10/RU20) PIs. .................................................................4641
Figure 26. Example HSDPA accessibility failure causes (RU10/RU20). .................................................4641
Figure 27. HSDPA accessibility with optimisation. ..................................................................................4843
Figure 28. HSDPA accessibility failure analysis with optimisation steps. ................................................4843
Figure 29. Effect of PrxLoadMarginMaxDCH on HSDPA return channel accessibility. ..........................4944
Figure 30. Relation between UL CE usage and HS-DSCH setup failures (RAS06) ...............................5045
Figure 31. Activation of TBO and 16 kbps return channel (RAS06) ........................................................5146
Figure 32. HSUPA Accessibility failure analysis ......................................................................................5247
Figure 33. Example of HSUPA performance (RU10/RU20). ...................................................................5348
Figure 34. Example of HSUPA setup failure causes (RAS06/RU10) ......................................................5449
Figure 35. Relation between CE usage and HSUPA setup and selection failures..................................5550
Figure 36. Max Achieved HSDPA application level throughputs for different category UEs ...................5752
Figure 37. Example of HSDPA link adaption parameters. .......................................................................5954
Figure 38. 64QAM throughput measured in the lab and in the field. ( 5 x 100M file downloads) ............5954
Figure 39. HSDPA 64QAM result showing TBS and retransmission rate. Vepro is measured in the lab and
Ahvenatie case is measured in the field. (5x100M file downloads) .........................................................6054
Figure 40. RSCP vs. DL application throughput, drive test Comparison of 16QAM and 64QAM - Test is
done in NSN test network under isolated cell without any other traffic to ensure that conditions remains
unchanged between testing. ....................................................................................................................6055
Figure 41. Comparison of DC-HSDPA, MIMO and 64QAM DL application level throughputs in the field
(RSCP around -60 dBm in measurement location) .................................................................................6155
Figure 42. Throughput per allocated HS-DSCH ‎[8] .................................................................................6257
Figure 43. General flow chart to analyse HSDPA throughput ‎[8] ............................................................6358
Figure 44. HSDPA throughput measurement from BTS and drive test log. ............................................6560
Figure 45 Example of throughput measurements included to M1027 .....................................................6560
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 7 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 46. Buffers with data Example (RNC_726b_number of HSDPA users per cell) .........................6762
Figure 47. Example of RNC_1879b HSDPA end used throughput formula vs. average active cell
throughput RNC_722b .............................................................................................................................6762
Figure 48. Example of differences between the Compensated CQI and Reported CQI .........................6863
Figure 49 – Air Interface bitrate estimation using reported CQI ..............................................................6863
Figure 50. Average CQI vs. TBS with different CPICH Tx Powers from drive test logs. .........................7065
Figure 51. CQI comparison between RAS06 and RU10 .........................................................................7165
Figure 52. The relation of Average reported CQI vs. HSDPA cell throughput in live network (RU10) ....7166
Figure 53. The relation of Average reported CQI and HSDPA User throughput in live network. ............7266
Figure 54. Number of codes and used modulation when RSCP drops – HSDPA 5 code feature ..........7267
Figure 55. Number of codes and used modulation when RSCP drops – HSDPA 10 Code feature .......7368
Figure 56. New usage of 16QAM codes transmission in RU10 due the unevenly distributed codes
between the users. ...................................................................................................................................7368
Figure 57. RNC_2093a Average reserved SF16 codes for HSDPA and RNC_722b Active HSDPA
throughput. ...............................................................................................................................................7570
Figure 58. MIMO “peak” performance. ....................................................................................................7671
Figure 59 . MIMO drive test under NSN test network. Above chart show modulation for main stream and
RSCP along the drive route. Chart below show modulation for secondary stream and also DL application
throughput along the route. ......................................................................................................................7772
Figure 60. Example of CQI report cycle. ..................................................................................................7873
Figure 61. Example of MIMO CQI counters distribution ..........................................................................7974
Figure 62. Example of DC HSDPA throughput in lab ..............................................................................7974
Figure 63. throughput in case there is simultaneously DC HSDPA and 64QAM users. .........................8075
Figure 64. HS-SCCH usage for both DC HSDPA and 64 QAM UE ........................................................8176
Figure 65. Example of TTI counters for scheduled DC HSDPA user for Primary and Secondary cells .8277
Figure 66. Example of HSUPA link adaption parameters. .......................................................................8479
Figure 67. HSUPA throughput when 2ms TTI and 5.8 Mbps was activated. (100M file uploaded) ........8580
Figure 68. HSUPA throughput (yellow) and Noise rise with different PrxMaxTargetBTS values ............8580
Figure 69. HSUPA performance with R99 load. PrxMaxTargetBTS =6 dB (default) ..............................8681
Figure 70. HSUPA throughput with HSUPA 2 Mbps feature ...................................................................8681
Figure 71. HSUPA Cell UL application level throughput with different number of HSUPA UEs and with
different PrxTargetMaxBTS values (changed in case of 3 HSUPA UE) .................................................8782
Figure 72. UL application level throughput of 1 HSUPA UE when there is different number of UEs in the
cell. ...........................................................................................................................................................8782
Figure 73. Uplink PrxTotal with different number of HSUPA UEs ...........................................................8883
Figure 74. Uplink Load with different number of HSUPA UEs .................................................................8883
Figure 75. HSUPA throughput PIS and drive test tool measurement. ....................................................9085
Figure 76. HSUPA throughput KPI comparison, example from NSN test network .................................9186
Figure 77. Example of Active HSUPA TTI throughput (both 2ms and 10ms) and Average number of
HSUPA 10ms & 2ms TTI users. Example is from NSN test networks ...................................................9287
Figure 78. HSUPA selections and throughput. ........................................................................................9287
Figure 79. BTS CE HSUPA Usage and HSUPA Maximum Mac-d Throughput (RAS06) .......................9388
Figure 80. BTS resource status counters ................................................................................................9489
Figure 81. HSUPA congestion control and HW overload CC Frame loss counter ..................................9590
Figure 82. Function of Iub congestion Control .........................................................................................9590
Figure 83. Function of Iub congestion control for throughput with different symbol rate .........................9691
Figure 84. HSUPA congestion control decrease the HSUPA bit rate by decreasing the Serving grant with
too high spreading code configuration .....................................................................................................9691
Figure 85. Uplink throughput with 1 x E1 for HSPA and different Parameter values ..............................9792
Figure 86. UE tx Power limitation vs. HSUPA throughput .......................................................................9893
Figure 87. RU20 RTT values in NSN test network ..................................................................................9994
Figure 88. Example of SCC Performance (RU10/RU20) ......................................................................10196
Figure 89. HSDPA SCC performance compared to HSDPA retainability. ............................................10297
Figure 90. HSPA retainability failure analysis ........................................................................................10398
Figure 91 Example of HSDPA release failure (RU10/RU20) .................................................................10499
Figure 92 Example of E-DCH release reasons (RU10/RU20).............................................................105100
Figure 93. Effect of DCH power on HSDPA throughput. .....................................................................106101
Figure 94. HS-PDSCH code reservation. ............................................................................................106101
Figure 95. DL power sharing between HSDPA and NRT PS traffic. ...................................................107102
Figure 96. DL power sharing analysis. ................................................................................................108103
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 8 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 97. Average HSDPA power vs. HSDPA Utilisation ..................................................................109104
Figure 98. Average UL and DL load as a function of HSDPA power ..................................................110104
Figure 99. HSDPA Code downgrade due to AMR with HSPDSCHMarginSF128=0 ...........................111106
Figure 100. Example of HSDPA code allocation and spreading code occupancy ‎[8]. ........................112107
Figure 101. Example of HSDPA & NRT code allocation duration with different UEs ..........................113108
Figure 102. Code tree occupancy. .......................................................................................................114109
Figure 103. Code tree blocking, with code downgrade due to congestion. .........................................115110
Figure 104. Code downgrade due to NRT with DPCHOverHSPDSCHThreshold=0. .........................116111
Figure 105. Setup fails with DPCHOverHSPDSCHThreshold=0. .......................................................116111
Figure 106. Example of WBTS resource sharing with HSDPA (RAS06) ............................................120115
Figure 107. Example of WBTS resource sharing with HSUPA (RAS06) ............................................121116
Figure 108. Effect of increased HSDPA traffic on CS RAB and HSPA bearer performance. .............122117
Figure 1. RRC connection setup signalling....................................................................................................9
Figure 2. F-DCPCH signalling example, when FDPCHSetup (1) RRC Connection Setup message moves
the UE into Cell_FACH. F-DPCH is then allocated immediately after receiving the RRC connection setup
complete message .......................................................................................................................................13
Figure 3. GPRS Attach procedure ...............................................................................................................14
Figure 4. Service Request procedure. .........................................................................................................15
Figure 5. PDP context setup procedure. ......................................................................................................15
Figure 6. Capacity request and resource allocation signalling for packet data call. HSDPA+HSUPA .......17
Figure 7. Comparison of Normal NRT RAB Setup and Direct Resource allocation for HSPA ....................19
Figure 8. RRC states and transitions. RU10 Introduce possibility to use URA_PCH state and fast call
setup directly from URA_PCH/CELL_PCH to Cell_DCH. New transitions supported by RU10, are shown
with black lines. ............................................................................................................................................20
Figure 9. Transition from CELL_DCH to CELL_FACH with Radio Bearer Reconfiguration procedure. .....21
Figure 10. Transition from CELL_FACH to CELL_PCH (URA_PCH) with Radio Bearer Reconfiguration
procedure. ....................................................................................................................................................21
Figure 11. Transfer of the UE to CELL_DCH and reactivation of the data connection (cause UL data
transmission). ...............................................................................................................................................22
Figure 12. Fast call setup with direct transition from URA_PCH/CELL_PCH to CELL_DCH. ....................23
Figure 13. Serving HS-DSCH cell change triggered by periodical EcNo measurements. ..........................24
Figure 14. Serving cell change triggered by Event 1B on the serving HSDSCH cell (no NBAP signalling
presented). ...................................................................................................................................................25
Figure 15. Inter-RNC serving HS-DSCH cell change with hard handover (no NBAP signalling presented).
.....................................................................................................................................................................25
Figure 16 HSDPA and HSUPA UE utilisation within last 100 weeks. .........................................................29
Figure 17 HSDPA UE category distribution within last 100 weeks. .............................................................29
Figure 18. HSUPA UE category distribution within last 100 weeks. ............................................................30
Figure 19 PS RAB setup failure rate statistics (RU10/RU20) .....................................................................33
Figure 20. PS RAB Access failure rate statistics (RU10/RU20) ..................................................................33
Figure 21. NRT PS RAB retainability analysis .............................................................................................36
Figure 22 Example of PS NRT RAB Active fail change due to BTS (RU10/RU20).....................................36
Figure 23 Example of PS setup failure rates (RU10/RU20) ........................................................................37
Figure 24 – HSDPA Accessibility Failure Analysis ......................................................................................39
Figure 25. Example HSDPA performance (RU10/RU20) PIs. .....................................................................41
Figure 26. Example HSDPA accessibility failure causes (RU10/RU20). .....................................................41
Figure 27. HSDPA accessibility with optimisation. ......................................................................................43
Figure 28. HSDPA accessibility failure analysis with optimisation steps. ....................................................43
Figure 29. Effect of PrxLoadMarginMaxDCH on HSDPA return channel accessibility. ..............................44
Figure 30. Relation between UL CE usage and HS-DSCH setup failures (RAS06) ...................................45
Figure 31. Activation of TBO and 16 kbps return channel (RAS06) ............................................................46
Figure 32. HSUPA Accessibility failure analysis ..........................................................................................47
Figure 33. Example of HSUPA performance (RU10/RU20). .......................................................................48
Figure 34. Example of HSUPA setup failure causes (RAS06/RU10) ..........................................................49
Figure 35. Relation between CE usage and HSUPA setup and selection failures......................................50
Figure 36. Max Achieved HSDPA application level throughputs for different category UEs .......................52
Figure 37. Example of HSDPA link adaption parameters. ...........................................................................54
Figure 38. 64QAM throughput measured in the lab and in the field. ( 5 x 100M file downloads) ................54
Figure 39. HSDPA 64QAM result showing TBS and retransmission rate. Vepro is measured in the lab and
Ahvenatie case is measured in the field. (5x100M file downloads) .............................................................54
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 9 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 40. RSCP vs. DL application throughput, drive test Comparison of 16QAM and 64QAM - Test is
done in NSN test network under isolated cell without any other traffic to ensure that conditions remains
unchanged between testing. ........................................................................................................................55
Figure 41. Comparison of DC-HSDPA, MIMO and 64QAM DL application level throughputs in the field
(RSCP around -60 dBm in measurement location) .....................................................................................55
Figure 42. DC-HSDPA, MIMO and 64QAM drive test comparison under empty, isolated cell. ..................56
Figure 43. Throughput per allocated HS-DSCH [8] .....................................................................................57
Figure 44. General flow chart to analyse HSDPA throughput [8] ................................................................58
Figure 45. HSDPA throughput measurement from BTS and drive test log. ................................................60
Figure 46 Example of throughput measurements included to M1027 .........................................................60
Figure 47. Buffers with data Example (RNC_726b_number of HSDPA users per cell) .............................62
Figure 48. Example of RNC_1879b HSDPA end used throughput formula vs. average active cell
throughput RNC_722b ...............................................................................................................................62
Figure 49. Example of differences between the Compensated CQI and Reported CQI .............................63
Figure 50 – Air Interface bitrate estimation using reported CQI ..................................................................63
Figure 51. Average CQI vs. TBS with different CPICH Tx Powers from drive test logs. .............................65
Figure 52. CQI comparison between RAS06 and RU10 .............................................................................65
Figure 53. The relation of Average reported CQI vs. HSDPA cell throughput in live network (RU10) ........66
Figure 54. The relation of Average reported CQI and HSDPA User throughput in live network. ................66
Figure 55. Number of codes and used modulation when RSCP drops – HSDPA 5 code feature ..............67
Figure 56. Number of codes and used modulation when RSCP drops – HSDPA 10 Code feature ...........68
Figure 57. New usage of 16QAM codes transmission in RU10 due the unevenly distributed codes
between the users. .......................................................................................................................................68
Figure 58. RNC_2093a Average reserved SF16 codes for HSDPA and RNC_722b Active HSDPA
throughput. ...................................................................................................................................................70
Figure 59. MIMO “peak” performance. ........................................................................................................71
Figure 60 . MIMO drive test under NSN test network. Above chart show modulation for main stream and
RSCP along the drive route. Chart below show modulation for secondary stream and also DL application
throughput along the route. ..........................................................................................................................72
Figure 61. Example of CQI report cycle.......................................................................................................73
Figure 62. Example of MIMO CQI counters distribution ..............................................................................74
Figure 63. Example of HSUPA link adaption parameters. ...........................................................................75
Figure 64. HSUPA throughput when 2ms TTI and 5.8 Mbps was activated. (100M file uploaded) ............76
Figure 65. HSUPA throughput (yellow) and Noise rise with different PrxMaxTargetBTS values ................77
Figure 66. HSUPA performance with R99 load. PrxMaxTargetBTS =6 dB (default) ..................................77
Figure 67. HSUPA throughput with HSUPA 2 Mbps feature .......................................................................78
Figure 68. HSUPA Cell UL application level throughput with different number of HSUPA UEs and with
different PrxTargetMaxBTS values (changed in case of 3 HSUPA UE) .....................................................78
Figure 69. UL application level throughput of 1 HSUPA UE when there is different number of UEs in the
cell. ...............................................................................................................................................................79
Figure 70. Uplink PrxTotal with different number of HSUPA UEs ...............................................................79
Figure 71. Uplink Load with different number of HSUPA UEs .....................................................................80
Figure 72. HSUPA throughput PIS and drive test tool measurement. ........................................................82
Figure 73. HSUPA throughput KPI comparison, example from NSN test network .....................................83
Figure 74. Example of Active HSUPA TTI throughput (both 2ms and 10ms) and Average number of
HSUPA 10ms & 2ms TTI users. Example is from NSN test networks .......................................................83
Figure 75. HSUPA selections and throughput. ............................................................................................84
Figure 76. BTS CE HSUPA Usage and HSUPA Maximum Mac-d Throughput (RAS06) ...........................85
Figure 77. BTS resource status counters ....................................................................................................85
Figure 78. HSUPA congestion control and HW overload CC Frame loss counter ......................................86
Figure 79. Function of Iub congestion Control .............................................................................................87
Figure 80. Function of Iub congestion control for throughput with different symbol rate .............................87
Figure 81. HSUPA congestion control decrease the HSUPA bit rate by decreasing the Serving grant with
too high spreading code configuration .........................................................................................................88
Figure 82. Uplink throughput with 1 x E1 for HSPA and different Parameter values ..................................89
Figure 83. UE tx Power limitation vs. HSUPA throughput ...........................................................................90
Figure 84. RU20 RTT values in NSN test network ......................................................................................91
Figure 85. Example of SCC Performance (RU10/RU20) ............................................................................93
Figure 86. HSDPA SCC performance compared to HSDPA retainability. ..................................................94
Figure 87. HSPA retainability failure analysis ..............................................................................................94
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 10 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 88 Example of HSDPA release failure (RU10/RU20) .......................................................................96
Figure 89 Example of E-DCH release reasons (RAS06/RU10) ..................................................................96
Figure 90. Effect of DCH power on HSDPA throughput. .............................................................................97
Figure 91. HS-PDSCH code reservation. ....................................................................................................97
Figure 92. DL power sharing between HSDPA and NRT PS traffic. ...........................................................98
Figure 93. DL power sharing analysis. ........................................................................................................99
Figure 94. Average HSDPA power vs. HSDPA Utilisation ........................................................................100
Figure 95. Average UL and DL load as a function of HSDPA power ........................................................101
Figure 96. HSDPA Code downgrade due to AMR with HSPDSCHMarginSF128=0 .................................102
Figure 97. Example of HSDPA code allocation and spreading code occupancy [8]. ................................103
Figure 98. Example of HSDPA & NRT code allocation duration with different UEs ..................................104
Figure 99. Code tree occupancy. ...............................................................................................................105
Figure 100. Code tree blocking, with code downgrade due to congestion. ...............................................106
Figure 101. Code downgrade due to NRT with DPCHOverHSPDSCHThreshold=0. ...............................107
Figure 102. Setup fails with DPCHOverHSPDSCHThreshold=0. .............................................................107
Figure 103. Example of WBTS resource sharing with HSDPA (RAS06) ..................................................111
Figure 104. Example of WBTS resource sharing with HSUPA (RAS06) ..................................................112
Figure 105. Effect of increased HSDPA traffic on CS RAB and HSPA bearer performance. ...................113
Formatted: Normal
Formatted: Space After: 0 pt
List of Tables
Formatted: Normal
Table 1. Packet data connection related information elements in RRC Connection Setup Request
message...................................................................................................................................................1510
Table 2. Feature related information elements in RRC Connection Setup Request message ...............1510
Table 3. Packet data connection related information elements in RRC connection setup message ......1510
Table 4. Packet data connection related information elements in RRC Connection Setup Complete
message...................................................................................................................................................1611
Table 5. Packet data connection related information elements in Activate PDP Context Request message
.................................................................................................................................................................2015
Table 6. Packet data connection related information elements in Radio Bearer Reconfiguration message
.................................................................................................................................................................2217
Table 7. 64QAM, MIMO parameter and secondary cell info can be added to Radio Bearer reconfiguration
message...................................................................................................................................................2318
Table 8. UMTS QoS attributes .................................................................................................................3126
Table 9 QoS negotiation at PDP context setup. ......................................................................................3126
Table 10. QoS values for different traffic classes. ...................................................................................3227
Table 11. Reports and PIs related NRT PS RAB accessibility ................................................................3732
Table 12. Reports and PIs related NRT PS RAB retainability .................................................................4035
Table 13. Reports and PIs related HSDPA accessibility .........................................................................4439
Table 14. RNC parameters related to CELL_DCH state selection and release. .....................................4742
Table 15. Reports and PIs related HSUPA accessibility .........................................................................5247
Table 16. Maximum user bit rates with different RAS features (RU20) ...................................................5752
Table 17. HSDPA traffic and throughput KPIs and counters ...................................................................6358
Table 18. Mobile Power Offset Calculation (MPO) for different Cell power setting – PtxMaxHSDPA is set
to same value as PtxCellMax ..................................................................................................................6964
Table 19. HSDPA performance comparison with different CPICH Tx Power values. .............................7064
Table 20. Maximum throughput that can be sent by shared HSDPA scheduler for BB efficiency in one TTI.
(This table does not include MIMO or DC HSDPA users) .......................................................................7469
Table 21. DC HSDPA functionality and throughput with different carrier spacing. Currently there is no UE
in the market which supports 5.2 MHz carrier spacing. ...........................................................................8075
Table 22. Example of RNC_722d Average Active HSDPA throughput ...................................................8176
Table 23. HSUPA bitrates with different MaxTotalUplinkSymbolRate settings .......................................8378
Table 24. HSUPA congestion control parameters. ..................................................................................8479
Table 25. HSUPA traffic and throughput KPIs and counters ...................................................................8984
Table 26. HSPA mobility counters and KPIs .........................................................................................10095
Table 27. HSPA retainability counters and KPIs (Report: Service/Session Retainability Analysis
RSRAN079) ...........................................................................................................................................10398
Table 28. PIs related power sharing between HSPA and R99 traffic ..................................................107102
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 11 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Table 29. PIs related to channelisation code sharing between HSPA and R99 traffic. .......................110105
Table 30. WBTS CE reservation of DCH bearers. In RU10, less CE needed with high bitrate (384 kbps)
with Flexi Rel2 HW system module. Less CE also needed for HSDPA users in Uplink (return channel) if
384 kbps is used. .................................................................................................................................117112
Table 31 UL/DL CE reservation example for HSUPA when Flexi Rel2 SM is used with 10ms TTI. (RU20)
.............................................................................................................................................................117112
Table 32. PIs related power sharing between HSPA and R99 traffic ..................................................118113
Table 1. Packet data connection related information elements in RRC Connection Setup Request
message.......................................................................................................................................................10
Table 2. Feature related information elements in RRC Connection Setup Request message ...................10
Table 3. Packet data connection related information elements in RRC connection setup message ..........10
Table 4. Packet data connection related information elements in RRC Connection Setup Complete
message.......................................................................................................................................................11
Table 5. Packet data connection related information elements in Activate PDP Context Request message
.....................................................................................................................................................................15
Table 6. Packet data connection related information elements in Radio Bearer Reconfiguration message
.....................................................................................................................................................................17
Table 7. 64QAM, MIMO parameter and secondary cell info can be added to Radio Bearer reconfiguration
message.......................................................................................................................................................18
Table 8. UMTS QoS attributes .....................................................................................................................26
Table 9 QoS negotiation at PDP context setup. ..........................................................................................26
Table 10. QoS values for different traffic classes. .......................................................................................27
Table 11. Reports and PIs related NRT PS RAB accessibility ....................................................................32
Table 12. Reports and PIs related NRT PS RAB retainability .....................................................................35
Table 13. Reports and PIs related HSDPA accessibility .............................................................................39
Table 14. RNC parameters related to CELL_DCH state selection and release. .........................................42
Table 15. Reports and PIs related HSUPA accessibility .............................................................................47
Table 16. Maximum user bit rates with different RAS features (RU20) .......................................................52
Table 17. HSDPA traffic and throughput KPIs and counters .......................................................................58
Table 18. Mobile Power Offset Calculation (MPO) for different Cell power setting – PtxMaxHSDPA is set
to same value as PtxCellMax ......................................................................................................................64
Table 19. HSDPA performance comparison with different CPICH Tx Power values. .................................64
Table 20. Maximum throughput that can be sent by shared HSDPA scheduler for BB efficiency in one TTI.
(This table does not include MIMO or DC HSDPA users) ...........................................................................69
Table 21. HSUPA bitrates with different MaxTotalUplinkSymbolRate settings ...........................................75
Table 22. HSUPA congestion control parameters. ......................................................................................75
Table 23. HSUPA traffic and throughput KPIs and counters .......................................................................80
Table 24. HSPA mobility counters and KPIs ...............................................................................................92
Table 25. HSPA retainability counters and KPIs (Report: Service/Session Retainability Analysis
RSRAN079) .................................................................................................................................................94
Table 26. PIs related power sharing between HSPA and R99 traffic ..........................................................98
Table 27. PIs related to channelisation code sharing between HSPA and R99 traffic. .............................101
Table 28. WBTS CE reservation of DCH bearers. In RU10, less CE needed with high bitrate (384 kbps)
with Flexi Rel2 HW system module. Less CE also needed for HSDPA users in Uplink (return channel) if
384 kbps is used. .......................................................................................................................................108
Table 29 UL/DL CE reservation example for HSUPA when Flexi Rel2 SM is used with 10ms TTI. (RU20)
...................................................................................................................................................................108
Table 30. PIs related power sharing between HSPA and R99 traffic ........................................................109
1 Introduction
The purpose of this guideline is to give guidance for packet data performance optimisation
tasks. The main focus is in HSPA (HSDPA and HSUPA) performance but also interworking with
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 12 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Rel99 NRT services is covered. Basic HSPA functionality and parameters is not described here
but in HSPA planning guide [2]‎[2][2]. Some performance related signalling charts are included
here also basic QoS information, which will be updated with RU10 features later. NRT feature
optimization is not described here but in Packet Scheduler Optimization document [7]‎[7][7].
There is also not info about different HSPA layers which is covered in HSPA layering guide
[5]‎[5][5]. It is recommended to look at separate capacity management guide for detailed capacity
analysis [8]‎[8][8]. From KPI guarantee document [13]‎[13][13] main KPI definitions with target
values are explained, also for HSPA. This guide can be used for MBB projects also.
The structure of the document is following the data call flow. In the beginning there is chapter for
PS signalling showing different packet call setup cases and mobility both in RNC level and at UE
side. Then there is a chapter for PS RAB QoS introduction. Then there is chapter for NRT PS
RAB performance covering traditional service level KPIs related to NRT PS RAB. After that
there is chapter for HSPA bearer performance optimization covering accessibility, throughout,
mobility and retainability related to HSDPA and HSUPA. The last chapter is covering the HSPA
and Rel99 interworking related mainly to WBTS resource sharing.
The performance KPIs shown in the document is structured based on the the latest RU20
reporting suite reports. In RU10, there are several updated KPIs due the introducing of
Streaming class.
Using reporting suite Content browser functionality, the user can also create own report based
on counters, KPIs or existing reports so it is not necessary to follow reporting suite report
content. Reporting suite KPI creator tool make it possible to create own KPIs also.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 13 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
2 PS Data connection signalling
Packet data connection related signalling information is exchanged in different phases of the
packet call. This section describes the main signalling information.
2.1 RRC Setup
RRC connection setup procedure is performed when UE moves from Idle mode to RRC
Connected mode. RRC connection is required for any signalling from UE to the network and the
setup information contains also information related to packet data connection. The RRC
connection setup signalling is presented in Figure 1Figure 1Figure 1.
Node B
UE
RNC
RRC: RRC Connection Request (RACH)
NBAP: Radio Link Setup Request
NBAP: Radio Link Setup Response
ALCAP: Establish Request
ALCAP: Establish Confirm
FP: Downlink Sync
FP: Uplink Sync
RRC: RRC Connection Setup (FACH)
L1 Synchronisation
NBAP: Synchronisation Indication
RRC: RRC Connection Setup Complete (DCH)
Figure 1. RRC connection setup signalling.
The fist message from UE is the RRC Connection Setup Request which mainly indicates the
RNC that the UE wants to establish signalling connection with the RAN. This message contains
these information elements that can be related to packet data connection establishment.
A) Rel-5 UE
B) Rel-6 UE
C) Rel-8 UE
File 1. Examples of RRC Connection Setup Request messages
IE: Establishment cause which gives RNC an indication of the service that the UE is requesting.
Establishment cause depends also on UE implementation. Cause value ‘Registration’ is used to
initiate GPRS Attach signalling and Measurement quantity about the quality of the pilot signal. IE
Access stratum release indicator indicates the RNC on the release of the specification the UE
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 14 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
supports. Release 6 UEs are capable of sending also the IE UE capability indication to indicate
the HSDPA and/or HSUPA capability of the UE.
Table 1. Packet data connection related information elements in RRC Connection Setup Request
message
Information element
Value
Description
Establishment cause
Registration
For GPRS Attach
Originating High
Priority Signalling
For PDP Context Setup
Measurement Quantity
Ec/No = -24 + IE / 2
EcNo used for initial UL and
DL power calculation
Access stratum release indicator
(Absence = R99), Rel4 / Rel-5 / Rel-6 / Rel7
/ Rel8
Release of the RRC
functionality supported by UE
UE capability indication
Absence = No HSPA,
HS-DSCH,
HSDSCH+EDCH
IE available only from R6 UEs
Optionally, UE signal its supports for different features in RRC Connection request message.
NSN support only Rel7 version of F-DPCH (Enhanced F-DPCH). Mac-ehs allows the support of
flexible RLC PDU sizes.
Table 2. Feature related information elements in RRC Connection Setup Request message
Information element
Value
Support for F-DCPCH
OP
Support for Enhanced F-DPCH
OP
MAC-ehs support
OP
EPCCH Discontinuous
Transmission support
OP
Multi Cell Support
OP
Description
The IE shall be present and set to TRUE in
TRUE this version of specification
The IE shall be present and set to TRUE in
TRUE this version of specification
The absence of this IE indicates that the
TRUE UE does not support MAC-ehs
The absence of this IE indicates that the
TRUE UE does not support DPCCH DTX
The absence of this IE indicates that the
TRUE UE does not support Multi-Cell
Release
Rel-6
Rel-7
Rel-7
Rel-7
Rel-8
The RRC Connection Setup is received from RNC as reply to the request message. This
message mainly contains the configuration of the signalling radio bearers that will be used for
the signalling. It also contains information defining the next RRC state and a request for UE
capability. RRC connection establishment is normally performed directly to the Cell_DCH state
or optionally on common channels (Cell_FACH). RU10 feature, Common Channel Setup
allows also connections to be established in CELL_FACH rather than CELL_DCH, i.e. using
RRC Idle to CELL_FACH transition. Parameter SRBMapRRCSetupEC defines the
establishment causes which prefer SRB mapping to the common channels in the RRC
connection setup. With F-DPCH feature (RU20) different options can be selected with parameter
FDPCHSetup.
Table 3. Packet data connection related information elements in RRC connection setup message
Information element
Value
Description
RRC state indicator
Cell-DCH
Signalling continues typically
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 15 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
in DCH channel type in NSN
RAN
Capability update requirement
True
Set ‘true’ for FDD
UARFCN uplink
Channel number UL
IE is provided if the frequency
is changed (can be done due
to DRRC procedure)
UARFCN downlink
Channel number DL
IE is provided if the frequency
is changed (can be done due
to DRRC procedure)
If RU20 feature fast L1 synchronisation feature is enabled, the RNC sets the ‘Post Verification
Period’ information element to TRUE when signaling to a release 6 or newer UE. This IE can be
included RRC Connection Setup, Radio Bearer Reconfiguration, Radio Bearer Setup or Cell
Update Confirm messages
The RRC Connection Setup Complete message contains mainly the UE radio access capability
information. There is range of information related to UE data connection capability, e.g. HSDPA
an HSUPA physical layer category and UE power class.
The UE signals also whether or not it benefits from network based battery power consumption
optimization within the RRC Connection Setup Complete message (This is related to CPC
feature)
A) Rel-5 UE
B) Rel-6 UE
C) Rel-8 UE
File 2. Example of RRC Connection Setup Complete message from Rel-5, Rel-6 and Rel-8 UEs.
Table 4. Packet data connection related information elements in RRC Connection Setup Complete
message
Information element
Value
Description
HS-DSCH physical layer
Category
1-64 (16-64 are spares)
Note 8
Rel-5 and later
HS-DSCH physical layer
category extension
OP
1-64 (used when DC-HSDPA
is disabled) Note 9
Rel-8
HS_DSCH physical layer
category extension2
OP
21..24 (used when
DC_HSDPA is enabled)
Rel-8
E-DCH physical layer
Category
1-16
Rel-6
UE power class
1-4
Note 8: All UEs supporting HS_DSCH should signal a category between 1 and 15 for this IE
even if the UE physical capability category is above 15. This IE corresponds to the HS_DSCH
category supported by UE when MAC-ehs is not configured.
Note 9: This is IE corresponds to the HS_DSCH category supported by the UE when MAC-ehs
is configured.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 16 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
2.2 SRB on HSPA
In RU20, there are 2 features which map SRB to HSPA/HSUPA. HSUPA 2ms TTI feature
require that SRB is mapped to HSUPA in Uplink. Requirement for F-DPCH allocation is that
SRB can be mapped to HSPA in both Uplink and Downlink. With F-DPCH, following two
configurations are possible:
 HSDPA & HSUPA 10 ms TTI
 HSDPA & HSUPA 2 ms TTI
(Require that HSUPA 2ms TTI is enabled)
If allocation of HS-DSCH in downlink for SRB is not possible, that is SRB on HSPA is not
possible, packet scheduler is able to allocate only E- DCH/DCH for SRB with 2ms TTI. Channel
type selection algorithm for SRBs proceeds together with downlink and uplink channel type
selection algorithm for HSDPA and HSUPA when there is setup RB simultaneous with SRBs on
HSPA.
Rel99 DCH shall be allocated for SRBs if the establishment cause received from the UE is
defined to use DCH for SRBs by FDPCHSetupEC parameter. Otherwise it shall follow the
allocation of F-DPCH controlled by the FDPCHSetup parameter. This parameter have 3 different
options



(0) RRC Connection Setup message configures F-DPCH and UE is moved into
CELL_DCH with an HSDPA SRB
(1) RRC Connection Setup message moves the UE into Cell_FACH. F-DPCH is then
allocated immediately after receiving the RRC connection setup complete message
(2) RRC Connection setup message moves the UE into CELL_DCH and allocates a
DCH connection for the standalone SRB. F-DPCH is then allocated a the same time as
user plane resources
When SRB are already on HSPA during the “initial” NRT-RAB setup phase, the Direct Resource
Allocation for HSPA (DRA) is used as a default, i.e. the MAC-d flow for NRT-RAB is allocated
during the RB setup without DCH-0/0 allocation and waiting for UL/DL capacity request first. If
there aren’t the required resources (radio, BTS, transport, DMCU, …) for an immediate u-plane
setup available, the NRT-RB shall be mapped to DCH-0/0 as in the “classic” NRT-RAB setup
scenario and the RAB Assignment Request is acknowledged to the SGSN. After this the (next)
UL/DL capacity request triggers the next resource allocation attempt
F-DPCH -related decision making and signaling concerns only those call-types for which
Cell_DCH is the preferred RRC state. All NAS signaling transactions (registrations, LAU, RAU,
SMS etc.) are still fully executed in Cell_FACH if so parameterized. If the established service
doesn’t allow the usage of F-DPCH the SRBs on HSPA need to be mapped to DCH/DCH and
UE/BTS must be reconfigured accordingly. One such service would be AMR on DCH when CS
voice over HSPA isn’t allowed (or any service requiring DCH), and thus the F-DPCH=>DPCH
reconfiguration will be executed in RB Setup/RL Reconfiguration procedures when setting up
the AMR-RAB
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 17 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
UE
BTS
RNC
CN
RRC Connection Request
[Support(RACH)
for F-DPCH=TRUE]
RNC establishes RRC connection on
RACH/FACH and waits for RRC
Conn. Setup Complete from the UE
RRC Connection Setup
(FACH)
UE in CELL_FACH
State
RRC: Initial UE message
RRC Connection Setup
[Enhanced
F-DPCH
Complete
support=TRUE]
RANAP: Initial DIRECT transfer
UE support REL7 F-DPCH
NBAP: RL Setup
Request [F-DPCH information]
NBAP:
RL
Setup
[F-DPCH capacity
Response
information]
AAL2 Setup
RRC: Radio Bearer
[RRC State Indicator: CELL_DCH; DL F-DPCH Info common
for all RL; DL F-DPCH info for each RL]
Reconfiguration
NBAP:
RL
Restore
RRC: Radio bearer Reconfiguration
Indication
complete
F-DPCH
setup
UE in CELL_DCH state
NAS Signalling Connection; UE – CN Signalling Continued
RRC:
Security
Complete
RRC: Security mode
Command
mode
RANAP: Security mode
command
RANAP: Security mode
complete
RANAP:
RAB Assignment
Request
F-DPCH can be used with established service,
DRA is used and all resources immediately
available
NBAP: RL reconfiguration
NBAP: RL prepare
Reconfiguration
ready
RRC:
Radio
Complete
Bearer
NBAP:RL Reconfiguration
RRC: Commit
Radio Bearer
DRA
Setup
Setup
RANAP: RAB Assignment
Response
Figure 2. F-DCPCH signalling example, when FDPCHSetup (1) RRC Connection Setup message
moves the UE into Cell_FACH. F-DPCH is then allocated immediately after receiving the RRC
connection setup complete message
2.3 Fast Dormancy
Fast dormancy is functionality that UE vendors have introduced to save UE battery life, by
forcing them to RRC idle mode. After completing data transfer, UE send signaling connection
release indicator, which RNC has to obey and release the UE to RRC idle mode. This can
increase network signaling load as “polls” and “keep alives” can cause UE to continuously setup
and release RRC connection.
In Rel8 specification is modified so that RNC can keep the UE in RRC connected mode after
receiving Signaling connection release indicator with new cause value ‘UE Requested PS Data
Session End’.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 18 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Fast Dormancy feature is included to RU20 MP1 without parameter control, Parameter control is
coming with RU30 (FD is originally planned to be RU30 feature). In RU20, the fast dormancy is
activated by default (RU30 this can be handled with parameter) which results T323 being
broadcasted within SIB1. T323 within SIB1 allow a UE to detect that the network supports fast
dormancy. By default the value of T323 is 0s.
After receiving a Signalling Connection Release Indication message with cause value ‘UE
Requested PS Data Session End’, Fast dormancy functionality overrides inactivity timers and
RNC instructs UE to make state change to CELL_PCH/URA_PCH.
if RNC receives signaling Connection Release Indication message without a cause value then
the existing legacy functionality is applied and the UE is moved to RRC Idle mode
2.4 Packet data connection setup
2.4.1 GPRS Attach
After the RRC connection setup procedure the UE has established a dedicated communication
link with UTRAN, it is in a position to send a message to the core network (PS core in this case).
With the GPRS attach the UE establishes a GPRS mobility management context with SGSN.
Figure 3. GPRS Attach procedure
The purpose of the Security Mode procedure is to trigger the start or ciphering for the radio
bearers of one core network domain and for all signalling bearers. It is also used to start integrity
protection for all signalling radio bearers.
The PS core may optionally request the UE to provide its identity, e.q. IMEI. This is done using
the Identity Request message.
2.4.2 Service Request
The Service Request procedure is initiated prior to PDP context setup to form a secure
connection between the SGSN and the UE for user data. This is required if no other signalling
with SGSN has preceded the PDP context setup. This could be the case with MT packet call,
but it is not supported by NSN.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 19 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure 4. Service Request procedure.
2.4.3 PDP context setup
PDP context forms the user data connection between the UE and internet or private network. An
IP address is allocated to the UE in the procedure. PDP Context Setup procedure includes
Radio Access Bearer (RAB) setup and Radio Bearer setup procedures. This is done to DCH 0/0
if Directed Resource Allocation for HSPA is not enabled. If DRA for HSPA is enabled, then
HSPA UEs can establish connection directly without allocating DCH 0/0.
Figure 5. PDP context setup procedure.
The Activate PDP Context Request message includes information related to the requested
service type and quality, connection end point (Access point name) and requested IP address.
Access point name can be used to request a connection to operator specific services like WAP
or to internet if this is allowed by the operator.
Table 5. Packet data connection related information elements in Activate PDP Context Request
message
Information element
Value
Description
Requested QoS
See Section 3‎33.
Requested IP address
By default IP address is
allocated automatically.
Access Point Name
Access points are defined in
the GGSN configuration and
UE request a connection
to/via specific access point
Requested service type and quality is defined in the Requested QoS information. Section 3‎33
describes more in detail the QoS definition parameters and procedure. The PDP context setup
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 20 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
procedure is completed with the Activate PDP Context Accept message, which contains mainly
the negotiated QoS and IP/PDP address allocated for the UE.
A) Activate PDP Context Request
B) Activate PDP Context Accept
File 3. Examples of Activate PDP Context Request and Activate PDP Context Accept messages.
The Activate PDP Context Request message triggers the SGSN to start the RAB setup
procedure. This is initiated when SGSN sends the RAB Assignment Request message to the
RNC, this message is sent over the Iu-PS interface and it contains the QoS of the RAB. The
reception of the RAB Assignment Request message triggers the admission control (AC)
procedure in RNC and the following radio bearer setup procedure. The AC algorithm defines the
maximum bit rate of the radio bearer, target BLER and other bearer parameters.
In NSN RAN, Prior to RU20 the initial bit rate allocated in the RAB setup procedure of the NRT
RAB is always zero (RAB 0/0). Thus there is no need for resource reservations in this phase.
The Radio Bearer Setup message sent from RNC to UE contains the next state (in NSN RAN
cell-DCH) some Radio Bearer information (RLC, TrCH), but no bit rate allocations. There is also
no radio link setup with Node B at this phase, i.e. no transport and CE resources are reserved.
With RU20 feature, Direct Resource allocation for HSPA (DRA for HSPA), HSPA is allocated
already during RAB establishment which replaces the allocation of a 0/0 kbps DCH. When SRB
are already on HSPA during the “initial” NRT-RAB setup phase (F-DPCH), the Direct Resource
Allocation for HSPA (DRA) is used as a default,
File 4. Example of Radio Bearer Setup message.
Once the RAB has been established the RNC sends a measurement control messages to the
UE in order to initiate the traffic volume measurements (UE internal) together with intra and inter
frequency measurements. Measurement control initiates the traffic volume measurements and
defines the reporting thresholds for traffic volume measurements which are used for the UL
capacity requests.
File 5. Example of Measurement Control message.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 21 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
2.4.4 Data flow setup
The data flow over the air interface is setup after a capacity request from either UE or internally
RNC. Typically UE initiates the connection to the server and the capacity request comes from
the UE. The data flow setup involves packet scheduling, channel type selection and resource
reservation for the selected connection type.
Figure 6. Capacity request and resource allocation signalling for packet data call. HSDPA+HSUPA
UE sends the Measurement Report message for Event 4A indicating that there is some data in
the buffers. This measurement report is handled as capacity request by the packet scheduler in
the RNC, which schedules the capacity request. The scheduling operation starts with channel
type selection procedure, where the RNC makes a selection between HSPA, HSDPA, DCH or
common channel usage. Scheduling includes also allocation of bit rates for DCH bearers
(allowed transport format set) based on RNC parameters and load conditions.
File 6. Example of Measurement Report message.
The selected radio bearer configuration is sent in the Radio Bearer Reconfiguration message to
the UE and with the following Radio Link Reconfiguration Prepare message to the Node B.
Table 6. Packet data connection related information elements in Radio Bearer Reconfiguration
message
Information element
Value
Description
RRC state indicator
cell-DCH, cell-FACH
The initial bit rate allocation is
typically done to DCH channel
at packet call setup
Uplink transport channel
Type
DCH, RACH, E-DCH
Selected UL the channel type
Downlink transport channel
Type
DCH, FACH, HSDSCH, DCH +
HSDSCH
Selected DL the channel type
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 22 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
MAC-d PDU size
Fixed (336 or 656) or
Flexible
336 used as default in NSN
RAN, 656 used for higher
HSDPA data rates. From
RU20 onwards, Flexible RLC
used for higher HSDPA rata
rates.
Maximum channelisation codes
sf4, 2sf4, 2sf2and2sf4
Maximum Channelisation
code configuration for
HSUPA.
Serving Grant value
0-37, 38
Initial grant value for HSUPA,
38 means no grant. Value is
defined by BTS and signalled
to RNC and to UE in this IE.
Spreading factor (UL)
4-128
Minimum spreading factor of
the UL DCH channel.
Measurement Power Offset
-6..13 dB
Measurement power offset Г
indicating the current
available HSDPA power
relative to pilot. UE utilises the
value in CQI reporting.
UARFCN uplink
Channel number UL
IE is provided if the frequency
is changed (not done in
packet call setup)
UARFCN downlink
Channel number DL
IE is provided if the frequency
is changed (not done in
packet call setup)
A) Rel-5 UE
B) Rel-6 UE
C) Rel-7 MIMO UE
C) Rel-8 DC-HSDPA UE
File 7. Example of Radio Bearer Reconfiguration message.
Table 7. 64QAM, MIMO parameter and secondary cell info can be added to Radio Bearer
reconfiguration message.
Information element
Value
Downlink 64QAM Configured
OP
MIMO Parameters
OP
dl-SecondaryCellInfoFDD IE
OP
Description
This allows UE the determine which TBS table
to use, and which HS-SCCH format to use.
Absence of this IE means that the HS-SCCH
TRUE does not use the 64QAM format
Absence of this IE means that the HS-SCCH
TRUE does not support MIMO
DL optional parameters relevant to reception of
secondary
TRUE serving HS-DSCH cell
Release
Rel-7
Rel-7
Rel-8
The UE acknowledges the Radio Bearer Reconfiguration message with a Radio Bearer
Reconfiguration Complete message.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 23 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RNC orders the UE with the Measurement Control message to stop the traffic volume
measurements, if the UE has been allocated the maximum available bit rate of HSPA channel
type, as there is no use for the UEs to request higher bit rate. If the UE is allocated a lower than
maximum bit rate, then the RNC modifies the Event 4A reporting threshold according to the
allocated bit rate (Flexible Upgrade feature provides possibility to define bit rate specific
thresholds).
A) Rel-5 UE, initial UL rate
B) Rel-6 UE, HSPA allocated
File 8. Example of Measurement Control message used to modify/release the Ul traffic volume
measurement.
2.4.5 Direct Resource Allocation for HSPA
Direct resource allocation for HSPA allocates HSPA during RAB setup establishment which
replaces the allocation of a 0/0 kbps. Direct resource allocation is applicable to full HSPA
connections using PS NRT Interactive or Background traffic classes.
Direct resource allocation for HSPA can be applied only for CELL_DCH or CELL_FACH or for
both, depending on settings of parameter RABDRAEnabled. If RABDRAEnabled is disabled,
then direct resource allocation for HSPA shall not be applied but RB is mapped to DCH 0/0 kbps
and traffic volume measurements are started according to existing principles.
In case HSPA allocation is not possible due to BTS, TRS or DSP congestion, no further attempt
shall be made and DCH 0/0 shall be allocated and TVM started as per existing principles.
Figure 7. Comparison of Normal NRT RAB Setup and Direct Resource allocation for HSPA
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 24 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
2.4.6 RRC state transitions
The RNC can order the UE to change the RRC state during the packet call. This is typically
performed due to packet connection inactivity or start of data transmission (see Figure 8Figure
8Figure 8). When the UE is transferred from CELL_DCH to CELL_FACH state, the radio bearer
is reconfigured to use common channels (RACH/FACH) with Radio Bearer Reconfiguration
procedure. The Physical Layer Reconfiguration procedure is used to transfer the UE to/from the
CELL_PCH and URA_PCH (RU10 feature) states. In this procedure the physical layer and
transport channel resources are released but RB (could be with SRB only), RAB and PDP
context remain active towards Iu-interface.
Phys. Reconfiguration
Phys. Reconfiguration
After RT call with
inactive PS RABs
Frequent cell updates
UTRA RRC Connected Mode
URA Update, UL data, Paging
Fast call setup from
CELL_PCH
CELL_PCH
URA_PCH
Fast call setup from
URA_PCH
After RT call with inactive
PS RABs & high mobility in
CELL_DCH
Phys. Reconfiguration
UL/DL activation timer
CELL_FACH
CELL_DCH
Phys. Reconfiguration
Cell Update, UL data, paging
RB. Reconfiguration
RRC Setup / Release
Traffic Volume, RACH load
RB. Reconfiguration
IDLE Mode
Inactivity Timer, Overload
Figure 8. RRC states and transitions. RU10 Introduce possibility to use URA_PCH state and fast
call setup directly from URA_PCH/CELL_PCH to Cell_DCH. New transitions supported by RU10,
are shown with black lines.
The transition of the UE from CELL_DCH to CELL_FACH is performed with the Radio Bearer
Reconfiguration message (see Figure 9Figure 9Figure 9 and File 9File 9File 9 A). It is initiated
by the RNC in basis of data transmission inactivity both in UL and DL or low measured
throughput. This transition included the release of the BTS and Iub resources reserved for the
connection. The common channel resources are used in CELL_FACH for the data and
signalling.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 25 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 9. Transition from CELL_DCH to CELL_FACH with Radio Bearer Reconfiguration procedure.
The transition of the UE from CELL_FACH to CELL_PCH is performed with the Physical
Channel Reconfiguration message (see Figure 10Figure 10Figure 10 and File 9File 9File 9 B) is
initiated by the RNC in basis of data transmission inactivity both in UL and DL. In CELL_PCH
state the UE is receiving the paging messages. Transition to URA_PCH is performed with the
same signalling procedure.
Figure 10. Transition from
Reconfiguration procedure.
A) RB reconfiguration
from CELL_DCH to CELL_FACH
CELL_FACH to CELL_PCH (URA_PCH) with Radio Bearer
B) Physical channel reconfiguration
from CELL_FACH to CELL_PCH
File 9. Example of Radio Bearer reconfiguration and Physical channel reconfiguration messages
used in the RRC state transitions.
When URA_PCH is enabled, to reduce the unnecessary signalling (cell updates) the UE is
moved to the URA_PCH state if UE has been moving fast (in CELL_DCH state) or when too
frequent execution of cell reselection procedure is observed (in CELL_FACH state). In
CELL_DCH state, UE location is known in cell level and handover process (HA3) can calculate
the velocity of the UE by active set changes needed for the UE. If the number of complete
active set changes during the time period FastUEPeriod is equal or exceeds the threshold
FastUEThreshold, the RNC (HA3) shall inform RRC signalling entity (MCC via CCM) about UE
which is moving fast. This is used for deciding Cell_PCH or URA_PCH state transitions after
inactivity is detected. Low moving UEs go to CELL_PCH state.
In CELL_FACH state, transition to URA_PCH is performed for high mobility UEs if amount of
cell reselections/updates exceed predefined threshold set by parameter MaxCellReselections
within time defined with parameter CellReselectionObservingTime. If MaxCellReselections is set
to 0, URA_PCH is not possible
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 26 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
In case of the UE is not supporting URA_PCH state, following handling is used: When RRC
entity has tried to switch the UE to URA_PCH state and the UE has responded by sending RRC:
PHYSICAL CHANNEL CONFIGURATION FAILURE message (cause: unsupported
configuration). There will be second trying to the CELL_PCH state and the ‘non-URA UE’ flag is
set.
The re-activation of the data connection can be initiated by the UE by using the Cell Update
message (cause UL data transmission, see Figure 11Figure 11Figure 11 and File 10File 10File
10A) or by the RNC by paging the UE. The RNC either keeps the UE in CELL_FACH or moves
it to CELL_DCH with the Radio Bearer Reconfiguration procedure.
Figure 11. Transfer of the UE to CELL_DCH and reactivation of the data connection (cause UL data
transmission).
A) Cell update
B) Radio bearer reconfiguration from CELL_FACH to CELL_DCH(HSDPA)
File 10 _ Example of Measurement Control message used to modify/release the UL traffic volume
measurement.
In RAS06, the Service establishment is always executed in Cell_FACH state and if the UE is in
Cell_PCH state when the establishment procedure is triggered, the UE is first transferred to the
Cell_FACH state. In RU10, it is possible to enable direct transition from Cell/URA_PCH states to
CELL_DCH state using Cell update –procedure. Direct transfer can be triggered by UL data
transmission when UE has set TVM-indicator as TRUE in Cell Update message indicating that
the RLC buffer level exceed the lower TVM threshold and RACH/FACH cannot be used for
transferring the buffered amount of data, or by DL data transmission when there is so much DL
data send towards UE that on RNC point of view it shall be transferred to Cell DCH state
(TrafVolThrDLLowGTP exceed).
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 27 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 12. Fast call setup with direct transition from URA_PCH/CELL_PCH to CELL_DCH.
2.4.7 Packet data connection mobility
The procedure used for mobility depends on channel type in use. Normal DCH channels utilise
the soft handover procedure and in CELL_FACH/CELL_PCH states a cell-reselection procedure
is used together with Cell Updates. In CELL_DCH with HSPA channels the mobility is in most
cases performed with the soft handover procedure combined with Serving HS-DSCH cell
change, which is required as HSDPA does not support soft handovers. RAS06 RNC supports
also a HSDPA cell-reselection procedure, but this is available only when HSUPA is not active
and serving cell change is not activated.
The Serving HS-DSCH cell change can be triggered by multiple different triggers



UE based measurements: Periodical EcNo measurements, Event1B or Event1C to
remove current Serving HS-DSCH cell
BTS SIRerror measurements on Serving HS-DSCH cell
Loss of UL synchronisation indication from BTS
The Serving HS-DSCH cell change procedure can be forbidden in some cases like when interRNC SHO is not supported or the Serving HS-DSCH cell change is not enabled. In these cases
the change of cell is performed via CELL_FACH.
An example of signalling for Serving HS-DSCH cell change with SHO is presented in Figure
13Figure 13Figure 13. This example starts with Active set update to add the Cell2 to the active
set. The start of SHO triggers also the Physical Channel Reconfiguration procedure (see File
11File 11File 11A) that is used to change the power offset of CQI, QCK and NACK bits in the
HS-DPCCH, as RAS06 RNC uses different values for single link and SHO connections. Also the
periodical EcNo measurements are activated for all active set cells. The decision for the SCC is
done based on these periodical measurements.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 28 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 13. Serving HS-DSCH cell change triggered by periodical EcNo measurements.
The Radio Bearer Reconfiguration message is used to inform the UE about the change of the
serving HS-DSCH cell (see File 11File 11File 11C). This information is indicated in the IE:
Serving HS-DSCH Indicator for RL.
A) Physical channel
reconfiguration to
SHO configuration
B) Physical channel
reconfiguration to
single link
configuration
C) Measurement control
message used to activate
the periodical EcNo
measurements
D) Radio bearer
reconfiguration to
change serving HSDSCH cell
File 11. Example of messages used for Serving Cell Change procedure.
The SCC can be triggered also by an Event 1B to remove the current serving HS-DSCH cell
from the active set (see Figure 14Figure 14Figure 14). In this case the Radio Bearer
Reconfiguration message is used first to change the serving HS-DSCH cell and then the Active
Set Update to remove the previous serving HS-DSCH cell from the active set. If there is only
one cell in active set after the update, then the Physical Channel Reconfiguration is used to
change to CQI, NACK and ACK offsets to the single link values.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 29 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 14. Serving cell change triggered by Event 1B on the serving HSDSCH cell (no NBAP
signalling presented).
The serving HS-DSCH cell change can be performed with hard handover when the SHO is not
possible, e.g. in inter-RNC mobility if inter-RNC SHO is not supported. Figure 15Figure 15Figure
15 presents the signalling of an inter-RNC mobility with HSPA. The inter-RNC cell change
triggers also the UE Capability Enquiry and UTRAN Mobility Information procedures.
Figure 15. Inter-RNC serving HS-DSCH cell change with hard handover (no NBAP signalling
presented).
HSDPA IFHO is supported from RU10 onwards. HSDPA IFHO can be triggered due to quality,
coverage, HSPA capability and immediate IMSI based handover reasons and is available for all
supported HSPA services and service combinations. Without this feature, intermediate channel
switching from HS-DSCH to DCH (and later back to HS-DSCH) is required before the
compressed mode can be started. Target cells for an HSPA inter-frequency handover can be
intra-BTS, inter-BTS intra-RNC, or inter-BTS inter-RNC cells. Before an HSDPA IFHO can be
started, the associated DCH must enter compressed mode so that IFHO measurements can be
performed. Existing HS-DSCH/E-DCH configuration are reconfigured to HS-DSCH/DCH
configuration independent of the need for compressed mode to perform the measurements.
For HS-DSCH ISHO, first there will be radio_bearer_reconfiguration to DCH, then compressed
mode with physical_channel_reconfiguration, cell change order (CCO) to GPRS, then LAU &
RAU and finally immediate assignment to start data flow in EGPRS.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 30 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
3 PS RAB QoS parameters
3.1 Specification
A set of UMTS bearer attributes have been defined to specify the UMTS service. They are listed
on the table below. When a UMTS bearer is established, modified or released, aspects such as
the UE capabilities, subscription profiles and network specific QoS profiles have to be taken
under consideration.
Traffic class
Conversational
class
Streaming
class
I nteractive
class
Background
class
Maximum bit rate
Delivery order
Maximum SDU size
SDU format
information
SDU error ratio
Residual bit
error ratio
Delivery of
erroneous SDUs
Transfer delay
Guaranteed bit rate
Traffic handling
priority
Allocation/Retention
priority
Table 8. UMTS QoS attributes
3.2 Definition of PS RAB QoS in connection setup
UE initiates the PS RAB setup by sending a PDP context request to the SGSN (1). This PDP
Context Request contains the requested QoS. This initiates the QoS negotiation procedure.
Table 9 QoS negotiation at PDP context setup.
SGSN compares the requested QoS to the QoS profile in HLR (See
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 31 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
). The QoS profile is defined for each subscriber per Access Point (AP) in the Home Location
Register (HLR) and each PDP context has to negotiate its own QoS profile. QoS profiles for
different PDP contexts of one subscriber can all be different. In Nokia R99 HLR, QoS attributes
are configurable.
Nokia SGSN downgrades the QoS if necessary and sends the negotiated QoS to the GGSN. (2)
The negotiated QoS is limited by the appropriate values defined for each traffic class in the
3GPP specification TS23.107. The limitations for the traffic classes are according to the
following
..
Table 10. QoS values for different traffic classes.
If a Service based QoS control feature is used in Nokia GGSN (Rel. 5), the GGSN may restrict
the negotiated QoS further. The GGSN session management and admission control function
selects the treatment class (TREC) based on used access point and service (service detection
and switching). The selected TREC is mapped to the 3GPP QoS attributes in the GGSN for the
QoS negotiation with the SGSN. GGSN can not allocate higher QoS than requested by SGSN.
(3)
4 UE Categories and Monitoring
New features and bitrates may notare typically be not supported by the oldest UEs models. With
Counters is possible to detect UE Release Indicator and HSPA category. UE HSPA category
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 32 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
tells number of codes, modulation and bit rates supported. UE release indicator is possible to
detect, but based on that it is possible to detect only mandatory features. Features that are
optional are not often possible to detect with counterdetected with the counterss. If more detail
understanding is required, some other methods like ICSU logging should be used
Access Stratum Release indicator counters can be used monitor number of RRC connection
establishment by UEs which access stratum release indicator release x.






M1001C405_ACCESS_STRATUM_REL_IND_99
M1001C404_ACCESS_STRATUM_REL_IND_4
M1001C552_ACCESS_STRATUM_REL_IND_5
M1001C616_ACCESS_STRATUM_REL_IND_6
M1001C675_ACCESS_STRATUM_REL_IND_7
M1001C699_ACCESS_STRATUM_REL_IND_8
Additionally UE support for features like Continuous Packet connectivity or CS Voice over HSPA
can be detected. (Also UE support for GSM, GANHO, IPHC, AGPS)


M1001C677_UE_SUPP_CPC
M1001C671_UE_SUPP_CS_VOICE_OVER_HSPA_
User throughput depends from the UE type which is used in the network. In RU20 maximum
64QAM user throughput can be achieved with Cat14 and Cat18 HSDPA UEs, MIMO maximum
throughput can be achieved with Cat 18 UE. Category 24 is required to support maximum DC
HSDPA throughput with 64QAM in RU20 on top. There are counters to check the UE type
distribution based HSDPA category










UE_SUPP_HSDSCH_CLASS_1_6 (M1001C548) 5 codes, 3.6 Mbps
UE_SUPP_HSDSCH_CLASS_7_8 (M1001C549) 10 codes, 7.2 Mbps
UE_SUPP_HSDSCH_CLASS_9_10 (M1001C550) 15 codes, and 10.8-14,4Mbps
UE_SUPP_HSDSCH_CLASS_11_12 (M1001C551) QPSK only, 5 code, 1.8Mbps
UE_SUPP_HSDSCH_CLASS_13_14 (M1001C672) 64QAM, 15 code, 17-21 Mbps
UE_SUPP_HSDSCH_CLASS_15_16 (M1001C673) MIMO, 15 code, 28 Mbps
UE_SUPP_HSDSCH_CLASS_17_18 (M1001C674) MIMO, 15 code, 28 Mbps
UE_SUPP_HSDSCH_CLASS_19_20 (M1001C696) MIMO with 64QAM
UE_SUPP_HSDSCH_CLASS_21_22 (M1001C697) DC HSDPA with 16QAM, 28 Mbps
UE_SUPP_HSDSCH_CLASS_23_24 (M1001C698) DC HSDPA with 64QAM, 42 Mbps
HSPA UE utilisation KPIs can be used to monitor how big percentage of HSPA capable UE’s got
RRC-Connection from all RRC-Connections.


RNC_655c_HSDPA UE utilisation
RNC_1049c_HSUPA UE utilisation
Additionally number of MIMO and DC HSDPA capable EUs can be monitored. Modified version
of these KPIs can be used monitor MIMO and DC_HSDPA capable UE utilisation similar way as
for HSPA UE utilisation.


RNC_2110a count Amount of MIMO capable UEs and
RNC_2111a counts amount of DC HSDPA capable UEs.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 33 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 16 below show HSDPA and HSUPA UE utilisation within last 100 weeks. In RU20
timeframe, the HSDPA utilisation is around 86% and HSUPA UE utilisation around 30% in this
example network.
Figure 16 HSDPA and HSUPA UE utilisation within last 100 weeks.
Majority of the HSDPA UEs are still category 1-6 five code UEs having max 3.6 Mbps
throughput, see below one example.
HSDPA UE categories %
100%
80%
%
60%
40%
20%
0%
1
4
7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97
weeks
UE_SUPP_HSDSCH_CLASS_1_6
UE_SUPP_HSDSCH_CLASS_7_8
UE_SUPP_HSDSCH_CLASS_9_10
UE_SUPP_HSDSCH_CLASS_11_12
Figure 17 HSDPA UE category distribution within last 100 weeks.
There are similar counters for HSUPA UE categories as well. Currently most of the HSUPA UEs
are category 5 UEs

UE_SUPP_EDCH_CATEGORY_1 (M1001C610)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 34 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20






Date:
175.110.2010
Version 2.10
UE_SUPP_EDCH_CATEGORY_2 (M1001C611)
UE_SUPP_EDCH_CATEGORY_3 (M1001C612)
UE_SUPP_EDCH_CATEGORY_4 (M1001C613)
UE_SUPP_EDCH_CATEGORY_5 (M1001C614) 2 Mbps and 10ms TTI only
UE_SUPP_EDCH_CATEGORY_6 (M1001C615) 5.8 Mbps, both 2ms and 10ms TTI
UE_SUPP_EDCH_CATEGORY_7 (M1001C676) 16QAM, both 2ms and 10ms TTI
For HSUPA, the majority of the UEs are Category 5 UEs by supporting 2Mbps throughput and
10 ms TTI. Less than 30% of the UEs are category 6 UEs supporting higher uplink bitrates with
2ms TTI.
Figure 18. HSUPA UE category distribution within last 100 weeks.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 35 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
5 NRT PS RAB performance
It is worth of mentioning here that RAN KPI does not always mean end user perception. So If
NRT RAB drops it is possible that end user does not see it due to RAB re-establishment
procedure, for example. The KPI example figures show the impact of RU10 upgrade (done
9.7.2009). KPIs are taken with RAS06 RS formulas to see the impact of performance change.
This is due to new RU10 KPIs could not be seen from RAS06 SW level with RU10 RS.
5.1 Accessibility
In normal network conditions there should not be NRT PS RAB access failures as there is no
resource reservation done in the RAB setup and access phases for NRT RAB.
The RAB setup procedure is started with RAB Assignment request message from CN (see
Figure 5Figure 5Figure 5). The NRT PS RAB setup does not require any resource reservation
as no radio link is setup at this phase.
High level RAB KPI - RNC_157a (RSRAN 003, service summary) RAB Setup and Access
Complete Ratio for NRT Service from User perspective can be used to monitor RAB
accessibility from user point of view. Low performing cells can be then ranked to more detail
analysis
RNC_156a  100
RAB_STP_ACC_COMP_PS_BACKG  RAB_STP_ACC_COMP_PS_INTER
%
RAB_STP_ATT_PS_BACKG  RAB_STP_ATT_PS_INTER
The failure reasons for NRT PS RAB Setup and Access are limited to following, as there is no
BTS or transport resource reservation done in RAB setup phase for NRT. If direct resource
allocation for HSPA fails, then DCH 0/0 is allocated instead.




The PS RAB setup attempt is not started due to requested parameters not supported by
the UE or RNC, Counters
 M1001C258 RAB_STP_FAIL_PS_UE_CAPA,
 M1001C257 RAB_STP_FAIL_PS_NOT_SUPP_PAR
 The RAB setup attempt counters are not updated in this case
RAB assignment fails due to AC; counters & PIs:
 RNC_376a=M1001C105 RAB_STP_FAIL_PS_BACKG_AC,
RNC_384a=M1001C110 RAB_STP_FAIL_PS_INTER_AC
 RNC_1073a (RAB Setup FR for PS I&B calls due to AC)
 There is no check of air interface resources in NRT PS RAB setup
RNC decides to reject the PS RAB request due to RNC internal failure, counters and PIs:
 RNC_387a = M1001C112 RAB_STP_FAIL_PS_BACKG_RNC
 RNC_379a = M1001C107 RAB_STP_FAIL_PS_INTER_RNC
 RNC_1076a (RAB Setup FR for PS I&B calls due to RNC)
The number of RAB setup failures caused by ongoing relocation or hard handover for PS
data interactive, Counters and PIs
 M1001C108_RAB_STP_FAIL_PS_INTER_ANCH,
M1001C113_RAB_STP_FAIL_PS_BACKG_ANCH
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 36 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20

Date:
175.110.2010
Version 2.10
 PIs: RNC_1074a (RAB Setup FR for PS I&B calls due to ANCH)
No RRC: Radio Bearer Setup Complete message received from the UE, Counters and
PIs
 RNC_403a=M1001C132 RAB_ACC_FAIL_PS_INTER_MS,
 RNC_404a=M1001C134 RAB_ACC_FAIL_PS_BACKG_MS
 RNC_1078a (RAB Setup Access FR for PS I&B calls due to UE)
Table 11Table 11Table 11 lists the reports and PIs related to NRT PS RAB performance
monitoring and failure analysis. The RAB setup failures due to transmission (RNC_1075a) are
not related to RAB setup phase but to actual radio bearer resource allocation or modification,
this PI or related counters M1001C106 and M1001C111 are not supported in RU10 onwards.
Table 11. Reports and PIs related NRT PS RAB accessibility
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000
RNC_616a
RAB Attempts PS Interactive and Background
#
RNC_157a
RAB Setup and Access Complete Ratio for NRT Service from User
perspective
%
Report: Service/Session Access Detailed info RSRAN73
RNC_569a
RAB PS Setup Attempts
#
RNC_1925a
PS RAB Setup Completed
#
RNC_1026a
PS RAB Setup FR due to AC
%
RNC_2007a
PS RAB Setup FR due to ANCH
%
RNC_1028a
PS RAB Setup FR due to RNC
%
RNC_1031a
PS RAB Setup FR due to FROZBS
%
RNC_1033a
PS RAB Setup Access FR due to UE
%
RNC_1035a
PS RAB Setup Access FR due to RNC
%
Figure 19Figure 19Figure 19 presents an example of PS RAB accessibility performance before
and after RU20 upgrade. AC failures disappeared already in RU10. This is natural because
resource reservation is not done during PS RAB setup. In general the failure rate is very low,
typically below 0.02 % and that the RNC failures are most typical in this example. RNC failures
can be studied in more detail with RNC internal ICSU logging. Figure 20Figure 20Figure 20
shows example of RAB access failure statistics. The failures were increasing after DRA
enabling.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 37 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0 EP1
first cluster
RU20
MP2
WN6.0
EP1
first cluster
RU20 MP2
Figure 19 PS RAB setup failure rate statistics (RU10/RU20)
RU10
RU20 MP1
RU20EP1
PP1.12
Failures
decrease on
01.10 after
enabling of DRA
Figure 20. PS RAB Access failure rate statistics (RU10/RU20)
5.2 Retainability
The NRT PS RAB consists of Iu bearer and radio bearer. The radio bearer can utilise multiple
different channel types (DCH, HSPA or CCCH). The retainability of a NRT PS RAB will depend
on the Iu bearer and radio bearer performance.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 38 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RAB active starts when the RNC sends a RANAP: RAB ASSIGNMENT RESPONSE message
to the CN (see Figure 5Figure 5Figure 5). RAB active is completed when the RNC receives a
RANAP: RAB ASSIGNMENT REQUEST message from the CN with the IE: RAB release, and
then acknowledges that by sending a RANAP: RAB ASSIGNMENT RESPONSE message to the
CN. After that, the RNC releases RAB resources, that is, RAB active phase ends before the
release.
RAB active is completed also when the RNC receives a RANAP: IU RELEASE COMMAND
message from the CN, and then releases RAB resources, that is, RAB active phase ends after
the release.
High level RAB KPI - RNC_736a (RAB Success Ratio, NRT Services, from User Perspective)
can be used to monitor RAB retainability. Low performing cells can be then ranked to more
detail analysis.
RNC_736a  100  100
RAB active failures (I & B) - RAB active failures in PCH state (I & B)
%
RAB active completions (I & B)  RAB active releases (I & B)  RAB active failures (I & B)
RAB active fails when an interface-related (Iu, Iur, Iub, or Uu) or RNC internal failure occurs, and
the failure causes the release of the RAB connection.







Caused by radio interface synchronisation
 PI: RNC_1086a (RAB Active FR for PS I&B due to RADIO)
 Counters: M1001C186_ RAB_ACT_FAIL_PS_INTER_RADIO, M1001C192_
RAB_ACT_FAIL_PS_BACKG_RADIO
 release is requested due to radio interface synchronisation failure
Caused by BTS (for example, radio link setup or reconfiguration problem)
 PI: RNC_1087a (RAB Active FR for PS I&B due to BTS)
 Counters: M1001C187_ RAB_ACT_FAIL_PS_INTER_BTS, M1001C193_
RAB_ACT_FAIL_PS_BACKG_BTS
 release is requested due to BTS failure
Abnormal reason related to Iu-interface
 PI: RNC_1085a (RAB Active FR for PS I&B due to IU)
 Counters: M1001C185_RAB_ACT_FAIL_PS_INTER_IU, M1001C191_
RAB_ACT_FAIL_PS_BACKG_IU
Caused by drift RNC procedures
 PI: RNC_1088a (RAB Active FR for PS I&B due to IUR)
 Counters: M1001C190_ RAB_ACT_FAIL_PS_INTER_IUR, M1001C194_
RAB_ACT_FAIL_PS_BACKG_IUR
Caused by UE
 PI: RNC_1091a (RAB Active FR for PS I&B due to UE)
 Counters: M1001C397_RAB_ACT_FAIL_PS_INTER_UE,
M1001C398_RAB_ACT_FAIL_PS_BACKG_UE
 because the UE is not responding to an RRC message or the UE is responding
with such failure message that the connection must be released
Caused by integrity check
 PI: RNC_1089a (RAB Active FR for PS I&B due to I_CHK)
 Counters: M1001C189_RAB_ACT_FAIL_PS_INTER_I_CHK,
M1001C195_RAB_ACT_FAIL_PS_BACKG_I_CHK,
 This counter is never updated.
Some reason not covered by the other failure counters
 PI: RNC_1090a (RAB Active FR for PS I&B due to RNC)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 39 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20

Date:
175.110.2010
Version 2.10
Counters: M1001C190_ RAB_ACT_FAIL_PS_INTER_RNC, M1001C196_
RAB_ACT_FAIL_PS_BACKG_RNC
It should be noted that RAB retainability is not same than RB retainability, because it is possible
to re-establish the RB in side RAN (by setting T315 parameter greater than 0) when having
existing RAB connection to the core network. In RU10 it is possible to have RAB reestablishment also for Voice and PS RT (by setting parameter T314 greater than 0).
Table 12Table 12Table 12 lists the relevant reports and PIs for NRT PS RAB retainability
monitoring and troubleshooting.
Table 12. Reports and PIs related NRT PS RAB retainability
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000
RNC_616a
RAB Attempts PS Interactive and Background
#
RNC_615c
RAB Success Ratio, NRT Services, from Network Perspective
%
RNC_736b
RAB Success Ratio, NRT Services, from User Perspective
%
Report: Service/Session Detailed Retain Info RSRAN79
RNC_1978a
RAB Setup Access Completions for PS
#
RNC_1964a
RAB Active FR for PS due to IU
%
RNC_1959b
RAB Active FR for PS due to RADIO
%
RNC_1960b
RAB Active FR for PS due to BTS
%
RNC_1961b
RAB Active FR for PS due to IUR
%
RNC_1962b
RAB Active FR for PS due to RNC
%
RNC_1963b
RAB Active FR for PS due to UE
%
RNC_2005a
RAB Active FR for PS due to trans
RU20 introduce new RAB Active failure cause due to transport (Drop) included; These new
counters are included to RNC_615c, RNC_736b: in RU10 this failure cause was included in
failure due to RNC -> KPI comparable
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 40 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Low NRT PS RAB
retainability (cell)
No
No Action
Needed
Yes
NRT PS RAB active
fail due to radio
Yes
Check NRT PS radio bearer failures due to
radio
Yes
Check BTS HW resources, can be caused by
failed SCC due to HSDPA ret channel
Yes
Check core network parameter settings
Yes
Inter RNC mobility?
No
NRT PS RAB
active fail due BTS
No
NRT PS RAB
active fail due to Iu
No
Rejections
NRT PS RAB
active fail due to Iur
No
NRT PS RAB active
fail due to RNC
Yes
RNC Internal Problem
No
NRT PS RAB active
fail due to UE
Yes
Terminal Problem
(
Figure 21. NRT PS RAB retainability analysis
Below is one example of NRT PS RAB retainability, it can be seen that RAB Active failure
improved since PRFILE change on 27.08.10 (TN148) and correction of a problem with iPhone in
PP1.93
.
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0 EP1
first cluster
TN148
RU20 MP2
iPhone
correction
in PP1.93
Figure 22 Example of PS NRT RAB Active fail change due to BTS (RU10/RU20)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 41 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Below is also example of PS setup failures causes based on packet call counters. Different
failure cases are explained in the HSDPA accessibility chapter in Table 13Table 13Table 13.
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0
EP1
first cluster
RU20 MP2
Increased failures due
to BTS on a few sites
during high traffic
season
Figure 23 Example of PS setup failure rates (RU10/RU20)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 42 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
6 HSPA bearer performance
6.1 Accessibility
HSUPA cannot be established without HSDPA; if HSUPA is supported the HSDPA UL return
channel is HSUPA instead of R99. In both cases, the High level Setup procedure is the same:
RNC starts by allocation a 0/0 kbps connection and selection between DCH and E-DCH is then
completed when RNC receives the uplink or downlink capacity request, or if Direct resource
allocation for HSPA feature (RU20) is used, then HSPA is already allocated during RAB
establishment which replace the allocation of 0/0 kbps.
6.1.1 HSDPA accessibility
High level HSDPA KPI - RNC_605a (RSRAN003, Service Summary) can be used to monitor
HSDPA accessibility from user point of view. Low performing cells can be then ranked to more
detail analysis.
RNC_605a 
ALLO _ HS _ DSCH _ FLOW _ INT  ALLO _ HS _ DSCH _ FLOW _ BGR
 ALLO _ HS _ DSCH _ FLOW _ INT  ALLO _ HS _ DSCH _ FLOW _ BGR  DCH _ SEL _ MAX _ HSDPA _ USERS _ INT
 100%
 DCH _ SEL _ MAX _ HSDPA _ USERS _ BGR  REJ _ HS _ DSCH _ RET _ INT  REJ _ HS _ DSCH _ RET _ BGR
 SETUP _ FAIL _ RNC _ HS _ DSCH _ INT  SETUP _ FAIL _ RNC _ HS _ DSCH _ BGR  SETUP _ FAIL _ UE _ HS _ DSCH _ INT
 SETUP _ FAIL _ UE _ HS _ DSCH _ BGR  SETUP _ FAIL _ BTS _ HS _ DSCH _ INT  SETUP _ FAIL _ BTS _ HS _ DSCH _ BGR 
 SETUP _ FAIL _ IUB _ HS _ DSCH _ INT  SETUP _ FAIL _ IUB _ HS _ DSCH _ BGR
Equation 1. RNC_605a HSDPA accessibility for NRT traffic from user point of view
The HS_DSCH setup and Selection can fail due the many reasons. When monitoring HSDPA
setup failure counters it is important to understand root cause of the failure. Typically setup
failures indicate resource shortage, and as can be seen from flow chart below (Figure 24Figure
24Figure 24), these problems are often related to HSDPA UL DCH return channel rather than
HSDPA Mac-d flow itself. But if there are not enough resources to set up HSDPA UL DCH
return channel, the HSDPA Mac-d flow setup will fail also.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 43 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Low HSDPA
accessibility (cell)
No
Date:
175.110.2010
Version 2.10
No Action
Needed
Yes
Too many HSDPA
users reached
Check Number of simultaneous HSDPA
users in BTS or cell level depending on the
scheduler type
Yes
No
Yes
Check BH Channel Element resource Usage
(Lack of CE for UL return Channel)
Rejection of UL
Return Channel
Rejections
No
Yes
Check BH UL Power Congestion
(Lack of Radio resources for UL return Ch.)
HSDPA Setup Fail
Iub (Both UL & DL)
Yes
Check BH AAL2 Iub congestion
(Lack of Iub resources for UL return Ch.)
HSDPA Setup Fail
due BTS
No
No
HSDPA Setup Fail
UE
Yes
Check RB reconfiguration failure rate
(Terminal Problem)
Yes
Check RNC Unit load (DMPG),
max number
(
of users/RNC, DSP failures and faulty alarms
No
HSDPA Setup Fail
RNC Internal
Figure 24 – HSDPA Accessibility Failure Analysis
Besides of reasons listed in Figure 24Figure 24Figure 24, the HSDPA accessibility problems
can be also related to Iu-PS or IP-BB capacity problems. HSDPA channel type selection can be
also fail due the downlink power if static power allocation is used instead of Dynamic
resource/power allocation. There should be also enough resources to set up HS_SCCH for DL.
Table 13Table 13Table 13 lists the relevant reports and PIs for HSDPA RB accessibility
monitoring and troubleshooting. Note: HSDPA access failure rate PIs are currently defined as %
of all failures calculating failure distribution, instead of the failure rate over the HS-DSCH
selection. In RU10, these PIs are changed to calculate failure rate over all HS-DSCH selections.
Table 13. Reports and PIs related HSDPA accessibility
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000
RNC_930b
Packet Session Attempts (for R99 & HSPA)
#
RNC_916b
Packet Session Setup Success Ratio for NRT (for R99 & HSPA)
%
RNC_614c
HS-DSCH selections (for HSDPA only)
#
RNC_605b
HSDPA Resource Accessibility for NRT Traffic (user) (for HSDPA only)
%
RNC_926b
HSDPA attempts
#
RNC_914c
HSDPA Setup Success Ratio from user perspective (HSDPA &
HSUPA)
%
Report: Service/Session Accessibility Analysis RSRAN073 (M1022, M1002)
RNC_930b
Packet Session Attempts (for R99 + HSPA)
Copyright © Nokia Siemens Networks 2008
Company confidential
#
Page 44 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RNC_967b
PS Call Setup FR due to AC (for R99 +HSPA)
%
RNC_955b
PS Call Setup FR due to BTS (for R99 +HSPA)
%
RNC_1080b
PS Setup FR for I&B due to lack of DMCU (for R99 +HSPA)
%
RNC_1081b
PS Setup FR for I&B due to Transport (for R99 + HSPA)
%
RNC_1082b
PS Setup FR for I&B due to UE (for R99 +HSPA)
%
RNC_1083b
PS Setup FR for I&B due to Others (for R99 +HSPA)
%
RNC_614c
HS-DSCH selections (for HSDPA only)
#
RNC_663d
HSDPA Access FR due to RNC (for HSDPA only)
%
RNC_673d
HSDPA Access FR due to BTS (for HSDPA only)
%
RNC_665d
HSDPA Access failures due to Iub (for HSDPA only)
%
RNC_667d
HSDPA Access FR due to UE (for HSDPA only)
%
RNC_661d
HSDPA Access FR due to UL DCH (for HSDPA only)
%
RNC_671c
HSDPA Access FR due to AMR+HSPA (for HSDPA only)
%
RNC_660d
DCH Selected due to too many HSDPA users (for HSDPA only)
%
RNC_914a (RNC_914c in RU10) HSDPA setup success rate, gives lower value than
RNC_605a due to the HSDPA/HSUPA attempt counters are incremented for cells which do not
have HSDPA/HSUPA enabled if the UE is HSDPA/HSUPA capable. RNC_914a also does not
include statistics from serving cell change mobility. Thus, the performance could be lower as
well due to statistical calculation. Also HSUPA is included into RNC_914a/b as well, so it is more
HSPA accessibility KPI. When aggregate across cells, this KPI should aggregate across cells
which have HSDPA enabled only (RNC level not recommended unless all cells HSDPA
enabled)
In RU20 there is less HSDPA setup failures due the changes in counter implementation. This
impact BTS and Iub Setup failure counters, which are typically related to HSDPA UL R99 return
channel. When the UE is attempted to transfer from FACH directly to high UL bitrate, attempt for
high bitrate fails and immediate retry to lower allowed UL bitrate is done, in RU10 the counter is
updated for each bit rate until successful allocation for that secuency happens or entire
procedure failed. Now in RU20, these counters are updated only ones resulting only counter
update.
This impact only FACH-> HSxPA procedure, In DCH 0/0 -> HSxPA transition counters work
similarly in RU10 and RU20. No impact to packet call counters (M1022)
Figure 25Figure 25Figure 25 presents an example of HSDPA accessibility PIs from live network.
HSDPA mac-hs efficiency increased on Flexi rel-2 sites due to new functionality ‘HSDPA
dynamic BLER’.
Otherwise performance is more or less same than in RU10 level.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 45 (123)
Formatted: French (France)
Formatted: English (U.S.)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
RU10
RU20 MP1
WN6.0
EP1
first cluster
RU20EP1
PP1.12
RU20 MP2
Configuration
error on 4 sites
of DC HSDPA
cluster.
HSDPA mac-hs
efficiency
increased on Flexi
rel2 sites
Figure 252525. Example HSDPA performance (RU10/RU20) PIs.
Formatted: French (France)
Field Code Changed
Figure 26Figure 26Figure 26 presents an example of HSDPA access failure cause. In this
example Iub and BTS failures are most dominating, which indicates HSDPA return channel
allocation failure due to BTS HW resource shortage. It can be seen that there are less access
failures with RU20.
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0
EP1
first cluster
RU20 MP2
Figure 26. Example HSDPA accessibility failure causes (RU10/RU20).
HSDPA setup can fail due the number of simultaneous users reached. There are two main
solutions available; increase the capability of the network or decreased the number of UEs in
DCH. The network capability can be increased by introducing high Share Scheduler for BB
efficiency (max 48 users/scheduler) or 48 users/cell feature, or even second scheduler. It should
also be considering if traffic balancing between neighbouring sites is possible. In RU10, the
maximum number of HSDPA users increase to 64 with full baseband scheduler (ex-48 users per
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 46 (123)
Formatted: French (France)
Formatted: French (France)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
cell scheduler). 64 users is also possible with shared scheduler for BB efficiency in case Flexi
BTS Rel 2 HW (FSMC/D) is used. In RU10 it is possible to limit either maximum number of
HSDPA users or HSDPA Mac-d flows in the cell, this is done with parameters
MaxNumberHSDPAUsers and MaxNumberHSDSCHMACdFlows. HSDPA user is a user that
has one or more HS-DSCH MAC-d flows established. (by default, both parameters are set to 0 –
default value does not restrict the number of HSDPA users.)
Typically cell have amount of HSDPA user which does not have any data in the buffers but are
still counted. This can be, for example, due the very long inactivity timer. Low utilisation and
inactivity timer parameter for HSDPA and UL DCH return channel can be tuned to increase
HSDPA accessibility in case maximum amount of HSDPA user is reach. Table 14Table 14Table
14 presents example parameter sets targeted to decrease HSDPA utilisation. The traffic volume
related parameters can be used to delay the transition from CELL_FACH to CELL_DCH. The
MAD-d flow throughput and utilisation parameters can be used to release the HSDPA allocation
faster.
Table 14. RNC parameters related to CELL_DCH state selection and release.
Figure 27Figure 27Figure 27 presents an example of the HSDPA accessibility (RNC_605a) and
Figure 28Figure 28Figure 28 the corresponding failure analysis. The results show that the main
accessibility failure cause is too many HSDPA users. This was first optimised by increasing the
scheduler capacity from 16 users/BTS to 48 users/BTS (16/cell), the result was a clear decrease
in the failure rate. The second optimisation action was to change the low traffic volume threshold
in order to decrease/postpone the transitions to CELL_DCH. This change shows a clear
improvement in accessibility and failure rates. The accessibility was increased further by
activating the 48 users/cell in the RNC, thus enabling higher number of users in cell level. This
removed most of the failures due to number of HSDPA users.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 47 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 27. HSDPA accessibility with optimisation.
Figure 28. HSDPA accessibility failure analysis with optimisation steps.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 48 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
6.1.2 HSDPA UL Return Channel
HSDPA UL return channel rejections due AC can be monitored with RNC_662a - HSDPA
access Failure Rate due the UL DCH. In RAS06, UL AC could be based on both throughput and
power based PS call algorithm depending on the parameter settings. PrxLoadMarginMaxDCH
parameter defines interference margin for the maximum UL DCH load. Using other value than
default (0 dB), for example value of 2dB (37% load) can cause HSDPA UL return channel
rejections due AC to increase. It is recommended to remove impact of this parameter by setting
it to value 0 dB (throughput based AC algorithm not in use), see Figure 29Figure 29Figure 29.
This parameter is valid for all R99 PS bearers, not only for HSDPA UL return channel.
PS_ATT_HSDSCH_DCH INT
PS_SETUP_FAIL_AC INT
35000
30000
25000
20000
15000
10000
5000
(blank)
10.10.2008 07:00
10.10.2008 03:00
09.10.2008 23:00
09.10.2008 19:00
09.10.2008 15:00
09.10.2008 11:00
09.10.2008 07:00
09.10.2008 03:00
08.10.2008 23:00
08.10.2008 19:00
08.10.2008 15:00
08.10.2008 11:00
08.10.2008 07:00
08.10.2008 03:00
07.10.2008 23:00
07.10.2008 19:00
07.10.2008 15:00
0
Figure 29. Effect of PrxLoadMarginMaxDCH on HSDPA return channel accessibility.
HSDPA BTS CE resource reservation is always fixed, and cannot be used for other purpose but
HSDPA only. This HSDPA Baseband resource reservation is symmetric for uplink and downlink,
and depends on scheduler type (shared or dedicated), BTS HW type and release.
However, resources are not reserved for HSDPA UL return channel. There have to be enough
free UL CE capacity available to setup HSDPA UL return channel or HSDPA setup will fail. In
RAS06, the UL DCH data rate of 16 kbps for HSDPA return channel is supported in addition to
currently supported 64, 128 and 384 kbps bitrates. 16 kbps for HSDPA return channel feature,
together with PBS or TBO, can be used to optimise resources for HSDPA UL DCH.
Prior to RU20, the parameter MaxBitrateULPSNRT was also applicable to the HSDPA UL return
channel. In RU20 onwards there is own parameter HSDPAMaxBitrateUL which defines the
maximum user bit rate allowed in the cell for HSDPA UL DCH return channel. By default the
value of this parameter is 384 kbps.
Existing RAS05 and RAS51 features support the dynamic use of lower DCH data rates for
HSDPA UL DCH return channel. The following existing functionalities are applied to the HSDPA
UL return channel (UL DCH):

Priority based scheduling and Overload control – PBS can release or downgrade existing
NRT allocation if there is other user requesting initial capacity in congested situation. This
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 49 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
means that for example in case of CE congestion, the PBS downgrade existing DCHs
from higher data rates to 16 kbps one by one until the maximum number of users in the
BTS is achieved. Congestion of following resources can trigger enhanced priority based
scheduling function: DL power, UL interference, downlink spreading code, BTS HW (CE)
and Iub transmission
Throughput based Optimization - TBO of PS Algorithms feature downgrades the DCH bit
rate down to 16 kbps if the high bit rate DCH is used inefficiently which help saving
resources (mainly BTS CE, transmission and downlink spreading code resources)
Upgrade of NRT DCH Data Rate (Normal or Flexible upgrade)
RT-over-NRT



RT over NRT and pre-emption actions for any reason shall not be targeted to Mac-d flow.
However, RT over NRT actions can be targeted to UL return channel DCH, causing also the
release of MAC-d flow.
More detail description of PSB and TBO can be found from [7]‎[7][7]
As can be seen from Figure 30Figure 30Figure 30 below, there is clear correlation between UL
CE usage and HS-DSCH setup failures. When Maximum used CE drop below 124 (from max.
128), the HS-SETUP_FAIL_BTS_HS_DSCH_BGR drops significantly
140
120
100
80
60
40
20
0
1
11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161 171 181 191 201 211 221 231 241 251 261 271 281 291 301 311 321 331
AVG_USED_CE_UL (Wbtshw)
MAX_USED_CE_UL (Wbtshw)
SETUP_FAIL_BTS_HS_DSCH_BGR (Traffic)
Figure 30. Relation between UL CE usage and HS-DSCH setup failures (RAS06)
Activation of TBO and HSDPA 16 kbps Return channel improves HSDPA accessibility (blue line)
as can be seen from Figure 31Figure 31Figure 31 below. This is because of improved UL CE
resource usage.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 50 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 31. Activation of TBO and 16 kbps return channel (RAS06)
16 kbps Return channel DCH data rate support for HSDPA is RAS06 optional feature, which can
be activated by the operator with management parameter HSDPA16KBPSReturnChannel.
Minimum allowed bit rate for HSDPA UL return channel is set with parameter
HSDPAminAllowedBitrateUL. Limitation should be disabled with the parameter
BitRateSetPSNRT.
When 16 kbps is activated, the throughput based optimisation and flexible upgrade features can
be activated for HSDPA return channel with parameter DynUsageHSDPAReturnChannel (This
require that TBO or/and FU features are also activated in the network).
6.1.3 HSUPA Accessibility
HSUPA cannot be established without HSDPA, the UL return channel is HSUPA instead of R99.
The decision between DCH and E-DCH allocation for a UE is based on the service (RAB
parameters), resource availability, multi-RAB combination and UE capability. Parameter
EDCHQOSClasses defines whether certain traffic class and traffic handling priority is allowed to
use for HSUPA. HSUPA allocation is not possible if there is ongoing IFHO or ISHO
measurements, the final EDCH active set size is not acceptable, HSDPA mobility is disabled or
HS-DSCH allocation is not possible. If the allocation of HS-DSCH in downlink is not possible,
the PS tries to allocate the DCH in both UL and DL.
High level HSUPA KPI - RNC_913a can be used to monitor HSUPA accessibility from user point
of view. Low performing cells can be then ranked to more detail analysis
RNC_913a_HSUPA_Accessibli ty 
 ALLO_SUCCESS_EDCH_IN T + ALLO_SUCCESS_EDCH_BG R
ALLO_SUCCESS_EDCH_IN T + ALLO_SUCCESS_EDCH_BG R + EDCH_ALLO_CANC_NA_AS_BGR
 100%
+ EDCH_ALLO_CANC_NA_AS_INT  UL_DCH_SEL_M AX_HSUPA_USR_BGR
+ UL_DCH_SEL_M AX_HSUPA_USR_INT  UL_DCH_SEL_BTS_HW_INT + UL_DCH_SEL_BTS_HW_BGR 
 + SETUP_FAIL_EDCH_BTS_BGR + SETUP_FAIL_EDCH_BTS_INT  SETUP_FAIL_EDCH_OTHER_BGR
+ SETUP_FAIL_EDCH_OTHER_INT + SETUP_FAIL_EDCH_TRANS_BGR
 SETUP_FAIL_EDCH_TRANS_INT + SETUP_FAIL_EDCH_UE_BGR + S ETUP_FAIL_EDCH_UE_INT
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 51 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Equation 2 – RNC_913a HSUPA Accessibility from User point of view
HSUPA access is done in two phases, first HSUPA channel type has to be selected in channel
type selection procedure, if this procedure will not allow HSUPA channel type the HSUPA
selection failure counters are triggered. After HSUPA channel type is selected the actual
HSUPA radio bearer setup will take place and is this fails the HSUPA setup failures are
triggered. HSUPA selection and setup failures reasons are similar to HSDPA. HSUPA selection
can also fail if Active set size is not acceptable. Also, if HSDPA Mac-d flow setup is failing, for
example, due the too many simultaneous users, the HSUPA setup will also fail.
Low HSUPA
accessibility
N
o
No Action
Needed
Selection failures
Yes
Too many HSUPA
users reached
Yes
Check Number of simultaneous HSUPA users
(60/BTS in RU10, 74/cell and 80/BTS in RU20 )
Yes
Check BH Channel element resource usage UL/DL
(BTS in state that no capacity available for EDCH)
No
UL DCH selected
due BTS HW
No
HSUPA fail due
Not Acceptable
Active Set
No
Yes
HSUPA Setup Fail
BTS
Yes
HSUPA is not supported in SHO branch
Check BH Channel element resource usage UL/DL
Setup failures
No
HSUPA Setup Fail
UE
Yes
Check RB reconfiguration failure rate
(Terminal problem)
No
HSUPA Setup Fail
TRANS
Yes
Check AAL2 connections (not enough CID) or
Signalling problems
No
HSUPA Setup Fail
Other
Yes
Go for troubleshooting
( E.g. RNC internal failures)
Figure 32. HSUPA Accessibility failure analysis
Below are main KPIs needed for HSUPA accessibility analysis..
Table 15. Reports and PIs related HSUPA accessibility
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 52 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
RNC_923c
E-DCH selections
#
RNC_913a
HSUPA Resource Accessibility for NRT Traffic
%
RNC_928b
HSUPA attempts
#
RNC_915c
HSUPA Setup Success Ratio from user perspective
%
RNC_923c
E-DCH selections
#
Report: Service/Session Accessibility Analysis RSRAN073 (M1022, M1002)
RNC_1103b
E-DCH Allocation FR due to NA AS (E-DCH allocation cancel due to non
acceptable active set)
%
RNC_968b
UL DCH Selected due to too many HSUPA users
%
RNC_957c
E_DCH not selected due the BTS HW
%
RNC_956c
E-DCH Setup FR due to BTS
%
RNC_1105c
E-DCH Setup FR due to Transport
%
RNC_1106c
E-DCH Setup FR due to UE
%
RNC_1104c
E-DCH Setup FR due to Other Failures
%
Figure 33Figure 33Figure 33 presents example of HSUPA performance. No changes compared
to RU10.
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0
EP1
first cluster
RU20 MP2
Figure 33. Example of HSUPA performance (RU10/RU20).
Figure 34Figure 34Figure 34 shows an example of HSUPA setup failure causes. Most failures
are due to Other reason, but there is also some level of transport and BTS failures.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 53 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
RU10
RU20 MP1
RU20EP1
PP1.12
Date:
175.110.2010
Version 2.10
WN6.0 EP1
first cluster
RU20
MP2
Figure 34. Example of HSUPA setup failure causes (RAS06/RU10)
DCH is selected instead of EDCH if Maximum amount of HSUPA allocations is reached either in
cell or in BTS LCG. Maximum amount of HSUPA users are limited either with parameter or
license. In RAS06, the maximum value is defined with license ‘HSUPA, Basic 3/12/24 and
parameters MaxNumberofEDCHCell and MaxNumberEDCHLCG. In RU10, there is new BTS
parameter HSUPAXUsersEnabled which is used to reserve corresponding license from RNC
license pool (3/12/24/60) for BTS. RU20 72 HSPA users feature increase the number of HSUPA
users to 72 per cell (80/BTS) Parameters MaxNumberofEDCHCell and MaxNumberEDCHLCG
together with license define maximum number of E-DCH allocations in the cell and BTS LCG
respectively. Limitations are also valid for Soft and softer (cell only) HO branch additions. Cell
specific PS use a value which is lower than these two values (parameter or license). Parameter
NumberEDCHReservedSHOBranchAdditions (default=2) defines the number of E-DCH
allocations that are reserved only for soft and softer handover branch additions in the cell and
for soft handover branch additions in the BTS LCG. The Value of this parameter is subtracted
from both, the maximum number of E-DCH allocations in the cell and the maximum number of
E-DCH allocations in BTS LCG to achieve correspondingly the maximum number of new E-DCH
allocations in the cell and BTS LCG. The values of these parameters are checked only in EDCH allocation and E-DCH branch addition phases.
The HSUPA baseband processing requirements are symmetric across the UL and DL
directions. In RAS06, the minimum static allocation of 8 CE (for both UL and DL) is reserved as
soon as HSUPA is enabled at a WBTS. In RU10, this fixed reservation of 8 CE is removed (0
CE in RU10). With the exception of fixed reservation, the CE allocation for HSUPA is dynamic
and depending upon both the number of HSUPA connections and load generated by the DCH
traffic. In the CE allocation, DHC has a higher priority than HSUPA, DCH capacity request are
able to pre-empt the set of CE allocated to HSUPA (with the exception of the minimum static
allocation of 8 CE in RAS06). Each active E-DCH user requires channel element capacity. BTS
informs RNC that E-DCH users can be taken in when at least 32 channel elements (dynamic
reservation) are reserved for E-DCHs (18 CE in case of Flexi Rel2 HW). If there is not enough
CE for HSUPA, the HSUPA setup will fail. HSUPA resource steps and reservations are different
between HW releases (e.g. Flexi Rel1 HW and Flexi Rel2 HW).
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 54 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Additional free capacity of 6 CE is needed top of the HSUPA resource steps to avoid ‘ping-pong’
effect in reserving and freeing HSUPA resource steps. When free channel element capacity
drops below 4 CE, the resource Manager starts to free resources used by HSUPA
There seems to be also correlation between EDCH setup failures and Maximum CE usages. As
HSUPA CE resource reservation is symmetric, both UL and DL should be monitored.
200
12
180
10
160
8
120
100
6
FR %
# of CEs
140
80
4
60
40
2
20
0
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94
M50001C0_MAX_AVAILABLE_CE
M5001C3_Max_Used_CE_DL
M5001C4_Max_Used_CE_UL
RNC_957a_EDCH_NOT_SELECTED_due_BTS_HW
RNC_956a_EDCH_STP_FR_BTS
Figure 35. Relation between CE usage and HSUPA setup and selection failures
The 2ms HSUPA TTI is selected if enabled with parameter HSUPA2MSTTIEnabled , UE
supports 2 ms TTI and RAB combination supports SRB on HSUPA. There is defined the
coverage area when the HSUPA 2ms TTI can be used. When there is no possible to use
HSUPA 2 ms TTI then HSUPA TTI is reconfigured to 10 ms TTI. If selection is from Cell_DCH,
then it is controlled with parameter CPICHRSCPThreEDCH2MS (RNC), then CPICH RSCP of
current cell must satisfy equation below.
PtxPrimaryCPICH - CableLoss – Meas CPICH RSCP < CPICHRSCPThreEDCH2MS (136 dB) +
MAX(0, UETxPowerMaxRef - P_MAX)*. Default value of 136 dB means approximately RSCP
value of -114 dBm.
If the selection is from Cell_FACH, then it is controlled with parameter CPICHECNOThreEDCH
then CPICH Ec/Io of current cell must satisfy equation below
Meas CPICH Ec/Io > CPICHECNOThreEDCH2MS (-6 dB)
Currently there are no counters to monitor switching in between 2ms TTI and 10 ms TTI EDCH
reconfiguration.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 55 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
6.2 HSPA Throughput and RTT (incl. MIMO and DC)
Throughput cannot be guaranteed for PS NRT Interactive or Background class services
including HSPA. Most of the resources, like Air Interface and Iub, are shared between the users
causing performance degrading when amount of users in the cell increase. When monitoring
HSDPA throughput with the counters, it is important to monitor number of simultaneous HSPA
users as well. Throughput measurements together with other counters can be used identify
possible causes for low throughput. Following has impact to user and cell throughputs:








Radio Channel Conditions
UE category and types
Activated features
Shortage on Iub User plane or DCH traffic too high
Incorrect Iub Parameter settings
HSPA parameters and HSDPA power parameter settings
Problems in core network or application server.
Problems with drive test tools (QoS profile, TCP IP settings etc.)
RU10 optional feature, Streaming QoS for HSPA enables also the definition of Nominal Bit Rate
(NBR) for Interactive and Background NRT MAC-d flows. This Nominal bitrate is scheduled as
Guaranteed BitRate, but with lower priority. More details can be found in [14]‎[14][14]
6.2.1 HSDPA throughput Optimisation
Both Counter statistic and drive test logs can be used to detect HSDPA throughput problems.
Test of maximum HSDPA throughput and understanding of the required configuration is a
starting point for HSDPA feature performance tests and performance optimisation, although it
can be achieved only in nominal conditions commonly not available for users. These issues are
covered with chapter ‎6.2.1.1.
Counter statistics can be used to detect network wide problems and bottlenecks. Counters and
KPIs that can be used to monitor HSDPA throughput performance are listed in ‎6.2.1.2.
NOTE! HSPA+ features are supported with Rel2 BTS HW only
6.2.1.1 HSDPA peak performance and configurations
HSDPA bitrates depend upon the protocol stack layer from where they are measured. In
RAS06, the maximum RLC throughput is 9.6 Mbps for single users (Cat-9 UE). In RU10, one
Cat10 UE can achieve the maximum bit rate of 13.976Mbps ~14 Mbps (13.4) Mbps RLC
payload) and RU20 increase bit rate to 42 Mbps with DC-HSDPA feature. It is crucial to
understand which protocol layer throughput is referred, typically all drive test/field measurement
results are based on application level throughput. RU20 target for DL application level
throughput is ~ 19 Mbps with 64QAM, 23,6 Mbps with MIMO and ~35 Mbps with DC-HSDPA.
Table 16 below give TCP/IP payload of 18.2 Mbps for 64QAM user, which refers quite well FTP
application level throughput (with 10% HARQ retransmission). .
Features
16-QAM
Min. UE Category
Modulation
Number of HS-PDSCH codes
Cat-6
16-QAM
5
Copyright © Nokia Siemens Networks 2008
+ 10/15
+10 Mbps/
HSDPA
MIMO
DC-HSDPA
user
+14.4
Mbps/
user
code
Cat-8
16-QAM
10
64-QAM
(2 flows)
(2 flows)
Cat-9
16-QAM
15
Cat-10
16-QAM
15
Cat-14
64-QAM
15
Cat-16
16-QAM
30
Cat-24
64-QAM
30
Company confidential
Page 56 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Air interface bit rate (Mbps)
Max. transport block size (bits)
Max. transport channel (HSDSCH) bit rate (Mbps)
4.8
7168
3.58
9.6
13904
6.95
14.4
19891
9.95
14.4
27952
14.0
21.6
42192
21.1
28.8
55904
28.0
43.2
84384
42.2
RLC PDU (bits)
RLC blocks/TTI
RLC bit rate (Mbps)
RLC payload (Mbps)
RLC payload (Mbps) - 10%
HARQ retrans.
336
21
3.53
3.36
2.99
656
21
6.89
6.72
5.98
656
30
9.84
9.60
8.54
656
42
13.8
13.4
12.0
11216
3.76
21.1
21.0
18.7
1312
84
27.6
26.9
23.9
22432
7.51
42.1
42.1
37.4
TCP/IP payload (Mbps)
2.91
5.82
8.32
11.6
18.2
23.3
36.4
Table 16. Maximum user bit rates with different RAS features (RU20)
Error! Reference source not found.Figure 36Figure 36Figure 36 below show lab
measurement results for different category UEs for RU10 and RU20. Maximum achieved DL
application level throughput in RU10 is 11.5 Mbps. RU20 new features increase HSDPA
throughput to 18-19 Mbps with 64QAM, 23 Mbps with MIMO and 35 Mbps with HSDPA DC
feature. Flexible RLC feature was used with the HSDPA measurements. Novatel Ovation was
used for HSDPA Cat14 measurements. Norm UE was used up to Cat8. (NORM is Nokia
Reference Mobile which is R&D UE and capable of changing it’s category). Novatel Ovation
MC996d was used for HSDPA Cat18 (MIMO) measurements and Qualcomm 8220 used for
Cat24 (DC-HSDPA) measurements. Results are FTP throughputs, DC-HSDPA throughput was
verified with UDP.
Figure 36. Max Achieved HSDPA application level throughputs for different category UEs
The maximum achievable throughput has to be supported by the whole end-to-end connection,
all interfaces and protocol layers. This topic is handled in multiple references like “RAN E2E
system performance optimization guide” [12]‎[12][12], “HSPA Radio Network Planning Guide”
[1]‎[1][1] and section “Checking HSDPA settings in network elements” in RAS06 product
documentation [3]‎[3][3].
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 57 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
HSDPA parameters for high bit rate testing are listed below;
•
•
•
•
•
•
•
Parameter MaxBitRateNRTMACDFlow defines the maximum bit rate of NRT MAC-d flow.
Value of this parameter can be set according to activated license or directly use RU10
default special value 65535 no restriction for NRT MACD flow.
Parameter HSDPAPeakRateLimitRABMax defines the peak rate of MAC-d flow, peak
rate of NRT RB mapped to HS-DSCH and peak rate of UL return channel limited to RAB
attribute maximum bit rate received from RANAP or not. Easiest way to avoid the HLR
profile to limit the throughput is set this to 0 (not limit) because if limitation is active (by
default), the HSDPA DL peak rate maximum cannot be higher than the RAB maximum.
o RU10 default value 1 (Limitation is active)
RU20 new features require that Flexible RLC is enabled with FlexiRLC parameter
Parameter PDUSize656WithHSDSCH enables the use of PDU size 656
The maximum bit rate of the NRT RB has to be equal to or higher than the threshold
defined with parameter PDUSizeBitRateThr before the PDU size 656 bits can be
selected
o Use default 3584 to use PDU size 656
Parameter PDUSizeCodeThreshold defines number of codes required to use PDU size
656 bits
o Change this from default 10 to 5 to use 656 always for maximum throughput
Parameter PDUSizeSIRThr defines the HS-DSCH signal to interference ratio threshold
for the usage of RLC PDU size 656 bits in DL data transfer if the RB is mapped to HSDSCH in the DL. HS-DSCH SIR has to be equal to or higher than the threshold before
RLC PDU size 656 bits can be selected
o By default (RU10) this is - 9 dB – this can set to “off”
When troubleshooting HSDPA user throughput, following should be checked:
CQI – Maximum performance can be reach on with high CQI values. Reported CQI can be used
to estimate what kind of bit rates are possible but CQI reported by the UE is different that
compensated CQI. BTS is using compensated CQI to selected Transport block side (TBS).
Compensated CQI value of 32 is required to reach maximum 64QAM performance.
Modulation – RU20 supports QPSK, 16QAM and 64QAM modulations for HSDPA. MIMO
supports only 16QMA modulation. UE support is required in both cases.
TBS & Retransmission – Check Transport block size (TBS) during transmission and
retransmission rate. High retransmission rate can decrease the throughput even when TBS is
high. Typical retransmission rate 10%, in very good conditions can be less than 10%. See
example in Figure 39. which shows TBS and retransmission rate for two different test cases
HS-SCCH Usage- Monitor HS-SCCH usage (HSDPA activity/utilisation) as low usage indicate
bottleneck in some part of the network like TCP limitations (client or/and server), or limitations in
Iub / core networks.
Number of codes allocated for HSDPA – With HSUPA enabled, 15 is possible for HSDPA
only if MaxNbrOfHSSCCHCodes is 1 or 2. (MaxNbrOfHSSCCHCodes is the parameter to
enable code multiplexing). HSPA 72 users feature change HS-SSCH code allocation to
dynamic. Maximum number of HS-SCCH codes increase from 3 to 4, and it is possible to have
15 codes for HSDPA even when MaxNbrOfHSSCCHCodes =3/4 and HSUPA enabled.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 58 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 37. Example of HSDPA link adaption parameters.
Figure 38 below show HSDPA 64QAM throughput results for both lab (Vepro) and the field
(Ahvenatie). In the lab, the average DL application (FTP) throughput ~19 Mbps while in the field
~17 Mbps was reached. Field test case is also measured in good radio conditions (RSCP 50dBm), but as can be seen in Figure 39, there is differences in retransmission rate. While in
the field, the retransmission rate is close to 10%, in the lab retransmission rate is below 2%
which have clear impact for the throughput. (Both get high TBS)
Figure 38. 64QAM throughput measured in the lab and in the field. ( 5 x 100M file downloads)
In both cases, the same TBS was reached, but in case of field, the retransmission rate was
close to 10% while in lab it was only 2%. This explains the throughput difference between the
cases.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 59 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 39. HSDPA 64QAM result showing TBS and retransmission rate. Vepro is measured in the
lab and Ahvenatie case is measured in the field. (5x100M file downloads)
64QAM is used only in good RF environments. Figure 40 below show RSCP vs. DL application
throughput result from 64QAM and 16QAM drive test comparison (test done under empty,
isolated cell). In cell edge, the 16QAM modulation is used in both cases, usage of 64QAM
modulation start to increase when RSCP increase above -80 dBm.
64QAM and 16QAM drive - DL App tp. vs. RSCP
21
19
17
DL app tp.
15
64QAM_20_drive
16QAM_20_drive
13
Poly. (64QAM_20_drive)
Poly. (16QAM_20_drive)
11
9
7
5
-110
-100
-90
-80
-70
-60
-50
RSCP
Figure 40. RSCP vs. DL application throughput, drive test Comparison of 16QAM and 64QAM Test is done in NSN test network under isolated cell without any other traffic to ensure that
conditions remains unchanged between testing.
Figure 41 below show result from DC-HSDPA, MIMO and 64QAM comparison measurements
done in NSN test network. In good RF environment, the DC HSDPA (ave. 27.7 M) show clear
gain against MIMO (Ave. 18.7M) and 64QAM (Ave. 15M). Measurement done in the field, under
empty, isolated cell with both MIMO and DC-HSDPA enabled.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 60 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
DCHSDPA, MIMO, 64QAM - DL application throuhgput in stationary location
35
DL app tp (Mbps)
30
25
DC HSDPA
20
MIMO
15
64QAM
10
5
0
1
10 19 28 37
46 55 64 73 82 91 100 109 118 127 136 145 154 163 172 181
Figure 41. Comparison of DC-HSDPA, MIMO and 64QAM DL application level throughputs in the
field (RSCP around -60 dBm in measurement location)
UE category and type: Performance between the UE types can vary. In RU20 maximum
64QAM user throughput can be achieved with Cat14 and Cat18 HSDPA UEs, MIMO maximum
throughput can be achieved with Cat 18 UE. Category 22 or 24 is required to support maximum
DC HSDPA throughput in RU20 on top. Currently there are no commercial available terminals
supporting DC HSDPA (9/2010).
Laptop & Server Settings:
Client Settings: Use Clean, high-spec laptop instead of NSN build laptop with TCP receive
window size >=256kB (unnecessarily high values should be avoided). Never set TCP values
manually by modifying registers (same parameter can be in the several places), use ready made
tools like TCP optimiser to change values. Conform e.g. by using Wireshark (Ethereal) that
change is done.
RNC Capacity
RNC HW capacity can also limit throughput. DMCU upgrade is needed in RNC196 and RNC450
to support new RU20 user bitrates. Old CDSP-C cards need to be replaces with CDSP-HD
cards.
Iub Capacity: High enough Iub capacity ensures that throughput is not limited by Iub. Iub
Capacity can be checked from the COCO. For example, used user plane size of 40000 cps
equals to 16.96Mbps. Iub capacity calculations per feature can be found:
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/404366147
Core Networks:
Flexi ISN GGSN should be used as old GGSN HW is not valid for maximum throughput.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 61 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
6.2.1.2 HSDPA throughput Monitoring and troubleshooting
HSDPA selections (RNC_614c) together with HSDPA data volume (RNC_608b) can be used to
monitor possible capacity bottlenecks.
 ALLO_HS_DSCH_FLOW_INT  ALLO_HS_DSCH_FLOW_BGR  ALLO_HS_DSCH_FLOW_STR



  DCH_SEL_MAX_HSDPA_USERS_INT  DCH_SEL_MAX_HSDPA_USERS_BGR  DCH_SEL_MAX_HSDPA_USERS_STR 
  REJ_HS_DSC H_RET_INT  REJ_HS_DSC H_RET_BGR  REJ_HS_DSC H_RET_STR  SETUP_FAIL_RNC_HS_DSCH_INT 


  SETUP_FAIL_UE_HS_DSC H_INT  SETUP_FAIL_BTS_HS_DSCH_INT  SETUP_FAIL_IUB_HS_TOTAL_INT

RNC _ 614c  

  SETUP_FAIL_RNC_HS_DSCH_BGR  SETUP_FAIL_UE_HS_DSC H_BGR  SETUP_FAIL_BTS_HS_DSCH_BGR

  SETUP_FAIL_IUB_HS_TOTAL_BGR  SETUP_FAIL_RNC_HS_DSCH_STR  SETUP_FAIL_IUB_HS_TOTAL_STR



  SETUP_FAIL_UE_HS_DSC H_STR  SETUP_FAIL_BTS_HS_DSCH_STR  DL_DCH_SEL_HSDPA_POWER_STR

  DL_DCH_SEL_HSDPA_POWER_INT  DL_DCH_SEL_HSDPA_POWER_BGR



Equation 3 - RNC_614c HSDPA Selections (RU10)
Normally, as can be seen from picture below, the HSDPA selections and data volume increase
with same linearity I.e. similar way. If this is not the case, e.g. HSDPA selections increase but
data volume remains constant, it indicates that possible capacity bottleneck exist somewhere.
10000000
1600000
HSDPA data volume (MAC-d) at Iub/RNC_608A
HS-DSCH selections/RNC_614A
9000000
1400000
8000000
1200000
1000000
Mbits
6000000
5000000
800000
4000000
600000
HS-DSCH Selection
7000000
3000000
400000
2000000
200000
1000000
07
07
13
/0
3/
20
07
03
/0
3/
20
07
21
/0
2/
20
07
11
/0
2/
20
07
01
/0
2/
20
07
22
/0
1/
20
07
12
/0
1/
20
06
02
/0
1/
20
06
23
/1
2/
20
06
13
/1
2/
20
06
03
/1
2/
20
06
23
/1
1/
20
06
13
/1
1/
20
06
1/
20
03
/1
0/
20
24
/1
0/
20
/1
14
04
/1
0/
20
06
0
06
0
Figure 424243. Throughput per allocated HS-DSCH [8]‎[8][8]
Low HSDPA throughput could be a reason from several issues, not only due to radio channel
conditions (lack of DL power or low CQI). For example it could be related to return channel,
which can be limited due to UL interface, Iub or BTS Channel Elements. Also incorrect
parameter settings (Iub/Radio), activated features and used server settings can cause
throughput to be lower than expected. Throughput can also be limited due the drive test tools (if
used) E.g. not optimised TC IP settings in laptop/server side or low power laptop.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 62 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
HSDPA Throughput Limiting Factor
Analysis
Date:
175.110.2010
Version 2.10
Air interface support from CQI distribution
A
HSDPA UL Return channel limitation (UL
Interference)
HSDPA Throughput Available from Iub
HSDPA UL Return channel limitation (Iub)
BTS Power Availability for HSDPA
Cell Channelisation code Availability for HSDPA
BTS scheduler limitation (#simultaneous users per
scheduler)
HSDPA UL Return channel limitation (CE)
RNC limiting factors: DSP, #simultaneous HSDPA
users and throughput (RNC HW?)
Iu-PS capacity available or HSDPA
IP Back Bone / PS CN
Figure 434344. General flow chart to analyse HSDPA throughput [8]‎[8][8]
Table 17Table 17Table 17 lists the relevant reports and PIs for HSDPA RB throughput
monitoring and troubleshooting.
Table 17. HSDPA traffic and throughput KPIs and counters
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000
RNC_930b
Packet Session Attempts
#
RNC_614c
HS-DSCH selections
#
RNC_926b
HSDPA attempts
#
RNC_608b
HSDPA received data
Mbit
RNC_722b
Active HS-DSCH MAC-d throughput, network perspective
Kbps
RNC_1879b
Average HSDPA end user throughput
kbps
RNC_5043a
HSDPA MAC-d data volume at RNC (added to RU10 system program)
Mbps
RNC_721c
Average MAC-d flow throughput (added to RU10 system program)
Kbps
Report: Cell Data Volume and Throughput at RNC RSRAN077 (M1023)
M1023C8
HS_DSCH_DATA_VOL
Byte
RNC_941a
HSDPA MAC-d average throughput at RNC
Kbps
M1023C9
NRT_DCH_HSDPA_UL_DATA_VOL
Byte
RNC_1175a
HSDPA UL Return Channel Throughput (DCH)
Kbps
Report: Allocated Traffic Amounts (R99 + HSPA) RSRAN070 (M1002, M5000)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 63 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RNC_683b
HSDPA MAC-d flow allocations
#
RNC_684c
HSDPA MAC-d flow allocation duration
Min
RNC_721c
Average MAC-d flow throughput
Mbps
RNC_722c
Active HS-DSCH MAC-d throughput, network perspective
Mbps
RNC_606d
HSDPA MAC-d average net throughput at BTS
Mbps
RNC_941a
HSDPA MAC-d average throughput at RNC
Kbps
RNC_608b
HSDPA received data
Mbit
RNC_686d
HS-DSCH return channel allocations, total
Kbps
RNC_1027b
HS-DSCH return channel allocations, 16kbit/s
Kbps
RNC_687c
HS-DSCH return channel allocations, 64kbit/s
Kbps
RNC_688c
HS-DSCH return channel allocations, 128kbit/s
Kbps
RNC_689b
HS-DSCH return channel allocations, 384kbit/s
Kbps
Report: Number of HSPA Users and UE capability RSRAN051 (M1000, M1001)
RNC_645c
Average number of simultaneous HSDPA users
#
RNC_726e
Average number of simultaneous HSDPA users, during HSDPA usage
#
RNC_2054a
Average Scheduled HSDPA users per TTI
#
Report: HSPA Overview RSRAN092
RNC_706b
Average Reported CQI
#
RNC_626b
Active HSDPA time share
%
RNC_685a
HS-DSCH utilization
ATM Iub Throughputs RSRAN080, Iub capacity RSRAN087, RNC capacity RSRAN068, Iu-PS
Throughputs RSRAN064
RNC_950b
ATM interface based average throughput for outgoing traffic (RNC side)
(RSRAN080)
Mbps
RNC_732b
HSDPA ATM VCC traffic load Iub downlink (RSRAN087)
Cps
RNC_986a
PS Data in DL (RSRAN068)
Mbps
RNC_753a
Average ATM VCC egress throughput (RSRAN087)
Cps
Iu-PS Throughputs RSRAN064
RNC_934a
Iu-PS incoming interactive user data throughput in RNC (RSRAN064)
Kbps
RNC_935a
Iu-PS incoming background user data throughput in RNC (RSRAN064)
Kbps
RNC_912a
Iu-PS GTP input traffic rate in RNC (RSRAN064)
Kbps
Radio Connection Performance Measurement M1017 based
RNC_613b
Average NRT HS-DSCH DL Throughput
Mbps
For HSDPA, it is possible to monitor both cell and user level throughput. For the cell throughput
different PIs are available. Figure 44Figure 44Figure 45 shows an example of HSDPA
throughput measurement from multiple throughput PIs (RNC_722c, RNC_606d, RNC_914a and
RNC_613b)) and drive test log. Throughput measured from drive test log is application level
throughput. It mainly shows that the active throughput PI RNC_722c shows quite close the
measured average throughput from drive test tool. The other PIs measure the average
throughput and they show that equal values can be achieved from different measurements (Cell
throughput M1023, BTS M5000 and RCPM M1017). This gives the freedom to choose the PI
based on the available measurements.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 64 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure 444445. HSDPA throughput measurement from BTS and drive test log.
RNC_1455a HSDSCH Cell throughput PI is based on M5002 measurements (RU10 new) and
includes both new and retransmitted MAC-hs PDUs.
RU10 introduce new RCPM RLC measurement tables including same counters as existing
RCPM RLC M1017 measurement table, but results are pre-aggregated either to RNC (M1027)
or Cell (M1026) level. For RNC level, the object includes TC, THP, RAB max bit rate and RB bit
rate. Figure 45Figure 45Figure 46 shows RLC active bit rate separately for interactive and
background traffic classes per RAB max bit rate. Activation of M1027 measurement table
generates less load than activation of existing M1017 counters.
Max/Ave RLC bit rate over hour of day
3000
512
0
0
384
4090
2723
990
799
447
2048
0
830
1045
1463
1220
918
457
457
1024
146
500
489
534
1000
747
815
884
1500
1661
2000
421
385
187
199
RLC active bit rate, kbps
2500
5120
RAB Max bit rate, kbps
Max INT- 2
Max BGR
Ave INT- 2
Ave BGR
Figure 454546 Example of throughput measurements included to M1027
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 65 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Low HSDPA throughput analysis can start by calculating rough HSDPA User Throughput.
Average Active HSDPA throughput can be monitored with the RNC_722c which calculates the
actual HSDPA throughput on cell level. Simplest way to calculate throughput per HSDPA user is
to divide RNC_722c average active HSDPA throughput with Average number of HSDPA users
(Either with RNC_645c or RNC_726d).
Other way of calculating is to adjust Average number of simultaneous HSDPA users by the real
activity of those users i.e. TTI utilization (RNC_685a). Average HSDPA throughput per session
can be calculated by using KPI RNC_1879a. When very low amount of HSDPA users or/and low
utilization, this KPI give value close to RNC_722c.
RNC _ 1879a 
RNC _ 722c
Max( RNC _ 726d * RNC _ 685b,1)
Equation 4 – RNC_1879a Average HSDPA throughput per session
RNC_1879b is new end user throughput formula included RU20 system program report, where
denominator includes those users having data in the buffer multiplied by Average number of
users per scheduler per TTI formula.
RNC _ 1879b 
(RECEIVED_ HS_MACD_BITS - DISCARDED_HS_MACD_BITS) * 500
HSDPA_BUFF_WITH_DATA_PER_TTI * RNC _ 2054a)
Equation 5. RNC_1879b Average HSDPA end user throughput
Average Number of HSDPA users KPIs (RNC_726d), included to previous version of the KPI
(RNC_1979a) also counts those users not necessary having any data in the buffer. KPI below
can be used instead to count number of users having data in the buffer
(HSDPA_BUFF_WITH_DATA_PER TTI counter is counting number of user buffers with data in
the buffer for each TTI).
HSDPA_BUFF_WITH_DATA_PER_TTI
( HS_SCCH_PWR_DIST_CLASS_0  HS_SCCH_PWR_DIST_CLASS_1
HS_SCCH_PWR_DIST_CLASS_2  HS_SCCH_PWR_DIST_CLASS_3 
HS_SCCH_PWR_DIST_CLASS_4  HS_SCCH_PWR_DIST_CLASS_5 )
Equation 6. Number users with data in buffer
Number _ of _ user _ buffers 
Below is one example from number of users in the buffer compared with other KPIs. It can be
seen that the average number of buffers with data is about 1.5. Priorisation is done in HSDPA
scheduler between buffers with data, formula sow HSDPA_BUFF_WITH_DATA_PER_TTI / # of
active TTIs.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 66 (123)
Number of buffers, buffers/user
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
3.50
14
3.00
12
2.50
10
2.00
8
1.50
6
1.00
4
0.50
2
0.00
Number of users
NPO/NSO Capability Management
0
1
11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161 171 181 191 201 211 221 231 241 251 261 271 281 291 301 311 321 331
Hours
Average number of simultaneous HSDPA users, during HSDPA usage
Buffers with data
Buffers/user
Figure 464647. Buffers with data Example (RNC_726b_number of HSDPA users per cell)
Figure 47. Example of RNC_1879b HSDPA end used throughput formula vs. average active cell
throughput RNC_722b
Figure 48. Example of RNC_1879b HSDPA end used throughput formula vs. average active cell
throughput RNC_722b
Reported CQI vs. Compensated CQI
Reported CQI is the value Reported by the UE, and this is the CQI that can be captured from
the drive test logs and CQI distribution counters (M5000). Legacy UEs are reporting CQI values
from 0-30 when MIMO UEs are reporting both CQI type A (from 0-14) and type B (from 0-30).
Reported CQI values can be used to estimate what kind of bitrates are available in air interface,
but BTS decides transport block size based on compensated CQI not based on reported CQI.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 67 (123)
Formatted: Caption
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
BTS link adaption compensates CQI for the differences between assumed HS-PDSCH transmit
power and actual available HS-PDSCH transmits power by targeting 10% HARQ retransmission
rate. Compensated CQI report values from 1-35. It is not possible to capture compensated CQI
values from the drive test logs and counter stats. Internal tool called DSP browser can be used
to collect compensated CQI values directly from the BTS if needed.
The difference between reported and Compensated CQI depends on channel quality and bit
rate. Figure 48Figure 48Figure 49 show theoretical difference between compensated CQI (from
LA table) and Reported CQI (from CQI mapping table)
25
MAC-d flow throughput, Mbps
Modulation for
Cat 13-18
64-QAM
16-QAM
QPSK
20
15
Compensated CQI
10
5
Reported CQI
35
33
31
29
27
25
23
21
19
17
15
13
11
9
7
5
3
1
0
CQI
Cat-10 (Com)
Cat-14,18 (Com)
Cat 13, 17, 19, 23 (Rep)
Cat-13, 17 (Com)
Cat 10 (Rep)
Cat 14, 18, 20, 24 (Rep)
Figure 484849. Example of differences between the Compensated CQI and Reported CQI
In RAS06, the Compensated CQI has been seen to be 2-3 dB better than reported CQI as
power offset makes reported CQI looks worse than it is in practice. Also there are some
differences between terminals related to reported CQI values. Low throughput but high
CQI/EcNo typically indicates that there is some other bottleneck in the network which limits the
throughput. By using reported CQI counters it is possible to estimate what kind of bitrates are
possible in air interface. CQI distribution counters (M5000) or Average CQI (RNC_706a) can be
translated into throughput with CQI throughput mapping.
CQI report from live
network per cell
Scale CQI value up by
2-3 dB
Estimate the throughput
using tp. mapping table
Figure 494950 – Air Interface bitrate estimation using reported CQI
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 68 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Measurement power offset,  is the default power offset between HS-PDSCH and P-CPICH.
Measurement power offset is signaled to the UE when HS-DSCH MAC-d flow is set-up or if
updating is needed due to serving HS-DSCH cell change. MPO is calculate as below
  Ptx _ allowed _ HSDPA  PCPICH
where Ptx_allowed_HSDPA is calculated as follows


Ptx _ allowed_ HSDPA  MAX MIN PtxMaxHSDPA, Pmax  Ptx _ non_ HSPA  * GammaFactor,0
where:




Pmax is the cell maximum output power
Ptx_non_HSPA is the latest received PtxNonHSPA measurement.
The PtxMaxHSDPA parameter defines the maximum allowed HSDPA tx power.
GammaFactor is RNC-internal (hidden) parameter which has an actual value of 0.5.
Based on formulas above, half of the available HSDPA power is signalled to UE. CQI value
reported by UE is then 3 less than it should be based on actual available power However, this
impact only reported CQI values and has no negative impact to final performance as BTS
make decision (about TBS) based on compensated CQI (by knowing how much power there is
actually available for HSDPA)
Table 18 below show MPO calculation for different BTS & CPICH power combinations, which is
matching for the value extracted from the drive test tool (Nemo Outdoor). Nemo Outdoor MPO
Values are from drive test done under isolated cell, without any other traffic.
PtxCellMax
43
40
PtxCPICH
33
30
33
CCCH total
35.5
32.5
35.5
Available HSDPA pwr (W)
16.4
8.2
6.5
Gammafactor
0.5
0.5
0.5
Ptx_Allowed HSDPA (W)
8.2
4.1
3.2
MPO, dB (calculated)
6.1
6.1
2.1
6
6
2
MPO from Nemo
40
Table 18. Mobile Power Offset Calculation (MPO) for different Cell power setting – PtxMaxHSDPA
is set to same value as PtxCellMax
Reported CQI is not absolute measure of channel quality as CQI compensation will tune the
HSDPA bit rate according to actual channel conditions and available power. Reported CQI can
be improved by optimization on DL FR quality and level (RF optimization) only, Reported CQI
can not be improved by direct parameter changes in NSN RAN.
Figure 50Figure 50Figure 51 below show average CQI vs. TBS with different CPICH tx Powers.
Measurements done under isolated cell by repeating same route with different CPICH tx power
values of 30 dBm and 33 dBm. No changes for other parameters (e.g. PtxCellMax was same in
both cases). While decreasing CPICH tx power by 3 dB (from 33 dBm to 30 dBm), Average
reported EcNo decrease ~ 2.5 - 3 dB but average reported CQI increase only ~ 1. With CPICH
30, throughput is slightly higher as there is more power available for HSDPA
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 69 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RSCP
EcNo
Average CQI
Ave TBS size
CPICH 30
-80.2
-11.05
24.35
22358
CPICH 33
-77.8
-8.5
23
20972.5
Table 19. HSDPA performance comparison with different CPICH Tx Power values.
MPO
6
2
Figure 505051. Average CQI vs. TBS with different CPICH Tx Powers from drive test logs.
In RU10, BTS link adaptation reduces HS-PDSCH power for low data rate users and users who
are in good radio conditions to value needed to reach the target BLER (10%). In RAS06 all
available power was used for HS-PDSCH transmissions, maximising the single user throughput
(BLER could be even ~0%). Due to spectral efficient link adaption, RU10 shows slightly
increased CQI values as Interference to own and neighbour cells is decreased due to the less
power used for HSDPA. However, impact is not very big as can be seen from Figure 51Figure
51Figure 52 below, average RNC level CQI increase 0.3-0.4 after upgrade to RU10.
CQI Average RNC FI11
20.4
20.3
20.2
RU10
20.1
CQI Av
20
19.9
19.8
19.7
11
/0
3
09
/0
3
00
:0
0.
.2
4:
00
00
:0
14
0.
.2
/0
4:
3
00
00
:0
16
0.
.
/0
24
R
3
:0
U
00
0
10
:0
18
0.
.2
/0
4:
3
00
00
:0
20
C
0.
or
.2
/0
re
4:
3
ct
00
00
io
:0
n
22
0.
an
.
/
2
0
d
4:
3
Ba
00
00
ck
:0
0
24
.
.
24
/0
3
:0
00
0
:
0
26
0.
/0
.2
3
4:
00
00
:0
28
0.
.
/0
24
3
:0
00
0
:0
30
0.
.2
/0
4:
3
00
00
:0
0.
.2
4:
00
19.6
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 70 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure 515152. CQI comparison between RAS06 and RU10
Example blow show HSDPA cell throughput vs. average CQI. It can be seen that even if there is
7.2 Mbps or more possible to have from the cell, the average throughput is about 2 Mbps
Average CQI vs. HSDPA Cell Throughput, week48
30
25
Average CQI
20
15
Avg reported CQI
Every BTS is one
point in this graph.
10
5
0
0
500
1000
1500
2000
2500
3000
3500
4000
4500
HSDPA Cell Throughput [kbps]
Figure 525253. The relation of Average reported CQI vs. HSDPA cell throughput in live network
(RU10)
Below is one example of Average CQI vs. HSDPA user Throughput (RNC_1879b). which show
that average CQI limits also the throughput per user capability.
Avg thp per session vs. CQI
30
25
CQI
20
15
10
5
0
0.0
0.5
1.0
1.5
Copyright © Nokia Siemens Networks 2008
2.0
2.5
tp (Mbps)
3.0
Company confidential
3.5
4.0
4.5
5.0
Page 71 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 535354. The relation of Average reported CQI and HSDPA User throughput in live network.
Modulation and code multiplexing
In RU20, QPSK, 16QAM and 64QAM modulations are supported. However, MIMO supports
only 16QAM. Switching between the modulations happens as example below where channel
conditions improve from being poor according to link adaption.



The Number of codes are increased while using QPSK – if all available codes are used
then the coding rate is increased, i.e. TBS is increased while continue to use QPSK with
all available codes.
If coding rates becomes too high then the modulation scheme is switched from QPSK to
16QAM (decreasing the coding rate by increasing the physical channel capacity). The
TBS is then futher increased while using 16QAM with all available codes.
If coding rate becomes to high then the modulation scheme is switched from 16QAM to
64QAM and then the TBS is further increased while using 64QAM with all available
codes.
Figure 55Figure 55Figure 56 and Figure 54Figure 54Figure 55 shows HSDPA behaviour with 5
code and 10 code features when FTP Download is performed. The Average number of codes
remains high even with low RSCP value. With 10 codes, the modulation is switched from
16QAM to QPSK prior to decreasing number of codes. With 5 codes, the 16QAM modulation
can be maintained longer than with 10 code feature. Number of codes is maximised by the link
adaptation algorithm for maximum spectral efficiency.
Figure 545455. Number of codes and used modulation when RSCP drops – HSDPA 5 code feature
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 72 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 555556. Number of codes and used modulation when RSCP drops – HSDPA 10 Code
feature
In RAS06, HSDPA codes are always evenly divided between the users when code multiplexing
between the users in same TTI is performed. In RU10, the HS-PDSCH codes and power
resources are shared between code multiplexed MAC-d flows based on channel conditions and
amount of data in the buffer. This will give possibility to allocate codes unevenly between the
users, more codes to high data rate users and less code for those users who have low amount
of data in the buffer. This will increase usage of small 16QAM code users, as can be seen from
Figure 56Figure 56Figure 57
code 16QAM
8000000
7000000
6000000
5000000
M5000C54_ORIG_TRANS_1_CODE_16QAM
M5000C55_ORIG_TRANS_2_CODE_16QAM
M5000C56_ORIG_TRANS_3_CODE_16QAM
M5000C57_ORIG_TRANS_4_CODE_16QAM
4000000
3000000
RU10
2000000
PCD2.0
08/04 00:00..24:00
07/04 00:00..24:00
06/04 00:00..24:00
05/04 00:00..24:00
04/04 00:00..24:00
03/04 00:00..24:00
02/04 00:00..24:00
01/04 00:00..24:00
30/03 00:00..24:00
29/03 00:00..24:00
28/03 00:00..24:00
27/03 00:00..24:00
26/03 00:00..24:00
25/03 00:00..24:00
23/03 00:00..24:00
22/03 00:00..24:00
Correction and Back 24/03 00:00..24:00
21/03 00:00..24:00
20/03 00:00..24:00
19/03 00:00..24:00
17/03 00:00..24:00
16/03 00:00..24:00
RU10 18/03 00:00..24:00
15/03 00:00..24:00
14/03 00:00..24:00
13/03 00:00..24:00
11/03 00:00..24:00
10/03 00:00..24:00
09/03 00:00..24:00
08/03 00:00..24:00
07/03 00:00..24:00
06/03 00:00..24:00
05/03 00:00..24:00
04/03 00:00..24:00
03/03 00:00..24:00
02/03 00:00..24:00
01/03 00:00..24:00
0
28/02 00:00..24:00
1000000
Figure 565657. New usage of 16QAM codes transmission in RU10 due the unevenly distributed
codes between the users.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 73 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Number of HS-SCCH channels increase from 3 to 4 in RU20 with Rel2 HW. This also increase
the number of scheduled users per TTI to 9. The Spectral Efficient Link Adaptation can Increase
the number of scheduled users per TTI if their combined throughput is low enough. In case of
shared scheduler for BB efficiency, up to 9 UEs can be served in one TTI (max 4 UEs per cell)
with Flexi Rel2 HW while up to 6 UEs per TTI can be served by scheduler based on WSPC/Flexi
System module Rel1 HW.
BTS scheduling algorithm maximised always the cell throughput. If Better throughput is
achieved by scheduling only 3 users per TTI then no more users are scheduled in that TTI.
Typically throughput in code multiplexing case (several users per TTI) is anyway limited for other
reasons (low data amount in buffer, low CQI etc.) and more users per TTI can be scheduled
without decreasing the achievable throughput. When many low data rate users, the number of
scheduled users can be increased as function of total throughput. If throughput with n user is
under possible throughput with n+1, one user is added into scheduling on that TTI. Throughput
will not be reduced to get more users. For example, if there are 4 users on scheduling (Rel1
HW) but they have throughput together only 4 Mbps. Then MAC-hs takes 5th user into
scheduling.
Max throughput that can be sent by Shared HSDPA Scheduler for BB efficiency in One TTI
Scheduled users per TTI
1 scheduled UE's per TTI
2 scheduled UE's per TTI
3 scheduled UE's per TTI
4 scheduled UE's per TTI
5 scheduled UE's per TTI
6 scheduled UE's per TTI
7 scheduled UE's per TTI
8 scheduled UE's per TTI
WSPC/FSMB
WSPF / FSMC/D/E
RU20
10.8 Mbps
21.1 Mbps
7.2 Mbps
5.4 Mbps
3.6 Mbps
n/a
n/a
n/a
14.4 Mbps
14.4 Mbps
10.8 Mbps
7.2 Mbps
5.4 Mbps
3.6 Mbps
WSPF / FSMC/D/E
RU20 On top
21.1 Mbps
42.2 Mbps
21.1 Mbps
21.1 Mbps
21.1 Mbps
14.4 Mbps
14.4 Mbps
10.8 Mbps
7.2 Mbps
9 scheduled UE's per TTI
Table 20. Maximum throughput that can be sent by shared HSDPA scheduler for BB efficiency in
one TTI. (This table does not include MIMO or DC HSDPA users)
BTS scheduling efficiency can be monitored HSDPA_users_x_y_cells counters (= x users in
target cell, y users in other cell), which are collection measurement data of simultaneous code
multiplexed HSDPA users in TTI level. Average Number of users per TTI can be monitored
using RNC_2054a below; all cells under same HSDPA Scheduler should show same value for
this KPI. This formula is also included to denominator when calculating HSDPA user throughput
(RNC_1879b)
RNC_2054a ((HSDPA_USERS_0_1_IN_CELLS HSDPA_USERS_1_0_IN_CELLS) 
2* (HSDPA_USERS_0_2_IN_CELLS  HSDPA_USERS_1_1_IN_CELLS  HSDPA_USERS_2_0_IN_CELLS) 
3 *(HSDPA_USERS_0_3_IN_CELLS HSDPA_USERS_1_2_IN_CELLS  HSDPA_USERS_2_1_IN_CELLS  HSDPA_USERS_3_0_IN_CELLS) 
4* (HSDPA_USERS_0_4_IN_CELLS  HSDPA_USERS_1_3_IN_CELLS  HSDPA_USERS_2_2_IN_CELLS  HSDPA_USERS_3_1_IN_CELLS  HSDPA_USERS_4_0_IN_CELLS) 
5* (HSDPA_USERS_0_5_IN_CELLS  HSDPA_USERS_1_4_IN_CELLS  HSDPA_USERS_2_3_IN_CELLS  HSDPA_USERS_3_2_IN_CELLS  HSDPA_USERS_4_1_IN_CELLS) 
6* (HSDPA_USERS_0_6_IN_CELLS  HSDPA_USERS_1_5_IN_CELLS  HSDPA_USERS_2_4_IN_CELLS  HSDPA_USERS_3_3_IN_CELLS  HSDPA_USERS_4_2_IN_CELLS) 
7* (HSDPA_USERS_0_7_IN_CELLS  HSDPA_USERS_1_6_IN_CELLS  HSDPA_USERS_2_5_IN_CELLS  HSDPA_USERS_3_4_IN_CELLS  HSDPA_USERS_4_3_IN_CELLS) 
8* (HSDPA_USERS_0_8_IN_CELLS  HSDPA_USERS_1_7_IN_CELLS  HSDPA_USERS_2_6_IN_CELLS  HSDPA_USERS_3_5_IN_CELLS  HSDPA_USERS_4_4_IN_CELLS) 
9*( HSDPA_USERS_1_8_IN_CELLS  HSDPA_USERS_2_7_IN_CELLS  HSDPA_USERS_3_6_IN_CELLS  HSDPA_USERS_4_5_IN_CELLS )
HSDPA_USERS_0_1_IN_CELLS + HSDPA_USERS_1_0_IN_CELLS + HSDPA_USERS_0_2_IN_CELLS + HSDPA_USERS_1_1_IN_CELLS +
HSDPA_USERS_2_0_IN_CELLS + HSDPA_USERS_0_3_IN_CELLS + HSDPA_USERS_1_2_IN_CELLS + HSDPA_USERS_2_1_IN_CELLS +
HSDPA_USERS_3_0_IN_CELLS + HSDPA_USERS_0_4_IN_CELLS + HSDPA_USERS_1_3_IN_CELLS + HSDPA_USERS_2_2_IN_CELLS +
HSDPA_USERS_3_1_IN_CELLS + HSDPA_USERS_4_0_IN_CELLS + HSDPA_USERS_0_5_IN_CELLS + HSDPA_USERS_1_4_IN_CELLS +
HSDPA_USERS_2_3_IN_CELLS + HSDPA_USERS_3_2_IN_CELLS + HSDPA_USERS_4_1_IN_CELLS + HSDPA_USERS_0_6_IN_CELLS +
HSDPA_USERS_1_5_IN_CELLS + HSDPA_USERS_2_4_IN_CELLS + HSDPA_USERS_3_3_IN_CELLS + HSDPA_USERS_4_2_IN_CELLS +
HSDPA_USERS_0_7_IN_CELLS + HSDPA_USERS_1_6_IN_CELLS + HSDPA_USERS_2_5_IN_CELLS + HSDPA_USERS_3_4_IN_CELLS +
HSDPA_USERS_4_3_IN_CELLS + HSDPA_USERS_0_8_IN_CELLS + HSDPA_USERS_1_7_IN_CELLS + HSDPA_USERS_2_6_IN_CELLS +
HSDPA_USERS_3_5_IN_CELLS + HSDPA_USERS_4_4_IN_CELLS + HSDPA_USERS_1_8_IN_CELLS + HSDPA_USERS_2_7_IN_CELLS +
Copyright © Nokia
SiemensS_3_6_IN_C
Networks
2008
CompanyCELLS
confidential
Page 74 (123)
HSDPA_USER
ELLS
+ hHSDPA_USERS_4_5_IN_
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Equation 7. RNC_2054a Average Number of scheduled users per TTI per scheduler
RNC_2093a can be used to monitor Average number of SF16 codes reserved for HSDPA. This
KPI is based on duration of HSDPA x code counters. Picture below show 100 weeks history
data of two KPIs, RNC_2093a and RNC_722b collected from one RNC. HSDPA x code
counters (M1000C248-C258) show duration of x code reservation, as soon as there is one
HSDPA Mac-d flow allocated to cell, all available codes are reserved for HSDPA regardless of
HSDPA UE category. Original transmitted_x_code counters for QPSK/16QAM can be used to
monitor number of codes allocated for UE (see Figure 56Figure 56Figure 57).
10.0
2500
8.0
2000
6.0
1500
4.0
1000
2.0
500
0.0
0
tp
3000
im
e
15
.1
2.
20
08
23
.0
2.
20
09
04
.0
5.
20
09
13
.0
7.
20
09
21
.0
9.
20
09
30
.1
1.
20
09
08
.0
2.
20
10
19
.0
4.
20
10
28
.0
6.
20
10
12.0
Pe
rio
d
st
ar
tt
Average # of SF16 codes
Average reserved SF16 codes and HSDPA active throuhgput - 100 weeks
Active HS-DSCH MAC-d throughput, network perspective
Average Reserved SF16 codes for HSDPA
Figure 575758. RNC_2093a Average reserved SF16 codes for HSDPA and RNC_722b Active
HSDPA throughput.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 75 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
6.2.1.3 MIMO throughput performance & monitoring
In RU20, MIMO is supported with 16QAM modulation. 64QAM modulation is not supported with
MIMO. Maximum MIMO dual stream bit rate per transport block 2*13.98 = 27.95 Mbps,
providing around 24Mbps downlink application level throughput with dual stream transmission.
Figure 58Figure 58Figure 59 below show MIMO measurement results done in very good
network environment. Above picture show downlink application level throughput (FTP) for MIMO
(3 x 100M file downloaded) and TBS separately for both streams. Below picture show MIMO
usage and CQI and CQI2. During testing average downlink application level throughput of 23.4
Mbps was measured.
MIMO TBS
and TBS1
MIMO CQI
and CQI2
Formatted: Left
MIMO Usage
Figure 585859. MIMO “peak” performance.
Example below show MIMO drive test results done in NSN test network. Modulation is plotted
separately for both streams. Above chart show also RSCP along route and below chart the DL
application level throughput is included.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 76 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
MIMO_20_drive - Modulation vs. RSCP
100%
-30.0
90%
-40.0
80%
-50.0
n/a %
-60.0
60%
50%
-70.0
40%
RSCP
Modulation %
70%
QPSK%
16QAM %
64QAM %
-80.0
RSCP
30%
-90.0
20%
-100.0
10%
0%
-110.0
1
9
17
25 33 41 49
57 65 73 81 89
97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233 241 249
100%
25
90%
80%
20
Modulation %
70%
60%
50%
15
40%
10
30%
20%
10%
DL app tp (Mbps)
MIMO_20_drive - Secondary stream modulation
MIMO n/a %
MIMO QPSK%
MIMO 16QAM %
MIMO 64QAM %
App thru DL
5
0%
0
1
13 25 37 49 61 73 85 97 109 121 133 145 157 169 181 193 205 217 229 241 253 265 277
Figure 595960 . MIMO drive test under NSN test network. Above chart show modulation for main
stream and RSCP along the drive route. Chart below show modulation for secondary stream and
also DL application throughput along the route.
MIMO usage in Nemo is indicating how often dual stream transmission is used. Dual stream is
selected if


UE preference is dual stream (indicated by CQI)
Buffer status > TBS1+TBS2 – mimoDualStreamOffset bits (hard coded to BTS)
MIMO is reporting both CQI type A (0-14) and type B (0-30). For Type A, MIMO is reporting CQI
and CQI 2 (from 0-14). As MIMO CQI differs from CQIs reported by legacy HSDPA UEs, there is
own counters to monitor MIMO CQI values (M5000C339 – C357).
RNC informs UE of parameters which defines CQI report sending pattern. These parameters
are listed below, where N_cqi_typeA/M_cqi ratio is new for MIMO.



CQI feedback cycle (range: 0,2,4,8,10,16,20,32,40,64,80 ms)
CQI repetition factor (range: 1,2,3,4)
N_cqi_typeA/M_cqi ratio (range: 1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10, 1/1)
When analyzing MIMO CQI from drive test results, both CQI type A and CQI type B can be
seen. CQIs are send based on A/M ratio, which by default is 9/10 indicating that every 10 CQI
report is type B. Type B is send periodically for single stream ‘fall back’ in case the BTS decides
to use single stream while the UE is reporting the dual stream.
Figure 60Figure 60Figure 61 below shows example from CQI report cycle, where CQI feedback
cycle = 8 ms
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 77 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
CQI repetition factor = 2 and N CQI type A / M = 9/10
New CQI sent every 4 TTI = 8 ms
Type A CQI
Type B CQI
Complete cycle of 10 × 4 = 40 TTI = 80 ms
Figure 606061. Example of CQI report cycle.
Below example of MIMO parameters included to Radio bearer reconfiguration message.
mimoParameters
mimoOperation : start
mimoN-M-Ratio : mnm910
mimoPilotConfiguration
secondCPICH-Pattern
diversityPattern
channelisationCode : 8
Counters and KPIs to Monitor MIMO performance.
The number of original MAC-ehs PDUs transmitted with MIMO dual stream compared to the
total number of original MAC-hs PDUs being transmitted can be monitored with MIMO usage
ratio.
 RNC_2095a_MIMO Usage ratio
 RNC_2096a retransmission ratio for MAC-ehs PDUs using MIMO dual stream
Number of scheduled TTIs separately for dual stream and single stream users
 M5000C336 TTIs Scheduled for MIMO users with Dual stream
 M5000C335 TTIs Scheduled for MIMO users with Single Stream
Users having MIMO dual stream mode active can be monitored with Average Active MIMO
users PI.
 RNC_2049a Active MIMO users
MIMO CQI can be monitored with MIMO CQI counters.
 MIMO CQI – M5000C339 – 357.
MIMO CQI counters include classes from 0 to 18 as can be seen below. For example;
 Class 11: The counter is updated by 1 because of the following class criteria:
class11: sum(CQI1+CQI2)= (17 or 18) and (Diff<5)
 Class 17: The Counter is updated by 1 because of the following class criteria: class17:
sum(CQI1+CQI2)= 25 or 26
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 78 (123)
Formatted: Space After: 0 pt
Formatted: Font: 11 pt
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
MIMO CQI
100 000
90 000
80 000
70 000
60 000
Hour 1
50 000
Hour 2
Hour 3
40 000
30 000
20 000
10 000
IM
_M
O
RR
O
RR
CQ
I_
C
CQ
I_
C
CQ
CQ
I_
C
O
RR
_M
IM
O
_D
_C
LA
O
SS
_D
_M
I_
0
_C
C
I
M
O
LA
O
RR
CQ
SS
_D
_
I_
1
_C
M
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
2
_
C
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
3
_
C
C
IM
O
LA
O
RR
CQ
SS
_D
_
I_
4
_C
M
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
5
_
C
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
6
_
C
C
IM
O
LA
CQ
O
RR
SS
_D
I_
_
7
C
_C
M
O
LA
RR IMO
CQ
SS
_D
_M
I_
8
C
_
I
C
M
O
LA
O
RR
CQ
_D
SS
_M
I_
_C
9
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
1
_
0
C
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
11
_C
C
I
M
O
LA
O
RR
CQ
SS
_D
_M
I_
12
_C
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
13
_
C
C
IM
O
LA
O
RR
CQ
SS
_D
_M
I_
14
_
C
C
IM
O
LA
O
RR
CQ
SS
_D
_
I_
15
_C
M
C
IM
O
LA
O
RR
SS
_D
_M
16
_C
IM
LA
O
SS
_D
17
_C
LA
SS
18
0
Figure 616162. Example of MIMO CQI counters distribution
Formatted: Heading 4
6.2.1.4 DC HSDPA throughput and Performance
Formatted: Font: 14 pt
Dual Cell HSDPA feature allow 2 adjacent channels to be combined to generate an effective
HSDPA channel bandwidth of 10 MHz. Maximum double peak rate for single user is 42 Mbps,
providing DL application level throughput of 36 Mbps with 10% retransmission rate. Figure 62
show DC HSDPA throughput example from the lab.
Formatted: Bullets and Numbering
Figure 62. Example of DC HSDPA throughput in lab
Formatted: Caption
Formatted: Space After: 0 pt
NSN BTS support carrier spacing from 3.8 MHz to 5.2 MHz for DC HSDPA. UE support for
different carrier spacing should be checked, currently there is not DC HSDPA UE which support
carrier spacing over 5 MHZ so functionality of 5.2MHz carrier spacing it is verified by product
line. Table 21 below show measurement result done by BTS product line.
1st ch.
10713
10713
10713
10713
2nd ch.
10687
10689
10690
10691
carrier spacing
5.2
4.8
4.6
4.4
tp (Mbps)
33
33
35
Formatted: Centered
DC Call
NOK
OK
OK
OK
Formatted Table
Formatted: Centered
Formatted: Centered
Formatted: Centered
Formatted: Centered
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 79 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
10713
10713
10713
10692
10693
10694
4.2
4
3.8
33
30
25
OK
OK
OK
Formatted: Centered
Formatted: Centered
Formatted: Centered
Table 21. Functionality and performance of Dual Cell HSDPA with different frequency carrier
spacing. Currently there is no UE in the market which supports 5.2 MHz carrier spacing.
Formatted: Caption
DC HSDPA configuration can be fixed or flexible. In fixed configuration, the HSUPA is enabled
only in one of the carriers, which then act as primary serving HSDPA cell for DC-HSDPA
capable UE. Flexible configuration require that HSUPA is enabled for both of the carriers and
allows both cells to simultaneously act as primary serving cell for some DC HSDPA capable UE
and secondary serving HSDPA cell for some DC HSDPA capable UE.
Single cell and dual cell users are scheduled in fair manner simultaneously in both cells.
Proportional fair scheduler decides the scheduled user on cell separately per TTI and DC
HSDPA user is included in scheduling in both cells. Based on cell specific scheduling decision
per TTI, the DC user can be scheduled in none of the cells, in one of the cell or in both of the
cells. This is the case in downlink, but uplink return channel is always served with primary cell.
After DC HSDPA UE penetration increase, the uplink capacity may be limiting factor in primary
cell if fixed configuration is used. However, it is possible to start with fixed configuration and
expands to flexible configuration when number of DC HSDPA capable UEs increase if enabling
HSUPA in all cells is an issue (require license).
Figure 63 below show DL application throughput when there is simultaneously DC HSDPA and
64QAM UEs. DC HSDPA UE is doing continuous download (blue line) while 64 QAM is
downloading 100 Mbps files (Pink line). Violet line show combined throughput of both UEs
Formatted: English (U.S.)
Formatted: English (U.S.)
Formatted: English (U.S.)
Formatted: English (U.S.)
Formatted: English (U.S.)
Simultaneous DC HSDPA UE & 64QAM UE
40
DC HSDPA UE 100.00
90.00
35
80.00
70.00
25
60.00
20
50.00
40.00
15
L1 BLER (%)
DL app tp (Mbps)
30
30.00
10
64QAM UE
5
20.00
10.00
0
0.00
1
19 37 55 73 91 109 127 145 163181 199 217 235 253 271 289 307 325343 361 379 397 415 433 451 469
DL app tp -DC UE
DL app tp - 64QAM UE
L1 BLER - DC UE
L1 BLER - 64QAM UE
Figure 63. throughput in case there is simultaneously DC HSDPA and 64QAM users.
Formatted: Caption
Figure 64 show HS-SCCH usage in case there is both DC HSDPA and 64 QAM UE
simultaneously active. When 64QAM UE start downloading (yellow), the DC HSDPA usage
decrease in the cell where 64 QAM UE is active. DC HSDPA is scheduled 100% in other cell but
only 10% in the cell where there is active 64 QAM UE.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 80 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Simultaneous DC HSDPA UE & 64QAM UE - Usage
DC HSDPA UE – primary cell
100.00%
90.00%
HS-SCCH Usage
80.00%
70.00%
64QAM UE
60.00%
50.00%
40.00%
DC HSDPA UE – secondary cell
30.00%
20.00%
10.00%
0.00%
1
16 31 46 61 76 91 106 121 136 151 166 181 196 211 226 241 256 271 286 301 316 331 346 361 376 391 406 421 436 451 466
HS-SCCH Usage Primary -DC UE
HS-SCCH Usage- Secondary DC UE
HS-SCCH Usage - 64QAM UE
Figure 64. HS-SCCH usage for both DC HSDPA and 64 QAM UE
Formatted: Caption
A scheduler metric is calculated for each RF carrier and instantaneous Transport block Size
(TBS) is generated separately for each cell by link adaptation. This average TBS is based upon
the previously allocated TBS in both cells belonging to the DC HSDPA cell pair i.e. reprsents the
total average throughput allocated for the UE. Thus, a UE which is scheduled high throughput in
cell 1 (possible because it is the only active UE) will have a reduced scheduling.
Formatted: English (U.S.)
There is some DC HSDPA specific counters & KPIs which can be used to monitor DC HSDPA
performance. After enabling DC HSDPA feature in the network, new PM counters need to be
included in some throughput and data volume KPIs. These KPIs are:






Formatted: Bullets and Numbering
RNC_608c HSDPA received data
RNC_721d Average MAC-d flow throughput
RNC_722d Active HS-DSCH MAC-d throughput, network perspective
RNC_1879c Average HSDPA end user throughput
RNC_606e HSDPA MAC-d average net throughput at BTS
RNC_739d HSDPA MAC-d data volume at BTS
All KPIs above should include new DC HSDPA counters which monitor total amount of MultiCarrier HSDPA original data send on MAC-ehs PDUs in the primary and secondary cell.


Formatted: Bullets and Numbering
M5002C128MC_HSDPA_ORIG_DATA_SEC (kB)
M5002C129MC_HSDPA_ORIG_DATA_PRI (kB)
For example new version of RNC_722d includes counters M5002C128 and 129.
 RECEIVED_H S_M ACD_BITS - DISCARDED_HS_M ACD_BITS

   (M C_HSDPA_ORIG_DATA_PRI  M C_HSDPA_ORIG_DATA_SEC) * 8 


RNC _ 722d 
 HS_SCCH_PW R_DIST_CLASS_0  HS_SCCH_PW R_DIST_CLASS_1 


   HS_SCCH_PWR_DIST_CLASS_2  HS_SCCH_PWR_DIST_CLASS_ 3 
  HS_SCCH_PW R_DIST_CLASS_4  HS_SCCH_PW R_DIST_CLASS_5) 


500
Table 22. Example of RNC_722d Average Active HSDPA throughput
Formatted: Caption
Formatted: English (U.S.)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 81 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
There also two new counters to monitor total amount of positively acknowledged Multi-carrier
HSDPA data send on MAC-ehs PDU in primary and secondary cell. Based on these counters
two new PI are introduced which can be used monitor MC PDU drop ratio.


Formatted: Bullets and Numbering
RNC_5114a Multi Carrier PDU drop ratio in the radio interface (%)
RNC_5115a Multi Carrier PDU drop ratio on BTS level (%)
Average number of DC HSDPA capable and Active UEs can be monitored separately. Also DC
HSDPA Usage ratio can be monitored (based on active DCHSDPA UE/capable DCHSDPA
UEs)








Formatted: Indent: Left: 0.25", Hanging:
0.25", Space After: 0 pt
RNC_2100a DC HSDPA Usage Ratio, per Cell (%)
RNC_2101a DC HSDPA Usage Ratio, per BTS (%)
RNC_2102a DC HSDPA two carriers Usage Ratio, per Cell (%)
RNC_2105a Average number of DC HSDPA capable users, per Cell
RNC_2106a Average number of DC HSDPA capable users, per WBTS
RNC_2107a Average number of Active DC HSDPA capable UE using 2C, Cell
RNC_2108a Average number of Active DC HSDPA capable UE using 2C, WBTS
RNC_2109a Average number of Active DC HSDPA capable UE using 1C
Formatted: Bullets and Numbering
Formatted: Bulleted + Level: 1 + Aligned at:
0.25" + Tab after: 0.5" + Indent at: 0.5"
Using M5000C331-C334 counters, number of TTIs for scheduled DC HSDPA users for Primary
and Secondary carrier when either one or two carrier is used can be monitored:
350,000.00
300,000.00
250,000.00
200,000.00
Cell 3
150,000.00
Cell 4
100,000.00
50,000.00
0.00
TTI_DC_HSDPA_USER
PRIMARY_1C
TTI_DC_HSDPA_USER
SECONDARY_1C
TTI_DC_HSDPA_USER
PRIMARY_2C
TTI_DC_HSDPA_USER
SECONDARY_2C
Figure 65. Example of TTI counters for scheduled DC HSDPA user for Primary and Secondary cells
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 82 (123)
Formatted: Caption
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Formatted: Norwegian (Bokmål)
6.2.2 HSUPA throughput optimisation
HSUPA throughput problems can be detected either by using drive test tools (user level
throughput problems) or with counters stats when network/BTS/cell level problems can be
tracked. HSUPA channel is often used simply as return channel for HSDPA while it carriers only
acknowledgment type of small packets. RU20 introduce HSUPA 2ms TTI feature which
increase HSUPA maximum throughput to 5.8 Mbps.
HSDPA peak performance
6.2.2.1‎6.2.2.16.2.2.1.
issues
and
configurations
are
discussed
with
chapter
Different counters and KPIs can be used to monitor HSUPA throughput performance and
problems in network level, these explained in chapter 6.2.2.2‎6.2.2.26.2.2.2 with some examples.
6.2.2.1 HSUPA Peak performance and configuration
HSUPA throughput depends on parameter settings, activated features, UE capability, BTS HW
capacity and Iub Capacity. Also air interface start to limit HSUPA throughput when several
HSUPA users under same cell. In RU20 total BTS level HSUPA throughput increase to 21 Mbps
(12.6 Mbps in RU10) (there can be up to 6 cells under one HSUPA scheduler)
RU20 introduces HSUPA 2ms and HSUPA 5.8 Mbps features. 2ms HSUPA TTI can be enabled
without 5.8 Mbps but for 5.8 Mbps the 2ms TTI feature is needed.

Parameter MaxTotalUplinkSymbolRate defines maximum total UL symbol rate of the EDPDCH(s) of the UE in the cell and should be set to 5760 (2 x SF2 + 2 x SF4) if HSUPA
5.8 Mbps is activated or to 3840 kbps (2 x SF2) if HSUPA 2.0 is activated. The lowest
parameter value among the values of the parameter of the cells that belongs to the EDCH active set is used when the E-DCH is allocated. Supporting HSUPA 2.0 Mbps
means that RNC is allowed to set up the bit rate for the UE when requested by core
network (in RAB QoS) and when needed conditions are met. The needed conditions are,
for instance, suitable UE category and that the bit rate is supported also in the
neighbouring cells (no SHO needed??). When some condition is not fulfilled during a
call, RNC may downgrade a UE bit rate.
MaxTotalUplinkSymbolRate
TBS
RLC Throughput
960
1920
3840
5760
7110
14484 bits
19950 bits
11484 bits
0.672
1.38 Mbps
1.89 Mbps
5.44 Mbps
SF4
2*SF4
2*SF2
2*SF2+2*SF4
Table 232321. HSUPA bitrates with different MaxTotalUplinkSymbolRate settings


Parameter FactorEDCHMaxBitRate should be set to 0 (Restriction not set) or checked
together with the RAB UL max bit rate setting in HLR
Parameter ThresholdMaxEDPDCHSR can be used to restrict the maximum total Uplink
symbol rate of E-DPDCH based on maximum uplink user bit rate of the RAB (see
[1]‎[1][1]). The test results is shown in Figure 85Figure 85Figure 82 (end of this chapter)
UL throughput values with different setting of above parameters.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 83 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Low HSUPA throughput can be also due the wrong HSUPA congestion control parameter
settings. In RU10, the highest HSUPA rates were achieved using parameter values listed in TN
SW 127. RU20 introduce own set of parameters for HSUPA 2ms TTI
RAS06
TN
Parameter
RAS06 default SW_104
RU10 default
DelayThresholdMax
300 ms
8 ms
8 ms
DelayThresholdMid
70 ms
4 ms
4 ms
DelayThresholdMin
40 ms
1 ms
1 ms
ProbabilityFactorMax
0.1
0.8
0.8
DelayThresholdMax2msTTI
DelayThresholdMid2msTTI
DelayThresholdMin2msTTI
ProbabilityFactorMax2msTTI
Table 242422. HSUPA congestion control parameters.
RU10 TN SW_127 &
RU20 default
100 ms
70 ms
50 ms
0.1
100 ms
70 ms
50 ms
0.1
When troubleshooting HSUPA user throughput, following should be checked:
Modulation – RU20 supports only QPSK for HSUPA
TBS & Retransmission – Check Transport block size (TBS) during transmission and
retransmission rate. RU20 maximum supported TBS is 11484 with 2ms TTI and 2xSF4 + 2xSF2
(this require that SRB can be mapped to HSUPA in uplink) High retransmission rate can
decrease the throughput even with high TBS. Default HARQ retransmission target is 10%. This
is possible to change with Feature RAN2170 “Adjustable HSUPA BLER target for PS NRT” if
there is need for high bit rate demostrations
Figure 666663. Example of HSUPA link adaption parameters.
HSUPA throughput can be limited by
 UE Tx Power – UE is already using its maximum Tx power
 Serving Grant – Maximum grant is used already
 Data – UE buffer is empty – no new data to send
PrxMaxTargetBTS – Parameter PrxTargetMaxBTS define maximum target for received total
wide band power in the cell for BTS Packet scheduling.
Figure 67Figure 67Figure 64 below show maximum HSUPA throughput when 2ms TTI and
HSUPA 5.8Mbps features are enabled. Measurements are done under empty cell (no other
traffic) by setting parameter PrxMaxTargetBTS = 30 dB to avoid air interface limitations during
peak bit rate testing. High PrxMaxTargetBTS values should only used for demonstration
purposes, not in live network. Average uplink application level throughput was 4.7 Mbps with
around 10% retransmission rate. Maximum TBS 11848 was reach during testing.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 84 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure 676764. HSUPA throughput when 2ms TTI and 5.8 Mbps was activated. (100M file uploaded)
Following show results from HSUPA throughput test done to test effect of PrxMaxTargetBTS on
HSUPA 5.8 Mbps feature throughput. Parameter PrxMaxTargetBTS defines the maximum UL
noise rise (NR) level used by the BTS scheduler. During testing, the value of PrxMaxTargetBTS
varies between 2 and 30 dB. Result indicated that PrxMaxTargetBTS value 6 dB (default) gives
90% of the maximum throughput while PrxMaxTargetBTS value 4 dB gives 75% of the
maximum throughput with low EbNo value (high power efficiency)
High PrxMaxTargetBTS value (>12 dB) is required for peak rate testing but high values will
cause lot of variation on uplink noise and application throughput resulting performance
degradation of all users in cell. High values increase also nonHSPA noise caused by
DPCCH+HS-DPCCH
30 dB
20 dB
35
UL Noise Rise (dB)
30 dB
8
7
30
6
8 dB 12 dB
6 dB 10 dB
25
20
5
4
4 dB
15
3
10
2
2 dB
5
0
16:45:07
1
16:48:00
16:50:53
Noise rise
16:53:46
NonHSPA NR
16:56:38
16:59:31
Application throughput UL (Mbps)
40
0
17:02:24
App thru UL
Figure 686865. HSUPA throughput (yellow) and Noise rise with different PrxMaxTargetBTS values
HSUPA and R99 are sharing uplink resources, íncreased R99 load will decrease HSUPA
throughput. Next test show HSUPA performance with DCH load with default parameters.
(PrxMaxTargetBTS = 6 dB, PrxTargetPSMin/Max = 4 dB). Cell was first loaded with R99 NRT
data users and after that HSUPA was started. After starting the HSUPA, the R99 UEs were shut
down one by one. Figure 69Figure 69Figure 66 show that maximum R99 throughput was 1.2
Mbps at 4 dB UL noise rice and HSUPA throughput was 0.3 Mbps with full R99 load. Cell with
high R99 load get HSUPA throughput of around 0.3 Mbps.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 85 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
3.5
3.0
HSUPA NR
3.2
PrxTargetPSMax
7.0
6.0
2.5
5.0
2.0
4.0
1.6
1.5
1.0
3.0
1.2
1.1
1.1
0.80.9
0.7
2.0
0.8
0.4
0.3
0.5
UL Noise Rise (dB)
Throughput (Mbps)
2.6
1.0
0.0
0.0
2xR99
3xR99
4to6xR99 4to6xR99 3xR99 +
+ HSUPA HSUPA
2xR99 +
HSUPA
1xR99 +
HSUPA
HSUPA
Traffic
HSUPA tp
R99 tp
UL NR
R99 NR
.
Figure 696966. HSUPA performance with R99 load. PrxMaxTargetBTS =6 dB (default)
HSUPA 2.0Mbps with 10ms TTI
Following study show HSUPA Cell and user peak throughput when 2Mbps and 10ms TTI is
enabled. This test is done in lab, under NSN test network. HSUPA 2.0 Mbps is licensed feature,
and by achieving maximum throughput the parameter Maximum total uplink symbol rate have to
be set 3840. Figure 70Figure 70Figure 67 below show UL application (green line) level
throughput when HSUPA 2.0 feature is activated.
HSUPA UE1 2x100M
UL
Figure 707067. HSUPA throughput with HSUPA 2 Mbps feature
Uplink radio resources are shared between the HSUPA and R99 users. Figure 71Figure
71Figure 68 below present cell level UL application throughput with different number of HSUPA
UEs. Maximum achieved UL cell level application throughput is around 3 Mbps with 2 HSUPA
UEs. Adding more UEs does not increase UL cell level throughput due uplink air interface
limitations.
Parameter PrxTargetMaxBTS define maximum target for received total wide band power in the
cell for BTS Packet scheduling. As can be seen from results below, changing this parameter
does not improve total uplink cell throughput significantly but rather make uplink unstable.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 86 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Max DL cell
app. throughput
with 2 HSUPA
UE
Date:
175.110.2010
Version 2.10
PrxTargeMaxBTS changed
Figure 717168. HSUPA Cell UL application level throughput with different number of HSUPA UEs
and with different PrxTargetMaxBTS values (changed in case of 3 HSUPA UE)
Figure 72Figure 72Figure 69 show uplink application level throughput of 1 HSUPA User, when
there is different number of users in the cell. In case of 3 HSUPA UE, PrxtargetMaxBTS was
changed from 6 (default) to 30 and both values were tested.
Figure 727269. UL application level throughput of 1 HSUPA UE when there is different number of
UEs in the cell.
Figure 73Figure 73Figure 70 show PrxTotal (from Online Monitor) value with different number of
HSUPA Users.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 87 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 737370. Uplink PrxTotal with different number of HSUPA UEs
With 1 HSUPA UE the uplink load is around 30%, with 2 HSUPA UE close to 60% but not yet
limited by air interface. Adding 3rd UE the load increase close to 75% (PrxTargetMaxBTS=6) and
cell level throughput is not increased any more.
Figure 747471. Uplink Load with different number of HSUPA UEs
6.2.2.2 HSUPA throughput monitoring and troubleshooting
RU20 introduce HSUPA 2ms TTI feature and increase the HSUPA user throughput to 5.8 Mbps.
HSUPA 2ms TTI attempts and selections cannot be monitored separately, but there are
counters/PIs to monitor number of users and TTI throughput separately for 2ms and 10 ms TTI.
The HSUPA performance evolution can be estimated with same method as HSDPA, by
comparing the HSUPA selection (RNC_923b) and HSUPA data volume (RNC_931c).
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 88 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Table 25Table 25Table 23 lists the relevant reports and PIs for HSUPA RB throughput
monitoring and troubleshooting.
Table 252523. HSUPA traffic and throughput KPIs and counters
PI ref
PI name / Abbreviation
PI unit
Report: System Program RNSRAN000 (M1002, M1022,), Service/Session Accessibility
analysis RSRAN073
RNC_930b
Packet Session Attempts
#
RNC_923c
E-DCH selections (RSRAN073)
#
RNC_928b
HSUPA attempts
#
RNC_1883a
HSUPA active Cell throughput
kbps
RNC_931c
HSUPA MAC-es data volume at RNC
Mbit
Report: Cell Data Volume and Throughput at RNC RSRAN077 (M1023)
M1023C10
NRT_EDCH_UL_DATA_VOL
Byte
RNC_952a
HSUPA MAC-es average throughput at RNC
kbps
Report: Allocated Traffic Amounts (R99 + HSPA) RSRAN070 (M1002, M5000)
RNC_1117b
E-DCH allocations
#
RNC_1118b
E-DCH allocation duration
Min
RNC_952c
HSUPA MAC-es average throughput at RNC
Kbps
RNC_931a
HSUPA MAC-es data volume at RNC
Mbit
M5000C151
HSUPA_MIN_MACD_THR
kbit/s
M5000C152
HSUPA_MAX_MACD_THR
kbit/s
M5000C153
HSUPA_AVE_MACD_THR
kbit/s
Report: Number of HSPA Users and UE capability RSRAN051 (M1000, M1001)
RNC_1036b
Average number of simultaneous HSUPA users
(RNC_1036b is based on RU10 new counters)
#
RNC_1037b
Average number of simultaneous HSUPA users, during
HSUPA usage
#
RNC_968b
UL DCH Selected due to too many HSUPA users
%
Report: HSPA Overview RSRAN092
RNC_1878a
Average HSUPA Mac-d throughput
Mbps
RNC_1883b
Active HSUPA cell throughput
Mbps
RNC_1884b
Average HSUPA throughput per session
Mbps
RNC_2050a
Active HSUPA 2ms TTI throughput
Mbps
RNC_2051a
Active HSUPA 10ms TTI throughput
Mbps
RNC_2048a
HSUPA 2 ms TTI Transmission Usage Ratio
%
RNC_2049a
HSUPA 10 ms TTI Transmission Usage Ratio
%
RNC_2052a
Average HSUPA 2ms TTI Users
#
RNC_2053a
Average HSUPA 10ms TTI Users
#
ATM VCC Traffic Load RSRAN083 (M530)
RNC_752a
Average ATM VCC ingress throughput
Cps
Iu-PS Throughputs RSRAN064
RNC_939a
Iu-PS outgoing interactive user data throughput in RNC
Copyright © Nokia Siemens Networks 2008
Company confidential
kbps
Page 89 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RNC_940a
Iu-PS outgoing backgroud user data throughput in RNC
kbps
RNC_936b
Iu-PS outgoing user data throughput in RNC
kbps
Figure 75Figure 75Figure 72 shows an example of HSUPA throughput measurement from
multiple throughput PIs (M5000C152, M5000C153, RNC_952b) and drive test log. M5000M152
show maximum HSUPA Mac-d throughput. The PIs that measure the average throughput from
different measurements (Cell throughput M1023 and BTS M5000) show equal values. This gives
the freedom to choose the PI based on the available measurements.
Figure 757572. HSUPA throughput PIS and drive test tool measurement.
RU20 introduce new KPI RNC_1883b_HSUPA_active_cell_throughput, which is included to
system program report. This KPI is based on existing counters and counts Average HSUPA cell
throughput when at least one user is allocated for HSUPA in the cell, including inactivity time
and time of allocated EDCH even if only download is done
Picture below show HSUPA throughput KPI comparison, RNC_1883b is HSUPA active cell
throughput and naturally show highest value. RNC_952c is data volume divided by
measurement period and value of this KPI highly depends on how much HSUPA activity there is
in the cell during measurement period. RNC_1878a is based M5000C153 and show average
HSUPA MAC-d throughput using the average over measurement period samples (updated
100ms periods).
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 90 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
700.00
600.00
tp (Kbps)
500.00
400.00
300.00
200.00
100.00
0.00
1
6
11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121 126 131 136
RNC_952c HSUPA Mac-es avg thp RNC
RNC_1878a Average HSUPA Mac-d throughput
RNC_1883b HSUPA active Cell througput
Figure 767673. HSUPA throughput KPI comparison, example from NSN test network
Active HSUPA TTI throughput can be monitored separately for 2ms and 10 ms TTIs. Similar
also average number of HSUPA users can be monitored.




RNC_2050a_Active HSUPA_2ms_TTI_Troughput
RNC_2051a_Active HSUPA_10ms_TTI_throughput
RNC_2052a_Average_HSUPA_2ms_TTI_users
RNC_2053a_Average_HSUPA_10ms_TTI_users
As on example, the RNC_2050a counts total volume of MAC-e data received with 2 ms by BTS divided by
number of 2ms TTI MAC-e PDUs received by BTS. So this is active TTI user throughput
HSUPA channel is often used simply as return channel for HSDPA while it carriers only
acknowledgment type of small packets.
10 ms TCP ack = 40 byte * 8 / 10ms = 32 kbps
2 ms TCP ack = 40 byte * 8 / 2ms = 160 kbps
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 91 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
200.00
4.0
180.00
3.5
160.00
2.5
tp (kbps)
120.00
100.00
2.0
80.00
1.5
60.00
avearage number of users
3.0
140.00
1.0
40.00
0.5
20.00
0.00
0.0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
Act HSUPA 10ms TTI thp RNC_2051A
Act HSUPA 2ms TTI thp RNC_2050A
Avg HSUPA 2ms TTI Users RNC_2052A
Avg HSUPA 10ms TTI Users RNC_2053A
Figure 777774. Example of Active HSUPA TTI throughput (both 2ms and 10ms) and Average
number of HSUPA 10ms & 2ms TTI users. Example is from NSN test networks
1400
300
1200
250
1000
200
800
150
600
100
400
50
200
0
19
.1
1.
20
08
19
__
.1
00
1.
20
:0
0:
0
19
8_
00
.1
_0
1.
2:
20
00
0
:
19
8_
00
.1
_0
1.
5:
20
00
0
:0
19
8_
0
.1
_0
1.
7:
20
00
0
:0
19
8_
0
.1
_1
1.
0:
20
00
0
:0
19
8_
0
.1
_1
1.
3:
20
00
08
:0
19
__
0
.1
15
1.
20
:0
0:
08
19
0
__
0
.1
19
1.
20
:0
0:
08
19
0
__
0
.1
21
1.
20
:0
0:
08
20
0
__
0
.1
23
1.
20
:0
0:
08
20
0
__
0
.1
02
1.
20
:0
0:
08
20
00
__
.1
06
1.
20
:0
0:
08
20
00
__
.1
08
1.
20
:0
0
0
:
20
8_
00
.1
_1
1.
0:
20
00
0
:0
20
8_
0
.1
_1
1.
3:
20
00
0
:0
20
8_
0
.1
_1
1.
5:
20
00
0
:0
20
8_
0
.1
_1
1.
7:
20
00
08
:0
__
0
19
:0
0:
00
0
RNC_614a_HS-DSCH_selections
RNC_928a_HSUPA_att
RNC_923a_E-DCH_selections
RNC_931a_MAC-es_data,_at_RNC (Mbps)
Figure 787875. HSUPA selections and throughput.
HSUPA throughput can be limited by BTS Channel elements. HSUPA CE allocation is done with
specific sizes of resource steps. Number of resource steps vary between RAN release and BTS
HW release. There is also differences between 10ms and 2ms resource steps as 2mst TTI
HSUPA users require more processing than 10ms TTI HSUPA users. The amount of resources
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 92 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
needed depends on the throughput (Physical layer cell level throughput) and the number of
HSUPA users
To be able to allocate the next HSUPA resource step, an additional free capacity of 6 CE is
needed. The required six CEs free on top of the HSUPA resource step is to avoid a ‘ping-pong’
effect in reserving and freeing HSUPA resource step. When free channel capacity drops below 4
CE, the Resource Manager starts to free resources used by HSUPA.
If all the HSUPA users are under one cell (or there is only one cell), only first WSPC card or
Flexi submodule is used in RAS06. Figure 79Figure 79Figure 76 below show BTS CE HSUPA
usage versus HSUPA MAX/AVE Mac-d throughput. There is few periods HSUPA throughput is
limited due the BTS HW due the increased R99 traffic which can be seen from Figure 79Figure
79Figure 76.
More details of HSUPA resource steps can be found from BB dimensioning guideline.
HSUPA_MAX_MACD_THR
HSUPA_AVE_MACD_THR
M5001C09_MAX_USED_CE_FOR_HSUPA_UL
Max_Used_CE
6 500
200
6 004
6 000
HSUPA
5 500
190
5 984
HSUPA + R99
5 503
180
170
160
4 361
4 500
UL throuhgput kbits/s
150
4 650
4 163
4 163
3 964
4 000
140
4 260
3 964
3 964
3 964
3 964
130
3 964
120
3 500
110
3 316
100
3 000
90
80
2 500
2 180
70
2 009
64
2 000
48
1 500
64
64
64
48
64
64
64
48
48
48
48
48
48
48
48
BTS Channel Elements
5 000
60
50
48
40
32
1 000
30
527
20
500
0 8
0
8
0
8
0 8
0 8
0 8
0 8
16
17
18
19
0
0
10
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
20
21
22
23
24
25
26
Figure 797976. BTS CE HSUPA Usage and HSUPA Maximum Mac-d Throughput (RAS06)
There is own counters to monitor HSUPA CE resource status. These counters can be used to
monitor periods when HSUPA throughput is limited or HSUPA setup is not possible due the BTS
HW.


M1000C269 BTS HSUPA HW Limited Duration is updated when BTS is in HSUPA HW
limited state. In this state, RNC sets up the E-DCH but the BTS HW shortage may cause
throughput to be lower than expected.
M1000C270 BTS HSUPA NO HW Capacity duration is updated when BTS reports to be
in state that it does not have HSUPA HW capacity available. In this state, the RNC does
not set up the E-DCH
Figure 80Figure 80Figure 77 present hours when HSUPA throughput is limited due the lack of
BTS CE (due the increase R99 traffic which, in case of BTS CE’s, has priority over HSUPA),
and if we compare Figure 79Figure 79Figure 76 and Figure 80Figure 80Figure 77, these are the
period when max used CE show very high value.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 93 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
M1000C269_BTS_HSUPA_HW_LIMITED_DUR
Date:
175.110.2010
Version 2.10
M1000C270_BTS_HSUPA_NO_HW_CAPA_DUR
M1000C268_BTS_HSUPA_HW_NOT_LIMITED_DUR
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Figure 808077. BTS resource status counters
HSUPA throughput can be low due the Iub congestion. HSUPA congestion control feature
consists of multiple detection entities separated into different parts of the system. The main
entities of interest are Iub in terms of transport capabilities and the RNC in terms of processing
resources. In case of congestion with Iub or RNC:
RNC sends HSUPA Congestion Control indications to the BTS based on detected received Iub
FP frame delay build up or RNC HW overload. Following counters count those messages:
• M1022C69 IUB_DELAY_CC_DELAY_IND
• M1022C70 HW_OVERL_CC_DELAY_IND
•
RNC sends HSUPA Congestion Control indications to the BTS based on detected received Iub
FP frame frame loss due to Iub delay, traffic loss or RNC HW overload. Following counters
count those messages:
• M1022C71 IUB_LOSS_CC_FRAME_LOSS_IND
• M1022C72 IUB_DELAY_CC_FRAME_LOSS_IND
• M1022C73 HW_OVERL_CC_FRAME_LOSS_IND
These problems can be detected with the KPIs.
 RNC_1165a Frame protocol delay rate for E-DCH traffic
 RNC 1166a Frame protocol lost rate for E-DCH traffic
Figure 81Figure 81Figure 78 below show successfully received EDCH frames and Frame losses
due the RNC HW. Counter HW_Overload_CC_Frame loss is triggered in case when there is 3
or 4 simultaneous HSUPA UEs indicating lack of DSP/DMPG processing capacity. (Counters
are presented in different scale, max frame loss 2.65. % )
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 94 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
HW_OVERL_CC_FRAME_LOSS_IND
Date:
175.110.2010
Version 2.10
SUCC_REC_EDCH_FRAMES
7 000.00
600 000.00
500 000.00
5 000.00
400 000.00
4 000.00
300 000.00
3 000.00
200 000.00
2 000.00
Succ Received EDCH Frames
HW Overload CC Frame Loss
6 000.00
100 000.00
1 000.00
0.00
0.00
1
3
5
7
9
11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65
Figure 818178. HSUPA congestion control and HW overload CC Frame loss counter
When the Node B receives a TNL congestion indication Control Frame it starts to decrease the
HSUPA throughput in air- interface. UE bit rate is decreases because the Packet Scheduler is
sending a relative grant ‘DOWN’ commands. The E-DCH Packet Scheduler decreases the UE
bit rate aggressively if received congestion indication was ‘Frame Loss’, compared to ‘Delay
Build-up’.


Frame Loss => 60 ms between consecutive reductions
Delay Build-up => 100 ms between consecutive reductions
Once the congestion is over, the Congestion Indication entity send an E-DCH FP control frame
of type ‘Congestion Indication’ and value ‘No TNL Congestion’ to the BTS.
Receiving the ‘No TNL Congestion’ indication, the E-DCH Packet Scheduler stops sending
‘DOWN’ commands to the UE and recovers gradually back to normal operation.


Node B waits 60 ms before re-allocating resources in case congestion reoccurs
Node B then has 200 ms to re-allocate resources to the UE from which they were
removed prior to making them generally available to all UE
‘Congestion’
Indication received
from the RNC
E-RGCH
Down
Hold
Period
Re-allocate
Resources
Resources generally
available to any
connection
Resources only
available to connection
from which they were
removed
‘No Congestion’
Indication received from
the RNC
60 ms
200 ms
Figure 828279. Function of Iub congestion Control
In case of limited Iub capacity (e.g. 1 x E1) the full symbol rate allocation (2 x SF2) can cause
throughput drops. HSUPA congestion control decrease the HSUPA bit rate by decreasing the
serving grant with too high spreading code configuration. Performance of unlimited (2 x SF2)
configuration is worse than limited (2 x SF4) configuration in a site with 1 x E1 Iub, because
HSUPA congestion control fluctuates the bitrate (serving grant). Solution to this issue is to
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 95 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
introduce cell level symbol rate limitation MaxTotalUplinkSymbolRate parameter. This impact
can be clearly seen from figure below.
PPP throughput - UL
1800000
1600000
PPP throughput / bps
1400000
1200000
1000000
PPP UL
Air bit rate
800000
600000
400000
SF4
200000
2xSF2
2xSF4
667
638
609
580
551
522
493
464
435
406
377
348
319
290
261
232
203
174
145
87
116
58
29
0
0
time
Figure 838380. Function of Iub congestion control for throughput with different symbol rate
HSUPA - SG & AG
30
25
SG, AG
20
SG
15
AG
SF4
10
5
2xSF4
2xSF2
675
650
625
600
575
550
525
500
475
450
425
400
375
350
325
300
275
250
225
200
175
150
125
100
75
50
0
25
0
tim e
Figure 848481. HSUPA congestion control decrease the HSUPA bit rate by decreasing the Serving
grant with too high spreading code configuration
HSUPA bit rate can be limited by BTS scheduler with two mechanisms which utilise the RAB
max bit rate (detail parameter description presented beginning of this chapter.)


E-DCH maximum bit rate limitation with RAB QoS and FactorEDCHMaxBitRate (def 1.5)
 (= 0): Max E-DCH bit rate not sent to BTS
 (> 0): E-DCH Max BitRate = FactorEDCHMaxBitRate · RAB: Max UL bit rate, sent to
BTS in NBAP: RL setup/reconfiguration message (IE : E-DCH Maximum Bit Rate)
Total uplink symbol rate of E-DPDCH(s) can be limited with ThresholdMaxEDPDCHSR
 RAB: Max UL bit rate ≤ ThresholdMaxEDPDCHSR960kbps (def 512 kbps) OR
MaxTotalUplinkSymbolRate = 960  SF4  672 kbps
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 96 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20

RAB: Max UL bit rate ≤ ThresholdMaxEDPDCHSR1920kbps (def 1024 kbps) OR
MaxTotalUplinkSymbolRate = 1920  2 * SF4  1380 kbps
Otherwise (RAB: Max UL bit rate > ThresholdMaxEDPDCHSR1920kbps AND
MaxTotalUplinkSymbolRate = 3840)  2 * SF2  1888 kbps
Maximum set of the E-DPDCHs sent to BTS in NBAP: RL setup/reconfiguration
message (IE : Maximum Set of E-DPDCHs) AND to UE in RRC: Radio bearer
reconfiguration message (IE: Maximum channelisation codes)


Figure 85Figure 85Figure 82 show result from HSUPA bit rate parameter test and impact of Iub
congestion control. Test cases and used parameter settings are listed below. With 1 x E1, the
Iub congestion control is limiting throughput with high bitrate settings. (Arrows in Figure 85Figure
85Figure 82 show cases where Iub congestion control is limiting HSUPA bitrate)
UL throughput
1200.0
1116
1038
1010
1000.0
861
843
830
867
852
kbit/s
800.0
592
600.0
400.0
200.0
584
QoS with
FactorEDCHMaxBitRate=1.5
375
367
297
FactorEDCHMaxBitRate
296
MaxTotalUplink
SymbolRate
ThresholdMaxEDP
DCHSR
QoS only
48
106
Fa
ct
=1
,Q
oS
Fa
=3
ct
84
=1
.5
,Q
oS
Fa
=3
ct
84
=5
,Q
oS
Fa
=3
ct
84
=N
S,
Q
oS
=3
84
Sy
m
Ra
te
=9
Sy
60
m
Ra
te
=1
92
Sy
0
m
Ra
te
=
3
Th
84
e=
0
de
f,
Q
oS
Th
=6
e=
4
de
f,
Q
oS
Th
=6
e=
40
de
f,
Q
oS
=1
50
0
Q
oS
on
ly
=6
Q
4
oS
on
l
y=
Q
oS
38
=6
4
4,
Fa
Q
c
oS
t=
1.
=1
5
28
,F
ac
Q
oS
t=
1.
=2
5
56
,F
ac
Q
oS
t=
1.
=3
5
84
,F
ac
t=
1.
5
0.0
Figure 858582. Uplink throughput with 1 x E1 for HSPA and different Parameter values





Test 1: Effect of FactorEDCHMaxBitRate
 FactorEDCHMaxBitRate = 0 (not set), 1, 1.5 and 5
 RAB Max UL bit rate 384 kbps
 ThresholdMaxEDPDCHSR = 0 (Not set)
Test 2: Effect of MaxTotalUplinkSymbolRate
 MaxTotalUplinkSymbolRate = 960, 1920, 3840
 ThresholdMaxEDPDCHSR = 0 (Not set)
 FactorEDCHMaxBitRate = 0 (Not set)
 RAB Max UL bit rate 4132 kbps
Test 3: Effect of RAB QoS and ThresholdMaxEDPDCHSR
 RAB Max UL bit rate 64, 640 kbps
 FactorEDCHMaxBitRate = 0 (Not set)
 ThresholdMaxEDPDCHSR960kbps = 512 ksps and
ThresholdMaxEDPDCHSR1920kbps = 1024 ksps
Test 4: Effect of RAB QoS only
 RAB Max UL bit rate 64, 384 kbps
 ThresholdMaxEDPDCHSR = 0 (Not set)
 FactorEDCHMaxBitRate = 0 (Not set)
Test 5: Effect of RAB QoS
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 97 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20



Date:
175.110.2010
Version 2.10
RAB Max UL bit rate 64, 128, 256 kbps
ThresholdMaxEDPDCHSR = 0 (Not set)
FactorEDCHMaxBitRate = 1.5
HSUPA data rate can be limited by



UE Tx Power – UE is already using its maximum Tx power
Serving Grant – Maximum grant is used already
Data – UE buffer is empty – no new data to send
Figure 86Figure 86Figure 83 below show situation when UE tx power increase and start to limit
throughput, there is more Absolute Grants given to the UE. BTS reduce aggressively the
throughput and therefore AG are used.
RED= AG
Yellow =E-TFCI
BLUE= SG
Figure 868683. UE tx Power limitation vs. HSUPA throughput
6.2.3 Round Trip Time (RTT)
Latency can be measured as round trip time (RTT), which is defined as the time an IP packet
takes to travel from the terminal through all network elements to the application server, and back.
It is important to understand that from a single RTT measurement we cannot see where the
packets have spent which amount of time, neither on which direction (UL/DL) nor on the
individual links, as we only see end-to-end the total sum of all the times a packet spent in the
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 98 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
network in UL and DL direction. However, for a theoretical RTT estimation, we can use the
following assumptions:






UE delay of 10-25ms
Air interface delay, including uplink and downlink buffering, of 43-53ms for Release 99,
20ms for HSDPA, and 10ms for HSUPA. The WCDMA release 99 data rate 64/64 kbps
uplink/downlink assumes a 20ms TTI while 128/384 kbps assumes a 10ms TTI. HSUPA
uplink assumes a 2ms TTI.
BTS delay 10-15ms
Iub delay of 20-40ms for release 99, 10ms for HSDPA, and 5ms for HSUPA
RNC delay of 20ms for release 99 and 10ms for HSDPA/HSUPA
Iu plus core network delay of 3ms
The ICMP packet uses 20 Byte for IP header and 8 byte for ICMP header plus the payload.
Often ping applications (e.g. ping from a Windows XP command line) use per default ICMP
messages with a payload of 32 Byte, making a total IP packet length of 60 Byte.
The RTT depends heavily on the used Radio Bearer. The Figure 87Figure 87Figure 84 below
shows typical lowest achievable RTT values for different RBs and different payload size. The
values were measured in NSN Test Network under empty cell with optimised E2E environment.
500
471
450
400
350
300
RU10 -32 byte
RU20 - 32 byte
250
RU10 - 1400 byte
200
150
RU20 - 1400 byte
148
133
106
89
100
62
57
39
50
23
40
0
64 / 64
384 / 384
384 / HSDPA
Cat 8
HSPA with
10ms HSUPA
TTI - Cat14
HSPA with 2ms
HSUPA TTI Cat14
Figure 878784. RU20 RTT values in NSN test network
6.3 Mobility
HSPA mobility can be performed with cell reselection in CELL_FACH or serving cell change
functionality. Serving cell change with soft handover is required for HSUPA,
HS-DSCH serving cell change can be triggered by the best server Ec/No, UL SIR error and
event 1B/1C. The most common triggering reason is supposed to be periodical Ec/No
measurements. HSDPAServCellWindow (def 2 dB) parameter determines the maximum
allowed difference between the best cell CPICH Ec/No and the serving HS-DSCH cell CPICH
Ec/No. The recommendation is to set DropWindow parameter value in HSDPA FMCS higher
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 99 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
than HSDPAServCellWindow, so that the serving cell change would be normally triggered by the
Ec/No measurements and not by the event 1B.
AdditionWindow in HSDPA FMCS is controlling the active set size of the associated UL
channels. It doesn’t have direct impact on the serving cell change functionality and triggering.
Current recommendation is to use lower value for AdditionWindow (closer to 0 dB) in HSDPA
FMCS than in the RT/NRT FMCS, to have smaller SHO area for HSDPA users.
The HSDPA serving cell change performance can be measured with RNC_733a (HSDPA
Serving Cell Change Success Rate). The SCC can be triggered mainly by CPICH EcNo, UL SIR
Error or active set update (removal of serving HS-PDSCH cell from AS).
Low success rate can be caused by
 Failures due to BTS
 When the RNC receives NBAP: RADIO LINK RECONFIGURATION FAILURE during
serving HS-DSCH cell change
 Failures due to transmission
 When a serving HS-DSCH cell change fails due to an Iub transport setup failure.
 Failures due to admission control
 The number of HS-DSCH serving cell change failures due to admission control, for
example because the maximum number of HSDPA users were already allocated in
the target cells.
 Failures doe to other reasons
 The number of HS-DSCH serving cell change failures due to other reasons.
Table 26Table 26Table 24 summarises the HSPA mobility related KPIs and counters.
Table 262624. HSPA mobility counters and KPIs
PI ref
PI name / Abbreviation
PI unit
Report: System Program RSRAN000
RNC_733a
HSDPA Serving Cell Change Success Rate
%
RNC_918b
HSUPA Serving Cell Change Success Rate
%
Report: HSPA Serving Cell Change RSRAN033
RNC_906a
HSDPA SCC attempts
#
RNC_733a
HSDPA Serving Cell Change Success Rate
%
M1008C213
SCC_STARTED_CPICH_ECNO
Integer number
M1008C214
SCC_STARTED_UL_SIR_ERROR
Integer number
M1008C215
SCC_STARTED_ACTIVE_SET_UPD
Integer number
M1008C216
SCC_STARTED_OTHER_REASON
Integer number
M1008C217
SCC FAILED_DUE_TO_UE
M1008C218
SCC_FAILED_DUE_TO_BTS
Integer number
M1008C219
SCC_FAILED_DUE_TO_TRANSM
Integer number
M1008C220
SCC_FAILED_DUE_TO_AC
Integer number
M1008C221
SCC_FAILED_DUE_TO_OTHER
Integer number
M1008C239
EDCH_SCC_STARTED
#
RNC_918b
HSUPA Serving Cell Change Success Ratio
%
RNC_2135a
HSUPA Inter-RNC SCC Success Rate
%
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 100 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Report: Service/Session Retainability Analysis RSRAN079 (M1022)
Formatted: Swedish (Sweden)
M1008C243
INTER_RNC_HHO_ATT_HSPA_SCC
RNC_1163a
HSUPA Inter-RNC SCC Failure Rate
%
RNC_1164a
HSUPA Inter-RNC SCC Drop Rate
%
HSUPA serving Cell Change are only done when HSDPA serving Cell change is needed. Below
is typical example of HSDPA mobility performance taken from RSRAN033 report. Main reasons
to start SCC is the decreased CPICH EcNo and active set update (event 1b/1c). It has been
sent that in RU10 the SCC performance is better and even better in RU20.
RU10
RU20 MP1
RU20EP1
PP1.12
WN6.0
EP1
first cluster
RU20 MP2
Figure 888885. Example of SCC Performance (RU10/RU20)
There seems not to be a relation with poor SCC success and HSDPA retainability, as seen in
the picture below. SCC success rate for HSDPA and HSUPA is not very accurate in cell level as
denominator is incremented in the source cell (old serving cell) and numerator is incremented in
the target cell (new serving cell).
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 101 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
250.00
101.00
100.00
200.00
99.00
98.00
97.00
RNC_609a
150.00
100.00
96.00
95.00
50.00
94.00
0.00
93.00
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81
RNC_733a_SCC SR
RNC_918a_HSUPA_SCC SR
RNC_609a_HSPDA_Retainability
Figure 898986. HSDPA SCC performance compared to HSDPA retainability.
Inter RNC SCC performance seems to be about 2-4 % lower than Intra RNC SCC due to SRNC
relocation issues.
6.4 Retainability
The retainability of a HSPA packet call describes the probability that the packet call is not
dropped when the HSPA channel type is used. The PI RNC_920a (see Table 27Table 27Table
25) describes the retainability based on packet M1022 measurements. This takes into account
only events when the DCH connection is abnormally released. The PI RNC_609a can be also
used for retainability measurement, but this PI is triggered in cell where the RL fails even if there
is working RL in other cell of active set and the packet call is switched to that, thus does not
necessary present users view of connection quality.
The HSPA packet call failures are mainly due to RL failures; radio link failure, RLC protocol
reset or uplink RLC unrecoverable error (Cell Update sent by UE). Figure 32Figure 32Figure 32
presents an example of HSPA packet call retainability analysis.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 102 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
RNC_920a<
X%
N
o
Date:
175.110.2010
Version 2.10
No Action
Needed
Yes
Yes
HSPA packet call
Radiolink failures
Check SCC Failure Rate – Radio, Iub, CE
resource congestion
No
Check CQI distribution and Ecno distribution for
coverage issue
Check HSDPA mobility parameter – Add/Drop
window, SCC parameter
Yes
HSPA packet call
failures - other
Check for RNC failures and use RNC logging if
required
Figure 909087. HSPA retainability failure analysis
Table 27Table 27Table 25 lists the relevant reports and PIs for HSDPA RB accessibility
monitoring and troubleshooting.
Table 272725. HSPA retainability counters and KPIs (Report: Service/Session Retainability
Analysis RSRAN079)
PI ref
PI name / Abbreviation
PI
unit
Report: System Program RSRAN000
RNC_930b
Packet Session Attempts
#
RNC_922b
Packet Session Success Ratio for NRT
%
RNC_614c
HS-DSCH selections
#
RNC_609a
HSDPA Resource Retainability for NRT Traffic
%
RNC_926b
HSDPA attempts
#
RNC_920b
HSDPA Success Ratio from user perspective for NRT
%
RNC_923c
E-DCH selections
#
RNC_919a
HSUPA resource Retainability for NRT Traffic
%
RNC_928b
HSUPA attempts
#
RNC_915c
HSUPA Success Ratio from user perspective for NRT
%
Report: Service/Session Retainability Analysis RSRAN079 (M1022)
RNC_1092b
Packet Session Rel from HS-EDCH
#
RNC_1093b
Packet Session Rel from HS-DCH
#
RNC_1094b
Packet Session Rel from DCH-DCH
#
RNC_1095a
HS-DSCH/E-DCH Packet Call Rel due to RL Failures
%
RNC_1096a
HS-DSCH/DCH Packet Call Rel due to RL Failures
%
RNC_1097a
DCH/DCH Packet Call Rel due to RL Failures
%
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 103 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
RNC_1098a
HS-DSCH/E-DCH Packet Call Rel due to Other Failures
%
RNC_1099a
HS-DSCH/DCH Packet Call Rel due to Other Failures
%
RNC_1100b
DCH/DCH Packet Call Rel due to Other Failures
%
RNC_1101b
HS-DSCH Allocation Rel
#
RNC_1102b
HS-DSCH Release Rate due to RL Failure
%
RNC_677b
HSDPA Radiolink failures
#
RNC_1185b
HS-DSCH Allocation Release Rate due to Non-RL failures
RNC_675b
HSDPA Non - Radiolink failures
#
RNC_679c
HS-DSCH release due to mobility
%
RNC_681b
S-DSCH release due to pre-emption
%
RNC_724b
HS-DSCH to DCH switch - other than DCH switch
%
RNC_1107d
E-DCH Allocation Rel
#
RNC_1108d
E-DCH Rel due to RL Failures
%
RNC_1115d
E-DCH Rel due to HS-DSCH serving cell change
%
RNC_1109d
E-DCH Rel due to Other Failures
%
Figure 91Figure 91Figure 88 shows one example about HS-DSCH release failure..
RU10
RU20 MP1
WN6.0 EP1
first cluster
RU20EP1
PP1.12
RU20 MP2
Direct transition
DCH-PCH
causing problems,
OK after
deactivation.
Figure 919188 Example of HSDPA release failure (RU10/RU20)
Figure 92Figure 92Figure 89 shows that also for HSUPA release the main cause is radio link
failure.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 104 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
RU10
RU20 MP1
WN6.0
EP1
first cluster
RU20EP1
PP1.12
RU20 MP2
Direct transition
DCH-PCH
causing problems,
OK after
deactivation.
Figure 929289 Example of E-DCH release reasons (RU10/RU20)
7 HSPA & R99 bearer interworking
When of R99 and HSPA traffic is allocated in the same cell, they will actively share the radio and
logical resources in the cell. Figure 93Figure 93Figure 90 presents and example of the effect of
DCH power reservation on the HSDPA cell throughput. Figure 94Figure 94Figure 91 presents
the effect of HS-PDSCH code allocation on the code tree occupancy and number of available
SF32 codes used for 64kbps connections. This resource sharing can cause some performance
degradation on both R99 and HSPA users
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 105 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
2500
HSDPA cell throughput
2000
1500
5 codes
15 codes
10 codes
1000
500
0
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
55%
60%
DCH pow er, % of PA
Figure 939390. Effect of DCH power on HSDPA throughput.
120
99.2
SF128 code occupancy - %
100
93
86.7
80.5
80
74.2
67.2
60.9
SF128 occupancy
54.7
60
Free SF32 codes
48.4
42.2
40
31
35.2
20
20
18
16
14
12
10
8
3.1
6
4
2
0
13
14
15
0
0
5
6
7
8
9
10
11
12
Number of allocated HS-PDSCH codes
Figure 949491. HS-PDSCH code reservation.
7.1 Power, Code and CE (HSUPA) sharing
7.1.1 DL power sharing
The power sharing between HSDPA and DCH traffic can be monitored based on the PtxTotal
and PtxNonHSDPA measurements reported by the BTS. Non-real time bearer power (PtxNRT)
can be monitored separately; it is calculated by the RNC as the sum of dedicated power
measurements of NRT bearers received from BTS.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 106 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 95Figure 95Figure 92 presents an example (BTS measurements from Online-monitoring)
of power sharing between HSDPA and NRT DCH traffic. The dynamic resource allocation is
active and all available power is allocated to HSDPA (about 4W is used by CCCHs) with
maximum of 15.5 W. The HSDPA power is averaged over the reporting period and it depends
also on the HSDPA activity (TTI activity%). In RU10, Spectral efficient link adaption reduces HSDSCH transmission power of the low data rate users and users in good radio conditions based
on function of compensated CQI, TB size, number of HS-PDSCH codes and modulation. Basic
principle of power sharing between r99 and HSDPA still works similarly as in RAS06, but now
HSDPA only use power it needs and not necessarily all power available for HSDPA.
Figure 959592. DL power sharing between HSDPA and NRT PS traffic.
The cell level DL power measurements are stored to number of counters and KPIs, Table
28Table 28Table 26 lists the main counters/KPIs and related measurements from BTS. HSDPA
transmit power is calculated as PtxTotal – PtxNonHSPA.
Table 282826. PIs related power sharing between HSPA and R99 traffic
PI ref
PI name / Abbreviation
PI unit
Report: Cell Capacity RSRAN067
RNC_102b
Average R99 Downlink Load
dBm
RNC_690a
Average active non-HSDPA power ratio
%
RNC_691a
Average non-HSDPA power ratio
%
M1000C236
MIN_HSPA_DL_POWER
dBm
M1000C237
MAX_HSPA_DL_POWER
dBm
M1000C238
AVE_HSPA_DL_POWER
dBm
M1000C232
MIN_PTX_TARGET_PS
dBm
M1000C233
MAX_PTX_TARGET_PS
dBm
M1000C234
AVE_PTX_TARGET_PS
dBm
RNC_101b
Average Uplink R99 Load
dBm
RNC_177b
Noise floor of the System
dBm*-100.0
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 107 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
M5000C154
HSUPA_UL_PWR_MIN
dBm
M5000C155
HSUPA_UL_PWR_MAX
dBm
M5000C156
HSUPA_UL_PWR_AVG
dBm
Report: NRT Radio Bearer PBS and OLC RSRAN013
M1000C142
RB_DOWNGR_DUE_OLC_TFC_SUBS
#
M1000C154
RB_DOWNGR_DUE_OLC_RL_RECONF
#
M1000C166
RB_RELEASE_DUE_OLC_RL_RECONF
#
M1000C147
RB_DOWNGR_DUE_PBS_INTERF
#
M1000C152
RB_DOWNGR_DUE_PRE_EMP_INTERF
#
M1000C159
RB_RELEASE_DUE_PBS_INTERF
#
M1000C164
RB_RELEASE_DUE_PRE_EMP_INTF
#
The main interest is on the monitoring of available DL power for HSDPA and also how much of
this power is actually used. The available power can be measured based on the
M1000C138_AVG_NON_HSDPA_PWR counter or Average DL Load RNC_102b KPI. The
HSDPA power utilisation can be measured as ratio of average HSDPA power
AVE_HSPA_DL_POWER and average available HSDPA power.
Low level of available HSDPA power will have an effect on the peak data rates in the cell.
HSDPA cell throughput limitation can be detected when the power utilisation increases.
HSDPA DL power
availability
AVG_NON_HSDPA
_POWER > 50%
No
Yes
Consider activation of 2
nd
carrier for HSPA
HSDPA power
utilization > 50%
No
Check other
resources
Figure 969693. DL power sharing analysis.
HSDPA power counters show average or maximum during measurement period. Increase R99
traffic decrease the HSDPA power as they share the same resource. However, average HSDPA
power can low due the low utilisation (low HSDPA activity) as can be seen in Figure 97Figure
97Figure 94 below. It is feasible to monitor cells with high HSDPA activity (50-60%) but low
HSDPA power.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 108 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 979794. Average HSDPA power vs. HSDPA Utilisation
Below is one example of HSDPA power compared to Average DL/UL load. With Dynamic power
allocation / resource allocation it is possible to use all left over power for HSDPA. HSDPA power
measurement with averaged input values.
Hourly UL/DL load example
45.00
-99.00
40.00
-99.50
-100.00
-100.50
30.00
-101.00
25.00
-101.50
20.00
UL Load
DL_load/Pwr_ratio
35.00
-102.00
15.00
-102.50
10.00
-103.00
-103.50
0.00
-104.00
19
.1
1
19 .20
.1 08
_
1
19 .20 _00
:
.1 08
1.
_ 00
19 20 _02 :00
:
.1 08
__ 00:
1.
00
0
19 20
.1 08 4:0
1
0
_
19 .20 _06 :00
:
.1 08
_ 00
1
19 .20 _08 :00
:
.1 08
1
_ 00
19 .20 _10 :00
.1 08
:
1
_ 00
19 .20 _12 :00
:
.1 08
_ 00
1
19 .20 _14 :00
:
.1 08
1
_ 00
19 .20 _16 :00
:
.1 08
_ 00
1
19 .20 _18 :00
:
.1 08
1.
__ 00:
00
2
20 20
.1 08 0:0
__ 0:
1.
22 00
20 20
:
.1 08
1
_ 00
20 .20 _00 :00
:
.1 08
_ 00
1
20 .20 _02 :00
:
.1 08
1
_ 00
20 .20 _04 :00
:
.1 08
_ 00
1
20 .20 _06 :00
:
.1 08
1
_ 00
20 .20 _08 :00
:
.1 08
_ 00
1
20 .20 _10 :00
:
.1 08
1
_ 00
20 .20 _14 :00
:
.1 08
__ 00:
1.
00
1
20 20
.1 08 6:0
1.
__ 0:
18 00
20 20
:
.1 08
_ 00
1.
20 _2 :00
08 0:0
__ 0:
22 00
:0
0:
00
5.00
RNC_102b_Avg_DL_load (dBm)
RNC_690a_Pwr_ratio,_act_non-HSDPA (%)
RNC_691a_Pwr_ratio,_non-HSDPA (%)
M1000C238_Avg_HSDPA_DL_Power (dBm)
M1000C237_Max_HSDPA_power (dBm)
RNC_101b_Avg_UL_load (dBm)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 109 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 989895. Average UL and DL load as a function of HSDPA power
Minimum, average and maximum HSUPA UL physical channel power (M5000C154-156) could
be used to see how UL power is changing in due to HSUPA. Right now they seem not giving
reasonable values (-112 dBm during most of the cases).
7.1.2 Channelisation code tree sharing
The DL Channelisation code tree is shared by the HSDPA traffic, DCH traffic and CCCHs. When
HSDPA is activated in the cell it reserves a minimum reservation of 5 codes out of 16 SF16
codes. The code reservation for HSDPA and R99 traffic is controlled by following principles and
monitored by the KPIs and counters. Table 29Table 29Table 27 lists the main PIs related to
channelisation code tree reservation and sharing.
Table 292927. PIs related to channelisation code sharing between HSPA and R99 traffic.
PI ref
PI name / Abbreviation
PI unit
Report: Cell Capacity RSRAN067
RNC_113a
Average occupancy
%
RNC_520b
Max occupancy
%
RNC_519b
Min occupancy
%
M1000C83
NBR_SUCC_CODE_TREE_ALLO
#
RNC_949a(b)
Spreading Code Blocking rate in DL
%
RNC_512b
SF4 blocking rate
%
RNC_513b
SF8 blocking rate
%
RNC_514b
SF16 blocking rate
%
RNC_515b
SF32 blocking rate
%
RNC_516b
SF64 blocking rate
%
RNC_517b
SF128 blocking rate
%
RNC_518b
SF256 blocking rate
%
M1000C266
CH_CODE_DOWNG_RT
#
M1000C267
CH_CODE_DOWNG_NRT_DCH
#
Report: NRT Radio Bearer PBS and OLC RSRAN013
M1000C148
RB_DOWNGR_DUE_PBS_SPREAD
#
M1000C153
RB_DOWNGR_DUE_PRE_EMP_SPREAD
#
M1000C160
RB_RELEASE_DUE_PBS_SPREAD
#
M1000C165
RB_RELEASE_DUE_PRE_EMP_SPREA
#
Report: HSPA Code and Modulation Usage RSRAN034
M1000C248258
DURA_HSDPA_x_CODE (from 5-15)
The HSDPA code reservation is increased when the first HSDPA connection is setup to the cell
or periodically while the HSDPA is active in the cell, if the cell is configured with higher number
of codes than 5 (up to 15) and the UE support that also. HSDPA code reservation can be
increased until the number of free SF16 codes is less that HSPDSCHMarginSF128 parameter.
This parameter tells how much margin is reserved in the code tree. This parameter could be set
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 110 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
even to zero, because RT calls will pre-empt or downgrade HSDPA codes if SF16 codes are
fully used. This can be seen in the Figure 99Figure 99Figure 96.
Figure 999996. HSDPA Code downgrade due to AMR with HSPDSCHMarginSF128=0
The total code occupancy of R99+HSDPA traffic can be monitored with RNC_113a (Average
occupancy), RNC_520b (Max occupancy, M1000C75), RNC_519b (Min Occupancy) and
HSDPA code usage counters M1000C248-258. The graph below present an example of code
tree occupancy and HSDPA code usage. In the below example the code occupancy is low when
the HSDPA code allocation is at minimum (5 codes static allocation), which indicated low
amount of R99 traffic. According to code tree occupancy calculations, the allocation of 10 HSPDSCH codes raises code occupancy to about 70% without any R99 traffic, with 5 HS-PDSCH
codes the reservation is minimum 38%. These figures correspond quite closely the presented
example.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 111 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Code Tree Occupancy vs Available HSDPA Codes
90.00
DURATION_HSDPA_5_CODES
DURATION_HSDPA_8_CODES
DURATION_HSDPA_10_CODES
AVERAGE_CODE_TREE_OCCUPANCY
100.00
90.00
80.00
80.00
Estimated HSDPA Available Codes
70.00
60.00
50.00
50.00
40.00
40.00
30.00
30.00
20.00
Actual Available Codes for HSDPA
70.00
60.00
20.00
10.00
0.00
0.00
20
0
20 804
0 13
20 804 15
0 13
20 804 20
0 14
20 804 01
0 14
20 804 06
0 14
20 804 11
0 14
20 804 16
0 14
20 804 21
0 15
20 804 02
0 15
20 804 07
0 15
20 804 14
0 15
20 804 19
0 16
20 804 00
0 16
20 804 05
0 16
20 804 10
0 16
20 804 15
0 16
20 804 20
0 17
20 804 01
0 17
20 804 06
0 17
20 804 11
0 17
20 804 16
0 17
20 804 21
0 18
20 804 02
0 18
20 804 07
0 18
20 804 12
0 18
20 804 19
0 19
20 804 00
0 19
20 804 17
0 19
20 804 22
0 20
20 804 18
0 21
20 804 03
0 21
20 804 09
0 21
20 804 14
0 21
20 804 19
0 22
20 804 00
0 22
20 804 05
0 22
20 804 10
08 22
04 16
22
21
10.00
Figure 10010097. Example of HSDPA code allocation and spreading code occupancy [8]‎[8][8].
Codes 5-15 can be allocated as wanted from network point of view. The default set is to use
codes like 5, 8, 10, 12, 14 and 15 with 15 codes feature. But it is also possible to use all codes
from network point of view by changing just the code usage by HS-PDSCH code set in RNC.
RNC_2093a can be used to monitor average number of reserved SF16 codes for HSDPA. This
KPI is based on duration of HSDPA x code counters (M1000C248-C258).
The picture below shows that regardless of UE category and code capability, the network
allocates all available codes for HSDPA. Also if network allocates possible codes (like default
values) UE can still use other number of codes depending on the situation. Cat9 UE supports 15
codes, Cat8 UE supports 10 codes and Cat UE 6 supports 5 codes.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 112 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 10110198. Example of HSDPA & NRT code allocation duration with different UEs
The PS NRT allocation (upgrade or initial bit rate) can fail if there is no free code for NRT DCH.
A code allocation failure causes typically the packet scheduler to allocate of lower bit rate
(higher SF) if possible.
The overall code blocking can be monitored with RNC_949b (Spreading Code Blocking rate in
DL) and per SF with Blocking rate of SF due to No codes available: PIs RNC_512b-RNC_518b,
counters M1000C76-82, M1000C89. The total R99 code requests are given in SF requests
M1000C259-265. Figure 102Figure 102Figure 99 presents an example of code occupancy and
code tree blocking rate. It shows that when the average code occupancy increases above 50%,
the maximum code occupancy reaches 100% and code tree blocking rate increases.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 113 (123)
20
.1
2 0 1 .2
.1 0 0
2 0 1 .2 8 _
.1 00 _1
20 1.2 8_ 6:0
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:
20 1.2 8_ 6:0 00
.1 00 _1 0:0
1. 8_ 6: 0
20 _ 00
08 16 :0
_ _ :0 0 0
1 6 :0
:0 0
0:
00
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
RNC_113a_Code_occup,_avg
Copyright © Nokia Siemens Networks 2008
RNC_520a_Code_occup,_max
Company confidential
Date:
175.110.2010
Version 2.10
120.00
100.00
80.00
60.00
40.00
20.00
0.00
RNC_519a_Code_occup,_min
Figure 10210299. Code tree occupancy.
Low amount of code blocking can be tolerated as it is typically due to NRT DCH allocation
attempts for low SF bearers (SF8 and SF16). Figure 103Figure 103Figure 100 presents and
example of increased code tree blocking rate and the SF(s) that cause the blocking.
Page 114 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
5.00
9
4.50
8
4.00
7
3.50
Code_BR
5
2.50
4
Code_DG
6
3.00
2.00
3
1.50
2
1.00
1
0.00
0
19
.1
1.
19 200
.1
8_
1.
_
19 200 00
.1
8 _ :0 0
1.
:0
_
0
19 200 02
.1
8 _ :0 0
1.
:0
_
0
19 200 04
:0
.1
1. 8__ 0:0
0
19 200 06
.1
8 _ :0 0
1.
:0
_
0
19 200 08
.1
8 _ :0 0
1.
:0
_
0
19 200 10
.1
8 _ :0 0
1.
:0
_
0
19 200 12
.1
8 _ :0 0
1.
:0
_
0
19 200 14
.1
8 _ :0 0
1.
:0
_
0
19 200 16
.1
8 _ :0 0
1.
_1 :00
2
19
0
8
.1 08_ :00
1
:0
_
0
20 .200 20
:0
.1
1. 8__ 0:0
2
2
0
20
0
2
.1 08_ :00
1.
_0 :00
2
20
0
0
.1 08_ :00
1.
:0
_
0
20 200 02
.1
8 _ :0 0
1.
_0 :00
2
20
0
4
.1 08_ :00
1.
:0
_
0
20 200 06
.1
8 _ :0 0
1.
:0
_
0
20 200 08
.1
8 _ :0 0
1
:0
_
0
20 .200 10
:0
.1
1. 8__ 0:0
0
20 200 14
.1
8 _ :0 0
1.
:0
_
0
20 200 16
.1
8 _ :0 0
1.
:0
_
0
20 200 18
.1
8 _ :0 0
1.
20 _20 :00
08
:0
__ 0:0
22
0
:0
0:
00
0.50
RNC_949a_BR_Code_tree
RNC_512a_BR_SF4
RNC_513a_BR_SF8
RNC_514a_BR_SF16
RNC_515a_BR_SF32
RNC_516a_BR_SF64
RCN_517a_BR_SF128
RNC_518a_BR_SF256
HSDPA_CH_code_DG_due_RT
HSDPA_CH_code_DG_due_NRT
Figure 103103100. Code tree blocking, with code downgrade due to congestion.
An incoming RT call will always downgrade (pre-empt) the HSDPA code reservation. Also PS
NRT allocation (upgrade or initial bit rate) can fail if there is code congestion. A code allocation
failure causes typically the packet scheduler to allocate of lower bit rate (higher SF) if possible.
The code tree congestion can cause also that the NRT RB are downgraded or released by PBS
or pre-emption due to code tree congestion. RB downgrade/release due to code congestion can
be seen from the RS RSRAN013 and the counters are:




M1000C148_RB_DOWNGRADE_BY_PBS_DUE_TO_SPREADING_CODE_CONGESTION
M1000C153_RB_DOWNGRADE_BY_PREEMPTION_DUE_TO_SPREADING_CODE_CONGESTION
M1000C160_RB_RELEASE_BY_PBS_DUE_TO_SPREADING_CODE_CONGESTION
M1000C165_RB_RELEASE_BY_PREEMPTION_DUE_TO_SPREADING_CODE_CONGESTION
The request for NRT can downgrade the HSDPA allocation only if the parameter
DPCHOverHSPDSCHThreshold allows it. The amount of downgrades can be monitored with
HSDPA CH CODE DOWNGRADE DUE TO RT M1000C266 and HSDPA CH CODE
DOWNGRADE DUE TO NRT DCH M1000C267.
In case this parameter is set to zero, there should not be room to downgrade HSDPA codes for
NRT. However it has been tested that when the parameter DPCHOverHSPDSCHThreshold is
set to zero, it is still possible to allocate NRT calls. Code downgrade happens already during RT
signalling phase. This is seen in the next picture, note the the last 2 samples are with the
parameter value of 5, so more code downgrade can be seen in that case.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 115 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
Figure 104104101. Code downgrade due to NRT with DPCHOverHSPDSCHThreshold=0.
Also it was found that when network is allocating all available codes for HSDPA and there is no
UE capability to fully utilize those, it is not possible to use remaining codes for PS NRT when the
parameter DPCHOverHSPDSCHThreshold is set to zero.
Figure 105105102. Setup fails with DPCHOverHSPDSCHThreshold=0.
It that case for example it can be seen that req_PS_rej_DL counter is updated as there is
capacity upgrade requests from initial bitrate to maximum. This can also seen as
req_PS_rej_UL and PS setup fail AC, which is updated only when there is initial capacity
request from DCH 0/0 or from FACH. Both cases means that there is no DL codes available.
It will be recommended not to use zero value for this parameter unless HSDPA will be the only
service for Data service.
7.1.3 WBTS resource sharing
HSDPA has a static reservation from WBTS resources. This reservation depends on the
HSDPA scheduler type and number of schedulers active in the BTS. The resource reservation
of R99 traffic depends on the traffic level and can be significant in shared carrier.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 116 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
The HSDPA return channel is critical from BTS HW availability point of view especially in areas
with high HSDPA traffic. The return channel can utilise NRT DCH or HSUPA channel type. NRT
DCH return channel reserves BTS resources from the UL channel element pool. Table 30Table
30Table 28 presents the CE reservation of DCH bearers. The HSDPA return channel bit rates
and CE reservations are highlighted.
Table 303028. WBTS CE reservation of DCH bearers. In RU10, less CE needed with high bitrate
(384 kbps) with Flexi Rel2 HW system module. Less CE also needed for HSDPA users in Uplink
(return channel) if 384 kbps is used.
Bearer data rate
CE UL/min SF
CE DL/min SF
SRB 3.4/13.4 kbps
1/ SF256
1/ SF256
AMR (voice) 1)
1/ SF64
1/ SF128
WB-AMR 2)
1 / SF64
1 / SF128
CS 64 kbps
4 / SF16
4 / SF32
PS 16 kbps
1 / SF64
1 / SF128
PS 32 kbps
2 / SF32
2 / SF64
PS 64 kbps
4 / SF16
4 / SF32
PS 128 kbps
4 / SF8
4 / SF16
PS 256 kbps
8 / SF4
8 / SF8
PS 384 kbps
16 / SF4
16 / SF8
HSUPA return channel reservation the DCH and E-DCH resources share the same DSP
resource pool. The DCH has the highest priority, and when the resources are left from the DCH,
the resources are given to the E-DCH. The HSUPA will have a minimum resource allocation of 8
CE in RAS06 and 0 CE in RU10, this can not be allocated to DCH. The maximum total number
of HSUPA users and total throughput depends on the amount of available CE resources,
example table from RU20 below: Different HSUPA resource step table is used for HSUPA 2ms
and 10 ms TTI features. There is also differences between BTS type and HWs.
Table 313129 UL/DL CE reservation example for HSUPA when Flexi Rel2 SM is used with
10ms TTI. (RU20)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 117 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Number of
HSUPA UEs per
LCG
1- 3
4- 6
7- 9
10-12
13-15
16-18
19-21
22-24
25-27
28-30
31-33
34-36
37-39
40-42
43-45
46-51
51-60
61-72
73-80
1,4
2,8
4,2
5,6
7
8,4
9,8 11,2 12,6
14
15,4 16,8 18,2 19,6
21
Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps
18
18
36
36
36
54
54
72
72
72
90
90
108
108
108
126
144
162
180
18
36
36
36
54
54
72
72
72
72
90
108
108
108
126
126
144
162
180
36
36
36
54
54
54
72
72
90
90
108
108
108
108
126
144
144
162
180
36
36
54
72
72
72
72
72
90
90
108
108
126
126
144
144
144
162
180
n/a
54
54
72
90
90
90
90
90
90
108
108
126
126
144
162
162
180
180
n/a
54
54
72
90
108
108
108
108
108
108
108
126
126
144
162
180
n/a
n/a
n/a
72
72
72
90
108
126
126
126
126
126
126
126
126
144
162
180
n/a
n/a
n/a
72
72
90
90
108
126
144
144
144
144
144
144
144
144
162
180
n/a
n/a
n/a
n/a
90
108
108
108
126
144
162
162
162
162
162
162
162
180
n/a
n/a
n/a
n/a
n/a
108
108
108
126
144
162
162
180
180
180
180
180
180
180
n/a
n/a
n/a
n/a
n/a
108
126
126
144
144
162
180
180
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
126
144
144
144
162
180
180
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
144
144
162
180
180
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
162
162
180
180
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
162
162
180
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
The BTS HW resource status can be monitored with WBTS HW resource counters in the M5001
counter table. This measurement supports the measurement of total available CE capacity
(licensed), CE reservation and HSUPA specific CE reservation
The total CE reservation can be monitored with maximum, minimum and average used CE
counters and RNC KPIs like RNC_959a (Maximum Used CE's ratio), RNC_730a (Average Ratio
of Utilised CE for DL in BTS) and RNC_731a (Average Ratio of Utilised CE for UL in BTS).
The HSUPA CE reservation can be monitored with maximum and minimum used CE counters
and RNC KPIs RNC_947a and RNC_948a (Average ratio of utilised CE for DL/UL for HSUPA in
BTS).
A HSUPA throughput limitation due to lack of CEs is indicated by the following counters:



1000C268 BTS HSUPA NOT HW LIMITED DURATION: In this state, the BTS HW does
not limit the HSUPA throughput.
1000C269 BTS HSUPA HW LIMITED DURATION: In this state, the RNC sets up the EDCH but the BTS HW shortage may cause the throughput to be lower than expected
1000C270 BTS HSUPA HW NO CAPACITY DURATION: In this state, the RNC does not
set up the E-DCH
The PIs discussed above together with other BTS resource related PIs are listed in table below.
Table 323230. PIs related power sharing between HSPA and R99 traffic
PI ref
PI name / Abbreviation
PI unit
Report: Node B Capacity RSRAN066
RNC_955b
PS Call Setup FR due to BTS
%
RNC_924a
RRC stp fail rate BTS (RU10 RS)
%
RNC_925a
RAB stp fail rate BTS (RU10 RS)
%
RNC_673d
HSDPA Access FR due to BTS
%
RNC_956a
E-DCH Setup FR due to BTS
%
RNC_957b
E-DCH Not Selected due the BTS HW
%
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 118 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
RNC_958a
RL Setup FR due the MISC
%
M1000C268
BTS_HSUPA_HW_NOT_LIMITED_DUR
S
M1000C269
BTS_HSUPA_HW_LIMITED_DUR
S
M1000C270
BTS_HSUPA_NO_HW_CAPA_DUR
S
M5001C0
MAX_AVAIL_CE
Integer number
M5001C1
MIN_AVAIL_CE
Integer number
M5001C2
AVG_AVAIL_CE
Integer number
RNC_830a
CE situation change indication
#
M5001C3
MAX_USED_CE_DL
Integer number
M5001C4
MAX_USED_CE_UL
Integer number
RNC_959a
Maximum Used CE's ratio
%
M5001C5
MIN_USED_CE_DL
Integer number
M5001C6
MIN_USED_CE_UL
Integer number
RNC_822a
Average free CEs
#
RNC_730a
Average ratio of utilized CE for DL in BTS
%
RNC_731a
Average ratio of utilized CE for UL in BTS
%
M5001C9
MAX_HSUPA_CE_UL
Integer number
M5001C12
MAX_HSUPA_CE_DL
Integer number
M5001C10
MIN_HSUPA_CE_UL
Integer number
M5001C13
MIN_HSUPA_CE_DL
Integer number
RNC_947a
Average ratio of utilized CE for DL for HSUPA in BTS
%
RNC_948a
Average ratio of utilized CE for UL for HSUPA in BTS
%
Report: NRT Radio Bearer PBS and OLC RSRAN013
M1000C146
RB_DOWNGR_DUE_PBS_BTS
#
M1000C151
RB_DOWNGR_DUE_PRE_EMP_BTS
#
M1000C158
RB_RELEASE_DUE_PBS_BTS
#
M1000C163
RB_RELEASE_DUE_PRE_EMP_BTS
#
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 119 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure 106Figure 106Figure 103 below presents an example of BTS resource reservation with
HSDPA. The minimum UL and DL resource reservation is 56 (16 for CCHs, 8 for HSUPA and 32
for HSDPA). It also shows that the maximum UL reservation is normally higher.
180
100.00
160
90.00
140
80.00
Max_Used_CE_DL
70.00
Max_Used_CE_UL
120
Min_Used_CE_DL
60.00
100
Min_Used_CE_UL
50.00
RNC_822a_Avg_free_CE's
80
40.00
60
30.00
40
20.00
10.00
0
0.00
RNC_730a_Avg_Ratio_of_Utilised_CE_for_
DL_in_BTS
RNC_731a_Avg_Ratio_of_Utilised_CE_for_
UL_in_BTS
19
.
19 11.2
.1 0
19 1.2 08
. 0 _
19 11. 08 _00
.1 20 __ :0
19 1.2 08 01 0:0
. 0 _ :0 0
19 11. 08 _02 0:0
.1 20 __ :0 0
19 1.2 08 03 0:0
. 0 _ :0 0
19 11. 08 _04 0:0
.1 20 __ :0 0
19 1.2 08 05 0:0
. 0 _ :0 0
19 11. 08 _06 0:0
.1 20 __ :0 0
19 1.2 08 07 0:0
. 0 _ :0 0
19 11. 08 _08 0:0
. 20 _ :0 0
19 11. 08 _09 0:0
.1 20 _ :0 0
19 1.2 08 _10 0:0
. 0 _ :0 0
19 11. 08 _11 0:0
.1 20 __ :0 0
19 1.2 08 12 0:0
. 0 _ :0 0
19 11. 08 _13 0:0
.1 20 __ :0 0
19 1.2 08 14 0:0
. 0 _ :0 0
19 11. 08 _15 0:0
.1 20 __ :0 0
19 1.2 08 16 0:0
. 0 _ :0 0
19 11. 08 _17 0:0
.1 20 __ :00 0
1. 08 18 :0
20 _ :0 0
08 _1 0:
__ 9:0 00
20 0:
:0 00
0:
00
20
RNC_959a_Max_Used_CE's_ratio
Figure 106106103. Example of WBTS resource sharing with HSDPA (RAS06)
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 120 (123)
NPO/NSO Capability Management
Date:
175.110.2010
Version 2.10
Data Performance Optimisation Guide for
RU10/RU20
Figure below shows an example of WBTS resource reservation with HSUPA. With high level of
HSDPA return channel on DCH causes typically high UL reservation. The maximum HSUPA
reservation is 64, which is for example due to user with >1.4 Mbps throughput in Ultrasite BTS.
70
14.00
60
12.00
50
10.00
40
8.00
30
6.00
Max_Used_CE_HSUPA_UL
Max_Used_CE_HSUPA_DL
Min_Used_CE_HSUPA_UL
Min_Used_CE_HSUPA_DL
4.00
10
2.00
0
0.00
19
.1
1 9 1 .2
.1 0
19 1.2 08
.1 0 _ _
19 1.2 08 00
.1 0 _ _ :0
19 1.2 08 01 0:0
.1 0 _ _ :0 0
19 1.2 08 02 0:0
.1 0 _ _ :0 0
19 1.2 08 03 0:0
.1 0 _ _ :0 0
19 1.2 08 04 0:0
.1 0 _ _ :0 0
19 1.2 08 05 0:0
.1 0 _ _ :0 0
19 1.2 08 06 0:0
.1 0 _ _ :0 0
19 1.2 08 07 0:0
.1 0 _ _ :0 0
19 1.2 08 08 0:0
.1 0 _ _ :0 0
19 1.2 08 09 0:0
.1 0 _ _ :0 0
19 1.2 08 10 0:0
.1 0 _ _ :0 0
19 1.2 08 11 0:0
.1 0 _ _ :0 0
19 1.2 08 12 0:0
.1 0 _ _ :0 0
19 1.2 08 13 0:0
.1 0 _ _ :0 0
19 1.2 08 14 0:0
.1 0 _ _ :0 0
19 1.2 08 15 0:0
.1 0 _ _ :0 0
19 1.2 08 16 0:0
.1 0 _ _ :0 0
19 1.2 08 17 0:0
.1 0 0 _ _ :0 0 0
1 . 8 1 8 :0
20 __ :0 0
08 19 0:
__ :0 00
20 0:0
:0 0
0:
00
20
RNC_947a_Avg_ratio_of_utilised_CE_for_D
L_for_HSUPA_in_BTS
RNC_948a_Avg_ratio_of_utilised_CE_for_U
L_for_HSUPA_in_BTS
Figure 107107104. Example of WBTS resource sharing with HSUPA (RAS06)
Lack of BTS resources is the most common reason for HSDPA and HSUPA accessibility
failures. These failures are monitored with KPIs: RNC_674a (HSDPA Access FR due the BTS),
RNC_956a (E-DCH Setup FR due the BTS), RNC_957a (E-DCH Not Selected due the BTS
HW). More about the return channel performance in Sections 0‎00 and 6.1.3‎6.1.36.1.3.
7.2 Effect of HSPA on R99 performance
The main concern related to effect of HSPA traffic on R99 traffic performance is typically related
to additional interference caused by HSDPA in DL. This is easy to understand in a case when
the HSDPA transmission increases the BTS transmit power from typical 8 W to maximum of 20
W in matter of milliseconds. This increased level of interference can cause call setup problems
and call drops. The decreased Ec/No can also increase the amount of inter-system handovers
or cell re-selections to GSM, as the Ec/No is typically used as the main criteria triggering the
procedures.
Figure 108Figure 108Figure 105 presents an example of network performance for two years
from the HSDPA launch. In this example the AMR call Retainability is even improved despite the
increased HSDPA traffic. The HSDPA accessibility and retainability are slightly dropped, but still
remain in good level.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 121 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
2500000
Date:
175.110.2010
Version 2.10
100.00
99.00
2000000
98.00
97.00
RNC_229a/RAB Attempts CS Voice
1500000
96.00
95.00
1000000
94.00
RNC_614a/HS-DSCH selections
RNC_231b/RAB Success ratio, CS Voice
RNC_605a/HSDPA Accessibility for NRT
Traffic from User point of View
RNC_609a/HSDPA Retainability for NRT
Traffic
93.00
500000
92.00
91.00
90.00
06
2
09 006
2 (0
12 006 6/0
2 (2 2/2
15 006 7/0 00
2 (2 2/2 6)
18 006 0/0 00
2 (1 3/2 6)
21 006 0/0 00
2 (0 4/2 6)
24 006 1/0 00
2 (2 5/2 6)
27 006 2/0 00
2 (1 5/2 6)
30 006 2/0 00
2 (0 6/2 6)
33 006 3/0 00
2 (2 7/2 6)
36 006 4/0 00
2 (1 7/2 6)
39 006 4/0 00
2 (0 8/2 6)
42 006 4/0 00
2 (2 9/2 6)
45 006 5/0 00
2 (1 9/2 6)
48 006 6/1 00
2 (0 0/2 6)
51 006 6/1 00
2 (2 1/2 6)
02 006 7/1 00
2 (1 1/2 6)
05 007 8/1 00
20 (0 2/2 6)
07 8/0 00
(2 1/2 6)
9/ 00
01 7
/2 )
00
7)
0
Figure 108108105. Effect of increased HSDPA traffic on CS RAB and HSPA bearer performance.
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 122 (123)
NPO/NSO Capability Management
Data Performance Optimisation Guide for
RU10/RU20
Date:
175.110.2010
Version 2.10
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
HSPA Radio Network Planning Guide https://sharenetims.inside.nokiasiemensnetworks.com/Open/378112337
3G Radio Network Planning Guidelines for RAS06 and RU10
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/363676257
RAS06 Product Documentation
'KPI for HSDPA Planning', 1st January 2007
Multilayer planning guideline https://sharenetims.inside.nokiasiemensnetworks.com/Open/383626385
Flexi WCDMA BTS sales guide - Baseband dimensioning
https://sharenetims.inside.nokiasiemensnetworks.com/livelink/livelink/guest/Download/360111458
Packet Scheduler optimisation guide
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/364909596
Capacity Management Workshop –phase 2, Jussi Reunanen et all.
Capacity Management Guide
https://sharenetims.inside.nokiasiemensnetworks.com/Open/363972983
HSDPA & HSUPA throughput and parameter testing in NTN https://sharenetims.inside.nokiasiemensnetworks.com/Open/398619055
LAM RAS06 Experiences, Paul Larsen 12/2008
RAN E2E system performance optimization guide
KPI list and targets recommendation doc https://sharenetims.inside.nokiasiemensnetworks.com/Open/364616733
RAN QoS Provisioning Guide https://sharenetims.inside.nokiasiemensnetworks.com/Guest/Overview/408667477
RSRAN RU10 Full Report Set, Inacio Rui 2009 http://nopi.nokiasiemensnetworks.com/reportmanager/htmlset.php?set=426&co=1&m=1&se=1
Copyright © Nokia Siemens Networks 2008
Company confidential
Page 123 (123)