260220995 data performance optimization guidelines

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 â&#x20AC;&#x201C; 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 â&#x20AC;&#x201C; 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 â&#x20AC;&#x201C;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)