Ericsson UMTS Feature Guidelines FSC Performance Engineering
Document Initiated Revision Number Revision Date
July 17, 2007 3.0 Sep 11, 2008
Š Copyright 2007 T-Mobile USA, Inc. All rights reserved. Confidential and proprietary information of T-Mobile USA, Inc. Not for distribution outside T-Mobile.
Ericsson UMTS Feature Guidelines
Document Information The information in these materials is confidential and proprietary to T-Mobile USA, Inc. These materials are authorized for the use of TMobile USA service providers and their employees and agents, solely for the purposes of the agreement under which these materials are provided. The rights granted hereunder constitute a limited, nonexclusive, revocable license and not a transfer of title. Authorized TMobile USA service providers and their employees and agents may view, copy or print pages of these materials solely for the purposes set forth herein, but may not otherwise use, modify, copy, print, display, reproduce, distribute, transmit, publish, license, sublicense or create derivative works from these materials in whole or in part, or remove any copyright or other proprietary notices set forth herein, without the express written permission of T-Mobile USA. The information in these materials is subject to change without notice. T-Mobile USA's liability for any errors in these materials is limited to the documentary correction of errors. T-Mobile USA will not be responsible in any event for errors in these materials or for any damages, incidental or consequential (including monetary losses), that might arise from the use of these materials or the information in them. T-Mobile, the T-Mobile logo and the World Class logo are registered or unregistered trademarks of Deutsche Telekom AG.
Acknowledgements The following individuals are responsible for contribution to the specifications, design and implementations represented in the various revisions: Alejandro Aguirre Changbo Wen Dinesh Arcotkumar Pankaj Chopra Ryan Kolln Shubhankar Saha Sireesha Panchagnula
Protection of Information Credibility This document contains confidential material critical to the business and is therefore a controlled document. Outdated copies must be destroyed to prevent erroneous use of obsolete information and compromised security of confidential material. Do not e-mail this file. Do send the link to correspondents so they are assured of seeing the latest revision. The most recent revision of this file is always in softcopy and can be accessed at the following link. http://docs.eng.t-mobile.com/InfoRouter/docs/~F93804 Note to revisers: For the above link to remain valid, you must use proper check out / check in procedures when you update this document.
Revision Code The revision number will reflect the modifications by following the format Rev. x, y, where X is the first digit, incremented for changes of substance, i.e. technical/procedural issues. Y is the second digit, incremented when editorial only changes have been incorporated. All draft/preliminary versions are 0.n; the first final version is Revision 1.0.
Revision History Rev. Date 0.1
07/17/2007
T-Mobile USA, INC. Confidential
Author
Information
Alejandro Aguirre and Sireesha Panchagnula
Initial document for Ericsson UMTS features covering Neighbor List, Soft Handover, 3G to 3G cell Reselection and Location and Routing Area.
Rev. 3.0
Sep 11, 2008
2 of 214
Ericsson UMTS Feature Guidelines
0.2
8/07/07
Sireesha Panchagnula
0.21 0.3
8/09/07 8/28/07
0.4
9/26/07
Sireesha Panchagnula Ryan Kolln, Sireesha Panchagnula Alejandro Aguirre and Sireesha Panchagnula
0.5
11/26/07
Sireesha Panchagnula
0.6
12/5/07
0.7
3/28/08
Alejandro Aguirre, Dinesh Arcotkumar and Sireesha Panchagnula Sireesha Panchagnula
0.8
5/12/2008
Sireesha Panchagnula
2.0 –
8/8/2008
Sireesha Panchagnula
9/11/2008
Sireesha Panchagnula
version number skip to make it compatib le with version numberin g on Info Router.
3.0
T-Mobile USA, INC. Confidential
Updates made to original content in IRAT Guideline and transferred to this document for Ericsson 3G. Same content as V 0.2. V0.21 has tracking disabled. Power Control Section added to the document. Added sections Call setup, Random Access Procedure and Paging. Additional content to section 10.7. based on feedback form south region. Added sections Capacity Management Overview, Admission Control and Congestion Control Added content on UE States, PS data services and Channel switching 1. Added content on HSDPA feature (section 21) and data strategy (section22). 2. Added section 22 with complete list of UTRAN parameter recommendations. 3. Added summary of channel switching tables in section 20.10. 4. Updates to IRAT parameters strategy. 1. Updates to HSDPA section to make it compatible with P6 release. 1. Update to section 21.4.1 to be compatible with P6. 2. Updated section 20 for P6. 3. Updated section 10 for P6 compatibility. 4. Updated section 14 and 15 for P6 compatibility. 5. Updated section 16 for P6 compatibility
Added Inter Frequency Feature in section 11 – preliminary will be modified close to actual deployment of 2nd carrier.
Rev. 3.0
Sep 11, 2008
3 of 214
Ericsson UMTS Feature Guidelines
Table of Contents 1. 2.
1.1. 1.2.
2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.2. 3. 3.1. 3.2. 3.3. 3.4. 4. 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.2. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.4. 4.5. 4.5.1. 4.5.2. 4.5.3. 4.6. 4.7. 4.7.1. 4.7.2. 4.7.3. 4.7.4. 5. 5.1. 5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.1.5. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 6.
Introduction ....................................................................................................................... 9 Purpose & Scope...........................................................................................................................9 Definitions for this Document.........................................................................................................9 Neighbor List .................................................................................................................... 12 Monitored Set Creation ................................................................................................................ 12 Neighbor Cell Priority................................................................................................................... 13 IAF Monitored Subset Creation..................................................................................................... 13 Field example of Monitored set creation .......................................................................................15 IEF and GSM Monitored Subset Creation ......................................................................................15 Neighbor List Creation and Priority ............................................................................................... 15 3G to 2G Neighbor List Generation .................................................................................. 18 UMTS to GSM 1:1 overlay with matched azimuths ......................................................................... 18 UMTS to GSM 1:1 overlay with mis-matched azimuths ..................................................................19 UMTS site without overlay ........................................................................................................... 19 New GSM site added to the 2G Network .......................................................................................20 Idle Mode Process ............................................................................................................ 21 PLMN Selection ........................................................................................................................... 22 PLMN Selection at UE switch on ................................................................................................... 22 PLMN selection in Automatic Mode ............................................................................................... 22 PLMN Selection in Manual Mode ...................................................................................................24 PLMN Selection while Roaming .................................................................................................... 24 Cell Selection Procedure in UTRAN state ....................................................................................... 24 Cell Reselection Parameters from 3G to 3G ................................................................................... 26 Measurements ............................................................................................................................ 26 Eligibility..................................................................................................................................... 26 Ranking ...................................................................................................................................... 27 Recommended Values for 3G to 3G Selection and Reselection parameters ...................................... 28 Cell Reselection Parameters from 3G to 2G ................................................................................... 28 Measurements ............................................................................................................................ 28 Eligibility..................................................................................................................................... 30 Ranking ...................................................................................................................................... 30 Recommended Values for 3G to 2G Reselection parameters .......................................................... 32 Location and Routing Area Registration and Updating ...................................................................33 Terminology ............................................................................................................................... 33 Normal LA and RA Updating ........................................................................................................ 33 Periodic LA and RA Updating ....................................................................................................... 33 IMSI Attach/Detach .....................................................................................................................34 Call Setup Procedure ........................................................................................................ 36 Circuit Switched Call Setup .......................................................................................................... 36 RRC Setup Phase, CS Voice ......................................................................................................... 36 Pre-RAB Phase, CS Voice ............................................................................................................. 37 RAB Setup Phase, CS Voice ......................................................................................................... 40 Counters Related to CS Voice Call Setup .......................................................................................42 Circuit Switched Voice Accessibility KPI......................................................................................... 46 Packet Switched Call Setup .......................................................................................................... 47 RRC Setup Phase, PS Setup ......................................................................................................... 47 Pre-RAB Phase, PS Setup.............................................................................................................48 RAB Setup Phase, PS Setup ......................................................................................................... 50 Counters Related to PS Setup ...................................................................................................... 52 Packet Switched Accessibility KPI ................................................................................................. 54 Random Access Procedure ............................................................................................... 55
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
4 of 214
Ericsson UMTS Feature Guidelines
6.1. Random Access Overview ............................................................................................................ 55 6.1.1. Random Access Channels ............................................................................................................ 55 6.1.2. Open Loop Power Control ............................................................................................................ 56 6.1.3. Physical Layer Random Access Procedure ..................................................................................... 57 6.1.4. MAC Monitoring and Control of Random Access Transmissions....................................................... 59 6.1.5. RRC Control or Random Access Transmissions ..............................................................................60 6.1.6. Interaction of RRC, MAC and Physical Layer Random Access Procedures ........................................ 61 6.1.7. RACH Sub-Channels .................................................................................................................... 62 6.1.8. Access Class and Access Service Class ..........................................................................................63 6.2. Random Access Parameter Optimization and Troubleshooting ........................................................ 65 7. Paging Procedures............................................................................................................ 67 7.1. Paging Types .............................................................................................................................. 68 7.1.1. Paging Type 1............................................................................................................................. 68 7.1.2. Paging Type 2............................................................................................................................. 69 7.2. Paging Channels ......................................................................................................................... 70 7.2.1. Paging Indication Channel ........................................................................................................... 70 7.3. DRX Procedure ........................................................................................................................... 71 7.4. Paging Repetition ........................................................................................................................ 73 7.5. Ericsson Specific Counters for Paging ........................................................................................... 73 7.5.1. Ericsson Paging Counters ............................................................................................................ 73 8. Soft/Softer Handover ....................................................................................................... 75 8.1. Soft/Softer Handover Procedure and Parameters .......................................................................... 75 8.1.1. Event 1a Evaluation .................................................................................................................... 77 8.1.2. Event 1b Evaluation .................................................................................................................... 78 8.1.3. Event 1c Evaluation .....................................................................................................................79 8.1.4. Event 1d Evaluation .................................................................................................................... 80 8.1.5. Event Triggered Periodical Measurement Reporting .......................................................................82 8.1.6. Buffering and Queuing ................................................................................................................ 82 8.1.7. Soft/Softer Handover Execution ................................................................................................... 82 8.1.8. Soft/Soft Handover Signaling ....................................................................................................... 83 8.1.9. ReleaseConnOffset setting ........................................................................................................... 85 9. Compressed Mode Operation ........................................................................................... 86 9.1. Halving the Spreading factor (SF/2) Method ................................................................................. 86 9.2. Higher Layered Scheduling (HLS) Method: .................................................................................... 87 9.3. Compressed Mode Pattern ........................................................................................................... 87 9.4. Limitations on number of mobiles in Compressed Mode ................................................................. 88 10. 3G to 2G Handover and Cell Change ................................................................................ 89 10.1. T-Mobile Strategy for IRAT .......................................................................................................... 89 10.2. Feature Activation ....................................................................................................................... 89 10.3. IRAT Interaction with Inter-Frequency Handover .......................................................................... 90 10.4. 3G to 2G IRAT Handover/Cell Change Procedure ..........................................................................90 10.4.1. Event based Connection quality monitoring ..................................................................................90 10.4.2. Event based GSM measurements reporting ................................................................................... 94 10.4.3. Identification of target GSM cell for Handover/Cell Change ............................................................ 97 10.4.4. 3G to 2G IRAT Handover/Cell Change Execution ...........................................................................97 10.5. Scenarios for 3G to 2G IRAT Handover / Cell Change .................................................................. 102 10.5.1. Edge Thresholds ....................................................................................................................... 103 10.5.2. Core Thresholds ........................................................................................................................ 103 10.6. Parameter recommendations for IRAT Scenarios ......................................................................... 103 10.7. 3G to 2G IRAT Handover/Cell Change Optimization Strategy........................................................ 104 11. 3G to 3G Inter Frequency Handover .............................................................................. 106 11.1. Feature Activation ..................................................................................................................... 106 11.2. Inter-Frequency Handover Interaction with IRAT Handover ......................................................... 106
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
5 of 214
Ericsson UMTS Feature Guidelines
11.3. Inter-Frequency Handover Procedure ......................................................................................... 106 11.3.1. Event based Connection quality monitoring ................................................................................ 107 11.3.2. Event based GSM measurements reporting ................................................................................. 107 11.3.3. Identification of target cell for IF Handover ................................................................................ 108 11.3.4. 3G to 3G IF Handover execution. ............................................................................................... 108 12. Emergency Call treatment .............................................................................................. 111 13. 2G to 3G IRAT Cell Reselection ...................................................................................... 113 13.1. Ericsson 2G to Ericsson 3G Reselection....................................................................................... 113 13.1.1. Measurements on WCDMA neighbors in idle mode ...................................................................... 114 13.1.2. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation ..................................... 114 13.1.3. Cell Reselection to UMTS for mobiles that support RSCP evaluation.............................................. 116 13.2. Nokia 2G to Ericsson 3G Reselection .......................................................................................... 116 13.2.1. UTRAN Neighbor Definitions and System Information .................................................................. 117 13.2.2. Measurements on WCDMA neighbors in idle mode ...................................................................... 117 13.2.3. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation ..................................... 118 13.2.4. Cell Reselection to UMTS for mobiles that support RSCP evaluation.............................................. 119 13.3. Nortel 2G to Ericsson 3G Reselection .......................................................................................... 120 13.3.1. Measurements on WCDMA neighbors in idle mode ...................................................................... 121 13.3.2. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation ..................................... 121 13.3.3. Cell Reselection to UMTS for mobiles that support RSCP evaluation.............................................. 122 13.4. 2G to 3G Reselection Parameter Recommendations .................................................................... 123 13.4.1. Ericsson BSS ............................................................................................................................. 123 13.4.2. Nokia BSS................................................................................................................................. 123 13.4.3. Nortel BSS ................................................................................................................................ 123 14. Capacity Management Overview .................................................................................... 124 14.1. Overview of UMTS Resources .................................................................................................... 125 14.1.1. DL Power ................................................................................................................................. 125 14.1.2. Received Total Wideband Power ................................................................................................ 126 14.1.3. OVSF Codes .............................................................................................................................. 126 14.1.4. RBS Channel Elements .............................................................................................................. 127 14.2. Common Resource Utilization..................................................................................................... 128 14.2.1. Overhead and Common Channels .............................................................................................. 128 14.2.2. Maximum Downlink Transmission Power .................................................................................... 130 14.2.3. HSDPA Resources ..................................................................................................................... 130 14.3. Dedicated Monitor Resource Handling ........................................................................................ 131 14.3.1. Downlink Channelization Code Monitor ....................................................................................... 131 14.3.2. Downlink Transmitted Carrier Power .......................................................................................... 132 14.3.3. ASE Monitor.............................................................................................................................. 133 14.3.4. RTWP Monitor .......................................................................................................................... 134 14.3.5. RBS Hardware Monitor .............................................................................................................. 134 14.4. Services Class and Setup Type ................................................................................................... 134 14.4.1. Service Class ............................................................................................................................ 134 14.4.2. Setup Type ............................................................................................................................... 134 15. Admission Control .......................................................................................................... 136 15.1. ARP attributes........................................................................................................................... 137 15.2. Enhanced Soft Congestion ......................................................................................................... 137 15.3. Admission Policies ..................................................................................................................... 137 15.3.1. Downlink Channelization Code Admission ................................................................................... 137 15.3.2. Downlink Transmitted Carrier Power Admission........................................................................... 138 15.3.3. Downlink ASE Admission ........................................................................................................... 138 15.3.4. Uplink ASE Admission ................................................................................................................ 138 15.3.5. Downlink Spreading Factor Admission ........................................................................................ 138 15.3.6. Uplink Spreading Factor Admission ............................................................................................. 138
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
6 of 214
Ericsson UMTS Feature Guidelines
15.3.7. Compressed Mode Admission ..................................................................................................... 139 15.3.8. HSDPA Admission ..................................................................................................................... 139 15.3.9. Downlink Node B Hardware Admission ....................................................................................... 140 15.3.10. Uplink Node B Hardware Admission ............................................................................................ 140 15.4. Counters Related to Admission Control ....................................................................................... 140 16. Congestion Control ......................................................................................................... 144 16.1. Congestion Detection ................................................................................................................ 144 16.1.1. Uplink Cell Congestion ............................................................................................................... 144 16.1.2. Downlink Cell Congestion .......................................................................................................... 146 16.1.3. DL HSDPA Cell Congestion ......................................................................................................... 147 16.2. Resolution of Congestion ........................................................................................................... 147 16.3. Counters Related to Congestion Control ..................................................................................... 148 17. Power Control................................................................................................................. 155 17.1. Importance of Power Control ..................................................................................................... 155 17.2. Overall Power Control Procedure ................................................................................................ 155 17.3. Power Control of downlink common channels ............................................................................. 156 17.4. Open Loop Power Control (Power Control of uplink common channels) ........................................ 157 17.5. Power Control of Dedicated channels ......................................................................................... 159 17.5.1. Initial Downlink Power Setting ................................................................................................... 160 17.5.2. Downlink Power Limits .............................................................................................................. 162 17.5.3. Initial Uplink Power Setting ........................................................................................................ 164 17.5.4. Initial Uplink SIR Target Setting ................................................................................................. 165 17.5.5. Uplink Outer Loop Power Control ............................................................................................... 165 17.5.6. Downlink Outer Loop Power Control ........................................................................................... 167 17.5.7. Downlink Inner Loop Power Control ........................................................................................... 167 17.5.8. Uplink Inner Loop Power Control................................................................................................ 168 17.6. Power Control during Soft Handover .......................................................................................... 168 17.6.1. Uplink power control during SHO ............................................................................................... 168 17.6.2. Downlink power control during Soft Handover ............................................................................ 169 17.7. Power Control during Compressed Mode .................................................................................... 172 17.7.1. Uplink Power Control in Compressed Mode ................................................................................. 172 17.7.2. Downlink Power Control in Compressed Mode............................................................................. 172 17.8. Power Control Scenarios ............................................................................................................ 173 17.8.1. Power Control steps for Radio Link Setup Procedure ................................................................... 173 17.8.2. Power Control steps for RAB Establishment ................................................................................ 173 17.8.3. Power Control steps for Soft Handover ....................................................................................... 174 17.9. Example of Power Control Procedure .......................................................................................... 174 18. UE States ........................................................................................................................ 176 18.1. Cell_DCH .................................................................................................................................. 176 18.1.1. CELL_DCH to CELL_FACH state .................................................................................................. 177 18.2. Cell_FACH ................................................................................................................................ 177 18.2.1. CELL_FACH to CELL_DCH .......................................................................................................... 177 18.2.2. CELL_FACH to URA_PCH ........................................................................................................... 178 18.3. URA_PCH ................................................................................................................................. 178 18.3.1. URA_PCH to CELL_FACH ........................................................................................................... 179 18.3.2. URA_PCH to IDLE ..................................................................................................................... 179 19. R99 PS Data.................................................................................................................... 180 19.1. Radio bearer QoS ...................................................................................................................... 180 19.2. Differentiation between traffic classes ........................................................................................ 180 19.3. Radio Resource Management for packet data services ................................................................. 181 19.4. Active Queue Management feature ............................................................................................ 181 19.5. Channel Switching Feature ........................................................................................................ 182 19.6. Channel Switching Triggers ....................................................................................................... 182
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
7 of 214
Ericsson UMTS Feature Guidelines
19.7. Triggers for Dedicated to Dedicated channel switching ................................................................ 183 19.7.1. Throughput-triggered Upswitch ................................................................................................. 183 19.7.2. Throughput-triggered Downswitch ............................................................................................. 183 19.7.3. Coverage-triggered downswitch ................................................................................................. 183 19.8. Multi RAB State Transitions ........................................................................................................ 184 19.8.1. Speech + Interactive ................................................................................................................. 184 19.8.2. 2xInteractive ............................................................................................................................ 184 19.8.3. Speech + 2xInteractive ............................................................................................................. 185 20. Channel Switching .......................................................................................................... 186 20.1. Common to Dedicated Evaluation............................................................................................... 186 20.2. Dedicated to Common Evaluation............................................................................................... 187 20.3. Common to URA Evaluation ....................................................................................................... 188 20.4. URA to Idle Evaluation .............................................................................................................. 188 20.5. Coverage Triggered Downswitch Evaluation ................................................................................ 188 20.6. Dedicated to Dedicated Upswitch Evaluation ............................................................................... 189 20.7. Throughput Based Dedicated to Dedicated Downswitch Evaluation .............................................. 191 20.8. Multi RAB Downswitch Evaluation .............................................................................................. 191 20.9. Multi RAB Upswitch Evaluation ................................................................................................... 192 20.10. Channel Switching Parameter Optimization ................................................................................. 192 21. High Speed Downlink Packet Access (HSDPA)............................................................... 194 21.1. HSDPA Codes Allocation ............................................................................................................ 194 21.2. HSDPA Scheduler Option ........................................................................................................... 194 21.3. Hybrid ARQ Options .................................................................................................................. 195 21.4. Admission and Congestion Control for HSDPA ............................................................................. 195 21.4.1. Channel type selection between HS-DSCH and DCH .................................................................... 195 21.5. HSDPA Power Control ................................................................................................................ 197 21.5.1. HSDPA Power Usage ................................................................................................................. 197 21.5.2. HS-SCCH Power ........................................................................................................................ 197 21.5.3. HS-DPCCH Power Control .......................................................................................................... 197 21.6. Channel Quality Estimation ........................................................................................................ 198 21.7. Iub Flow Control ....................................................................................................................... 198 21.8. HSDPA Mobility – Serving HS-DSCH Cell Change ......................................................................... 200 21.8.1. HS-DSCH Cell Change due to change of best cell ........................................................................ 201 21.8.2. HS-DSCH Cell Change due to removal of serving HS cell .............................................................. 202 21.9. HSDPA Mobility – Coverage triggered downswitch ....................................................................... 202 21.10. HSDPA Mobility over IuR without HS support .............................................................................. 202 21.11. Effect of HSDPA on R99 ............................................................................................................ 203 22. Data Services Strategy ................................................................................................... 205 23. Parameter Recommendations ........................................................................................ 206 24. Appendix A: Weighting Factor Analysis for Soft Handover Algorithm ........................... 207 24.1. Event 1a evaluation................................................................................................................... 207 24.2. Event 1b evaluation .................................................................................................................. 208 24.3. Tradeoff due to weighting factor ................................................................................................ 208 25. Appendix B: Monitored Set Creation Field Example ....................................................... 210 25.1. Description ............................................................................................................................... 210 25.2. Execution ................................................................................................................................. 210 25.3. Neighbor Lists ........................................................................................................................... 210 25.4. Results ..................................................................................................................................... 210 26. References ...................................................................................................................... 214
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
8 of 214
Ericsson UMTS Feature Guidelines
1. Introduction 1.1. Purpose & Scope The intent of this document is to introduce important UMTS features from an Ericsson Radio Access Network (RAN) perspective, and provide detailed algorithms and parameters related to these features. Where applicable, T-Mobile USA’s strategy for deploying these features is provided from a performance point of view. This document also provides parameter recommendations required to realize the outlined strategy. In the initial phase, these recommended values are based on vendor recommendations and prior UMTS experience. Once UMTS networks are available for testing, these parameters will be tested and updated with new recommended values. The recommended values are listed at the end of the document under the “Parameter Recommendations” section for all UTRAN features. The parameters and algorithms described here are applicable to the P6 release of the Ericsson UTRAN. This document is not all inclusive and is only intended to provide a quick reference to some of the various UMTS features available in the Ericsson UMTS RAN. For any information not covered here, the vendor product documentation should be referenced.
1.2. Definitions for this Document Term or Acronym 3GPP
Definition Third Generation Partnership Project
AS
Active Set
BSIC
Base Station Identity Code
BTS
Base Transceiver Station
CN
Core Network
CPICH
Common Pilot Channel
DCH
Dedicated Channel
DL
DownLink
DPCCH
Dedicated Physical Control Channel
DPCH
Dedicated Physical Channel
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
9 of 214
Ericsson UMTS Feature Guidelines
DRNC
Drift Radio Network Controller
FACH
Forward Access Channel
FIFO
First In First Out
GERAN
GSM EDGE RAN
GSM
Global System for Mobile Communications
HCS
Hierarchical Cell Structure
HSDPA
High Speed Data Packet Access
IAF
Intra Frequency
IE
Information Element
IEF
Inter Frequency
IFHO
Inter Frequency HandOver
Inter-RAT
Inter Radio Access Technology
IRAT
Inter Radio Access Technology
Iur
Interface between two RNCs
KPI
Key Parameter Indicator
LA
Location Area
LAI
Location Area Indicator
NBAP Node B
Node B Application Part Logical node responsible for radio transmission and reception in one or several cells
OCNS
Orthogonal Channel Noise Simulator
PLMN
Public Land Mobile Network
RA
Routing Area
RAB
Radio Access Bearer
RAI
Routing Area Indicator
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
10 of 214
Ericsson UMTS Feature Guidelines
RAN
Radio Access Network
RAT
Radio Access Technology
RB RBS
Radio Bearer Radio Base Station – another name for the Node B
RF
Radio Frequency
RL
Radio Link
RNC
Radio Network Controller
RRC
Radio Resource Control
RSCP
Received Signal Code Power
RSSI
Received Signal Strength Indicator
SIB
System Information Block
SIR
Signal to Interference Ratio
TRX
Transceiver
TX
Transmit
UE
User Equipment
UL UMTS
UpLink Universal Services
UTRAN
UMTS Terrestrial Radio Access Network
WCDMA
Wideband Code Division Multiple Access
T-Mobile USA, INC. Confidential
Mobile
Rev. 3.0
Telecommunication
Sep 11, 2008
11 of 214
Ericsson UMTS Feature Guidelines
2. Neighbor List Neighbor List creation is crucial to the proper operation of a WCDMA network. When the UE is in connected mode, the RNC follows it on cell level. Once it knows in which cell the UE is located, the RNC checks information about all the neighboring cells and transmits the data back to the UE. The RNC updates continuously the neighbor cell lists in order to reflect the changing neighborhood of a moving mobile station in connected mode. By relaying information about neighbor cells to the UE, the RNC is effectively telling it what to look for, and the RNC knows what the available options are if the load in the serving cell increases. Neighbor cell definitions also speed up cell re-selection procedures, as the UE does not have to decode the scrambling codes of other cells. The cells in a WCDMA RAN, from the UE’s point of view are divided into the following sets as per 3GPP 25.331 [4].
Active Set: The cells involved in Soft/Softer Handover and measured by the UE.
Virtual Active Set: The Active set associated with a non-used frequency for support of Inter-Frequency evaluation.
Monitored Set: The cells measured by the UE but not part of the Active Set. The monitored set is further divided into intra-frequency monitored subset, interfrequency monitored subset and GSM monitored subset.
Detected Set: The intra frequency cells (P-CPICH scrambling codes) detected by the UE but not part of the Monitored Set.
The number of Intra-frequency cells in the Monitored Set + the Active Set cells is limited to 32 as per [4]. The number of Inter-Frequency cells in the Monitored set is limited to 32. The number of Inter-RAT cells in the Monitored set is limited to 32.
2.1. Monitored Set Creation The maximum number of cells that a UE is required to measure according to [4] is 32 of each type - Intra-Frequency, Inter-Frequency and GSM cells. For IEF cells, the number may be divided between a maximum of two frequencies. The IAF monitored subset always includes the cells in the active set. The IAF Monitored Subset is obtained by performing Monitored Subset Reduction with MaxMonSubset=MaxIafMonSubset = C_MaxSohoListSubset(32) –PresActiveSet, where PresActiveSet is the number of cells in the present Active Set. It is equal to 1 when the connection is set up on CELL_DCH. The cells in the Reduced IAF neighbor Cell Lists that are not included in the IAF Monitored Subset shall be retained in the IAF Unmonitored Subset. The IAF Unmonitored Subset is used to check if a reported cell, belonging to the Detected Set, is a valid cell. The IEF Monitored Subset is obtained by performing Monitored Subset Reduction with
MaxMonSubset=MaxIefMonSubset = maxIefMonSubset(32). A maximum of two unused
frequencies are included in the IEF Monitored Set, if a third frequency is found during the filtering process then all “third-frequency” inter frequency neighbor cells are discarded.
The GSM Monitored subset is obtained by performing Monitored Subset reduction with MaxMonSubset=MaxGSMMonSubset = maxGsmMonSubset(32).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
12 of 214
Ericsson UMTS Feature Guidelines
Recommended Values: The parameters maxIefMonSubset and maxGsmMonSubset are recommended to be set to a value of 32. The parameter C_MaxSohoListSubset is a constant hard coded value and is set to 32 by Ericsson. The listed set sent to the UE contains the Active Set cells, plus the monitored set cells. The monitored set is created from the neighbor cell lists of all the cells in the Active Set, and if the resulting Monitored subset contained in the listed set becomes larger than MaxMonSubset, some of the neighbor cells will be removed and stored in the unmonitored set.
2.1.1.
Neighbor Cell Priority
The neighbor cell priority defined by selectionPriority is used when building the monitored set, so that neighbor cells with higher priority are included before low priority neighbors, for each cell in the active set. The neighbor priorities are not compared between different cells in the active set, priorities only apply among defined neighbors out from the same cell. If several neighbors are given the same priority, the order between them is not defined. The highest priority is 1, which should be given to the most important neighbors. If no value or a value of zero is entered when a neighbor is defined, the system will automatically set it to the currently highest used value of selectionPriority + 1, that is, to the currently lowest priority definition for the source cell and for the relation type (Intra / Inter / GSM).This priority can be set separately for IAF, IEF and GSM neighbors. Refer to section “Neighbor List Creation and Priority� for the procedure to assign the Neighbor Cell priority for different neighbors of a serving cell.
2.1.2.
IAF Monitored Subset Creation
If possible, a specific cell’s position in the listed set sent to the UE is retained in consecutive measurement control messages. Cells that are removed from the IAF Monitored subset and not sent to the UE, are retained in the IAF Unmonitored subset. If there is only one cell (A) in the Active Set, a monitored set containing the first 31 neighbors of this cell is created in priority order (based on the setting of parameter selectionPriority). When a second cell (B) is added to the Active Set, and assuming that Cell (A) is reported as the strongest cell in the 1a event triggered measurement report, the monitored set is created in the following manner. Add both the active cells (A) and (B) to the listed set in the same position as they existed previously. Take the neighbor cell with the highest priority for the best active set cell, cell (A), and if it already exists in the old listed set, add it to the new listed set in the same position. If it does not exist in the old listed set, then the position does not matter; therefore store it for addition later in a temporary array. Take the neighbor cell with the highest priority for the second best active set cell (B), and if it already exists in the old listed set, add it to the new listed set in the same position. If it does not exist in the old listed set, then the position does not matter and it can be stored in a temporary array for addition later. Store the neighboring cell only if it does not already exist in the temporary array to avoid duplications. If it is already stored in the temporary
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
13 of 214
Ericsson UMTS Feature Guidelines
array, take the next neighboring cell in priority order from the next cell in the Active Set, cell (A) applying the same rules. Repeat until all neighbor cells have been processed or until MaxIafMonSubset number of neighboring cells have been selected for the listed set. Take the cells that have been selected to be included in the new listed set that are stored in the temporary array and add them to the listed set by filling the empty spaces. The neighboring cells are picked from the temporary array in the order they were stored (FIFO). This makes sure that neighboring cells stored early in the temporary array will be the first to fill out the spaces in the listed set. If the listed set gets full (reaches a value of C_MaxSohoListSubset), remaining unprocessed neighbor cells or cells in the temporary array shall instead be stored in the unmonitored set, without duplicates. If the Active Set contains more than 2 cells, the above algorithm can be expanded to include the neighboring cells of all the active set cells. Below is an illustration of the combined monitored set, when the Active set has 3 cells. The following figure shows the individual neighbor lists for the 3 cells in the active set.
Assume that Cell A is the strongest cell and Cell C is the weakest cell. The combined monitored set when the active set contains all 3 cells is shown below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
14 of 214
Ericsson UMTS Feature Guidelines
2.1.3.
Field example of Monitored set creation
Refer to Appendix B for a field example of the monitored set creation for event 1a when there is initially 1 cell in the Active set.
2.1.4.
IEF and GSM Monitored Subset Creation
The IEF and GSM Monitored sets don’t contain any Active set cells, and there is no unmonitored set in these cases. The maximum number of cells in the monitored subsets is maxIefMonSubset and maxGsmMonSubset respectively. Otherwise, the same approach as described in the previous section is used when creating the IEF and GSM monitored subsets.
2.2. Neighbor List Creation and Priority A good cell plan and correctly defined neighbor cell list is the foundation for good handover behavior. Due to the restriction in the number of neighbors that is possible to monitor as per [4], superfluous neighbors should not be defined. On the other hand, it is important for all true neighbor cells to be defined. A UE will approach an undefined neighbor cell without adding it to the Active Set, and will therefore not be power controlled by the cell. If the UE comes close to an undefined neighbor, it will cause destructive interference that in the worst case leads to dropped calls. By defining a large number of neighbors per each cell, there is a risk that the combined neighbor list would exceed the maximum limit of 32 cells when the Active Set contains more
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
15 of 214
Ericsson UMTS Feature Guidelines
than 1 cell. Hence it is important to define only the required neighbors. In addition to this risk, for Ericsson networks, there is an additional disadvantage of defining a large number of neighbors, which is covered below. Recommended Value: It is recommended not to exceed 16 neighbor definitions per each serving cell for the Intra Frequency case. This recommendation is based partly on vendor recommendations. This number will be updated in the future based on network performance and needs. This section will be updated with recommendations for IEF neighbors in the future when more than one WCDMA carrier is deployed in T-Mobile networks. Refer to the next section for the recommendations on neighbor list size for the GSM neighbor case. Though the recommended maximum neighbor list size is 16 neighbors, it is foreseen that in most cases depending on the network plan, a much smaller number of neighbor definitions will be needed for most serving cells. There may also be a few cases, where due to cell site locations issues caused by zoning, a neighbor list greater than 16 may been needed. However these cases should be limited to a minimum number and used only when absolutely required. Since the priority of neighbors per each serving cell plays a huge part in the creation of the unmonitored set, it is very important to plan the neighbor list with the correct priorities for each neighbor. One property of the Monitored set reduction algorithm in Ericsson RAN is that if cells in the active set have a large difference in number of neighbors, all of equal importance; for example, cell A = 32 and Cell B = 10, then assuming that these cells have a very small number of common neighbors, Cell A with the most neighbors will be penalized relative to cell B by the monitored set reduction algorithm, since cell B will get all its neighbors into the monitored set, but only a subset of Cell A’s neighbors may be included. This can be controlled to a certain extent by assigning the correct priorities to the neighbors, such that the more important neighbors of Cell A will be selected into the combined neighbor list. The following are some options that can be used for constructing the priorities of the IAF neighbor list. Refer to the next section for the GSM neighbor list creation. The IEF neighbor list creation will be covered in future updates when a second WCDMA carrier is planned to be deployed. 
Option 1: Visualization of the cell proximities to assign higher priorities for neighbors that are closer to the serving cell, with lower priorities as we radiate farther away form the server. This option while being a very basic and practical approach might take longer to implement.

Option 2: The neighbors of the underlying GSM cell of any serving WCDMA cell can be ordered based on the number of handover attempts obtained from GSM statistics, with the highest priority for neighbors with the most handover attempts. This ordered GSM neighbor list can then be translated in to an ordered UMTS neighbor list by replacing each of the GSM neighbors with the corresponding overlay UMTS cell. This option results in the most automated way to create a neighbor list as long as the UMTS site has the same sector configurations as the collocated GSM site, but would need manual work otherwise.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
16 of 214
Ericsson UMTS Feature Guidelines

Option 3: Scanner data if available can be processed to create an ordered IAF neighbor list. This can only be used if the entire network has scanner data available.

Option 4: For areas with weak coverage, which are covered by far away cells, it might be advisable to make sure these cells are defined as higher priority neighbors, even if they have lesser number of handover attempts, so as to keep a call alive in these poor coverage areas.
The options provided here should be treated only as a starting point, and should be further verified with planning tools and visual checks.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
17 of 214
Ericsson UMTS Feature Guidelines
3. 3G to 2G Neighbor List Generation GSM neighbor definitions are required for 3G to 2G handovers and 3G to 2G Reselection to work. It is recommended to define GSM neighbors for all UMTS cells in the network, irrespective of their location with respect to the edge of the coverage, and then use relevant parameters to disable IRAT handovers and reselection for UMTS cells that are well within the 3G coverage area. This would allow rescue handovers to work from 3G to 2G in case there is ever a service disruption on the UMTS network due to any reason. For Ericsson RAN, a UMTS cell can have up to 32 GSM cells defined as neighbors. However it is recommended to keep the GSM neighbor list to an optimum number as the time it takes for a UE to find a candidate GSM cell generally increases with longer neighbor lists. Keeping the neighbor list short would generally lead to less time in compressed mode and better retainability. More information on compressed mode and its effects are covered in a subsequent section. If the UMTS coverage falls quickly, the probability of quickly finding a suitable GSM candidate cell will increase, if there are fewer GSM cells to measure on. The following strategy for the creation of GSM neighbor lists for UMTS cells depends on the overlay configuration and utilizes existing neighbor lists on the GERAN network where possible. Planning tools can be used to run validation checks on neighbor lists created through this procedure. The following is the neighbor list creation strategy for all the possible overlay configurations. It should be noted that the intent of the following neighbor list tuning strategy is to create the initial GSM neighbor list for UMTS cells. Once the UMTS cell is integrated and enabled, scanner data from cluster drives, wherever available should be utilized to tune the UMTS GSM neighbor list. Ultimately, the UMTS neighbor lists should be based on the signal strength of the best server, not just the geographical proximity of the UMTS and GSM cells. Neighbor list tuning techniques are outside the scope of this document. In the Ericsson 3G network, neighbor priorities play an important role in the creation of a monitored set. Hence the following procedure addresses recommendations to assign priorities among neighbors for a particular UMTS cell. For any other cases that are not covered here, the GSM neighbor list should be planned using visual checks and planning tools as necessary.
3.1. UMTS to GSM 1:1 overlay with matched azimuths This scenario refers to the case where the UMTS site is co-located with the GSM site, and the UMTS cell azimuths are within +/- 15 degrees of the GSM azimuths. In addition, the UMTS antennas are required to have a horizontal beam width of 65 or 90 degrees. The recommended size of the GSM neighbor list for this configuration is 11 neighbors, with 8 neighbors generated from the following procedure and 3 neighbors reserved for any missing GSM cells found after validation checks. Procedure to generate GSM neighbors Identify the corresponding sector of the co-located GSM site for the UMTS cell. Add this GSM cell to the top of the neighbor list with highest priority.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
18 of 214
Ericsson UMTS Feature Guidelines
Add the other sectors of the co-located GSM site to this list starting with priority 2. Using the 2G network statistics, order the remaining 2G neighbors of the GSM cell as per number of handover attempts. Choose the top 5 neighbors and add them to the bottom of the above created list. Validate the list using visual checks or planning tools to make sure none of the obvious neighbors are missing. Make sure that all required in-building GSM cells are included, otherwise add them as necessary. Extend the neighbor list beyond 11, only if necessary to accommodate any missing 2G neighbors found after validation checks.
3.2. UMTS to GSM 1:1 overlay with mis-matched azimuths This scenario refers to the case where the UMTS site is co-located with the GSM site, but the UMTS sector azimuths are more than +/- 15 degrees different from the GSM azimuths. This solution can also be used for co-located sites with matched azimuths (within +/- 15 degrees of GSM), but with narrow horizontal beam widths (less than 65 degrees). The recommended size of the GSM neighbor list for this configuration is 14 neighbors with 11 neighbors generated from the following procedure and 3 neighbors reserved for any missing GSM cells found after validation checks. Procedure to generate GSM neighbors Add all sectors of the co-located GSM site to the top of the 3G -> 2G neighbor list with the highest priorities. Identify the two closest co-located GSM sectors for the UMTS cell. Using GSM statistics, order the combined 2G neighbor list of these 2 GSM sectors as per number of handover attempts. Choose the top 8 neighbors and add them to the bottom of the above created list with the next highest priorities. Validate the list using visual checks or planning tools to make sure none of the obvious neighbors are missing. Make sure that all required in-building GSM cells are included, otherwise add them as necessary. Extend the number of neighbors beyond 14, only if necessary to accommodate any missing 2G neighbors found after validation checks.
3.3. UMTS site without overlay This scenario refers to a new UMTS site without a co-located GSM site. In this case the GSM neighbors will have to be created using planning tools. The recommended size of the GSM neighbor list for this scenario is 11 neighbors. The neighbor list size should be extended beyond 11, only if required, to accommodate missing 2G neighbors after validation checks.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
19 of 214
Ericsson UMTS Feature Guidelines
3.4. New GSM site added to the 2G Network When a new GSM site is added to the 2G network, since GSM handover statistics would not available as soon as the new site is added, visual checks and planning tools will have to be used to ensure that the new GSM site is correctly configured as a neighbor to the relevant UMTS cells.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
20 of 214
Ericsson UMTS Feature Guidelines
4. Idle Mode Process The idle mode tasks are divided into the following 3 processes:
PLMN Selection
Cell Selection & Reselection
Location and Routing Areas Registration
The relationship between these 3 processes is shown in the figure below.
Camping on a cell is necessary for the UE to get access to some services in the network. The following three types of services are defined for the UE in Idle mode:
Limited service, which allows the UE to make emergency calls only on an acceptable cell.
Normal service, for public use on a suitable cell
Operator-related services, which allow the operator to test newly deployed cells without being disturbed by normal traffic.
An "acceptable cell" is a cell on which the UE may camp to obtain limited services (originate emergency calls). Such a cell fulfils the following requirements, which is the minimum set of requirements to initiate an emergency call in a UTRAN network:
The cell is not barred.
The cell selection criteria are fulfilled.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
21 of 214
Ericsson UMTS Feature Guidelines
A "suitable cell" is a cell on which the UE may camp on to obtain normal service. Such a cell fulfils all the following requirements.
The cell is part of the selected PLMN or, of the registered PLMN or, of a PLMN considered as equivalent by the UE according to the information provided by the NAS.
The cell is not barred.
The cell is not part of the list of "forbidden LAs for roaming".
The cell selection criteria are fulfilled.
A “barred cell” is a cell that is restricted (barred) to camp on for all access classes. This is indicated on SIB 3. A “reserved cell” is a cell that has been reserved for operator use where only UEs with USIM access class 11 or 15 can camp on. This is indicated on SIB 3.
4.1. PLMN Selection The PLMN selection for the various modes are detailed below.
4.1.1.
PLMN Selection at UE switch on
Whenever a UE is switched on or enters an area with acceptable coverage after coverage loss, it attempts to camp on the last registered PLMN or equivalent PLMN, if available. To speed up the PLMN selection procedure, the UE uses information about the last registered PLMN, such as carrier frequencies or the list of neighboring cells stored in the USIM before the UE was switched off. On each stored carrier frequency, the UE searches first for the cell with strongest signal and reads its system information to verify the PLMN to which the cell belongs. It also reads the system information for PLMN identity, which consists of MCC and MNC. Then the UE decides whether the chosen cell is acceptable or whether at least one acceptable cell belonging to that PLMN exists. Finally, the UE attempts registration if the PLMN is allowed. If the last registered PLMN is not available, a registration attempt fails. If there is no registered PLMN stored in the USIM, the UE selects and attempts registration on other PLMNs using either the Automatic mode or the Manual mode.
4.1.2.
PLMN selection in Automatic Mode
In Automatic mode, if no last registered PLMN exists or is available, the UE will select a PLMN that is available and allowed, in the following order:
Home PLMN (HPLMN), if not previously selected, according to the Radio Access Technologies (RATs) supported by the UE.
Each PLMN in the user-controlled PLMN list in the USIM, if present, in order of priority, according to the RATs supported by the UE
Each PLMN in the operator-controlled PLMN list in the USIM, in order of priority, according to the RATs supported by the UE.
Other PLMNs, according to the high-quality criterion, in random order.
Other PLMNs that do not fulfill high-quality criterion, in order of decreasing signal strength (SS).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
22 of 214
Ericsson UMTS Feature Guidelines
PLMNs are considered high quality if the Received CPICH RSCP fulfills the high-quality criterion. The high-quality criterion is fulfilled when CPICH RSCP level is greater than or equal to –95 dBm. For GSM cells the high-quality criterion is fulfilled when the signal level is above –85 dBm. A PLMN with at least one acceptable cell is considered available. If that PLMN is allowed, the UE tries to register on it. If registration is successful, the UE displays the selected PLMN. When the UE cannot register on any PLMN in the user and operator lists, it attempts to register on other PLMNs according to the high-quality criterion. If the UE cannot register on any PLMN, it selects an available PLMN and enters a limited service state. If it does not find an available PLMN, the UE enters the non-service state, and waits until a new PLMN is available and allowed. The following figure shows the PLMN selection procedure using the Automatic mode.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
23 of 214
Ericsson UMTS Feature Guidelines
4.1.3.
PLMN Selection in Manual Mode
The Manual mode allows the user to select a PLMN among those indicated by the UE. The UE displays all PLMNs that it finds by scanning all frequency carriers. The UE displays those PLMNs that are allowed as well as those that are not allowed. The user makes a manual selection, according to the available RAT for the chosen PLMN, and the UE attempts registration on this PLMN, ignoring the contents of the forbidden Location Area Identities (LAIs) and PLMN lists. If the user selects an available PLMN in the forbidden PLMN list, the UE attempts to register and may receive a positive acknowledgement from the CN. In this case, the PLMN is removed from the forbidden list. If the user does not select a PLMN, the selected PLMN is the one that was selected before the PLMN selection procedure started. If this PLMN is no longer available, the UE attempts to camp on an acceptable cell at any PLMN and enters the limited service state. The UE remains in that state until it is switched off or the user makes a manual PLMN reselection.
4.1.4.
PLMN Selection while Roaming
Roaming is a service through which a UE is able to obtain services from another PLMN in the same country (national roaming area) or another country (international roaming area). The behaviour that the UE must follow is specified by agreements among the network operators. A UE in automatic mode, having selected and registered on a Visited PLMN (VPLMN) in its home country, periodically attempts to return to its Home PLMN (HPLMN). The time interval between consecutive attempts is stored in the USIM and is managed by the network operator using a timer. The timer may have a value of between 6 minutes and 8 hours, with a step size of 6 minutes. In the absence of a fixed value, a default value of 60 minutes shall be used by the UE as per 3GPP 22.011. This timer is not a radio or core network parameter; it is stored in the USIM when provisioned. T-Mobile is setting this timer to 6 minutes.
4.2. Cell Selection Procedure in UTRAN state The cell selection and reselection process allows the UE to look for a suitable cell in the selected PLMN and to camp on it. The UE then camps on the suitable cell in a “camped normally’ state. In this state, the UE monitors paging and system information, performs periodical radio measurements, and evaluates cell reselection criteria. If the UE finds a better cell, that cell is selected by the cell reselection process. The change of cell may imply a change of the RAT. The purpose of camping on a cell in idle mode is the following:
It enables the UE to receive system information from the PLMN.
When registered and if the UE wishes to establish an RRC connection, it can do this by initially accessing the network on the control channel of the cell on which it is camped.
If the PLMN receives a call for the registered UE, it knows the registration area of the cell in which the UE is camped. It can then send a "paging" message for the UE on control channels of all the cells in the registration area. The UE will then receive the paging message because it is tuned to the control channel of a cell in that registration area and the UE can respond on that control channel.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
24 of 214
Ericsson UMTS Feature Guidelines
It enables the UE to receive cell broadcast services.
The UE attempts cell selection in the following cases:
When a UE is switched on
When a UE in idle mode has had a number of failed RRC connection requests
When a UE returns to idle mode from connected mode on common channels (CELL_FACH state) after a number of failed cell update attempts.
When a UE moves from dedicated mode to idle mode. The candidate cells for cell selection are the ones used immediately before leaving connected mode. If no suitable cell is found, the UE can use stored information cell selection procedure to find a suitable cell.
When a UE returns to idle mode after an emergency call on any PLMN. The UE selects an acceptable cell on which to camp. In this case, candidate cells for cell selection are the ones used immediately before leaving the connected mode. If no acceptable cell on that PLMN is found, the UE continues to search for an acceptable cell on any PLMN.
When a UE moves from dedicated mode to state CELL_FACH or URA_PCH.
The UE uses one of the following cell selection procedures:
Initial Cell Selection: This procedure requires no prior knowledge of which RF channels are UTRA carriers. The UE shall scan all RF channels in the UTRA bands according to its capabilities to find a suitable cell of the selected PLMN. On each carrier, the UE only needs to search for the strongest cell. Once a suitable cell is found this cell is selected.
Stored Information Cell Selection: This procedure requires stored information of carrier frequencies and optionally also information on cell parameters, e.g. scrambling codes, from previously received measurement control information elements. Once the UE has found a suitable cell for the selected PLMN the UE selects it. If no suitable cell of the selected PLMN is found, the Initial cell selection procedure is started.
The cell selection criterion S is fulfilled when the following is true. Squal > 0 and Srxlev > 0 The quantities Squal and Srxlev are defined as Squal = Qqualmeas - qQualMin and Srxlev = Qrxlevmeas - qRxLevMin – Pcompensation Qqualmeas is the quality of the received signal expressed as CPICH Ec/No and Qrxlevmeas is the received signal strength expressed as CPICH RSCP. The parameter qQualMin in object UtranCell indicates the minimum required quality value in the cell while the UtranCell parameter qRxLevMin indicates the minimum required signal strength in the cell. These values are sent in SIB 3 for the serving cell. Pcompensation = max (maxTxPowerUl - P, 0) Pcompensation is introduced for UEs that cannot transmit at maximum power on the RACH in the cell. The cell range decreases for those UEs. P is the output power of the UE
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
25 of 214
Ericsson UMTS Feature Guidelines
according to its class. The parameter maxTxPowerUl in the object UtranCell is the maximum allowed transmission power when the UE accesses the system on RACH. It is broadcast in SIB 3.
4.3. Cell Reselection Parameters from 3G to 3G The UE performs the cell reselection procedure in the following cases:
When the cell on which it is camping is no longer suitable.
When the UE, in “camped normally” state, has found a neighboring cell better than the cell on which it is camping.
When the UE is in “limited service” state on an acceptable cell.
The cell reselection process is divided into 3 steps – Measurements, Eligibility and Ranking. The parameters for each of these phases are detailed below.
4.3.1.
Measurements
A UE makes measurements on intra frequency neighbors when Squal <= sIntraSearch. The quantity Squal is defined as Squal = QqualMeas – qQualMin. Qqualmeas is the quality of the received signal in the serving cell, expressed as CPICH Ec/No. Hence If CPich_Ec/Nomeas > qQualMin + sIntraSearch , then no intra frequency measurements. If CPich_Ec/Nomeas <= qQualMin + sIntraSearch, then UE makes intra frequency measurements. If the parameter sIntraSearch is not sent for the serving cell (this is accomplished by setting the value of sIntraSearch = 0), the UE always performs intra frequency measurements. The parameters qQualMin and sIntraSearch are cell based parameters are found in the object UtranCell.
4.3.2.
Eligibility
The eligibility of the intra frequency neighbors for reselection is verified using the cell selection criteria (S criteria). The cell selection criterion S is fulfilled when Squal > 0 and Srxlev > 0 The quantities Squal and Srxlev are defined as Squal = Qqualmeas - qQualMin and Srxlev = Qrxlevmeas - qRxLevMin – Pcompensation Pcompensation = max (maxTxPowerUl - P, 0) As per the Ericsson implementation, the parameters qQualMin, qRxLevMin and maxTxPowerUl are the same as the ones found in the object UtranCell, and are not defined separately for the intra frequency neighboring cells.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
26 of 214
Ericsson UMTS Feature Guidelines
4.3.3.
Ranking
The cells that satisfy the Selection criteria are then selected to be ranked as per the following procedure. The cells are ranked according to the R criteria. R(serving) = Qmeas(s) + qHyst(s) R(neighbor) = Qmeas(n) - qOffset(s,n) Qmeas is the quality value of the received signal, which is derived from the average CPICH Ec/No or CPICH RSCP level for WCDMA cells and from the average received signal for GSM cells. (s) and (n) refer to the serving cell and neighboring cell values respectively. The ranking of GSM neighbors is always made using the measurement quantity CPICH RSCP. The ranking of WCDMA cells can be done using CPICH RSCP or CPICH Ec/No based on the value of the parameter qualMeasQuantity. The recommended setting is qualMeasQuantity = 2 which corresponds to CPICH Ec/No. The quantity qHyst(s) is the hysteresis value of the serving cell and is configured by the parameter qHyst1 when the ranking is based on CPICH RSCP and by parameter qHyst2 when the ranking is based on CPICH Ec/No. The quantity qOffset(s,n) is the offset between the serving and neighbor cell and can be used to move the border between the two cells. It can be configured using the parameter qoffset1sn when the ranking is based on CPICH RSCP and by qoffset2sn when the ranking is based on CPICH Ec/No. For cells that fulfill the selection criteria, a first ranking is done using CPICH RSCP. R(serving) = CPICH RSCP(s) + qHyst1 RWCDMA(neighbor) = CPICH RSCP(n) – qoffset1sn(s,n) RGSM(neighbor) = RxLev(n) – qoffset1sn(s,n) If a GSM cell is the best ranked cell after the first ranking, it is selected for the 3G to 2G reselection. The UE reselects to the new cell, if it is better ranked than the serving cell for a time equal to treSelection. A second ranking is only performed if the best ranked cell resulting from the first ranking is a WCDMA neighbor and the parameter qualMeasQuantity is set to CPICH Ec/No. The second ranking is performed as per CPICH Ec/No as follows. R(serving) = CPICH Ec/No(s) + qHyst2 RWCDMA(neighbor) = CPICH Ec/No(n) – qoffset2sn(s,n) After the second ranking the UE reselects to the best ranked neighbor, as long as this neighbor is better ranked than the serving cell for at least a time equal to a value defined by the parameter treSelection. The parameters qHyst1, qHyst2 qualMeasQuantity and treselection are defined per 3G cell and are set in the object UtranCell. The parameter qoffset1sn is defined per 3G – 3G neighbor pair (configured in object UtranRelation) and per 3G – 2G neighbor pair (configured in object GsmRelation). The parameter qoffset2sn is defined per 3G – 3G neighbor pair and is configured in the object UtranRelation.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
27 of 214
Ericsson UMTS Feature Guidelines
4.4. Recommended Values for 3G to 3G Selection and Reselection parameters The camping strategy places an important role in determining the recommended values of Reselection parameters. T-Mobile’s camping strategy is to camp on UMTS, whenever UMTS coverage is available, and reselect to GSM at the boundaries of UMTS coverage. Since UMTS is being launched with only 1 WCDMA carrier, the setting of sInterSearch is not considered here. Hence, in order to adhere to this camping strategy, the values of sIntraSearch and sRatSearch should be set such that the UE is making measurements only on 3G neighbors as long as it is in the UMTS coverage area, and tries to make measurements on GSM neighbors only when at the edge of the 3G coverage area. A constant value of -18 dB is recommended for qQualMin and a constant value of -115 dBm for the qRxLevMin, so that all cells are selected at the same thresholds. The other reselection parameters should be used to optimize the idle mode cell size. Recommended value for sIntraSearch: With qQualMin set to a constant value, a small value of sIntraSearch would reduce the number of measurements on intra frequency neighbors, while a large value of sIntraSearch would increase the number of times the UE measures on intra frequency cells. A large number of measurements would decrease the battery life in the UE. On the other hand, less frequent measurements may result in the UE camping on a non-optimum cell, thus increasing the call setup time when the UE tries to place a call. An optimum value for this parameter should achieve a balance between good battery life and lower call setup time. It should be noted that the battery life impacted would be the idle mode battery life which is not as critical as the connected mode battery life. The vendor recommended value of 0 for sIntraSearch would result in the UE always measuring on all available intra frequency cells, thus reducing the call setup time. However this may result in a lower UE battery life while compared to a different setting. Again the battery life reduction would be only in the idle mode, which is not as critical as the connected mode battery life. Further testing will be done to optimize this parameter value.
4.5. Cell Reselection Parameters from 3G to 2G The following are the parameters involved in the inter RAT reselection of a 3G cell on the Ericsson RAN to a 2G cell of any vendor’s BSS. The cell reselection process is divided into 3 steps – Measurements, Eligibility and Ranking.
4.5.1.
Measurements
For a 3G cell that has GSM neighbors defined, the decision about when the GSM measurements are performed is based on the parameter sRatSearch in relation to Squal. The parameter Squal is defined as QqualMeas – qQualMin. If the Squal value is larger than the parameter sRatSearch, the UE does not perform measurements on GSM cells. If the Squal value is less than or equal to the parameter sRatSearch, the UE performs measurements on the GSM neighbors. If the value of sRatSearch is not sent for the serving cell (by setting sRatSearch = 0), the UE always performs measurements on GSM cells. Squal = QqualMeas – qQualMin = CPich_Ec/Nomeas – qQualMin
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
28 of 214
Ericsson UMTS Feature Guidelines
As illustrated in the example below, qQualMin = -18 dB and sRatSearch = 4 dB. As the Ec/Io of the pilot drops below -14 dB, the UE will begin measuring GSM candidates assuming they are provided as neighbors in SIB 11/12. If the Ec/Io of the current pilot improves and exceeds -14 dB, the UE will cease measuring GSM candidates. The parameters qQualMin and sRatSearch are cell based parameters and are found in the UtranCell object.
In order to trigger GSM measurements based on RSCP measurements relative to qRxLevMin, the sHcsRat parameter is used. The behavior of these measurements is similar to the Ec/Io case. Assuming qRxLevMin = -111 dBm and sHcsRat = 3 dB, the UE will begin measuring GSM candidates when the current pilotâ&#x20AC;&#x2122;s RSCP drops below -108 dBm. If the RSCP of the current pilot improves and exceeds -108 dBm, the UE will cease measuring GSM candidates. The default value for this parameter is -105 dB, which deactivates the parameter and only allows the UE to trigger GSM measurements based on Ec/Io. Because Ec/Io measurements are not a complete indication of quality, especially at the UMTS network edge, it is recommended that sHcsRat parameter be enabled. The parameter fachMeasOccaCycLenCoeff is used to control the inter frequency and IRAT cell reselection measurements of a UE in CELL_FACH state. A UE in CELL_FACH state is allowed to make inter frequency and/or IRAT measurements only when this parameter fachMeasOccaCycLenCoeff > 0. If there are only GSM neighbors or inter-frequency neighbors defined for a cell, then fachMeasOccaCycLenCoeff should be set to 4 so that the UE will leave the FACH channel every 16th frame to perform measurements on these neighbors. If a cell has both GSM and Inter-frequency neighbors, then this parameter should be set to a value of 3, so that the UE will leave the FACH channel every 8th frame to perform measurements on the inter-frequency and GSM neighbors.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
29 of 214
Ericsson UMTS Feature Guidelines
Since T-Mobile networks will have only 1 WCDMA carrier to start with, for cells that have GSM neighbors defined, this parameter is recommended to be set to 4. For any cell with no IRAT neighbors or Inter frequency neighbors, fachMeasOccaCycLenCoeff should be set to 0.
4.5.2.
Eligibility
The eligibility of the neighboring GSM cells for reselection is verified using the selection criteria (S criteria). The selection criteria are fulfilled when Srxlev > 0 for the neighboring GSM cells. The parameter Srxlev is defined as Srxlev = Qrxlevmeas - qRxLevMin - Pcompensation Where Qrxlevmeas is the quality value of the received signal and is derived from the average received signal level for a GSM cell. qRxlevMin is the minimum received signal strength for a specific GSM cell. Pcompensation = max (maxTxPowerUl - P, 0) where P is the output power of the UE according to its class maxTxPowerUl is the maximum allowed transmission power when the UE accesses the system on RACH The parameters qRxLevMin and maxTxPowerUl are defined per GSM cell and can be set in the ExternalGsmCell Object.
4.5.3.
Ranking
Only GSM cells that satisfy the selection criteria are chosen for ranking. The cells are ranked according to the R criteria. R(serving) = Qmeas(s) + qHyst(s) R(neighbor) = Qmeas(n) - qOffset(s,n) Qmeas is the quality value of the received signal, which is derived from the average CPICH Ec/No or CPICH RSCP level for WCDMA cells and from the average received signal for GSM cells. (s) and (n) refer to the serving cell and neighboring cell values respectively. The ranking of GSM neighbors is always made using the measurement quantity CPICH RSCP. The ranking of WCDMA cells can be done using CPICH RSCP or CPICH Ec/No based on the value of the parameter qualMeasQuantity. The quantity qHyst(s) is the hysteresis value of the serving cell and is configured by the parameter qHyst1 when the ranking is based on CPICH RSCP and by parameter qHyst2 when the ranking is based on CPICH Ec/No. The quantity qOffset(s,n) is the offset between the serving and neighbor cell and can be used to move the border between the two cells. It can be configured using the parameter qoffset1sn when the ranking is based on CPICH RSCP and by qoffset2sn when the ranking is based on CPICH Ec/No. For cells that fulfill the selection criteria, a first ranking is done using CPICH RSCP.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
30 of 214
Ericsson UMTS Feature Guidelines
R(serving) = CPICH RSCP(s) + qHyst1 RWCDMA(neighbor) = CPICH RSCP(n) – qoffset1sn(s,n) RGSM(neighbor) = RxLev(n) – qoffset1sn(s,n) If a GSM cell is the best ranked cell after the first ranking, it is selected for the 3G to 2G reselection. The UE reselects to the new cell, if it is better ranked than the serving cell for a time equal to treSelection. A second ranking is only performed if the best ranked cell resulting from the first ranking is a WCDMA neighbor and the parameter qualMeasQuantity is set to CPICH Ec/No. In this case a 3G to 3G reselection will be performed. Simply put, the evaluation of a GSM candidate for reselection is based on the following parameters qHyst1, qOffset1sn, and treSelection. qHyst1 is a hysteresis added to the CPICH RSCP of the serving UMTS cell. The parameter qOffset1sn is offset subtracted from the candidate GSM RSSI. This offset can be used to appropriately compare a GSM RSSI to a UMTS RSCP value. Two examples are illustrated below.
In the first example, qOffset1sn = 0 dB, and qHyst1 = 4 dB. In this case, reselection will occur if the target GSM cell’s RSSI is 4 dB stronger than the serving CPICH RSCP, for period of treSelection seconds.
In the second example, qOffset1sn = 7 dB, and qHyst1 = 4 dB. In this case, reselection will occur if the target GSM cell’s RSSI is 11 dB stronger than the serving CPICH RSCP, for period of treSelection seconds
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
31 of 214
Ericsson UMTS Feature Guidelines
The parameters qHyst1, qualMeasQuantity and treSelection are defined per 3G cell and are set in the object UtranCell. The parameter qoffset1sn is defined per 3G â&#x20AC;&#x201C; 3G neighbor pair (configured in object UtranRelation) and per 3G â&#x20AC;&#x201C; 2G neighbor pair (configured in object GsmRelation).
4.6. Recommended Values for 3G to 2G Reselection parameters T-Mobile camping strategy is to keep the UE on UMTS coverage as far as possible with good quality. The following are the recommended values for the 3G to 2G reselection parameters. Measurements: The parameters qQualMin and sRatSearch found in the UtranCell object to trigger measurements on 2G neighbors should be set to -18 dB and 4 dB respectively, so that the UE can make GSM measurements when the CPICH Ec/No of the serving UMTS cell is less than or equal to -14 dB. The threshold of -14 dB is consistent with the Planning Guidelines as well as the 2G to 3G reselection threshold of -12 dB, avoiding ping pong between 3G and 2G networks. The parameters qRxlevMin and sHcsRat are recommended to be set to -115 dBm and 3 dB. It is recommended to keep the same parameter value for all cells so as to trigger the 2G measurements at the same threshold. The parameter qQualMin also influences the start of measurements on 3G neighbors. If this value is changed, then the sRatSearch parameter should be changed accordingly to keep the mobile measuring on GSM cells when the CPICH Ec/No falls below or is equal to -14 dB. Eligibility: The parameters qRxLevMin and maxTxPowerUl defined per GSM cell in the ExternalGsmCell Object should be set to -105 dBm and 24 dBm respectively. The value of qRxLevMin chosen is the minimum receive signal level required for a GSM call. It is recommended to keep the same parameter value for all cells. With these values, a GSM cell would be eligible for reselection to Class 3 UEs as long as the Rxlev in that cell is greater than -105 dBm. For Class 4 UEs, with a maximum transmit power of 21 dBm, the Pcompensation factor would be equal to 3 dB. This would result in the GSM cell to be eligible to Class 4 UEs, only when the Rxlev is greater than -102 dBm. Ranking: The recommended value for the parameter qHyst1 in UtranCell is 4 dB. The parameter qHyst1 is used to avoid ping pong between the serving cell and the neighbor cells. The parameter qoffset1 can be used to move the borders between cells. From the 3G to 3G reselection, it can be seen that the recommended value of qOffset1 in UtranRelation is 0 dB. From various testing it had been shown that the WCDMA RSCP is related to GSM RSSI as WCDMA RSCP + 7dB ~ GSM RSSI. Hence in order to keep RSSI and RSCP comparable, the parameter qOffset1 in GsmRelation should be set to 7 dB. This implies that a neighboring 3G cell needs to be greater than 4dB of the serving cell in order to be ranked higher, and a neighboring GSM cell needs to be greater than 11 dB of the serving cell in order to be ranked higher than the serving cell. This would ensure that a WCDMA cell is first checked for reselection before choosing a GSM cell for reselection. If for any reason, if we choose to prefer reselection to GSM above WCDMA, this can be accomplished by reducing the value of qOffset1 in object GsmRelation for the corresponding GSM neighbor. Recommended value for treSelection: The setting for the parameter treSelection is a compromise between a too low value, triggering too many reselections in the fading radio environment, and a too high value, that slows down the process. The recommended value for the parameter treselection is set to 2 seconds. This value would avoid too many
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
32 of 214
Ericsson UMTS Feature Guidelines
reselections between cells and hence too many LA/RA updates when crossing LA/RA borders. Thus there would be less signaling and less call failures at LA/RA borders due to LA/RA update. It is recommended to keep the same values for these parameters for all cells and all neighbor relations for network launch, and only change on as needed basis afterwards.
4.7. Location and Routing Area Registration and Updating After a UE has found a suitable cell and can access services requiring registration, it tries to register on the selected PLMN. If the Location Area Identity (LAI) or Routing Area Identity (RAI), read on SIB 1, is different from the one stored on the USIM before switch-off, the UE performs a LA or RA registration update. When a UE in idle mode moves into a new cell in a new LA or RA or into a new PLMN, it performs a registration area update. The LA or RA update procedure is managed by the CN and is transparent to the WCDMA RAN. There are three types of registration update procedures: normal, periodic and IMSI attach/detach.
4.7.1.
Terminology
Location Area (LA) is an area to which the core network (CN) sends a paging message for circuit switch services. The LA may consist of cells belonging to one or more RNCs, which are connected to the same CN. Location Area Identity (LAI) is formed by a PLMN Identity and a Location Area Code (LAC) sent in SIB 1. Routing Area (RA) is an area to which the CN sends a paging message for packet switch services. The RA may consist of cells belonging to one or more RNCs, which are connected to the same CN. Routing Area Identity (RAI) is formed by a PLMN Identity and a Routing Area Code (RAC) sent in the SIB 1.
4.7.2.
Normal LA and RA Updating
A UE executes a normal registration update when, in a cell belonging to a new LA or RA, it is switched on or leaves the Connected mode. Normal registration update is also performed when the UE, in Idle mode, moves in a cell belonging to a new LA or RA, or when the UE is unknown to the CN. The UE reads the LAI and the RAI in the system information and detects that one or both of the received area identities differ from the ones stored on the USIM. If the LAI received is not in the forbidden LAIs list, an LA and/or RA update request is sent by the UE to the WCDMA RAN. If the LAI is forbidden, the UE tries to select another cell belonging to a permitted LAI or another PLMN.
4.7.3.
Periodic LA and RA Updating
Periodic LA or RA updating is used to notify the network of the UEs availability, and to avoid unnecessary paging attempts for a UE that has lost coverage and is not able to inform the CN that it is inactive.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
33 of 214
Ericsson UMTS Feature Guidelines
The periodic LA update procedure is controlled by a timer, t3212, which gives the time interval between two consecutive periodic location updates. The value is sent by the WCDMA RAN to UEs on the SIB 1. The periodic RA update procedure is controlled by a timer, t3312, which gives the time interval between two consecutive periodic routing updates. The value of this timer is sent by the CN to the UE in the IMSI attached or in the routing area update message accept. The following figure shows an Example of a SIB1 and Attach Accept messages showing the periodic LA and RA update timer values, respectively.
4.7.4.
IMSI Attach/Detach
A location registration request indicating IMSI attach is made when the UE is activated in the same LA in which it was deactivated, and the system information indicates that IMSI attach/detach is used (SIB 1). The IMSI attach/detach procedure allows the UE to avoid unnecessary paging attempts from the CN. If IMSI attach/detach is used the UE sends an “attach” or “detach” message to the CN when is powered on or off indicating whether the UE is active or inactive in the network. The CN avoids performing paging attempts when the IMSI detach is applied and the UE is switched off. When the UE is switched on and the IMSI attach/detach procedure is applied the UE performs a location registration request, indicating IMSI attach, if it is in the same LA or RA in which it was switched off. If the registration area is changed, a normal LA update is performed by the UE. Ericsson has a parameter called “att” to indicate if IMSI attach/detach is used.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
34 of 214
Ericsson UMTS Feature Guidelines
The following figure depicts an example of an IMSI detach message sent by UE when powered off.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
35 of 214
Ericsson UMTS Feature Guidelines
5. Call Setup Procedure The fundamental steps required in the accessing the T-Mobile UMTS network is similar for both CS and PS services. In both cases the UE utilizes the same random access procedure to request establishment of a RRC Connection with the RNC. If dedicated resources are available to setup this radio link, an RRC Connection will be established with the RNC. Once an RRC Connection is established with the RNC, the Core Network (CN) is signaled to establish an Iu connection between the CN and RNC. At this time core network may initiate security procedures such as Authentication and Ciphering. After the security procedures are complete, the UE requests services from the Core Network. At this point the CN requests the establishment of a Radio Access Bearer (RAB) with the RNC to support the requested services. If this RAB is established, the RNC will acknowledge the CN request and a successful access will have occurred. Alternatively, if any of these steps fail, an access failure will occur. The procedure described above only summarizes the steps required to successfully access the UMTS network. In the following sections, the details for both the CS and PS setup procedure are described. Understanding these setup procedures is required to successfully troubleshoot and optimize the Accessibility metric of the UMTS network.
5.1. Circuit Switched Call Setup Figure 1 illustrates the call flow diagram for a typical CS call establishment. The setup is divided into three phases:
5.1.1.
The RRC Setup Phase
The Pre-RAB Phase
The RAB Setup Phase
RRC Setup Phase, CS Voice
In order to setup a call, the UE must establish an RRC Connection with the UTRAN. Once the UE has completed the Random Access Procedure, a RRC Connection Request message is sent to the SRNC. Embedded in this message is the establishment cause, or the reason the UE is requesting a RRC connection. For the case of mobile originating CS Call, the establishment cause would be “Originating Conversational Call”. If the UE is responding to a page, or a mobile terminating call, the establishment cause would be “Terminating Conversational Call”. Upon reception of the RRC Connection Request, the UE is assigned UMTS Radio Network Temporary Identifier (U-RNTI). This identifier is unique to the PLMN and is derived from the SRNC identity and a unique SRNC RNTI (S-RNTI). In this manner the U-RNTI is unique to the UE. After a RRC Connection Request message is received, the Admission Control algorithm is invoked to confirm the required dedicated resources are available to establish a signaling connection. These resources include codes, power, and channel elements. If admission can not be granted, an RRC Connection Reject message is sent, and the counter pmNoReqDeniedAdm is pegged. If admission is granted, a Radio Link Setup request is sent to the Node B requesting dedicated resources be reserved. Once resources are
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
36 of 214
Ericsson UMTS Feature Guidelines
reserved, the Node B responds with a Radio Link Setup Response message, and activates its Radio Link Set Supervision algorithm for this Radio Link. At this time, the RRC Connection Setup is sent to the UE with a RRC state indicator ordering the UE to go to CELL_DCH. Embedded in this message is all the information the UE needs to construct a dedicated channel. This includes all the logical, transport, and physical layer information required to build the 13.6 kbps SRB. For Ericsson, the SRB is identified by Transport Channel 31, and uses third rate convolution coding. The transport channel DL BLER target for outer loop power control, as well as the Rate Matching for the SRB is also transmitted to the UE at this time. At the physical layer, this SRB utilizes a 128 bit spreading factor. After the RRC Connection Setup message is sent, the Node B begins transmitting the DL DPCH to enable L1 synchronization. Once synchronization has occurred, the UE sends an RRC Connection Setup Complete message to the SRNC. Within this message are all the UE radio access capabilities for the RLC, Transport Channel, and Physical Channel. At this point, an RRC connection has been established between the UE and the SRNC. At this point in the call setup, the UE has reached a major milestone. Not only has it successfully completed the Random Access procedure, it has also setup a dedicated radio bearer with the RNC. This allows the UE to utilize fast power control, and soft handover to overcome adverse RF conditions. Prior to this, the UE was highly susceptible to interference and coverage issues. The UE is now known by the UTRAN and has been assigned an ID: U-RNTI. It has signaling resources assigned to it, but has no bearer resources. The CN, however, has no visibility about this UE at this point. That is where the next phase (Pre-RAB Phase) comes in.
5.1.2.
Pre-RAB Phase, CS Voice
Once the RRC connection has been established, the next phase of the call setup procedure is the Pre-RAB or Signaling phase. This is initiated by the UE transmitting the Non-Access Stratum (NAS) message, CM Service Request, to the CN. This initial NAS message will trigger the creation of an Iu Signaling Connection between the SRNC and the MSC. At this point, the core network initiates the security procedures like Authentication and Ciphering. During the Authentication process, the Authentication Center (AuC) uses an IMSI specific Authentication Key (K) and a randomly generated number (RAND) to generate five security parameters, known as the Quintet. Once these security parameters are generated, the CN sends the NAS message, Authentication Request, to the UE. Embedded in this message is the RAND used to generate the Quintet, as well as an Authentication Token (AUTN), which is derived from two of the Quintet parameters. Because the Authentication Key is also stored on the UEâ&#x20AC;&#x2122;s SIM card, the UE can use this RAND to generate the same Quintet that was generated by the AUC. In this manner, the UE can compare its locally generated AUTN to the version sent in the Authentication Request message. If these versions match, the UE has successfully authenticated the sender of the message, thus eliminating fraudulent access to UE specific information. This network authentication step is new for UMTS and was not available in GSM. Once this is complete, the UE responds with a NAS Authentication Response message, which contains one of the Quintet parameters, know as the Response (RES). The CN compares this RES with is locally generated Expected Response (XRES) to authenticate the UE. This method of bi-directional authentication between the UE and the CN is known as Mutual Authentication.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
37 of 214
Ericsson UMTS Feature Guidelines
Once Mutual Authentication is complete, the Integrity and Ciphering security features can be initiated. Integrity insures that L3 messaging can not be altered in an unauthorized manner and that the sender of the signaling is the appropriate sender (i.e. Integrity protects the UE from the â&#x20AC;&#x153;man in the middle attackâ&#x20AC;?). Ciphering encrypts the signaling and user data sent between the UE and the SRNC. Integrity and Ciphering procedures are initiated by the MSC by sending the RANAP message Security Mode Command. This message contains the Integrity Key (IK) and the Ciphering Key (CK), which are two of the five security parameters (Quintet). The RNC uses these keys to perform the Integrity and Ciphering security features. Because the UE can generate the same Quintet that was generated by the AUC, the IK and CK are known to the UE as well. The RRC message Security Mode Command is sent by the SRNC to instruct the UE to start the Integrity and Ciphering procedures. The Security Mode Control procedure is finalized by sending the RRC Security Mode Complete message from the UE to the SRNC. This message is also forwarded to the MSC using the RANAP Security Mode Complete message. Once the security functions are enabled, the NAS message Setup is sent from the UE to the MSC. This message contains the dialed digits, as well as some Bearer and Call Control capabilities of the UE. The MSC confirms the call setup request has been received and is in progress with a Call Proceeding message.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
38 of 214
Ericsson UMTS Feature Guidelines
Figure 1 - Circuit Switched Call Setup Flow Diagram
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
39 of 214
Ericsson UMTS Feature Guidelines
5.1.3.
RAB Setup Phase, CS Voice
Now that the RRC Connection is established, and the UE authentication and encryption is enabled, the UE can request the setup it requires for this call and the MSC can start negotiating the call with the UE. Upon a successful negotiation, the MSC triggers the setup of resources for the User Plane by means of the “RAB Assignment” procedure. Since the QoS parameters indicate that the Traffic Class for this call is “Conversational”, the RRC state for the Radio Bearer to be set up is “Cell_DCH.” Having set up the resources for the User Plane, the call can be completed by means of some further NAS messages to notify the user that the call has been accepted. The voice traffic can now be sent over the resources in the User Plane. Once the service request has been initiated, the MSC requests the UTRAN to allocate the necessary radio resources via the RANAP message RAB Assignment Request. The RAB Assignment is the mechanism for the CN to notify the UTRAN of the appropriate Quality of Service (QoS) and attributes required to deliver the service. Examples of these attributes include, but are not limited to:
Maximum Bit Rate
o o
UL = 12.2 kbps DL = 12.2 kbps Guaranteed Bit Rate:
o o
UL = 4.75, 5.9, 7.95, 12.2 kbps DL = 4.75, 5.9, 7.95, 12.2 kbps Maximum SDU Size:
o
244 (bits) Sub-flow SDU Size (bits)
o o o
Sub-flow 1: 42, 55, 75, 81, 39 Sub-flow 2: 53, 63, 84, 103, 0 Sub-flow 3: 0, 0, 0, 60, 0
Because this is requesting dedicated resources, the Admission Control Algorithm is again invoked. If admission is granted, a Radio Link Setup Request message is sent from the RNC to the Node B via Node B Application Part (NBAP) signaling. If the Node B responds positively with a Radio Link Setup Response, and Bearer Synchronization is established, a RRC Radio Bearer Setup message is sent from the RNC to the UE. Embedded in this message is all the information the UE needs to construct a dedicated channel to support the CS voice call (e.g. AMR 12.2 kbps codec plus SRB). The AMR trans-coder within the MSC divides speech into 3 classes (A, B, and C) where A is the highest priority, B is next, C is lowest priority. Since each of these classes has unique RAB attributes, they are mapped to their own logical and transport channel within the radio bearer. For Ericsson, the AMR A bit sub-flow is identified by Transport Channel 8, and uses third rate convolutional coding. The transport channel DL BLER target for outer loop power control, as well as the Rate Matching attribute the for this Transport Channel are also transmitted to the UE at this time. Because the successful transmission of the B and C sub-flows (Transport Channels 9 and 10 respectfully) are not monitored by the outer loop power control, transport channel DL BLER targets are not required. The AMR B sub-flow transport channel uses third rate convolutional coding, while the AMR C sub-flow uses half rate convolutional coding. Table
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
40 of 214
Ericsson UMTS Feature Guidelines
1 lists some of the Transport Channel attributes for each of the sub-flows used for AMR Speech.
Ericsson TrCh ID
AMR Sub-flow
Coding
8 9 10
A B C
1/3 1/3 1/2
CRC 12 bits None None
Physical Frame Size 20 ms 20 ms 20 ms
Table 1 - Transport Channel Attributes AMR Speech In addition to configuring the transport channels for the AMR speech sub-flows, Transport Channel 31 is reconfigured from 13.6 kbps to a 3.4 kbps SRB. All four of these transport channels (8, 9, 10, and 31) are multiplexed into a single Coded Composite Transport Channel (CcTrCh), and mapped to a physical channel with a 64 bit spreading factor for the UL, and a 128 bit spreading factor for the DL (assuming AMR 12.2 kbps). Once this Radio Bearer has been configured and synchronized in the DL, the UE sends the SRNC a RRC Radio Bearer Setup Complete message. Upon receiving this message, the SRNC responds to the MSC with a RANAP RAB Assignment Response message. At this point, the call has been successfully setup, and moves into the Retainability phase of the call. The remaining NAS messages are used to provide the UE with the status of the call. The NAS Alerting message indicates to the UE that the other end has been notified of an incoming call. At this time, the UE typically generates ringing tones to alert the caller that progress is being made. Once the called party answers the call, the MSC sends NAS message Connect to the UE. At this point the UE and MSC activate their respective voice coders, and the UE sends the NAS message Connect Acknowledgement to the MSC. Figure 2 illustrates the actual L3 messaging of a call setup, collected by UE logging tool, in a market with an Ericsson UTRAN.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
41 of 214
Ericsson UMTS Feature Guidelines
Figure 2 - L3 Messaging sample
5.1.4.
Counters Related to CS Voice Call Setup
In this section, the counters associated with a CS Voice call setup are discussed. Understanding which counters are affected, and under what circumstances they are incremented during the call flow, is essential to successfully monitor and troubleshoot the performance of the network. Figure 3 illustrates the counters associated with a RRC Connection establishment based a CS establishment cause. These counters include, but are not limited to the following:
pmTotNoRrcConnectReq
pmTotNoRrcConnectReqSucc
pmTotNoRrcConnectReqCs
pmTotNoRrcConnectReqSuccCs
pmNoRejRrcConnMpLoadC
Refer to [14] for details on these counters.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
42 of 214
Ericsson UMTS Feature Guidelines
Figure 3 - Flowchart for Ericsson Counters, RRC Connection Setup, CS
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
43 of 214
Ericsson UMTS Feature Guidelines
Figure 4 and Figure 5 illustrate the counters associated with a RAB Establishment Attempt and Success respectively. These counters related to a CS Call Setup include, but are not limited to the following:
pmNoRabEstablishAttempts
pmNoRabEstablishAttemptSpeech
pmpmNoRabEstablishSuccess
pmpmNoRabEstablishSuccessSpeech
pmNoRabEstablishFailureUeCapability
pmNoFailedRabEstAttemptExceedConnLimit
pmNoFailedRabEstAttemptLackDlAse
pmNoFailedRabEstAttemptLackUlAse
pmNoFailedRabEstAttemptLackDlChnlCode
pmNoFailedRabEstAttemptLackDlPwr
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
44 of 214
Ericsson UMTS Feature Guidelines
Figure 4 - Flowchart for Ericsson Counters, RAB Setup
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
45 of 214
Ericsson UMTS Feature Guidelines
Figure 5 - Flowchart for Ericsson Counters, Successful RAB Setup
5.1.5.
Circuit Switched Voice Accessibility KPI
Equation 1 provides the KPI equation for CSV Access failure rate. pmTotNoRrcConnectReqCsSucc(UtranCell) pmNoRabEstablishSuccessSpeech(UtranCell) * 100 * 1 pmNoRabEstablishAttemptSpeech(UtranCell) pmTotNoRrcConnectReqCs(UtranCell)
Equation 1 - CSV Access Failure Rate
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
46 of 214
Ericsson UMTS Feature Guidelines
5.2. Packet Switched Call Setup Figure 6 illustrates call flow diagram for the typical establishment of a Packet Switched call. Similar to the CS call setup, the PS setup is also divided into three phases:
5.2.1.
The RRC Setup Phase
The Pre-RAB Phase
The RAB Setup Phase
RRC Setup Phase, PS Setup
In order to setup a call, the UE must establish an RRC Connection with the UTRAN. Once the UE has completed the Random Access Procedure, a RRC Connection Request Message is sent to the SRNC. Embedded in this message is the establishment cause, or the reason the UE is requesting a RRC connection. For the case mobile originating PS Call, the establishment cause could be “Originating Interactive Call”, or “Originating Background Call”. If the UE is responding to a page, or a mobile terminating PS call, the establishment cause could be “Terminating Interactive Call”, or “Terminating Background Call”. Upon reception of the RRC Connection Request, the UE is assigned UMTS Radio Network Temporary Identifier (U-RNTI). This identifier is unique to the PLMN and is derived from the SRNC identity and a unique SRNC RNTI (S-RNTI). In this manner the U-RNTI is unique to the UE. After a RRC Connection Request message is received, the Admission Control algorithm is invoked to confirm the required dedicated resources are available to establish a signaling connection. These resources include codes, power, and channel elements. If admission can not be granted, an RRC Connection Reject message is sent, and the counter pmNoReqDeniedAdm is pegged. If admission is granted, a Radio Link Setup request is sent to the Node B requesting dedicated resources be reserved. Once resources are reserved, the Node B responds with a Radio Link Setup Response message, and activates its Radio Link Set Supervision algorithm for this Radio Link. At this time, the RRC Connection Setup is sent to the UE with a RRC state indicator ordering the UE to go to CELL_DCH. Embedded in this message is all the information the UE needs to construct a dedicated channel. This includes all the logical, transport, and physical layer information required to build the 13.6 kbps SRB. For Ericsson, the SRB is identified by Transport Channel 31, and uses third rate convolution coding. The transport channel DL BLER target for outer loop power control, as well as the Rate Matching for the SRB is also transmitted to the UE at this time. At the physical layer, this SRB utilizes a 128 bit spreading factor. After the RRC Connection Setup message is sent, the Node B begins transmitting the DL DPCH to enable L1 synchronization. Once synchronization has occurred, the UE sends an RRC Connection Setup Complete message to the SRNC. Within this message are all the UE radio access capabilities for the RLC, Transport Channel, and Physical Channel. At this point, an RRC connection has been established between the UE and the SRNC. At this point in the PS call setup, the UE has reached a major milestone. Not only has it successfully completed the Random Access procedure, it has also setup a dedicated radio bearer with the RNC. This allows the UE to utilize fast power control, and soft handover to
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
47 of 214
Ericsson UMTS Feature Guidelines
overcome adverse RF conditions. Prior to this, the UE was highly susceptible to interference and coverage issues. The UE is now known by the UTRAN and has been assigned an ID: U-RNTI. It has signaling resources assigned to it, but has no bearer resources. The CN, however, has no visibility about this UE at this point. That is where the next phase (Pre-RAB Phase) comes in.
5.2.2.
Pre-RAB Phase, PS Setup
Once the RRC connection has been established, the next phase of the PS call setup procedure is the Pre-RAB or Signaling phase. This is initiated by the UE transmitting the Non-Access Stratum (NAS) message, Service Request, to the CN. This initial NAS message will trigger the creation of an Iu Signaling Connection between the SRNC and the SGSN. At this point, the core network initiates the security procedures like Authentication and Ciphering. During the Authentication process, the Authentication Center (AuC) uses an IMSI specific Authentication Key (K) and a randomly generated number (RAND) to generate five security parameters, known as the Quintet. Once these security parameters are generated, the CN sends the NAS message, Authentication Request, to the UE. Embedded in this message is the RAND used to generate the Quintet, as well as an Authentication Token (AUTN), which is derived from two of the Quintet parameters. Because the Authentication Key is also stored on the UE’s SIM card, the UE can use this RAND to generate the same Quintet that was generated by the AUC. In this manner, the UE can compare its locally generated AUTN to the version sent in the Authentication Request message. If these versions match, the UE has successfully authenticated the sender of the message, thus eliminating fraudulent access to UE specific information. This network authentication step is brand new in UMTS and was not available in GSM. Once this is complete, the UE responds with a NAS Authentication Response message, which contains one of the Quintet parameters, know as the Response (RES). The CN compares this RES with its locally generated Expected Response (XRES) to authenticate the UE. This method of bi-directional authentication between the UE and the CN is known as Mutual Authentication. Once Mutual Authentication is complete, the Integrity and Ciphering security features can be initiated. Integrity insures that L3 messaging can not be altered in an unauthorized manner and that the sender of the signaling is the appropriate sender (i.e. Integrity protects the UE from the “man in the middle attack”). Ciphering encrypts the signaling and user data sent between the UE and the SRNC. Integrity and Ciphering procedures are initiated by the SGSN by sending the RANAP message Security Mode Command. This message contains the Integrity Key (IK) and the Ciphering Key (CK), which are two of the five security parameters (Quintet). The RNC uses these keys to perform the Integrity and Ciphering security features. Because the UE can generate the same Quintet that was generated by the AUC, the IK and CK are known to the UE as well. The RRC message Security Mode Command is sent by the SRNC to instruct the UE to start the Integrity and Ciphering procedures. The Security Mode Control procedure is finalized by sending the RRC Security Mode Complete message from the UE to the SRNC. This message is also forwarded to the SGSN using the RANAP Security Mode Complete message. Once the security functions are enabled, the NAS message PDP Context Activation Request is sent from the UE to the CN. This message is basically requesting a connection
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
48 of 214
Ericsson UMTS Feature Guidelines
to the Public Packet Data Network via the SGSN and GGSN, using the Packet Data Protocol (PDP).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
49 of 214
Ericsson UMTS Feature Guidelines
Figure 6 - Packet Switched Call Flow Diagram
5.2.3.
RAB Setup Phase, PS Setup
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
50 of 214
Ericsson UMTS Feature Guidelines
Now that the RRC Connection is established, and the UE authentication and encryption enabled, the UE can request the setup it requires for this call and the SGNS can start negotiating the setup with the UE. Upon a successful negotiation, the SGSN triggers the setup of resources for the User Plane by means of the “RAB Assignment” procedure. Since the QoS parameters indicate that the Traffic Class for this call is “Interactive”, the RRC state for the Radio Bearer to be set up is “Cell_DCH.” Once the service request has been initiated, the SGSN requests the UTRAN to allocate the necessary radio resources via the RANAP message RAB Assignment Request. The RAB Assignment is the mechanism for the CN to notify the UTRAN of the appropriate Quality of Service (QoS) and attributes required to deliver the service. Examples of these attributes include, but are not limited to:
Maximum Bit Rate
o o
UL = 12.2 kbps DL = 12.2 kbps Guaranteed Bit Rate:
o o
UL = 8, 64, 128, 384 and HSPA DL = 8, 64, 128, 384 and HSPA Maximum SDU Size:
o
12016 (bits)
Because this is requesting dedicated resources, the Admission Control Algorithm is again invoked. If admission is granted, a Radio Link Setup Request message is sent from the RNC to the Node B via Node B Application Part (NBAP) signaling. If the Node B responds positively with a Radio Link Setup Response, and Bearer Synchronization is established, a RRC Radio Bearer Setup message is sent from the RNC to the UE. Embedded in this message is all the information the UE needs to construct a Radio Bearer to support the PS session. At this point, the PS session may be setup utilizing dedicated channels, (i.e. 64 kbps UL/64 kbps DL), the High Speed Downlink Shared Channel (HS-DSCH) and an UL dedicated channel (i.e. 64 kbps UL/HS-DSCH), or the HS-DSCH and Enhanced Uplink (EUL) (i.e. EUL/HS-DSCH). Setup for these three scenarios is dependant on UE capabilities (as communicated in the RRC Connection Setup Complete message), and the capabilities of the serving cell. For this discussion, it is assumed that the PS session is setup using dedicated channels (i.e. 64k/64k). Since this bearer has unique RAB attributes, it is mapped to its own logical, transport and physical channel within the radio bearer. For Ericsson, Transport Channel 24 is used for PS, and utilizes Turbo coding for forward error correction. The transport channel DL BLER target for outer loop power control as well as the Rate Matching attribute for this transport channel is also transmitted to the UE at this time. In addition to configuring the transport channel for the PS Session, Transport Channel 31 is reconfigured from 13.6 kbps to a 3.4 kbps SRB. Both of these transport channels (24 and 31) are multiplexed into a single Coded Composite Transport Channel (CcTrCh), and mapped to a physical channel with a 16 bit spreading factor for the UL, and a 32 bit spreading factor for the DL (assuming 64k/64k RAB). Once this Radio Bearer has been configured and synchronized in the DL, the UE sends the SRNC a RRC Radio Bearer Setup Complete message. Upon receiving this message, the SRNC responds to the SGSN with a
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
51 of 214
Ericsson UMTS Feature Guidelines
RANAP RAB Assignment Response message. At this point, the session has been successfully setup, and moves into the Retainability phase of the call. The NAS Activate PDP Context Accept message indicates to the UE that an IP address has been assigned and the PS session may begin. Figure 7 illustrates the actual L3 messaging of a PS session setup, collected by UE logging tool, in a market with an Ericsson UTRAN.
Figure 7 - L3 Messaging for PS Setup
5.2.4.
Counters Related to PS Setup
In this section, the counters associated with a PS session setup are discussed. Understanding which counters are affected, and under what circumstances they are incremented during the call flow, is essential to successfully monitor and troubleshoot the performance of the network. Figure 8 illustrates the counters associated with a RRC Connection establishment based a PS establishment cause. These counters include, but are not limited to the following:
pmTotNoRrcConnectReq
pmTotNoRrcConnectReqSucc
pmTotNoRrcConnectReqPs
pmTotNoRrcConnectReqSuccPs
pmTotNoUtranRejRrcConnReq
pmNoRejRrcConnMpLoadC
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
52 of 214
Ericsson UMTS Feature Guidelines
Figure 8 - Flowchart for Ericsson Counters, RRC Connection Setup, PS
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
53 of 214
Ericsson UMTS Feature Guidelines
Figure 4 and Figure 5 illustrate flowchart for the counters associated with a RAB Establishment Attempt and Success respectively. The counters related to a PS Session Setup include, but are not limited to the following:
5.2.5.
pmNoRabEstablishAttempts
pmNoRabEstablishAttemptPacketInteractive
pmpmNoRabEstablishSuccessPacketInteractive
pmNoRabEstablishAttemptPacketInteractiveHs
pmNoRabEstablishSuccessPacketInteractiveHs
pmNoRabEstablishFailureUeCapability
pmNoFailedRabEstAttemptExceedConnLimit
pmNoFailedRabEstAttemptLackDlAse
pmNoFailedRabEstAttemptLackUlAse
pmNoFailedRabEstAttemptLackDlChnlCode
pmNoFailedRabEstAttemptLackDlPwr
Packet Switched Accessibility KPI
Equation 2 provides the KPI equation for PSD Access failure rate (refer to the Ericsson UMTS Network KPI document for details regarding this equation). pmTotNoRrc ConnectReq PsSucc(Utr anCell) 100 * 1 * 0.9993 * R99 Interactiv eRABEstabl ishSuccess Rate pmTotNoRrc ConnectReq Ps(UtranCe ll)
Equation 2 - PSD Access Failure Rate
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
54 of 214
Ericsson UMTS Feature Guidelines
6. Random Access Procedure The Random Access Procedure is utilized by the UE to access the UTRAN network from an Idle, or Cell_FACH state. Since this is a critical step in the CS or PS call setup process, understanding this procedure is essential to successfully maintain and operate the UMTS network. In addition to being familiar with the Random Access Procedure, it is important to understand the configurable parameters utilized by the algorithm, and the affects of modifying these parameters. It is quite possible to aggressively configure the Random Access parameters to improve the likelihood of accessing the network, at the cost of capacity. Alternatively, it is also possible to be overly concerned about capacity at the cost of successfully accessing the network. The UMTS Random Access Procedure is based on a slotted ALOHA approach, which is commonly utilized by modern wireless communication systems. Developed at the University of Hawaii in the early 1970’s, this access algorithm allows any terminal to transmit on the shared uplink channel without considering if the channel is being utilized by another terminal. The term “slotted” implies that these transmissions occur at predefined time slots. If the transmission is received by the Node B correctly, an acknowledgement will be sent to the UE. If no acknowledgement is received by the UE, it assumes the previous transmission was lost and retransmits after waiting a random amount of time. An overview of the 3GPP implementation of this Random Access Procedure, and the configurable parameters utilized by Ericsson, are discussed in the following section.
6.1. Random Access Overview When accessing the UMTS network, several factors must be considered. The channel which is utilized, the Random Access Channel (RACH), is a shared channel. Because of this, the possibility of collisions from multiple user access attempts is possible. In addition, all uplink transmissions result in co-channel interference and therefore require stringent power control to minimize this interference. However, since the RACH does not use closed loop power control, the UE must estimate the power required to transmit the RACH message. The goal of the Random Access Procedure is to minimize the chance of collisions, and to estimate the UE transmit power so that interference to other UEs is minimized. However, these goals must be achieved while minimizing system access time.
6.1.1.
Random Access Channels
To achieve these goals, the UE initially sends test messages (i.e. preambles) on the Physical Random Access Channel (PRACH), prior to sending the RACH message (e.g. the RRC Connection Request message). The preamble messages are sent in predefined slots known as Access Slots. The PRACH Access Slot format, and its relation to the Acquisition Indication Channel (AICH) slots, is illustrated in Figure 9 (ref. 3GPP TS 25.214). There are 15 defined Access slots, divided into two access slot sets, every 20 ms. There are 8 access slots (0-7) in access slot set 1, and 7 access slots (8-14) in access slot set 2. In addition,
there are 15 corresponding AICH slots which are time offset by p-a. The AICH only exists on the physical layer and is used solely to acknowledge preambles sent on PRACH Access Slots.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
55 of 214
Ericsson UMTS Feature Guidelines
Figure 9- PRACH access slot and downlink AICH relation
p-a is the preamble to Acquisition Indication (AI) distance p-p is the preamble to preamble distance p-m is the preamble to message distance The AICH Transmission Timing (p-a) can be set by a configurable parameter called aichTransmissionTiming and can be either equal to 0 or 1 in the Ericsson implementation. This parameter is interpreted as follows (Reference 3GPP TS 25.211). If aichTransmissionTiming = 0
p-p, min = 15360 chips ( 3 access slots) p-a = 7680 chips p-m = 15360 chips (3 access slots)
If aichTransmissionTiming = 1
p-p, min = 20480 chips ( 4 access slots) p-a = 12800 chips p-m = 20480 chips (4 access slots)
The AICH Transmission Timing parameter is broadcast in SIB 5.
6.1.2.
Open Loop Power Control
As previously stated, the initial preamble power (P_PRACH) must be conservatively calculated to insure that uplink interference to other UEs is minimized. To achieve this, the initial preamble power (P_PRACH) is calculated by the following equation:
P_PRACH L_PCPICH RTWP constantValueCprach Equation 3 - Initial Preamble Transmit Power Where:
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
56 of 214
Ericsson UMTS Feature Guidelines
L_PCPICH = the estimated downlink path loss of the Pilot Channel (CPICH)
RTWP = the Received Total Wideband Power (i.e. Uplink Interference) measured by the Node B
constantValueCprach = is a configurable parameter used to offset the equation’s result
The downlink path loss of the Pilot Channel (L_CPICH) is estimated by subtracting the CPICH RSCP (measured by the UE) from the primaryCPICH-TX-Power, which is broadcast in System Information Block 5 (SIB 5). In addition, the parameter constantValueCprach is also broadcast in SIB 5. The uplink interference (RTWP) measured by the Node B is broadcast in SIB 7. The purpose of the configurable parameter constantValueCprach, is to account for the processing gain of the preamble, which is equivalent to 10log(256) = 24 dB. Ericsson’s default value for constantValueCprach is equal to -27 dB, which results in a -3 dB offset to the initial preamble transmit power. This negative offset yields a conservative estimate for the transmit power of the initial preamble, thus reducing the potential of causing unnecessary uplink interference.
6.1.3.
Physical Layer Random Access Procedure
Once the initial preamble transmit power is determined, the physical layer random access procedure shall be performed as follows (reference 3GPP TS 25.214, Section 6): 1. An access slot is randomly selected from the group of available access slots in the next full access slot set (e.g. Access Slot set 1). If there are no available access slots in the selected set, randomly select an available access slot in the next access slot set (e.g. Access Slot set 2). The term “available access slots” is used because some of the access slots may be reserved for a higher priority Access Class (AC), such as emergency personnel. 2. Once an access slot has been selected, the UE randomly selects a Preamble Signature from the set of available signatures. As specified in 3GPP TS 25.213, Section 4.3.3, the set of Preamble Signatures consist of 16 Hadamard codes, each 16 bits long. The selected 16 bit code is repeated 256 times and combined with a preamble scrambling code, to form the transmitted preamble code. The preamble scrambling code selected is one of 16 associated with the CPICH Scrambling code of the cell being accessed. In this manner, the Node B can identify preambles targeted for it, and ignore preambles intended for other Node Bs. Similar to the access slot scenario, the term “available signatures” is used because some of the signatures may be reserved for a higher priority Access Class (AC), such as emergency personnel. 3. At this point, the UE transmits the selected preamble code, using the selected slot; at an initial preamble transmit power (P_PRACH), which was calculated using Equation 3. If the calculated transmit power exceeds the maximum allowed UE transmit power (as broadcast on SIB 3), the preamble will be transmitted at the maximum allowed power. 4. After the preamble is sent, the UE monitors the AICH for an acknowledgement on the corresponding AICH access slot (refer to Figure 9). The UE is able to differentiate AICH acknowledgements targeted for it, and ignore those intended for other UEs, because the 16 specified 32 bit AICH signature patterns used by the AICH are related to the 16 preamble signatures previously described. Refer to 3GPP TS 25.211, Section 5.3.3.7 for information regarding the AICH.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
57 of 214
Ericsson UMTS Feature Guidelines
5. If no acknowledgement (positive or negative) is detected on the corresponding AICH access slot, the UE utilizes the next available access slot, randomly picks an available preamble signature, and increases the preamble transmit power by a value equal to the configurable parameter powerOffsetP0 (broadcast in SIB 5/6). If this newly adjusted power is not greater than the maximum allowed UE transmit power by 6 dB, the preamble is transmitted at the calculated power or the maximum UE transmit power, whichever is minimum. 6. Assuming no acknowledgement is detected, the power ramping process will continue (as described in step 5), unless one or both of the following events occur: a. The number of preambles transmitted equals the configurable parameter preambleRetransMax (broadcast in SIB 5/6). b. The newly calculated preamble transmit power exceeds the maximum allowed UE transmit power by 6 dB, after applying the powerOffsetP0 offset. 7. If step 6a or 6b occur, the UE will exit the physical random access process and inform the MAC layer that “No Ack on AICH” was detected. 8. If the preamble is detected, and the Node B responds with a positive acknowledgement, the UE will transmit the Layer 3 message three or four access slots after the last preamble transmitted. The control part of this message will be transmitted at a power equal to the power of the last preamble sent, plus the value of the configurable parameter powerOffsetPpm (not to exceed the maximum allowed UE transmit power). The data part of this Layer 3 message is transmitted based on the gain factors for PRACH, which are also broadcast in SIB 5. 9. If the preamble is detected, and the Node B responds with a negative acknowledgement the UE will exit the physical random access process and inform the MAC layer that a “Nack on AICH recieved”. Figure 10 illustrates the major aspects of the physical random access procedure. The first preamble is transmitted at the calculated initial preamble transmit power. If no acknowledgement is received on the AICH, the next preamble is transmitted with a power that is increased by powerOffsetP0. Once the preamble is positively acknowledged, the message is sent with a power that is increased by powerOffsetPpm, relative to the last preamble power.
Figure 10 - Random Access Power Ramping on PRACH
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
58 of 214
Ericsson UMTS Feature Guidelines
The time between preamble transmissions is dependant on the availability of access slots, and the AICH Transmission Timing parameter described earlier. The minimum time interval is based on the AICH Transmission Timing parameter as specified earlier. The maximum time between preambles is dependant on the availability of access slots. If access slots are reserved for a higher priority Service Class (SC), the time between preambles may increase as a function of the number of sub channels used.
6.1.4.
MAC Monitoring and Control of Random Access Transmissions
The physical layer random access procedure described is only part of the overall Random Access procedure. In addition to initiating the physical random access procedure, the Medium Access Control (MAC) also monitors and reinitiates RACH transmission based on parameters provided by higher layers. Figure 11 is a flowchart illustrating the MAC’s control for RACH transmissions. Once it is determined that there is a message to send on RACH, the MAC obtains required parameters from higher layers and initiates the physical layer random access procedure, which is described in the previous section. The three possible responses from Layer 1 are: “Ack”; “Nack”; or “No Ack”
An “Ack” indicates a positive acknowledgement was received during the physical random access procedure. In this case, the procedure was successful and the RRC Message was transmitted on RACH. At this point, the MAC ends the RACH transmission procedure.
A “Nack” indicates that a negative acknowledgement was received during the physical random access procedure, possible due to contention. In this case, the UE needs to reinitiate the random access procedure after time delay. As shown in Figure 11, the MAC inserts a fixed T2 =10 ms delay, plus an additional back off timer TBO1 = (NBO1 * 10 ms), where NBO1 is an integer randomly selected within the range of parameters NBO1 (max) and NBO1 (min), which are broadcast in SIB 5. The purpose of this random back off timer is to reduce the probability of repeated collisions on the PRACH. Once this timer has expired, the MAC checks the number of initiated preamble transmissions to the configurable parameter maxPreambleCycle. This parameter basically limits the number of physical random access procedures that can be initiated by the MAC, per request from higher layers. If the maxPreambleCycle limit has been exceeded, the MAC ends the RACH transmission procedure and the higher layer (RRC) is notified that the transmit status was “unsuccessful”. If the maxPreambleCycle limit has not been exceeded, the MAC performs a persistency check. A persistency check is basically another way to insert a random delay (in increments of 10 ms) into the algorithm. Once this delay is completed, the command is sent to the physical layer to reinitiate the physical random access procedure.
A “No Ack” indicates that neither a negative or positive acknowledgement was received during the physical random access procedure. In this case, the UE needs to reinitiate the random access procedure after a time delay. As shown in Figure 11, the process used for this scenario is similar to the “Nack” scenario, except the back off timer TBO1 is not utilized.
Simply put, the MAC will reinitiate the physical layer random access procedure (described in Section 6.1.3) repeatedly until either a positive acknowledgement is received, or the maxPreambleCycle limit has been exceeded.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
59 of 214
Ericsson UMTS Feature Guidelines
In the Ericsson implementation, NBO1 (max) = NBO1 (min) = 0, which means the backoff timer TBO1 is not used. Also the persistence value selected is 1, so that the delay due to persistence check is not implemented either.
S ta rt N O T E : M A C -c /sh re c e iv e s R A C H tx c o n tro l p a ra m e te rs fro m R R C w ith C M A C -C O N F I G -R e q p rim itiv e w h e n e v e r o n e o f th e p a ra m e te rs is u p d a te d
G e t R A C H tx c o n tro l p a ra m e te rs fro m R R C : M m a x , N B O 1 m in , N B O 1 m a x , s e t o f A S C p a ra m e te rs N
A n y d a ta to b e tra n sm itte d ? Y
A S C se le c tio n : (P R A C H p a rtitio n i, P i ) M := 0
In c re m e n t p re a m b le tra n s m is sio n c o u n te r M M M max ?
In d ic a te to h ig h e r la y e r th a t m a x im u m n u m b e r o f p re a m b le c y c le s h a v e b e e n re a c h e d (T X s ta tu s "u n su c c e ss fu l")
N
Y
End
S e t a n d w a it e x p iry tim e r T B O 1 (N B O 1 * 1 0 m s )
U p d a te R A C H tx c o n tro l p a ra m e te rs W a it e x p ir y T im e r T 2 (1 0 m s)
S e t T im e r T
2
W a it e x p ir y T im e r T 2 (1 0 m s)
(1 0 m s )
W a it e x p ir y tim e r T 2 (1 0 m s)
D ra w ra n d o m n u m b e r 0 R i 1 N
R Pi? Y S e n d P H Y -A C C E S S -R E Q ( s ta rt o f L 1 P R A C H tra n s m is s io n p ro c e d u re )
N o Ack
L 1 a c c e s s in fo
N ack
? A ck
S e n d P H Y -D A T A -R E Q , in d ic a te T X sta tu s to h ig h e r la y e r (P R A C H m e s sa g e p a rt tra n sm itte d ) End
Figure 11 – MAC Flowchart of RACH Transmission Control
6.1.5.
RRC Control or Random Access Transmissions
The Radio Resource Control (RRC) initiates the MAC RACH transmission control algorithm whenever a message needs to be sent on the RACH. In addition, the RRC monitors the results of these transmissions and has the ability to resend messages that were not successfully transmitted. For the specific case of the RRC Connection Request message,
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
60 of 214
Ericsson UMTS Feature Guidelines
these retransmissions are controlled by the N300 and T300 parameters, which are broadcast in SIB 1. When it is determined that an Idle UE requires an RRC Connection, RRC will initiate the RRC Connection procedure. At the onset of this procedure, an internal counter, V300 is set to 1 and the RRC Connection Request message is submitted to the lower layers (MAC and L1) for transmission on RACH. When the MAC indicates either success or failure in sending this RRC message, timer T300 is started. If this transmission does not result in the reception of a RRC Connection Setup message before T300 expires, the RRC checks the value of counter V300. If V300 is less than or equal to N300, the RRC Connection Request message is resubmitted to the MAC for transmission on the RACH. This process is continued until either an RRC Connection Setup message is received by the UE, or the V300 counter exceeds the parameter N300. If the latter occurs, the UE enters idle mode and RRC Connection procedure is considered to be unsuccessful. (Reference 3GPP TS 25.331, Section 8.1.3.5) To summarize, if the transmission of the RRC Connection Request message does not result in the reception of the RRC Connection Setup message; it will be retransmitted N300 times with T300 seconds delay between transmissions. Failure to receive the RRC Connection Setup message may be due to several reasons, which include, but are not limited to:
The Layer 1 preambles were never detected
The Layer 1 preambles were detected, and a “Nack” was transmitted by the AICH (preambleRetransMax times)
The Layer 1 preambles were detected, an “Ack” was transmitted by the AICH, and the RRC Connection Request message was sent, however it was not successfully detected by the Node B
The RRC Connection Request message was received by the Node B, however the RRC Connection Setup message was not successfully detected by the UE.
In Ericsson implementation, these parameters are not operator configurable and are currently set as N300 = 5, and T300 = 2000 ms.
6.1.6. Interaction of RRC, MAC and Physical Layer Random Access Procedures As described before, the Physical, MAC, and RRC layers all play a part in the random access procedure. In order to clarify the interaction of these layers on random access, an example will be provided in this section. For this example, the following parameter values will be assumed:
powerOffsetP0 = 2 dB
preambleRetransMax = 15
maxPreambleCycle = 3
powerOffsetPpm = 2 dB
N300 = 5
T300 = 2000 ms
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
61 of 214
Ericsson UMTS Feature Guidelines
Assume that an idle UE is originating CS call, and RRC Connection Request message needs to be sent. The initial preamble power is determined by Equation 3 to be -25 dBm. The preamble is sent at this power and no acknowledgement is sent on the AICH. The second preamble is sent at -23 dBm (due to powerOffsetP0 = 2 dB). Assuming an acknowledgement is not received on all the following preambles, a total of 15 preambles (preambleRetransMax = 15) would be sent with the last one transmitting at +3 dBm. After a delay of 2-15 ms, the MAC would repeat the process up to 2 more times (maxPreambleCycle = 3). Every time the process is repeated, the initial preamble transmit power would be recalculated. If the process continued without a received acknowledgement on all the following preambles, an additional 30 preambles could be transmitted during the 2nd and 3rd preamble cycle. This would bring the total to 45 preambles for the initial RRC Connection Request (15 * 3 = 45 preambles). After a 2 second delay (T300 = 2000 ms), a second RRC Connection Request message would be sent to the MAC layer initiating the process to repeat. If this continues without an acknowledgement being received, it is possible that a total of 270 preambles could be sent over a 10-11 second period (45 * (5+1) = 270). This is a worst case scenario; however its occurrence in real world situation is not rare. As a second example, assume that RF conditions are poor and the initial preamble power is determined by Equation 3 to be +18 dBm. The second preamble is sent at +20 dBm and a positive acknowledgement is sent on the AICH. The UE would transmit the RRC Connection Request message with the control part of the message at +22 dBm (powerOffsetPpm = 2 dB). Assuming a RRC Connection Setup message is received within 2 seconds, then no additional preambles will be sent. Figure 12 is an example of a physical random access logged with TEMS. This mode report lists the initial preamble transmit power (18 dBm), the number of preambles sent during this cycle (2 preambles) and the result on the associated AICH slot (Ack received).
Figure 12 â&#x20AC;&#x201C; Log file of Physical Layer Random Access
6.1.7.
RACH Sub-Channels
As mentioned previously, some of the PRACH access slots may be reserved for UEs containing higher priority Access Class (AC) USIMS, such as those for emergency personnel. This functionality is accomplished by means of RACH sub-channels. By reserving one or more RACH sub-channels to a specific Access Service Class (ASC), the likelihood of a successful access can be improved for members of that AC. A RACH sub-channel is defined as a subset of the PRACH access slots. There are a total of 12 sub-channels with each sub-channel consisting of 5 access slots. Since 15 access slots span 2 radio frames, the 12 sub-channels repeat every 60 access slots (or 8 radio frames). Each sub channel consists of 5 access slots which include the access slot corresponding to
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
62 of 214
Ericsson UMTS Feature Guidelines
the sub channel number as well as the 12th access slot relative to the sub channel number. Table 2 defines the PRACH access slot to RACH sub-channel mapping (3GPP TS 25.214, Section 6.1.1). As shown in the Table 2, Sub-channel 0 consists of 5 access slots: 0 (frame 1), 12 (frame 2), 9 (frame 3), 6 (frame 4), and 3 (frame 6). Here access slot 0 corresponds to the sub channel number 0, and the 12th access slot for this sun channel would be access slot 12. Sub-channels 1-11 are similarly distributed across the 8 radio frames. SFN modulo 8 0 of corresponding P-CCPCH frame 0 0 1 12 2 3 4 5 6 7
Sub-channel number 1
2
3
4
5
6
7
1 13
2 14
3
4
5
6
7
0 12
1 13
2 14
3
9 6
10 7
3
4
11 8 5
9 6
10 7
8
9
10
11
8 5
9 6
10 7
11
4 1 13
2 14
3
4
8 5
11
0 12
8
9
10
11
0 12
1 13
2 14
Table 2 – The available uplink access slots for different RACH sub-channels
6.1.8.
Access Class and Access Service Class
16 Access Classes (0-15) are defined for UMTS and GSM users (3GPP TS 22.011). Access Classes 0 to 9 are equivalent and are randomly allocated to all UEs such that every UE belong to one of these ten Access Classes. The access class assigned to a user is stored in their SIM/USIM. In addition to these first 10 Access Classes, UEs may also belong to one or more of the 5 special Access Classes (11-15). These special Access Classes are allocated to high priority users as follows:
Class 15: PLMN Staff;
Class 14: Emergency Services;
Class 13: Public Utilities (e.g. water/gas suppliers);
Class 12: Security Services;
Class 11: For PLMN Use
Access Class 10 is used for Emergency Calls. In addition, any number of these Access Classes may be barred access to the network at any time. For example, Access Classes 015 can be barred access to a site during maintenance, or testing. Alternatively, Access Classes 0-9 can be barred access to the entire network during a natural disaster (e.g. a hurricane). The 16 Access Classes are mapped to 7 Access Service Classes (ref 3GPP 25.331, Section 8.5.13). This mapping is shown in Table 3. At the RRC layer, the set of available signatures and the set of available RACH sub-channels for each Access Service Class (ASC). In this manner, specific RACH signatures and RACH sub-channels can be reserved for specific Access Classes.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
63 of 214
Ericsson UMTS Feature Guidelines
AC ASC
0–9 1st IE
10 2nd IE
11 3rd IE
12 4th IE
13 5th IE
14 6th IE
15 7th IE
Table 3 – Access Class to Access Service Class Mapping
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
64 of 214
Ericsson UMTS Feature Guidelines
6.2. Random Access Parameter Optimization and Troubleshooting When optimizing the Random Access parameters, one must consider the tradeoffs between accessibility, and capacity. As previously stated, it is quite possible to aggressively configure the Random Access parameters to improve the likelihood of accessing the network, at the cost of capacity. Alternatively, it is also possible to be overly concerned about capacity at the cost of successfully accessing the network. Several of the parameters utilized in the random access process can be configured to achieve one of these extremes. This section will discuss how the configurations of these parameters will affect accessibility, as well as capacity. As previously described, the initial preamble transmit power is calculated at the beginning of every ramping cycle, using Equation 3. The configurable parameter in this equation is constantValueCprach, which has a default value of -27 dB. If the maximum value of -10 dB was used, the initial preamble transmit power would likely be excessive, as well as the power of the subsequent RRC message. Although the chance for successfully sending the RRC message is increased, the side effect of increased UL interference is unwanted. Note that if drive testing analysis determines that the estimated transmit power for the initial preamble is consistently low; adjusting this parameter to a higher value (e.g. – 24 dB) will improve the accuracy of the estimate. Alternatively, if drive testing analysis determines that a large percentage of the initial preambles are being acknowledged, then the initial preamble power is likely to be excessive and constantValueCprach may need to be reduced. Once the initial preamble transmit power is calculated, the preamble power is ramped until an acknowledgement is detected on the AICH. The two parameters related to this functionality are powerOffsetP0, and preambleRetransMax. The dynamic range of the power ramping function can be calculated by using Equation 4. Assume that 2 dB and 15 were used for powerOffsetP0, and preambleRetransMax respectively. This would result in a dynamic range of 28 dB. The dynamic range of the UE (assuming 24 dBm max power) is (24 dBm – (-50 dB) = 74 dB. Comparing these two ranges emphasizes the need for the initial preamble power estimate to be relatively accurate. Under certain conditions (i.e. very high measure CPICH RSCP), it has been observed in the field that this estimate is erroneous and yields a value that is too low. The result, in some cases, is that all preambleRetransMax preambles are transmitted, no acknowledgement was received, and the UE did not transmit at maximum power (e.g. 24 dBm).
PowerRampD ynRange powerOffsetP0 preambleRetransMax - 1 Equation 4 – Dynamic Range of Preamble Power Ramping Function An example of this is shown in Figure 13. As the mode report shows, 15 preambles were transmitted without an acknowledgement received on the AICH. The initial preamble transmit power is -40 dBm, and the step size is 2 dB (not shown). This equates to a final preamble transmit power of -12 dBm, which is 36 dB less than the maximum UE transmit power. The occurrence of this scenario needs to be minimized as it can lead to access failures and increased call setup time.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
65 of 214
Ericsson UMTS Feature Guidelines
Figure 13 - Log File of Failed Preamble Ramping Function To mitigate the risk of this occurring, the dynamic range of the power ramping function can be increased. This can be accomplished by increasing either powerOffsetP0 or preambleRetransMax. If powerOffsetP0 is increased, the potential of overshooting the required preamble transmit power during a power ramp step is increased. The average amount of overshoot should be approximately (50% x powerOffsetP0). Therefore, increasing the step size from 2 to 3 dB would result in the average amount of overshoot increasing from 1 dB to 1.5 dB. The alternative would be increasing the maximum number of preamble step with the parameter preambleRetransMax. Although this change would not result in an increase in the average amount of overshoot, it would potentially increase the number of preambles transmitted. Although this could result in increased setup time and rise, the effects should be negligible and should only affect UEs in bad radio condiitons. Since this scenario has a low percentage of occurrences, increasing the preambleRetransMax parameter would have the least effect on the network, given the two options. If drive test analysis determines that this scenario is occurring frequently, increasing the preambleRetransMax value may be required. Since this is a UtranCell parameter, only cells effected by this problem can be modified. The final issue to consider is related to the transmission of the RRC Connection Request message after a positive acknowledgement has been received on the AICH. The parameter powerOffsetPpm defines transmit power of the message, relative to the last transmitted preamble. For example, if the last transmitted preamble was sent at +10 dBm, and powerOffsetPpm = 2 dB, the control part of the RRC message would be sent at +12 dBm. Since both the preamble signature and the RRC Connection Request message have the same processing gain, it is tempting to set the parameter to 0 dB (which would also reduce UL interference). However one must consider the Node Bs ability to receive and decode these messages. The preamble signatures are known to the Node B. By using a matched filter in the channel element, the Node B only has to detect the preamble, not actually decode the message. On the other hand, the RRC Connection Request message must be received and correctly decoded by the Node B. Based on this, it is likely that the transmit power for the RRC Connection Request message should be higher than the power used on the detected preamble. If test analysis indicates this scenario may be occurring, it can be validated with RNC logs (e.g. UETR) and powerOffsetPpm parameter can be optimized.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
66 of 214
Ericsson UMTS Feature Guidelines
7. Paging Procedures The primary purpose of paging is to set up a Mobile Terminating (MT) call. The idle User Equipment (UE) is normally paged in a Location Area (LA) or a Routing Area (RA) using a subscriber-Id (e.g. IMSI or P-TMSI), depending on the Core Network (CN) domain that originated the page message. The idle UE’s response to the paging message will reveal its location at the cell level to the network and necessary signaling will continue on common and/or dedicated channels in order to establish a connection to the UE. The LA and RA definitions in UMTS are exactly the same as for GERAN. As a vendor feature, the UE may be paged in a global RNC area corresponding to cells under the control of one RNC. In UMTS the paging procedure has been enhanced in a number of ways. This is required in order to deal with the more complicated behavior of the UE in connected mode (“connected while sleeping”), and the increased responsibilities of the UTRAN in managing radio related tasks. As an example, unlike GERAN, a paging message in UMTS may be originated autonomously by the RNC in order to inform the UE about changes in System Information Blocks (SIB), or trigger the UE to do a Cell Update. As in 2G networks there is a great need for reducing battery consumption by the UEs. UMTS also utilizes a discontinuous reception (DRX) mechanism on paging channels which is similar to the paging-groups concept of GSM but quite different in details due to the radical difference in the air interface between GSM and UMTS. This is discussed in the following sections. In addition to paging in LA and RA, UMTS defines a new paging area known as UTRAN Registration Area (URA). The URAs are known only within the UTRAN and are generally independent of LAs and RAs. A UE is paged in a URA only when it is in the RRC URA_PCH mode (i.e. it has an active RRC connection towards a Serving RNC). A single cell can belong to more than one URA, thus allowing for overlapping URAs. SIB 2 indicates a list of URAs the cell belongs to, and a UE can be assigned more than one URA-id. Careful URAplanning involves considerations regarding a balance between the paging load and UE initiated URA-updates, similar to LA/RA planning. The chart below shows the possible scenarios related to paging in terms of the UE states, the resources used, the originating node for pages and the paging area. Further details on Paging in UTRAN can be found in [19]. In Ericsson, CELL_PCH state is not implemented.
UE State
RRC Connected
Paging Type
Resources Used
Originating Node
Paging Reason
Paging Area
Idle
No
Type 1
PICH & SCCPCH (carrying PCH)
CN
Terminating service
LA/RA
UTRAN
System Information updates
CN
Terminating service from
CELL_DCH
Yes
T-Mobile USA, INC. Confidential
Type 2
DPCCH (carrying
Rev. 3.0
Sep 11, 2008
Specific UE
67 of 214
Ericsson UMTS Feature Guidelines
DCH)
a CN that UE is not connected to
CELL_FACH
Yes
Type 2
SCCPCH (carrying FACH) and PRACH (carrying RACH)
CN
Terminating service from a CN that UE is not connected to
Specific UE
CELL_PCH
Yes
Type 1
PICH & SCCPCH (carrying PCH)
CN
CS terminating service
Last known cell
UTRAN
System Information updates, allow UE to trigger cell update
CN
CS terminating service
UTRAN
System Information updates, allow UE to trigger cell update
URA_PCH
Yes
Type 1
PICH & SCCPCH (carrying PCH)
Last known URA
7.1. Paging Types The paging procedure is normally initiated by CN using the RANAP procedure called PAGING. Once the PAGING message has been received by the RNC, it will use one of the two types of RRC paging messages depending on the state of the UE.
7.1.1.
Paging Type 1
For a UE in RRC Idle state, an RRC: PAGING TYPE 1 is sent from the RNC to the UE. Two parameters in Paging Type 1 are the CN domain-Id and the IMSI/(P)TMSI of the paged UE. If the UE has already an RRC connection, then the RNC may convert the IMSI/(P)TMSI to a UTRAN Radio Network Temporary Id (U-RNTI). The reception of the PAGING TYPE 1 message typically results in the establishment of an RRC Connection which is initiated by the UE after the page message is received. T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
68 of 214
Ericsson UMTS Feature Guidelines
Another use of the Paging Type 1 message is when the UE has an RRC connection but no radio resources are allocated to it. In this case the UE is either in Cell_PCH or URA_PCH mode. As indicated by the name of these RRC states, the UE’s position is known to the serving RNC at cell and URA levels respectively and the UE is monitoring the paging channel based on certain criteria that can be set differently from the idle mode criteria for monitoring paging channels.
Figure 14 - Signaling for Paging Type 1
7.1.2.
Paging Type 2
For a UE that is already in the RRC Connected mode and has dedicated (Cell-DCH) or common channels (Cell_FACH) assigned to it, the paging procedure uses the RRC PAGING TYPE 2 message. This is especially useful in a scenario where the other CN domain that does not already have an active connection with the UE wants to establish a new signaling connection. PAGING TYPE 2 is sometimes referred to as “Dedicated Paging”. From the radio access point of view this is just like any other signaling message carried on dedicated channels.
Figure 15 – Signaling for Paging Type 2 Note that the RANAP PAGING message is similar in both cases. It is the RNC that decides to initiate the correct paging type based on UE-id and the current state of the paged UE. The UE’s response to these paging messages also depends on the current RRC state of the UE. In RRC Idle mode, the UE sends an RRC Connection Request message with establishment cause set to “paging response”. In RRC connected mode the paging can trigger the UE to change RRC state from Cell_PCH or URA_PCH to Cell_FACH by doing a Cell Update procedure, with cause value set to “paging response”. Alternatively the UE will directly send a Paging Response if it is already in Cell_DCH/FACH mode. An autonomous
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
69 of 214
Ericsson UMTS Feature Guidelines
Paging Type 1 message can be initiated from the RNC when new downlink data or signaling messages need to be sent to the UE. This causes the UE to transition to Cell_FACH and subsequently do a Cell Update.
Figure 16 - State Changes due to Paging
7.2. Paging Channels The paging message is carried in the downlink on the Logical channel Paging Control Channel (PCCH). The logical channel is mapped to the transport channel Paging Channel (PCH) at the MAC layer. This channel in turn is coded and carried over the air using the Secondary Common Control Physical Channel (S-CCPCH). A paging message type 2 is associated with the Dedicated Control Channel DCCH, which may be mapped to FACH or DCH transport channels. A cell may be configured with more than one S-CCPCH depending for example on the cell load and the expected paging volume. The S-CCPCH spreading factor (SF) may be chosen from any valid SF from 4 to 256.
Figure 17 - Logical, Transport, and Physical Channels Associated with Paging
7.2.1.
Paging Indication Channel
The Paging Indicator Channel (PICH) has fixed spreading factor of 256 and carries the Paging Indicator. The paging indicator indicates the presence of a page message on the PCH for the UEs using Paging Indicator (PI) bits. Each PICH is associated with a S-CCPCH which carries the transport channel PCH (see Figure 17). Of the 300 available bits in a 10ms PICH frame, 288 are used to carry paging indicators, while the remaining 12 bits are not used. Each PICH frame can carry Np paging indicators, where Np = 18, 36, 72 or 144,
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
70 of 214
Ericsson UMTS Feature Guidelines
corresponding to 16, 8, 4 or 2 bits per Paging Indicator. The PICH frame timing is fixed in relation to the associated S-CCPCH. The PICH transmission power is given in relation to the CPICH power level and depends on the number of PIs configured in PICH. For higher Np values, more power is needed on the PICH. This follows from the fact that for higher Np values there will be fewer bits for each PI. In order to maintain an acceptable bit error probability, more power per bit will be required. The PICH power offset is broadcasted in SIB 5/6. On the other hand, a higher Np value can decrease the probability of false paging indications. A false paging indication occurs when a UE sees positive paging indication on PICH but does not see a paging message on S-CCPCH for itself (IMSI/TMSI or RNTI). In Ericsson implementation, the value of Np is hard coded to 18.
Figure 18 – PICH and PCH Frame Synchronization
7.3. DRX Procedure A UE in idle mode (or RRC Cell_PCH/URA_PCH) has to continuously monitor PCH so that it will not miss any incoming calls or RRC messages. This can be very demanding on the UE’s battery power consumption. For this reason, discontinuous reception (DRX) mechanism is used in UMTS as in many other wireless systems. The PICH is used to indicate to the UE when it should read the S-CCPCH which carries the true paging message. If a UE that is monitoring the PICH does not see an indication that it is paged, it will ignore the following S-CCPCH. If the UE does see an indication then it will decode the S-CCPCH which occurs 2ms after the PICH frame. This may be a false indication as described above. In that case the S-CCPCH will carry a paging message for another UE that happens to share the same PI. Although the PICH carries a simple “yes-no” message, listening to PICH on every frame is not a very effective power saving feature. Further enhancement to power saving can be achieved if the UE only wakes up and listens to certain PICH frames. This frequency of wake-up is called the Paging Occasion (PO) and is determined by important DRX cycle length parameter. Each UE will calculate a PO which simply corresponds to the frame number that the UE must read the PICH on. The PO is a function of the IMSI, the DRX cycle length, and the number of S-CCPCH in the cell and the System Frame Number (SFN). In Ericsson’s current implementation, only 1 SCCPCH can be configured per cell. Hence the paging occasions for a specific UE are calculated as
(IMSI mod DRX cycle length) + n * DRX cycle length where n = 0, 1, 2 …
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
71 of 214
Ericsson UMTS Feature Guidelines
Using the Np value and the IMSI, the UE can also calculate its own Paging Indicator to know where in the PICH to look for paging indicators. The paging indicator for a particular UE can be calculated based on its IMSI as PI = (IMSI div 8192) mod Np
Figure 19 - Paging Occasions The DRX cycle length is defined by Equation 5, where k is the DRX cycle coefficient and ranges from 3 to 9. The possible DRX values are then from 80ms to a little more than 5 seconds of sleeping time. If this value is set too low, the UE is more active in monitoring the PICH, thus decreasing the UE stand-by time. On the other hand, large values of this parameter will increase mobile-terminating call set-up times, since the UE will take longer periods of time to read the PICH. The DRX Cycle Length value can be set separately for each Core Network domain type. If a UE is connected to both the PS and CS Core networks simultaneously, then the shorter of the two values will always be used by the UE. For UEs in connected mode (URA_PCH and Cell_PCH) a separate k value is defined as in the table below. It is generally considered beneficial to decrease the DRX cycle length for connected mode UEs since transitions to Cell_FACH need to occur faster in comparison to those between idle mode and connected mode.
DRX_CYCLE_LENGTH ď&#x20AC;˝ 2 k ď&#x201A;´ 10 msec Equation 5 - DRX Cycle Length A useful rule-of-thumb used by Ericsson when dealing with the DRX_Cycle_Length parameter, is the fact that an increase in the DRX_Cycle_Length will generally increase the call set-up time by half of the increased amount. For example, changing the value from 640 ms to 1280 ms (k is changed from 6 to 7) will increase the call set-up time by (1280-640) ms/2 = 320 ms on average.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
72 of 214
Ericsson UMTS Feature Guidelines
7.4. Paging Repetition Paging repetition in Ericsson UTRAN depends on the UE state and on where the page was originated.
A page that is initiated by the CN is repeated by the UTRAN “noOfPagingRecordTransm” subsequent times, irrespective of the response to the first paging attempt.
A UTRAN originated page for a UE in URA_PCH state is time supervised. An RNC timer is started when a page is sent and stopped when the UE answers. If the timer expires the paging is repeated once. On a second expiry of this timer, the PS connection of the UE is released. The RNC timer is hard coded to a value of (10 ms * 2k * noOfPagingRecordTransm) + 1000 ms, where k = utranDrxCycleLength.
When the UTRAN has to inform a UE about updates to system information, it sends a number of consecutive Paging Type 1 messages to the UE using the maximum possible DRX cycle length to ensure that the UE receives this at least once. The number of times a page indicating updates to the same system information is sent to the UE is set with a configurable RNC parameter “noOfMaxDrxCycles”.
7.5. Ericsson Specific Counters for Paging 7.5.1.
Ericsson Paging Counters
Figure 19 illustrates the counters associated with the Ericsson Paging Process. These counters include, but are not limited to the following:
pmNoPagingAttemptCnInitDcch
pmCnInitPagingToIdleLa
pmNoPageDiscardCmpLoadC
pmCnInitPagingToIdleRa
pmCnInitPagingToIdleUe
pmNoPagingAttemptUtranRejected
pmCnInitPagingToUraUe
pmUtranInitPagingToUraUe
pmNoPagingType1Attempt
pmNoPagingType1AttemptPS
pmNoPagingType1AttemptCS
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
73 of 214
Ericsson UMTS Feature Guidelines
Figure 20 Flowchart for Ericsson Counters, Paging
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
74 of 214
Ericsson UMTS Feature Guidelines
8. Soft/Softer Handover Soft/Softer Handover implies that a UE is connected to more than one WCDMA BTS at the same time. For a UE moving from the coverage area of one WCDMA cell to another, Soft/Softer handover allows the UE to start communicating with the new cell before it stops communicating with the old cell. In Soft Handover, the UE is connected to at least 2 cells belonging to different Node B’s, and the uplink signals from the different cells are combined in the RNC. When the UE is connected to at least 2 cells belonging to the same Node B, the handover is called Softer Handover, and in this case, the uplink signals from the different cells are combined in the Node B. The following are the advantages of Soft/Softer handover.
Seamless Handover without disconnection of the radio access bearer.
Fast closed loop power control is possible since the UE is always linked to the strongest cell.
Sufficient reception level for communication at cell edge by combining reception signals from different cells.
The macro diversity gain achieved by combining reception signals improves the uplink signal quality and decreases the required transmission power of the UE, reducing uplink interference and increasing system capacity.
Despite the above advantages of Soft/Softer Handover, there is a trade-off between soft handover and system capacity. A UE involved in Soft/Softer Handover uses several radio links, more DL channelization codes, more DL power and more channel elements than a single link connection. However, as long as the number of radio links involved in Soft Handover is optimized, the capacity advantage offered due to Soft Handover from interference reduction is larger and hence system capacity is actually improved.
8.1. Soft/Softer Handover Procedure and Parameters The Soft/Softer handover Algorithm can be split into the following 3 parts.
Algorithm for handling cell sets, subsets and Lists to determine the subset of cells to be measured on by the UE based on the cells present in the active set and their configured neighboring cells. This has been detailed in the previous 2 sections.
Soft/Softer Handover Evaluation for determining which cells should be proposed to be added, removed, or replaced in the Active Set. The algorithm bases its decision on quality measures of the P-CPICH done in the UE. An evaluation that results in a revised Active Set proposes it to the execution part of Soft/Softer handover.
Soft/Softer Handover Execution covers the actual addition and/or removal of radio links proposed by the Soft/Softer Handover Evaluation algorithm.
Soft/Softer Handover evaluation is enabled for a UE entering the CELL_DCH state. Soft/Softer Handover evaluation is performed based on the UE’s intra frequency measurement report. Before the first MEASUREMENT CONTROL message has been sent from the RNC, any MEASUREMENT REPORT message received from the UE is evaluated based on intra-frequency measurement reporting criteria broadcasted by system information (SIB11/SIB12).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
75 of 214
Ericsson UMTS Feature Guidelines
Soft/Softer Handover is controlled by the events 1a, 1b, 1c and 1d. The following is the description of these four events.
Event 1a: A new candidate for the active set enters the reporting range.
Event 1b: A cell in the active set leaves the reporting range.
Event 1c: A cell not in the active set becomes stronger than a cell in the active set when the active set is at its maximum size.
Event 1d: Any cell becomes better than the best cell in the active set.
When a UE enters CELL_DCH state, intra frequency measurements are set up by sending a MEASUREMENT CONTROL message with IE MEASUREMENT REPORT MODE set to “setup” for event 1a, 1b, 1c and 1d. This first MEASUREMENT CONTROL message is used to setup the UE reporting mode as well as send the very first Intra-frequency Monitored Subset. After an Active Set update, a MEASUREMENT CONTROL message with IE “MEASUREMENT REPORT MODE” set to “modify” for event 1a, 1b, 1c and 1d is sent to the UE, telling it which cells will be added to and deleted from the Monitored Subset. The measurement criteria don’t change during a connection lifetime. The UE is configured to check event criteria for the different events as follows:
Event 1a: IAF Monitored Subset and Detected set cells.
Event 1b: Active set cells
Event 1c: Any cell that is not included in the active set.
Event 1d: Any cell that is not the best cell.
In addition to the 3GPP cell sets, Ericsson 3G network uses the following additional classification. Valid Cell: A cell that is part of the Active Set, Monitored set or the Unmonitored set, so that the SRNC is able to translate information about reported P-CPICH scrambling code to a configured cell by using the configured neighbor cell lists. Invalid Cell: A cell that is not part of the Active Set, Monitored set or the Unmonitored set, so the SRNC does not have information for P-CPICH scrambling code translation to a configured neighboring cell. The UE is configured to base event evaluation as per the setting of the parameter measQuantity1. The measured values are filtered by the UE before comparing the resulting values with the event report criteria. Recommended Value: The recommended value for measQuantity1 is CPICH_EC_NO. This configures the UE to base event evaluation on CPICH Ec/No. A MEASUREMENT REPORT sent by the UE for event 1a, 1b, 1c and 1d contains the following messages:
Quality of cells in the active set.
List of cells that fulfill the event criteria.
Quality of cells that fulfill the event criteria.
Synchronization information for the cells that fulfill the event criteria.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
76 of 214
Ericsson UMTS Feature Guidelines
8.1.1.
Event 1a Evaluation
Reporting event 1a is used to add cells into the active set. The UE sends event 1a triggered measurement report when a cell enters the reporting range defined by the following formula for at least a time equal to timeToTrigger1a.
NA 10 LogM New individualoffset New w1a 10 Log M i (1 w1a) 10 LogM best (reportingRange1a hyster i 1 The following are the definitions of the parameters used. MNew: measurement result of the cell entering the reporting range individualoffsetNew: offset of the neighbor cell entering the reporting range. w1a: weighting factor for event 1a. Mi: measurement result of a cell in the active set. NA: number of cells in the current active set. Mbest: measurement result of the strongest cell in the active set. reportingRange1a: relative threshold referenced to the CPICH of the best cell in the active set. hysteresis1a: Hysteresis used in event evaluation for event 1a to avoid ping pong effects. timeToTrigger1a: Minimum time during which a candidate cell should stay within reporting range of event 1a before the UE can send event 1a triggered measurement report to the RNC. filterCoefficient1: The measured values are filtered by the UE using the filter coefficient value before comparing with event criteria. Since the parameter measQuantity1 is recommended to be set to CPICH_EC_NO, the measurement result in the above equation refers to the CPICH Ec/No of the relevant cell. Recommended Value: The recommended value for w1a is 0 for network launch, so that the event evaluation is only done with respect to the best cell in the active set. Refer to the Appendix A for more information on the weighting factor. The recommended value for parameter individualoffset is 0 for initial network launch. These parameters should be reevaluated based on network statistics and changed to a non-zero value only as needed for specific scenarios. When an event 1a triggered MEASUREMENT REPORT is received, the Soft/Softer Handover Evaluation Algorithm at the RNC processes the report and evaluates if the proposed candidate can be added to the Active set. Only the best cell that fulfilled the reporting criteria is retained, and all other cells from the MEASUREMENT REPORT are discarded. If the retained cell already belongs to the Active set, the RNC updates the Active Set with the Ec/No value from the measurement report and the evaluation process terminates with no other actions. If the retained cell is not in the active set, the following 3 scenarios are possible based on the validity of the retained cell. Invalid Retained Cell: If the retained cell is invalid and the quality measure (Ec/No) of this invalid cell is not included in the MEASUREMENT REPORT, then the Soft Handover evaluation process is terminated. If the retained cell is an invalid cell and its quality measure
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
77 of 214
Ericsson UMTS Feature Guidelines
exceeds the quality measure of the best cell in the Active set by an amount defined by the parameter releaseConnoffset, then the connection is terminated. The reason for terminating this connection is to avoid UL interference caused by the UE entering a new cell area without being power controlled by that cell. If the retained cell is invalid, but the quality measure of the cell doesn’t exceed the quality measure of the best cell in the Active set by the amount of releaseConnoffset, then the Soft handover Evaluation procedure updates the ordered Active Set List with the quality measure reported in the received measurement report, and the evaluation process terminates with no other action. Valid retained Cell missing synchronization information: If the retained cell is a valid cell but is missing synchronization information, the Soft handover procedure can’t be executed, since the synchronization information is necessary to perform soft handover. Hence the Soft Handover Evaluation Procedure updates the quality measures in the ordered Active Set List with the values received in the Measurement report, and the evaluation process terminates with no other actions. Valid retained Cell with synchronization information: If the retained cell is valid with synchronization information available, and the number of cells in the current active set is less than the amount defined by the parameter maxActiveSet, the Soft handover Evaluation Algorithm creates a new Active Set by adding the retained cell to the Active set. If the retained cell is valid with synchronization information available, but the number of cells in the current active set is equal to the maximum possible valued defined by the parameter maxActiveSet, and the quality of the retained cell is better than that of the worst cell in the Active set, the Soft Handover Evaluation Algorithm creates a new Active set by replacing the worst cell in the previous Active set with the retained cell. Recommended Value: The recommended value for the parameter maxActiveSet is 3. This would limit the number of soft handover links, thus optimizing network capacity.
8.1.2.
Event 1b Evaluation
Reporting event 1b is used to delete cells from the Active set. The UE sends event 1b triggered measurement report when a cell leaves the reporting range defined by the following formula for at least a time equal to timeToTrigger1b.
NA 10 LogM individualoffset w1b 10 Log M (1 w1b) 10 LogM (reportingRange1b hysteresis Old Old best i 1 i The following are the definitions of the parameters used. MOld: measurement result of the cell leaving the reporting range individualoffsetOld: offset of the neighbor cell leaving the reporting range. w1b: weighting factor for event 1b. Mi: measurement result of a cell in the active set. NA: number of cells in the current active set. Mbest: measurement result of the strongest cell in the active set. reportingRange1b: relative threshold referenced to the CPICH of the best cell in the active set.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
78 of 214
Ericsson UMTS Feature Guidelines
hysteresis1b: Hysteresis used in event evaluation for event 1b to avoid ping pong effects. timeToTrigger1b: Minimum time during which a candidate cell should stay within reporting range of event 1b before the UE can send event 1b triggered measurement report to the RNC. filterCoefficient1: The measured values are filtered by the UE using the filter coefficient value before comparing with event criteria. Since the parameter measQuantity1 is recommended to be set to CPICH_EC_NO, the measurement result in the above equation refers to the CPICH Ec/No of the relevant cell. Recommended Value: The recommended value for w1a is 0 for network launch, so that the event evaluation is only done with respect to the best cell in the active set. Refer to the Appendix A for more information on the weighting factor. The recommended value for parameter individualoffset is 0 for initial network launch. These parameters should be reevaluated based on network statistics and changed to a non-zero value only as needed for specific scenarios. When an event 1b triggered MEASUREMENT REPORT is received, the Soft Handover Evaluation Algorithm at the RNC processes the report and evaluates if the proposed candidate can be removed from the Active set. If the event 1b triggered MEASUREMENT REPORT includes more than 1 cell, then all the cells fulfilling the reporting criteria are stored in a Remove List. The Soft Handover Evaluation Algorithm retains the first cell in the Remove List and deletes it from the list. If this retained cell is not in the Active set, then the next cell on the Remove List is processed. When the current retained cell is in the Active Set, the Soft handover Evaluation Algorithm creates a new proposed Active set by removing the retained cell from the Active set. The new Active Set is forwarded to the Soft Handover Execution Algorithm. This process is repeated as long as there is at least 1 cell remaining in the Remove List. When the Remove List is empty, the evaluation process terminates for that particular MEASUREMENT REPORT.
8.1.3.
Event 1c Evaluation
Reporting event 1c is used for replacing cells in the Active Set. A UE sends the event 1c triggered MEASUREMENT REPORT when the number of cells in the Active set is equal to the value defined by parameter maxActiveSet, and a cell that is not included in the Active Set becomes better than a cell in the Active set as defined by the following formula for at least a time equal to timeToTrigger1c.
10 LogM New individualoffset New 10 LogM InAS individualoffset InAS hysteresis1c / 2 The following are the definitions of the parameters used. MNew: measurement result of the cell not included in the Active set. individualoffsetNew: offset of the neighbor cell not included in the Active set. MInAS: measurement result of a cell in the active set with the least measurement value among active set cells. IndividualoffsetInAS: offset of the cell in the Active set. hysteresis1c: Hysteresis used in event evaluation for event 1c to avoid ping pong effects.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
79 of 214
Ericsson UMTS Feature Guidelines
timeToTrigger1c: Minimum time during which a candidate cell should stay stronger than a cell in the Active set before the UE can send event 1c triggered measurement report to the RNC. filterCoefficient1: The measured values are filtered by the UE using the filter coefficient value before comparing with event criteria. Since the parameter measQuantity1 is recommended to be set to CPICH_EC_NO, the measurement result in the above equation refers to the CPICH Ec/No of the relevant cell. The evaluation of an event 1c triggered MEASUREMENT REPORT is the same as of an event 1a triggered report. When an event 1a triggered MEASUREMENT REPORT is received, the Soft Handover Evaluation Algorithm at the RNC processes the report and evaluates if the proposed candidate can be added to the Active set. Only the best cell that fulfilled the reporting criteria is retained, and all other cells from the MEASUREMENT REPORT are discarded. If the retained cell already belongs to the Active set, the RNC updates the Active Set with the Ec/No value from the measurement report and the evaluation process terminates with no other actions. If the retained cell is not in the active set, the following 3 scenarios are possible based on the validity of the retained cell. Invalid Retained Cell: If the retained cell is invalid and the quality measure (Ec/No) of this invalid cell is not included in the MEASUREMENT REPORT, then the Soft Handover evaluation process is terminated. If the retained cell is an invalid cell and its quality measure exceeds the quality measure of the best cell in the Active set by an amount defined by the parameter releaseConnoffset, then the connection is terminated. The reason for terminating this connection is to avoid UL interference caused by the UE entering a new cell area without being power controlled by that cell. If the retained cell is invalid, but the quality measure of the cell doesnâ&#x20AC;&#x2122;t exceed the quality measure of the best cell in the Active set by the amount of releaseConnoffset, then the Soft handover Evaluation procedure updates the ordered Active Set List with the quality measure reported in the received measurement report, and the evaluation process terminates with no other action. Valid retained Cell missing synchronization information: If the retained cell is a valid cell but is missing synchronization information, the Soft handover procedure canâ&#x20AC;&#x2122;t be executed, since the synchronization information is necessary to perform soft handover. Hence the Soft Handover Evaluation Procedure updates the quality measures in the ordered Active Set List with the values received in the Measurement report, and the evaluation process terminates with no other actions. Valid retained Cell with synchronization information: If the retained cell is valid with synchronization information available, but the number of cells in the current active set is equal to the maximum possible valued defined by the parameter maxActiveSet, and the quality of the retained cell is better than that of the worst cell in the Active set, the Soft Handover Evaluation Algorithm creates a new Active set by replacing the worst cell in the previous Active set with the retained cell.
8.1.4.
Event 1d Evaluation
Reporting event 1d is used to change the best cell in an Active set. A UE send the event 1d triggered MEASUREMENT REPORT when a cell in the Active set, Monitored set or Detected set becomes stronger than the best cell in the Active set as defined by the following formula for at least a time equal to timeToTrigger1d.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
80 of 214
Ericsson UMTS Feature Guidelines
10 LogM NotBest 10 LogM Best hysteresis1d / 2 The following are the definitions of the parameters used MNotBest: measurement result of a cell that is currently not the best cell. MBest: measurement result of the best cell in the active set. hysteresis1d: Hysteresis used in event evaluation for event 1d to avoid ping pong effects. timeToTrigger1d: Minimum time during which a candidate cell should stay stronger than the best cell in the Active set before the UE can send event 1d triggered measurement report to the RNC. filterCoefficient1: The measured values are filtered by the UE using the filter coefficient value before comparing with event criteria. Since the parameter measQuantity1 is recommended to be set to CPICH_EC_NO, the measurement result in the above equation refers to the CPICH Ec/No of the relevant cell. When an event 1d triggered MEASUREMENT REPORT is received, the Soft Handover Evaluation Algorithm at the RNC processes the report and evaluates if the proposed candidate can be added to the Active set. If the retained cell already belongs to the Active set, the RNC updates the Active Set with the Ec/No value from the measurement report and the evaluation process terminates with no other actions. If the retained cell is not in the active set, the following 3 scenarios are possible based on the validity of the retained cell. Invalid Retained Cell: If the retained cell is invalid then the Soft Handover evaluation process is terminated with no other actions. Valid retained Cell missing synchronization information: If the retained cell is a valid cell but is missing synchronization information, the Soft handover procedure can’t be executed, since the synchronization information is necessary to perform soft handover. Hence the Soft Handover Evaluation Procedure updates the quality measures in the ordered Active Set List with the values received in the Measurement report, and the evaluation process terminates with no other actions. Valid retained Cell with synchronization information: If the retained cell is valid with synchronization information available, and the number of cells in the current active set is less than the amount defined by the parameter maxActiveSet, the Soft handover Evaluation Algorithm creates a new Active Set by adding the retained cell to the Active set. If the retained cell is valid with synchronization information available, but the number of cells in the current active set is equal to the maximum possible valued defined by the parameter maxActiveSet, then the Soft Handover Evaluation Algorithm creates a new Active set by replacing the worst cell in the previous Active set with the retained cell. In most cases event 1d is triggered when a cell already in the active set becomes stronger than the best cell. Hence these reports will not lead to a proposed Active Set. The ordered Active Set List is updated with the Ec/No values reported in the Measurements section of the received report and the evaluation process terminates with no other actions.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
81 of 214
Ericsson UMTS Feature Guidelines
8.1.5.
Event Triggered Periodical Measurement Reporting
When a cell enters the reporting range and triggers event 1a or 1c, the UE transmits a measurement report to the RNC in order to update the Active Set. The RNC maybe unable to add the reported cell to the Active set due to various reasons, one of which is capacity shortage on the target cell. If the UE doesn’t receive an Active Set Update message from the RNC, it continues the measurement reporting by changing to periodical reporting mode. During periodical reporting, the UE transmits measurement reports to the RNC at predefined intervals. If an event 1a triggered measurement report doesn’t result in an Active Set Update message received, the UE transmits the same event every interval defined by the parameter reportingInterval1a. If an event 1c triggered measurement report didn’t result in an Active Set Update message, then the UE transmits this event every interval defined by the parameter reportingInterval1c. The event triggered periodic reporting is applicable only for valid retained cells that weren’t added to the Active set. An invalid cell will not be considered by the RNC to be part of the Active set to begin with. Event-triggered periodic measurement reporting is terminated either when there are no more monitored cells within the reporting range or when the RNC has updated the active set so that it includes the optimal cells
8.1.6.
Buffering and Queuing
There are 3 buffers for event 1x measurement reports. There is 1 combined buffer for event 1a and event 1c, a separate buffer for event 1b and another for event 1d. The 1a/1c reporting buffer is used to hold reports triggered on event 1a and event 1c, and also the event triggered periodic reports based on these events. This buffer holds only the last received report, so a new received report overwrites a report already in the buffer. The 1b reporting buffer is used to hold reports triggered on event 1b, and the 1d reporting buffer is used to hold reports triggered on event 1d. These 2 buffers can hold up to 10 reports each. The reports in these 2 buffers are queued in order of arrival with the oldest report first and the newest report last in the queue. If the 1b or 1d reporting buffer is full when a new event 1b or event 1d report is received, an indication is forwarded to Soft Handover Execution Algorithm to release the connection. When the Soft Handover Evaluation Algorithm is ready to process a new report, the buffers are searched in the following order – 1d reporting buffer, then the 1a/1c reporting buffer followed by the 1b reporting buffer. A report is removed from the buffer when its processing begins.
8.1.7.
Soft/Softer Handover Execution
Once a proposed new Active Set is created by the Soft/Softer Handover Evaluation Algorithm, Soft/Softer Handover Execution is started and the result of this is one of the following.
Radio Link Addition
Radio Link Removal
Radio Link Replacement
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
82 of 214
Ericsson UMTS Feature Guidelines
Proposed Active set Rejection
RRC Connection Release
The Active set always includes at least 1 radio link and hence the Soft Handover Algorithm would never remove the last existing radio link from the Active set. There is no information loss or interruption of data flow during a Soft handover procedure. Soft Handover Algorithm interacts with the Capacity Management Algorithm to request admission before adding radio links and also informs the Capacity Management Algorithm about successful changes to the Active set.
8.1.8.
Soft/Soft Handover Signaling
The Soft/Softer Handover Signaling for the following processes is covered below.
Radio Link Addition
Radio Link Deletion
Radio Link Replacement
Radio Link Addition Radio link addition is normally triggered by event 1a, event 1c or event 1d reports from the UE. During execution of addition, the Admission Control algorithm in the SRNC is asked if the new RL setup can be allowed in the cell. After access has been granted, the Code Control algorithms in the SRNC allocate DL channelization code, and the Power Control algorithms in the SRNC set the initial DL transmission power, UL SIR Target, and DL power range. The SRNC then contacts the Node B, which allocates resources, starts reception, and tries to synchronize the UE on the uplink. The SRNC sends the Active Set UPDATE message to the UE, which allocates reception resources, synchronizes to the new radio link on the downlink. The UE responds with an Active Set UPDATE COMPLETE message. Other Evaluation algorithms and interacting functions are informed about the new Active Set. In case of Inter-RNC Radio Link Addition, the SRNC establishes signaling connections to the DRNC over the Iur interface. Once the Iur connection exits, Node B resources are demanded by the SRNC and if resources are available, the new radio link is setup. Radio Link Removal Radio Link removal is triggered by the reception of an event 1b report from the UE. The Soft/Softer Handover Evaluation algorithm sends an Active Set proposal to the Execution part in the SRNC to remove the reported cells from the Active Set of the UE. During execution of the removal, the SRNC sends an Active Set UPDATE message to the UE, which releases the resources for that radio link and responds with an Active Set UPDATE COMPLETE message. Other Evaluation algorithms and interacting functions are informed about the new Active Set. In case of Inter-RNC Radio Link Removal, the DRNC stays involved in the connection provided that at least one radio link uses an RBS belonging to the DRNC. If not, the Iur connection will be released.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
83 of 214
Ericsson UMTS Feature Guidelines
Radio Link Replacement Combined radio link addition and removal replaces one radio link with another in the Active Set. Radio link replacement is normally triggered by an event 1c report or an event 1d report from the UE. The new Node B is contacted by the SRNC. The new Node B allocates resources, starts reception, and tries to synchronize the UE on the uplink. During replacement execution, power is determined for the radio link to be added. The SRNC sends an Active Set UPDATE message to the UE indicating which radio link to add and which radio link to remove. The UE allocates resources for the new radio link and releases corresponding resources for the old radio link. The UE responds with an ACTIVE SET UPDATE COMPLETE message. Node B and SRNC resources are then released for the removed radio link, and Evaluation algorithms and interacting functions are informed about the new Active Set. The RRC messages between the UE and the RNC for the Radio Link Addition and removal procedures are shown in the following figure.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
84 of 214
Ericsson UMTS Feature Guidelines
If a Radio Link Addition is denied by the Admission Control Algorithm, then the UE will normally repeat the 1a or 1c event reports. Capacity Management might perform best-effort cleanup actions in the target cell and downgrade actions for the current connection, so that the repeated RL add requests might be admitted. RRC Connection Release The current RRC connection can be released due to any of the following reasons. A Detected Set report is received where the invalid cell is more than releaseConnOffset stronger than the strongest cell in the active set. A failed RL add/replace attempt, where the proposed cell is more than releaseConnOffset stronger than the strongest cell in the active set. A Measurement Control message failure for a 1x event. An Active set update failure, in which the UE does not respond to the Active Set UPDATE message and the timer <RRC> T-ASU expires. The timer <RRC> T-ASU is started when an Active Set UPDATE message is sent and stopped when the Active Set UPDATE COMPLETE or Active Set UPDATE FAILURE is received and is a hard-coded value set to 5 s.
8.1.9.
ReleaseConnOffset setting
The vendor recommended value for this parameter is set at 12 dB, which would imply that the a call is released only when a cell that is 12 dB stronger than the best cell in the Active set is not being added to the Active set. This value would make the dropped calls due to this feature less likely. This is the recommended value for network launch. A value smaller than 12 dB can be used during optimization to find problems related to missing neighbors which would result in drop calls. The parameter should be put back to 12 dB after optimization to ensure that the drop call rate is not affected.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
85 of 214
Ericsson UMTS Feature Guidelines
9. Compressed Mode Operation Compressed mode is a physical layer function that allows the UE to temporarily tune to another frequency, and measure the RF environment of another UMTS frequency (e.g. IFHO) or another technology (e.g. IRAT), while maintaining an existing dedicated channel. Unlike TDMA type air interfaces, the WCDMA physical frame does not contain any idle or unused slots to make measurements on other frequencies. This is not an issue if a UE has a dual Transceiver, which would allow the second receivers to make measurements while the first receiver is processing the 10 millisecond frames. However, most UEs do not contain dual transceivers (at this time), thus requiring an alternate means for a single transceiver UE to make measurements on other frequencies In the case of Ericsson, compressed mode may take one of two forms depending on the radio bearer combination at the measurements on other frequencies are taken. If the radio bearer contains any delay sensitive services (e.g. circuit switched voice), then SF/2 is utilized. If it is not critical to delay the data flow (e.g. interactive or background packet switched data) then Higher Layered Scheduling (HLS) is used.
9.1. Halving the Spreading factor (SF/2) Method If SF/2 is required, the spreading factor (or OVSF) is reduced to half of its typical value. For example, a radio bearer containing an AMR 12.2k utilizes a 128 OVSF code. When compressed mode is enabled, the spreading factor will be reduced to a 64 bit OVSF. This allows a transmission gap of up to seven slots (of the fifteen slots per frame) to be available for measurements on other frequency. However this 50% reduction in the spreading factor has many side effects. To maintain the appropriate Bit Error Rate (BER), and counter the reduced processing gain, the power of the compressed frame will have to be increased by approximately 3 dB. This is illustrated in the following figure of a compressed mode transmission from 3GPP TS 25.212. In addition to downlink power utilization, compressed mode will also affect capacity by consuming more codes in the downlink, increasing channel element usage, and increasing uplink noise rise due to increased UE transmit power. Because of these side effects, care must be taken to ensure that UEs do not unnecessarily trigger compressed mode. In addition, the time spent in compressed mode should be minimized.
One frame (10 ms)
T-Mobile USA, INC. Confidential
Transmission gap available for inter-frequency measurements
Rev. 3.0
Sep 11, 2008
86 of 214
Ericsson UMTS Feature Guidelines
9.2. Higher Layered Scheduling (HLS) Method: In the case of HLS, the transmission gap is generated by simply reducing the user throughput in the higher layers. This is achieved in Layer 2 where the MAC utilizes a subset of the available transport format combinations (TFC) within the transport format combination set (TFCS). For example, the transport block set size for a PS 64 kbps transport channel may contain 0, 1, 2, 3 or 4 transport blocks of 336 bits within every 20 ms transport time interval (TTI). By only utilizing 0, 1, or 2 transport blocks every TTI, a transmission gap of up to 7 slots can be generated, while maintaining a maximum throughput of 50% of the original transport channel. Unlike the SF/2 method, HLS does not require additional power, code usage, channel element usage, or UE transmit power to achieve compressed mode operation.
9.3. Compressed Mode Pattern When the UE reports that event 2d or 6d has occurred, the RNC sends a Physical Channel Reconfiguration Message to the UE which contains the Compressed Mode parameters. These parameters include the following (which are illustrated below in the figure from 3GPP TS 25.215):
TGPSI (Transmission Gap Pattern Sequence Indicator): This defines a unique transmission gap pattern sequence. Multiple transmission gap pattern sequence may be configured in a single Physical Reconfiguration Message;
TGPRC (Transmission Gap Pattern Repetition Count): This is the number of repeated transmission gap patterns within the transmission gap pattern sequence;
TGSN (Transmission Gap Starting Slot Number): This is the slot number of the first transmission gap slot within the first radio frame of the transmission gap pattern;
TGL1 (Transmission Gap Length 1): This is the number of slots in the first transmission gap;
TGL2 (Transmission Gap Length 2): This is the number of slots in the second transmission gap;
TGD (Transmission Gap start Distance): This is the number of slots between the first and second transmission gap within a transmission gap pattern;
TGPL1 (Transmission Gap Pattern Length): This is the number of frames within a transmission gap pattern.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
87 of 214
Ericsson UMTS Feature Guidelines
#1
#2
#3
#4
#5
#TGPRC
TG pattern 1
TG pattern 1
TG pattern 1
TG pattern 1
TG pattern 1
TG pattern 1
TG pattern 1
Transmission
Transmission
gap 1
gap 2
TGL1
TGL2
TGSN
TGD TGPL1
9.4. Limitations on number of mobiles in Compressed Mode To minimize the impact of compressed mode on coverage, capacity and call quality, it is possible to limit the number of UEs in compressed mode on a cell basis using the UtranCell parameter compModeAdm. It is recommended to keep the value of this parameter equal to the vendor default value of 15. In case the number of UEs in compressed mode for a cell reaches this number, Admission control blocks a new radio link in being setup for this cell. This is the only configurable parameter with regard to Compressed Mode for Ericsson 3G RAN. The actual implementation of the Compressed Mode implementation is hard coded in the Ericsson 3G RAN. Power control parameters related to Compressed Mode will be dealt with in the Power Control section of this document.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
88 of 214
Ericsson UMTS Feature Guidelines
10. 3G to 2G Handover and Cell Change This section details the 3G to 2G handover algorithm and the relevant parameters for Ericsson 3G network.
10.1. T-Mobile Strategy for IRAT T-Mobile deployment of UMTS in the U.S. will be carried out in several phases. In order to maintain contiguous coverage to customers, it is important to transition them to the GERAN network at the edge of UMTS coverage, without service disruption. This can be accomplished by configuring 3G to 2G handover in the connected mode and 3G to 2G reselection in the idle mode. The following is the current T-Mobile strategy for IRAT transition:
Allow 3G to 2G handover in poor UMTS coverage areas.
Allow 3G to 2G cell change in poor UMTS coverage areas.
Allow 3G to 2G Reselection in poor UMTS coverage areas.
Allow 2G to 3G Reselection even in good GSM coverage as long as UMTS coverage is available.
Do not allow 2G to 3G handovers in connected mode.
The objectives of the IRAT feature as described here are:
Offload the CS traffic on GSM networks by maximizing the use of UMTS networks, where available to carry speech traffic. This will be done through the use of 2G to 3G reselection even in areas of good GSM signal strength, as long as there is UMTS coverage available.
Keep UMTS capable UEs on UMTS coverage as long as possible with an acceptable call quality.
Move 3G UEs to GSM using handover or reselection while leaving UMTS coverage areas before call quality degradation.
10.2. Feature Activation The IRAT feature in the Ericsson 3G RAN can be activated using the following parameters. C_GsmHoAllowed: IRAT handover is only attempted if this parameter is set to Allowed for the current UeRc state. This is a constant hard coded value and is currently set to Allowed by Ericsson. FddGsmHoSupp: This parameter at the RNC level should be set to TRUE to enable IRAT functionality. hoType: This cell parameter controls if IRAT Handover or Inter-Frequency HO or None shall be evaluated in case both Inter RAT and Inter-Frequency neighboring cells have been configured. The detailed working of this parameter is covered in the following section. defaultHoType: This parameter set per DRNC indicates the hoType for cells in the neighboring RNC. If not datafilled, IRAT handover is preferred.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
89 of 214
Ericsson UMTS Feature Guidelines
10.3. IRAT Interaction with Inter-Frequency Handover For 3G cells that have both GSM and Inter frequency neighbors configured, the cell parameter hoType controls which type of handover is actually carried out. If all cells in the active set have hoType = None, then neither IRAT nor Inter-Frequency Handover is attempted. If at least one cell in the active set has hoType = IF-Preferred, then Inter-Frequency handover is attempted. If at least one cell in the active set has hoType = GSM-Preferred and no cell has hoType = IF-Preferred, then IRAT handover will be attempted. Recommendation: For network launch, when only one WCDMA carrier is available, hoType should be set to GSM-Preferred for all cells in the network. When there is more than one WCDMA carrier available, this parameter would be re-evaluated and this guideline would be updated accordingly.
10.4. 3G to 2G IRAT Handover/Cell Change Procedure When a UE is on a CS call, 3G to 2G IRAT Handover is used to transition the mobile to GSM at the edge of UMTS coverage area allowing service continuation on dedicated channels. When the UE is on a PS call at the edge of the 3G network, IRAT Cell Change procedure is used to transition the mobile to GPRS. The IRAT Cell Change procedure on dedicated channels involves a network initiated cell reselection from UMTS to GSM, after which the UE is responsible to continue the existing PS connection through the GPRS network. One important difference in the Cell Change and IRAT handover procedures is that there are no resources allocated in the target system in the case of the Cell Change procedure. The 3G to 2G Handover procedure for Ericsson RAN can be grouped into the following 4 steps.
Connection quality monitoring based on event triggers.
Event based GSM measurements reporting.
Identification of target GSM cell for Handover/Cell Change.
3G to 2G IRAT Handover/Cell Change execution.
10.4.1.
Event based Connection quality monitoring
Three connection qualities are monitored and used to trigger IRAT handover process. The downlink is monitored using CPICH RSCP and CPICH Ec/No, and the uplink is monitored using UE TX power. If any of these three monitored connections qualities reach a predefined threshold, indicating poor RF conditions, the IRAT handover process is triggered (i.e. GSM candidate cells will be measured). If RF conditions improve, and all three monitored connection qualities meet predefined thresholds indicating minimum RF conditions are met, the IRAT handover attempt will be aborted. Filtering Concept The measurement values are filtered by the UE before comparison with the event criteria. The filtering is performed as per 3GPP recommendations according to the following formula.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
90 of 214
Ericsson UMTS Feature Guidelines
Fn = (1–a) Fn-1 + a Mn where Fn is the updated filtered measurement result Fn-1 is the old filtered measurement result Mn is the latest received measurement result from physical layer measurements a = ½^(k/2), where k is the parameter received in the IE "Filter coefficient", and refers to the filter coefficient parameter available in the Ericsson network for the various features. A high value of this parameter emphasizes an old filtered measurement result (for example, with k = 9, the weight of an old filtered measurement is 96% and the weight of a new measurement is 5%). A low value of this parameter emphasizes a new measurement result (for example, with k = 1, the weight of a new measurement result is 71%). With k = 0, old measurements are not considered. The details of the Ericsson implementation of the filtering period from the filter coefficient are out of the scope of this document. Weighting Concept A weighting factor is used to include active cells other than the best cell in the evaluation criteria for reporting events. The measured value after weighting will be
NA W 10 Log M i (1 W ) 10 LogM Best i 1 where Mi is a measurement result of a cell in the active set NA is the number of cells in the current active set MBest is the measurement result of the cell in the active set with the highest measurement result W is the weighting factor Recommendation: The recommended value for the weighting factors is 0. This would enable the evaluation criteria for the reporting events to be based completely on the best cell’s measurement. Event 2d and 2f for CPICH RSCP and CPICH Ec/No monitoring Events 2d and 2f are typically used to trigger and suspend compressed mode operations, respectively. The Threshold, Hysteresis and Time-to-trigger parameters are delivered to the IRAT capable UE via Measurement Control messages. The Measurement Quantity for the Threshold can be CPICH RSCP, or CPICH Ec/No. If a Measurement Quantity drops below the Event 2d threshold level, for the specified Time to trigger, a Measurement Report indicating Event 2d has occurred will be sent to the RNC. This will typically result in compressed mode being triggered to enable the UE to measure GSM neighbors. The actual Event 2d threshold is defined by the parameters
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
91 of 214
Ericsson UMTS Feature Guidelines
(usedFreqThresh2dEcno + serviceOffset2dEcno - hysteresis2d/2), for the Measurement Quantity CPICH Ec/No
(usedFreqThresh2dRscp + serviceOffset2dRscp - hysteresis2d/2), for the Measurement Quantity CPICH RSCP.
The time to trigger is defined by the parameters timeToTrigger2dEcno and timeToTrigger2dRscp for Measurement Quantities CPICH Ec/No and CPICH RSCP respectively. If a Measurement Quantity improves and goes above the Event 2f threshold level, for the specified Time-to-trigger, a Measurement Report indicating Event 2f has occurred will be sent to the RNC. This will typically result in compressed mode being suspended, and the measurement of GSM neighbors ending. The actual Event 2f threshold is defined by the parameters
(usedFreqThresh2dEcno + serviceOffset2dEcno + usedFreqRelThresh2fEcno + hysteresis2f/2), for the Measurement Quantity CPICH Ec/No
(usedFreqThresh2dRscp + serviceOffset2dRscp + usedFreqRelThresh2fRscp + hysteresis2f/2), for the Measurement Quantity CPICH RSCP.
The time to trigger is defined by the parameters timeToTrigger2fEcno and timeToTrigger2fRscp for Measurement Quantities CPICH Ec/No and CPICH RSCP respectively. The following figure shows the concept of events 2d and 2f for CPICH Ec/No monitoring. Here the value of the serviceoffsetEcno is considered to be zero.
The following are the definitions of parameters used for events 2d and 2f.
usedFreqThresh2dEcno: indicates threshold to trigger event 2d for Ec/No.
usedFreqThresh2dRscp: indicates threshold to trigger event 2d for RSCP.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
92 of 214
Ericsson UMTS Feature Guidelines
serviceOffset2dEcno: Service-specific offset for event 2d when the measurement quantity is Ec/No. Specified as a different value for each UeRc
serviceOffset2dRscp: Service-specific offset for event 2d when the measurement quantity is Rscp. Specified as a different value for each UeRc
usedFreqThresh2dEcnoDrnc: indicates the threshold to trigger event 2d for Ec/No when the best cell in the active set belongs to a DRNC.
usedFreqThresh2dRscpDrnc: indicates the threshold to trigger event 2d for RSCP when the best cell in the active set belongs to a DRNC.
hysteresis2d: Hysteresis used for event 2d.
timeToTrigger2dEcno: Minimum interval of time the Measurement Quantity Ec/No must be below the Event 2d threshold level before event 2d is triggered, and a measurement report is sent.
timeToTrigger2dRscp: Minimum interval of time the Measurement Quantity RSCP must be below the Event 2d threshold level before event 2d is triggered, and a measurement report is sent.
usedFreqRelThresh2fEcno: Relative threshold for event 2f for Ec/No referenced to the parameter usedFreqThresh2dEcno.
usedFreqRelThresh2fRscp: Relative threshold for event 2f for RSCP referenced to the parameter usedFreqThresh2dRscp.
hysteresis2f: Hysteresis used for event 2f.
timeToTrigger2fEcno: Minimum interval of time the Measurement Quantity Ec/No must be above the Event 2f threshold level before event 2f is triggered, and a measurement report is sent.
timeToTrigger2fRscp: Minimum interval of time the Measurement Quantity RSCP must be above the Event 2f threshold level before event 2f is triggered, and a measurement report is sent.
usedFreqW2d: weighting factor for event 2d.
usedFreqW2f: weighting factor for event 2f.
If the value of 2d threshold changes as a result of an Active Set update for the Ec/No or the RSCP measurement, due to different settings of the cell parameter usedFreqThresh2dEcno or usedFreqThresh2dRscp, the corresponding measurements using event 2d and event 2f must be modified with the new thresholds. This is also valid if the serviceOffset2dEcno or the serviceOffset2dRscp changes as a result of a change of UeRc state. If the best cell of the active set belongs to a neighboring RNC, then the parameters usedFreqThresh2dEcno is replaced by usedFreqThresh2dEcnoDrnc and the parameter usedFreqThresh2dRscp is replaced by usedFreqThresh2dRscpDrnc to evaluate event 2d. The parameters usedFreqThresh2dEcnoDrnc and usedFreqThresh2dRscpDrnc are RNC based parameters. These can’t be modified on a cell level, however, with the current implementation of soft handovers at the IuR boundary, there will be minimal IRAT handovers, if any at RNC borders. Hence the absence of flexibility in tuning these parameters on a cell level should not pose a big disadvantage to network optimization. The parameters usedFreqThresh2dEcno and usedFreqThresh2dRscp can be uniquely configured at the cell level. This allows the event 2d threshold for individual cells to be
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
93 of 214
Ericsson UMTS Feature Guidelines
tuned to meet desired network conditions (e.g. a cell in the UMTS core may have more stringent conditions to trigger event 2d as opposed to a site on the UMTS network border). All other IRAT (as well as handover) parameters are global RNC parameters. Event 6d and 6b for UE TX Power monitoring Event 6d is used to evaluate if the TX power of the UE increases above the maximum transmit power of the UE class. There is no pre-defined threshold to trigger event 6d. The transmit power of the UE is compared to its maximum transmit power, P_max in order to trigger event 6d, which typically results in IRAT measurements. Event 6b is used to evaluate when the TX power goes below a pre-defined threshold, typically ending GSM measurements. There is no support for hysteresis for events 6d and 6b. Also since the comparison is done on the UE (and not on a specific cell in the active set), there is no requirement of a weighting factor. The following are the definitions of parameters used for events 6d and 6b.
txPowerConnQualMonEnabled: Enables or disables the connection quality monitoring based on UE Tx power.
ueTxPowerThresh6b: The threshold used to trigger event 6b when UE Transmit power becomes less than an absolute threshold.
timeToTrigger6d: Minimum interval of time the UE transmit power must be above the Event 6d threshold level before event 6d is triggered, and a measurement report is sent.
timeTrigg6b: Minimum interval of time the UE transmit power must be below the Event 6b threshold level before event 6b is triggered, and a measurement report is sent.
filterCoeff6: Coefficient for layer 3 filtering before UE internal measurement reporting evaluation. This is set to a value of 3, so that there is more weight given to an old filtered measurement result (65%) and less weight given to the new measurement result (35%).
Relation between time to trigger and filter coefficients A time to trigger parameter is used to ensure that a detected event is verified for a reasonable amount of time before it is reported. A filter coefficient value is used to make sure that an event is not reported based on momentary fluctuations of the current signal. A higher value of filter coefficient is recommended to ensure that the event detection is not based on momentary signal fluctuations. Since by doing this the event detection is already based on reliable signal levels, the time to trigger parameters should be set to smaller values, so that the event reporting is not further delayed.
10.4.2.
Event based GSM measurements reporting
Once the UE receives the compressed mode parameters and responds with a Physical Channel Reconfiguration Complete message, the RNC delivers a Measurement Control message to the UE which contains the following: The GSM monitored subset, built from the GSM neighbors of the active set cells. This is a list of the candidate cells to measure (i.e. GSM cells). In the case of IRAT, the BCCH ARFCN, and BSIC are also provided
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
94 of 214
Ericsson UMTS Feature Guidelines
The event 3a parameters, including the following:
The UMTS event 3a threshold trigger
The weighting factor, used to include measurements from the cells in the active set
The hysteresis applied to the UMTS event 3a threshold
The time to trigger
The GSM event 3a threshold trigger
The connection frame number (CFN) indicating which frame each TGPSI begins.
Note that the Measurement Quantity used for the UMTS event 3a threshold trigger is dependant on the original event 2d or event 6d trigger. If event 2d was triggered based on Ec/No, then the event 3a threshold trigger will be based on Ec/No. If event 2d was triggered based on RSCP, or an event 6d was the trigger, then the event 3a threshold trigger will be based on RSCP.
If the connection quality trigger is CPICH Ec/No, event 3a is triggered when the (estimated quality < usedFreqThresh2dEcno + serviceOffset2dEcno + utranRelThresh3aEcno - hysteresis3a/2) and the (GSM carrier RSSI > gsmThresh3a), for at least TimeToTrigger3a.
If the connection quality is CPICH RSCP, event 3a is triggered when the (estimated quality < usedFreqThresh2dRscp + serviceOffset2dRscp + utranRelThresh3aRscp hysteresis3a/2) and the (GSM carrier RSSI > gsmThresh3a), for at least TimeToTrigger3a.
If the connection quality is UE Tx power, event 3a is triggered when the (estimated quality < usedFreqThresh2dRscp + serviceOffset2dRscp + utranRelThresh3aRscp + utranRelThreshRscp - hysteresis3a/2 and the (GSM carrier RSSI > gsmThresh3a), for at least TimeToTrigger3a. In the case of UE Tx power, the event 3a is always evaluated only on CPICH RSCP and not on CPICH Ec/No.
The following figure shows the concept of event 3a when the trigger is CPICH Ec/No. Here the value of serviceOffset2dEcNo is assumed to be zero.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
95 of 214
Ericsson UMTS Feature Guidelines
The following are the definitions of the parameters used for event 3a.
utranRelThresh3aEcno: Relative threshold for event 3a versus event 2d when the 2d measurement quantity is CPICH Ec/No.
utranRelThresh3aRscp: Relative threshold for event 3a versus event 2d when the 2d measurement quantity is CPICH RSCP.
utranRelThreshRscp: This is used to compute the absolute RSCP threshold for event 3a when bad connection quality has been triggered in the UL.
timeToTrigger3a: Minimum interval of time that both the UMTS and GSM event 3a thresholds are met, before event 3a is triggered, and a measurement report is sent.
Hysteresis3a: Hysteresis used for event 3a.
gsmThresh3a: Threshold for event 3a (the estimated quality of the currently used UTRAN RAN frequency is below a certain threshold and the estimated quality of the GSM system is above a certain threshold for GSM).
individualOffset: The offset is added to the measured quantity before the UE evaluates whether an event has occurred. This parameter is found in the object ExternalGSMCell. Improper use of non-default values may result in instability and unequal cell borders. Recommended value is 0 for network launch.
maxGsmMonSubset: Maximum number of GSM cells that the UE will measure on. It is recommended to keep this value to the default = 32.
utranFilterCoefficient3: Coefficient for layer 3 filtering of UTRAN quality before IRAT reporting evaluation. This is set to a value of 2, so that there is equal weight given to an old filtered measurement result as well as to the new measurement result.
utranW3a: Weighting factor for event 3a for UTRAN.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
96 of 214
Ericsson UMTS Feature Guidelines
If the RNC receives a second event 3a MEASUREMENT REPORT while it is already processing one, the new report is buffered. The buffer holds only the last received report so a new received report overwrites a report already in the buffer.
10.4.3.
Identification of target GSM cell for Handover/Cell Change
The RNC uses the measurement report from event 3a and orders the GSM cells according to their GSM quality measure. While doing this, RNC discards all GSM cells that are not BSIC verified and cells whose GSM carrier RSSI is less than gsmThresh3a. RNC then chooses the target GSM cell as the cell which has the best carrier RSSI and starts an IRAT handover attempt towards this cell.
10.4.4.
3G to 2G IRAT Handover/Cell Change Execution
Once the evaluation carried by the IRAT Handover Evaluation algorithm has lead to a target GSM/GPRS cell, IRAT Handover Execution starts. The result of the execution part is one of the following: ď&#x201A;ˇ
Hand over the UE connection to a GSM/GPRS cell. That is, the UE is finally connected to the GSM/GPRS cell and WCDMA RAN resources related to the UE connection are released.
ď&#x201A;ˇ
The UE connection remains on the WCDMA RAN due to a handover to GSM/GPRS failure.
IRAT Handover Execution requests resources in the GSM/GPRS system, according to the proposal received from the IRAT Handover Evaluation algorithm. If the attempt succeeds, the actions necessary to fulfill the handover proposal are executed. If execution fails, exception handling is performed to get back to stable situation and keep the UE connection on the WCDMA RAN. 3G to 2G IRAT Handover Execution for CS services IRAT Handover function can only be executed for connections in CELL_DCH state and only for UEs connected towards a Circuit-Switched service. The Circuit-Switched service can be either voice or data. The following ladder diagram (reference 3GPP TS 25.931) illustrates the signaling required between the UMTS and GSM network to perform a handover for CS services.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
97 of 214
Ericsson UMTS Feature Guidelines
UE
Node B
RNC S ervin g
RANAP
CN
1. R elocatio n R eq uired
M SC
BSC
BTS
RANAP
M A P /E
2. P rep are H and o ver
M A P /E
BSSM AP
3. H ando ver R eq uest
BSSM AP
4 . H and over R eq uest A ck BSSM AP
M A P /E
5. P repare H ando ver R esp o nse
BSSM AP
M A P /E
6 . R elo cation C o m m and RANAP
RANAP
7 . D C C H : H and o ver fro m U T R A N C o m m and RRC
RRC 8. H ando ver D etect B S SM A P
BSSM AP
9. H ando ver C o m plete RR
RR 10 . H and o ver C o m p lete BSSM AP
M A P /E
RANAP
1 2 . Iu R elease C o m m and
11 . Send E nd S ignal R eq uest
BSSM AP
M A P /E
RANAP
1 3. Iu R elease C om p lete RANAP
RANAP 14 . Send E nd S ignal R esp onse M A P /E
M A P /E
Once a target GSM neighbor is selected for handover, the RNC sends the RANAP message RELOCATION REQUIRED to the 3G MSC, and the timer T_RELOC_prep is started. The RELOCATION REQUIRED message contains information regarding the target GSM cell, and this is forwarded on to the 2G MSC and BSC via MAP/E and BSSMAP signaling respectively. If resources are allocated by the GSM target system, a RELOCATION COMMAND message is received by the SRNC. At this point, the SRNC sends HANDOVER FROM UTRAN COMMAND message to the UE to initiate the handover. The GSM/GPRS message HANDOVER COMMAND is included in the handover message. The resources on WCDMA RAN side are kept to allow the UE return to the old channels in case of handover failure. When the target GSM BSS detects the UE and the handover is completed, the RR message HANDOVER COMPLETE is sent by the UE to the BSC. At this point, the successful IRAT handover is reported to the 3G Core Network, and a RANAP IU RELEASE COMMAND message is sent to the RNC. At the reception of this message, the SRNC de-allocates all resources related to the UE connection and responds to the 3G MSC with an IU RELEASE COMPLETE message. The RRC and RANAP messages between the UE, UTRAN, and 3G MSC, for the IRAT Handover execution are shown in the figure below. Actual UE traces showing IRAT message flow will be included once available.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
98 of 214
Ericsson UMTS Feature Guidelines
Exception Handling of Failed 3G to 2G IRAT Handover As stated in the previous section, the hard coded timer T_RELOC_prep, is started at the transmission of the RELOCATION REQUIRED message and stopped at the reception of the RELOCATION COMMAND. If this timer expires prior to receiving a response to the RELOCATION REQUIRED message (either positive or negative), a RELOCATION CANCEL message is sent to the 3G CS core network. The current 3G connection is maintained if possible. If a MEASUREMENT CONTROL failure occurs for event 3a, the SRNC cancels the IRAT Handover procedure and the connection is released. If the RELOCATION PREPARATION FAILURE message is received at SRNC from the Core Network, IRAT Handover is canceled, and the connection is kept, if possible. If the cause of the message is “No resource available”, the IRAT Handover Evaluation algorithm is informed that the allocation failed due to lack of resources in the target system. If it is not possible to fulfill the RELOCATION
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
99 of 214
Ericsson UMTS Feature Guidelines
COMMAND message for any reason, the function is cancelled and the RELOCATION CANCEL message is sent from the SRNC to Core Network. The connection is kept, if possible. If the UE fails to access the GSM cell and returns to the old channel, then a RADIO LINK RESTORE INDICATION message is sent from RBS to the SRNC to indicate that the UE has returned to the old channel. When the UE comes back to the old channel, a HANDOVER FROM UTRAN FAILURE message is sent to the SRNC by the UE. The SRNC informs the Core Network that IRAT Handover has failed so GSM resources can be de-allocated. The IRAT Handover Execution informs the IRAT Handover Evaluation algorithm that the handover has failed. If the IRAT handover to the target cell fails, and if there are soft handover reports buffered, RNC uses these to perform soft handover evaluation before returning to the IRAT handover evaluation. If the IRAT handover fails, and there is a buffered 3a measurement report, RNC terminates the existing event 3a handling, and processes the buffered event 3a report to find a new GSM target for handover. If the IRAT handover fails due to RELOCATION PREPARATION FAILURE (which is the failed response to the RELOCATION REQUIRED message) or HANDOVER FROM UTRAN FAILURE, then the RNC makes multiple attempts to the same GSM cell. If there is more than one GSM cell in the 3a measurement report, repeated handover attempts shall be made to these cells in quality order. The following are the parameters that influence repeated attempts to handover.
gsmAmountPropRepeat: Maximum number of repeated attempts (not including the first attempt) of GSM cells for handover based on the same measurement report.
gsmPropRepeatInterval: Minimum time interval between handover attempts to the same GSM cell based on the same measurement report.
gsmFilterCoefficient3: Coefficient for layer 3 filtering of GSM quality before IRAT reporting evaluation. This is set to a value of 1, so that there is less weight given to an old filtered measurement result (29%) and more weight given to the new measurement result (71%).
If the IRAT handover failure cause is “Other”, then the IRAT algorithm will be terminated and the UE stays on UMTS. 3G to 2G IRAT Cell Change Execution for PS services IRAT Cell Change is used to transition a UE connected to PS on a dedicated channel to the GSM system. A network-initiated cell reselection is used to transition the UE to GPRS. The following ladder diagram (reference 3GPP TS 25.931) illustrates the signaling required between the UMTS and GSM network to perform a network initiated cell change for PS services.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
100 of 214
Ericsson UMTS Feature Guidelines
UE
S erv in g RNC
CN
1 . C ell C h an g e O rd e r fro m UTRAN RRC
RRC
RANAP
RANAP
2 . Iu R ele ase C o m m a n d
3 . Iu R ele ase C o m p lete
RANAP
RANAP
Once a target GSM cell is selected for a UE connected to the PS network (via HLS compressed mode), the SRNC initiates the IRAT Cell Change in the UE by sending the CELL CHANGE ORDER FROM UTRAN message to UE. The message includes information of the RAB to hand over and a target cell description. The UE synchronizes to the GPRS system and sends a ROUTING AREA UPDATE message. Then, the PS Core Network sends a SRNS CONTEXT REQUEST message that includes the RAB id for which the context must be transferred. At this moment the DL transmission is stopped. The SRNC sends an SRNS CONTEXT RESPONSE message. The PS Core Network initiates the release of the Iu connection by sending the IU RELEASE COMMAND message. When this message is received by the SRNC, the Iu bearers are released. The SRNC terminates the Iu release by sending an IU RELEASE COMPLETE message to the PS Core Network. The RRC connection messages between the UE and the UTRAN for the IRAT Cell Change Execution are shown in the figure below. Actual UE traces showing IRAT message flow will be included once available.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
101 of 214
Ericsson UMTS Feature Guidelines
Exception Handling of Failed 3G to 2G IRAT Cell Change If the UE sends a MEASUREMENT CONTROL FAILURE message, the SRNC will cancel the IRAT Cell Change Execution procedure and the connection is released. If the UE fails to access the GPRS cell, it returns to the old channel. A RADIO LINK RESTORE INDICATION is sent from the Node B to the SRNC to indicate that the UE has returned to the old channel. The UE then sends a CELL CHANGE ORDER FROM UTRAN FAILURE message to the SRNC. The IRAT Handover Evaluation is informed about the failure. If there is an invalid RAB id in the SRNS CONTEXT TRANSFER, the SRNC will respond with SRNS CONTEXT RESPONSE using the indicator that “RABs Context Failed to Transfer”, due to invalid RAB id. 3G to 2G IRAT Handover Execution for CS and PS Multi-service In cases where the UE is connected to both the CS and PS networks simultaneously, the transition to 2G is handled by the IRAT Handover Execution procedure for CS.
10.5.Scenarios for 3G to 2G IRAT Handover / Cell Change The primary purpose of 3G to 2G IRAT handover in the T-Mobile USA network is to transition mobile users from the UMTS network to the GSM network while leaving the UMTS coverage areas. A UE might leave the UMTS coverage area in the following 4 cases.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
102 of 214
Ericsson UMTS Feature Guidelines
At the edge of the defined UMTS network – As the UMTS network is scheduled to be deployed in phases across the country, there are bound to be gaps in UMTS coverage area. Hence while leaving the UMTS network; the users would be able to maintain a call through handover to 2G.
In-building areas without dedicated UMTS sites – In the initial phase of 3G network planning, outdoor UMTS sites will be used to cover in-building areas. The 2G network would then provide better in-building coverage in these areas, and hence a 3G to 2G handover might be useful to maintain the call in indoor locations.
Missing Sites – During initial deployment, it is possible that one or more planned UMTS sites in a cluster may be built later than the rest of the cluster. In these cases as well, it would be beneficial to use 3G to 2G handover to maintain a call while transitioning between sites.
Coverage Holes – To address any unplanned coverage holes resulting from site related failures. 2G handover can be used maintain a call in this scenario as well.
The following are the 2 scenarios chosen for 3G to 2G IRAT handover optimization.
10.5.1.
Edge Thresholds
The Edge thresholds can be used when the intent of the 3G to 2G handover is to transition the UE to GSM at fairly stronger values of RSCP and Ec/No. The intent is to compromise on the extent of the UMTS coverage area, by enabling mobiles to handover to GSM well within the 3G coverage. This would help in making the handover more reliable and minimize the number of drop calls. Since this set of values for RSCP and Ec/No triggers might reduce the 3G coverage area, this should be used only as required for a limited number of sites. The details on the actual RSCP and Ec/No values are available in the next chapter.
10.5.2.
Core Thresholds
The Core thresholds should be used when the intent of 3G to 2G handover is to allow transition from UMTS to GSM at relatively weaker values of RSCP and Ec/No when compared to the Edge case. The intent of these lower thresholds is to maximize the UMTS coverage area, especially in areas where a temporary fade in the RF environment may otherwise trigger unwanted handovers to 2G when higher values are used for the trigger points. In the core of the network, there may be areas where the signal strength may start falling due to temporary fade conditions, but the UE maybe able to recover fairly quickly from these temporary fade conditions, making handover to GSM unnecessary. By not setting the thresholds to stronger values, the UE is given enough time to recover from these temporary fade conditions. This is the recommended starting configuration for most sites in the UMTS network, thus maximizing the UMTS coverage area.
10.6.Parameter recommendations for IRAT Scenarios This section details the recommended values for parameters that influence IRAT 3G to 2G handover for the two scenarios discussed in the previous section. The following are the recommended values for each of the two scenarios. Hysteresis values: Using hysteresis the event 2d triggering condition is met if
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
103 of 214
Ericsson UMTS Feature Guidelines
Q <= threshold – hysteresis/2 Where Q is the quality, threshold is either the RSCP or Ec/No related event 2d threshold and hysteresis is the corresponding hysteresis value for the event. The event triggering 2d condition is cancelled if Q >= threshold + hysteresis/2 Hence hysteresis reduces the number of unnecessary event detections and thus reduces the amount of signaling involved. For event 3a thresholds, these are recommended to be higher than the 2d thresholds. The reason for this is that, by making sure that event 2d and hence the compressed mode event is only triggered when needed, event 3a is triggered as soon as a suitable GSM cell is found, thus having the mobile transition to GSM quickly, and avoid spending a long time in compressed mode. For the Ericsson 3G RAN, the parameters usedFreqThresh2dEcno for Ec/No based trigger and usedFreqThresh2dRscp for RSCP based trigger are configurable on a per-cell basis. In case the best cell of the active set belongs to a DRNC, then the parameters usedFreqThresh2dEcnoDrnc and usedFreqThresh2dRscpDrnc are used for IRAT handover to 2G. Since these parameters are set at the RNC level, these have the same value for both scenarios and are set equal to the Core Thresholds.
10.7.3G to 2G IRAT Handover/Cell Change Optimization Strategy Initially, it is recommended to use the Core set of values for the RSCP and Ec/No thresholds for the majority of the UMTS sites in the UMTS network, except for UMTS cells that fall at the defined edge of a UMTS market. This would ensure that the UMTS coverage area is maximized in the core of the network, and in any particular case of a UMTS coverage hole due to a missing site either outdoor or in-building, a UE on UMTS can be transitioned to GSM before dropping the call. The strategy outlined here is for the optimization of the Core and Edge thresholds in order to ensure that the UE is transitioned to 2G only at the edge of the UMTS coverage area while minimizing the overall 3G plus 2G drop call rate. Since the intent of the Edge thresholds (as described in the previous sections) is to transition a UE to 2G well within the 3G coverage area, even though the UMTS coverage is slightly reduced, the final Edge thresholds should still be at higher RSCP and Ec/No values when compared to the Core thresholds. The metrics outlined here are only to aid in the optimization strategy of the IRAT thresholds. The exact counter names are not specified here and can be referenced from the KPI documents [5] and [6].
3G and 2G Drop Call Rate: The combined drop call rate of 3G and 2G should be monitored to ensure that the IRAT handover feature doesn’t affect the performance of the T-Mobile network. The goal of 3G to 2G IRAT handovers is to transition mobiles to 2G systems at the edge of UMTS network, while minimizing the drop call rate on 3G as well as 2G. The 3G and 2G drop call percentages should be monitored on a network level as well as on a cell level for each of the cells that have IRAT handover enabled. The trend in drop call rate changes for 3G and 2G
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
104 of 214
Ericsson UMTS Feature Guidelines
corresponding to any IRAT related parameter changes should be monitored to ensure the success of the new values.
Ratio of 3G to 2G Handover attempts to 3G calls established: This metric when compared for 2 different sets of IRAT handover triggers, would give an idea as to which set of values for RSCP and Ec/No threshold might be more suitable. As long as the 3G and 2G total drop call rate is not affected, the thresholds for IRAT handover should be chosen such that the ratio of 3G to 2G handover attempts to 3G calls established is minimized. This would eliminate unnecessary IRAT handover attempts to 2G.
Ratio of 3G to 2G Handover attempts to Number of Compressed Mode (CM) attempts: This metric gives a trend of how many compressed mode triggers actually result in a 3G to 2G handover attempt. This metric in combination with the combined 3G and 2G drop call rate can be used to pick a suitable value for 2 different sets of RSCP and Ec/No thresholds. As long as the total 3G and 2G drop call rate is not affected, the set of thresholds which minimize the ratio of IRAT handover attempts to number of CM attempts should be chosen.
Ratio of 3G to 2G handover attempts to overlay GSM cell to total 3G to 2G handover attempts: This metric on a WCDMA cell level, helps in finding premature IRAT handover trigger. A high value shows a lot of IRAT handovers happening in the core of the cell, and may point to non-optimal compressed mode and IRAT handover triggers.
IRAT attempts for UMTS cells in the core: A high value for this metric indicates problems with the UMTS cell.
Ratio of Number of IRAT handovers from a UMTS cell to Number of idle mode 2G3G reselections to the same UMTS cell: A low value can be used to identify ping pong behavior between in-call mode and idle mode. If the IRAT Handover and idle mode reselection parameters are set incorrectly, it can happen that a UE camps on 3G in idle mode and when a call is setup it will do an IRAT HO almost immediately because of aggressive IRAT parameter settings and the call will be completed on 2G. After the call is completed it will reselect back to 3G until the next call and the process will repeat itself.
This is just a high level strategy for optimization thresholds and further analysis of drive test data as well as counter data should be performed before actual changes in parameter values is implemented.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
105 of 214
Ericsson UMTS Feature Guidelines
11. 3G to 3G Inter Frequency Handover Inter Frequency (IF) Handover like IRAT handover is a hard handover but is carried out to a cell on a different UMTS carrier. This section details the algorithm and parameters related to IF handover.
11.1. Feature Activation The IF Handover feature in the Ericsson 3G RAN can be activated using the following parameters.
C_ifHoAllowed: IF handover is only attempted if this parameter is set to Allowed for the
current UeRc state. This is a constant hard coded value and is currently set to Allowed by Ericsson.
fddIFHOSupp: This parameter at the RNC level should be set to TRUE to enable IF handover functionality.
hoType: This cell parameter controls if IRAT Handover or Inter-Frequency HO or None shall be evaluated in case both Inter RAT and Inter-Frequency neighboring cells have been configured. The detailed working of this parameter is covered in the following section.
defaultHoType: This parameter set per DRNC indicates the hoType for cells in the
neighboring RNC. If not datafilled, IRAT handover is preferred.
11.2. Inter-Frequency Handover Interaction with IRAT Handover For 3G cells that have both GSM and Inter frequency neighbors configured, the cell parameter hoType controls which type of handover is actually carried out. If all cells in the active set have hoType = None, then neither IRAT nor Inter-Frequency Handover is attempted. If at least one cell in the active set has hoType = IF-Preferred, then Inter-Frequency handover is attempted. If at least one cell in the active set has hoType = GSM-Preferred and no cell has hoType = IF-Preferred, then IRAT handover will be attempted. IF handover is usually preferred over IRAT handover since IF handover would result in the UE carrying a call on UMTS, which ahs superior data capabilities. Hence whenever possible, the parameter hoType should be set to IF-Preferred. If there are no inter frequency neighbors available, only then this parameter should be set to GSM-Preferred.
11.3. Inter-Frequency Handover Procedure The IF Handover procedure for Ericsson RAN can be grouped into the following 4 steps.
Event based Connection quality monitoring
Event based measurements reporting.
Identification of target cell for Handover.
3G to 3G IF Handover execution.
11.3.1.
Event based Connection quality monitoring
This is the same as for IRAT handover and is covered in section 10.4.1 T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
106 of 214
Ericsson UMTS Feature Guidelines
11.3.2.
Event based GSM measurements reporting
When the UE reports event 2d or 6d measurements, the RNC responds by setting up event 2b for IF handover. This is done by a MEASUREMENT CONTROL message with ‘setup’ for event 2b. This includes the IF Monitored subset built from the inter frequency neighbors of the active set cells. Note that the Measurement Quantity used for the UMTS event 2b threshold trigger is dependant on the original event 2d or event 6d trigger. If event 2d was triggered based on Ec/No, then the event 2b threshold trigger will be based on Ec/No. If event 2d was triggered based on RSCP, or an event 6d was the trigger, then the event 2b threshold trigger will be based on RSCP.
If the connection quality trigger is CPICH Ec/No, event 2b is triggered when the estimated quality of the used frequency < (usedFreqThresh2dEcno + serviceOffset2dEcno + UsedFreqRelThresh4_2bEcno - hyst4_2b/2) and the estimated quality of the unused frequency > (NonUsedFreqThresh4_2bEcno + serviceOffset2dEcno + hyst4_2b/2), for at least timeTrigg4_2b.
If the connection quality is CPICH RSCP, event 2b is triggered when the estimated quality of the used frequency < (usedFreqThresh2dRscp + serviceOffset2dRscp + UsedFreqRelThresh4_2bRscp - hyst4_2b/2) and the estimated quality of the unused frequency > (NonUsedFreqThresh4_2bRscp + serviceOffset2dRscp + hyst4_2b/2), for at least timeTrigg4_2b.
If the connection quality is UE Tx power, event 2b is triggered when the estimated quality of the used frequency < (usedFreqThresh2dRscp + serviceOffset2dRscp + UsedFreqRelThresh4_2bRscp + utranRelThreshRscp - hyst4_2b/2) and the estimated quality of the unused frequency > (NonUsedFreqThresh4_2bRscp + serviceOffset2dRscp + hyst4_2b/2), for at least timeTrigg4_2b. In the case of UE Tx power, the event 3a is always evaluated only on CPICH RSCP and not on CPICH Ec/No.
Ongoing IF measurements may have to be modified due to an Active Set update. If the IF monitored set changes, the new neighboring set will have to be sent to the UE. Ongoing IF measurements are stopped in the following cases.
the UeRC state does not allow the evaluation to continue (e.g. due to rate connection switching)
the Inter-Frequency Monitored Set becomes empty at Active Set update
the connection quality becomes good, i.e. if an event 2f or event 6b or both occur before event 2b occurs.
11.3.3.
Identification of target cell for IF Handover
When a Measurement report for event 2b is received by the RNC, it orders the cells of the unused frequency according to their Ec/No values and stores them as a list. A IF handover is attempted to the best cell on the ordered list.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
107 of 214
Ericsson UMTS Feature Guidelines
If the measurement report is missing RSCP values, then the RSCP values are not checked. The RSCP and Ec/No values are checked and the report is discarded if Ec/No < nonUsedFreqThresh4_2bEcno or Rscp < nonUsedFreqThresh4_2bRscp. If an IF handover attempt fails, the soft handover buffers are checked for any buffered reports. These reports are processed and a soft handover is executed if possible. If there are no soft handover events buffered, and if there is an event 2b buffered, this buffered event 2b is processed. If there are no buffered soft handover events or 2b events, then the IF handover attempt is retried. The number of repeated attempts, excluding the first attempt is given by the parameter IfhoAmountPropRepeat. The time interval between the attempts is set by parameter IfhoPropRepeatInterval. If there is more than one IF cell retained in the 2b measurement report, the repeated attempts shall be made for these cells in quality order. If failed attempts have been made for all cells in the measurement report without reaching IfhoAmountPropRepeat re-attempts, the cells in the 2b report shall be attempted again in quality order.
11.3.4.
3G to 3G IF Handover execution.
Once the evaluation carried by the IRAT Handover Evaluation algorithm has lead to a target IF cell, IF Handover Execution starts. The result of the execution part is one of the following: ď&#x201A;ˇ
Hand over the UE connection to a IF cell. That is, the UE is finally connected to the IF cell and the old WCDMA RAN resources related to the UE connection are released.
ď&#x201A;ˇ
The UE connection remains on the old WCDMA RAN due to a handover failure.
Regardless of the number of radio links included in the old Active Set, the connection is always set up on only one radio link on the new frequency. The following figure shows the IF handover sequence.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
108 of 214
Ericsson UMTS Feature Guidelines
Figure 21: IF Handover Sequence If the targeted cell is owned by the SRNC, the Admission Control Algorithm in the SRNC decides if the new radio link setup/Addition can be allowed in the cell. If the targeted cell is owned by a DRNC, the SRNC will send the radio link setup/addition to the DRNC. The Admission Control Algorithm in the DRNC decides if the new radio link setup/addition can be allowed in the cell.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
109 of 214
Ericsson UMTS Feature Guidelines
The new RBS is contacted by the SRNC/DRNC. The new RBS allocates resources, starts reception and tries to synchronize the UE on the uplink. The SRNC sends PHYSICAL CHANNEL RECONFIGURATION message to the UE, which synchronizes to the new radio link on the downlink. The UE responds with PHYSICAL CHANNEL RECONFIGURATION COMPLETE when synchronization has been obtained. The radio links of the old Active Set are released. A MEASUREMENT CONTROL message is sent to the UE indicating a new set of intra frequency neighbors. A MEASUREMENT CONTROL message is sent to the UE ordering the UE to stop measurements for event 2b. Exception Handling of Failed IF Handover If the UE fails to access the target cell and returns to the old Active Set, a PHYSICAL CHANNEL RECONFIGURATION FAILURE message with failure cause Physical Channel failure is sent from the UE to the SRNC to indicate that the UE has failed to synchronize on the target cell and returned to the source (old) channel. If allocation of resources in the target cell is not granted, the Inter-Frequency handover is aborted and the Inter-Frequency Handover Evaluation is informed so a new evaluation can be performed.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
110 of 214
Ericsson UMTS Feature Guidelines
12. Emergency Call treatment The Location Technology Systems team has defined in [7] how a E911 call needs to be treated in order to be reported to the PSAP (Public Safety Answering Point) with the most accurate latitude and longitude values. The following is just a very brief explanation of the proposed treatment for an emergency call. The long term solution is a network based A-GPS system called as stand along SMLC (Service Mobile Location Center) or SAS based on 3GPP standards. Unfortunately, neither this system nor the A-GPS capable UEs will be available at launch. Therefore, interim solutions have been defined for emergency call handling. One interim solution is based on Service Based Handover (SBHO) and the other is based on emergency RRC Redirection. The preferred solution is to use SBHO, however this would need the availability of the Lb interface via LCS conversion. Markets with a Lb interface will be using SBHO for emergency calls, while markets that don’t have a Lb interface available will be using the emergency RRC redirection method for handling emergency calls. SBHO for emergency calls can be enabled by setting parameter “ecCnSbhoRequestIgnore” to False. The handover from WCDMA to GSM will be performed immediately following the RAB Assignment request message from the MSC and it will be performed only if the following is fulfilled: the ServiceHandover IE in the RAB Assignment request need to have the value "should" and the Priority Level IE in the same RANAP message need to have the value equal to the configurable parameter ecCnPriorityLevel. Also the parameter agpsEnabled should be set to False indicating the lack of AGPS support in the 3G network. A timer, ecSbhoTimer, is started if a handover to GSM is initiated. Before expiration of this timer, the RNC will not respond to a Location Reporting Control message from the CN. At expiration of the timer, a Location Report may be sent if the handover to GSM was unsuccessful, but otherwise no response will be sent. In order for SBHO to be used for emergency calls, the parameter “emergencyCallRedirect” should be set to OFF. For emergency RRC redirection, the parameter emergencyCallRedirect is set to ‘On’ to allow all emergency calls to be redirected to GSM. When a UE requests to establish an RRC connection and indicates 'Emergency call' as establishment code, the WCDMA RAN will reject the request by sending the message RRC Connection Reject with the 'Redirection info' equal to 'Inter-RAT info GSM'. The UE will then perform a cell selection to GSM and attempt to establish a connection to GSM. This procedure is applied when there is no RRC connection already setup in WCDMA RAN. If there is an existing RRC connection used for packet-switched traffic, this RRC connection has to be ended by the user ending its packet session before dialing an emergency call. If the cell selection in GSM fails, the UE may do a cell re-selection to UMTS after the time stated in the 'Wait time' has elapsed. The timer ‘Wait time’ is sent by the RNC to the UE in the ‘RRC Reject Message’. It is the minimum wait time after which the UE can perform a reselection back to UMTS after a failed call attempt on GSM following an emergency call redirection. This timer is hard coded to 1 second. Once the UE returns to UMTS, the RNC will provide location information to the PSAP based on cell ID (CI). There is a second UE timer in the RNC, hard coded to 60 seconds, enabling the RNC to remember the “initial UE identity” for 60 seconds from the time of RRC reject message. If
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
111 of 214
Ericsson UMTS Feature Guidelines
this UE makes a second RRC connection attempt within this 60 second time period, then the RNC will recognize the UE and allow it to make a call on UMTS. The following are the related parameters to the E911 interim solutions activation. The proposed settings are to allow the interim solutions to be activated. All other settings are following vendors default values. Parameter Name emergencyCallRedirect
Object Name RncFunction
Recommended Value On (only if SBHO canâ&#x20AC;&#x2122;t be used)
ecCnSbhoRequestIgnore
RncFunction
False
ecLocationAttemptUmts
RncFunction
Off
ecSbhoTimer
RncFunction
6s
ecCnPriorityLevel
RncFunction
7
agpsEnabled
UtranCell
False
uePositioning
RncFunction
enabledPositioningFeatures = Cell_ID_ONLY
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
112 of 214
Ericsson UMTS Feature Guidelines
13. 2G to 3G IRAT Cell Reselection The T-Mobile camping strategy is to allow mobiles to camp on UMTS, wherever UMTS service is available, so that the users can take advantage of the advanced features available in the UMTS network, as well as to offload the GSM traffic whenever possible. The 2G to 3G Cell Reselection feature can be used to transition mobiles in idle mode from GSM to UMTS, when entering UMTS coverage areas. In order to comply with T-Mobile strategy, the UEs should be allowed to camp on UMTS, irrespective of the GSM signal strength whenever UMTS coverage is available. This section details the reselection algorithms to transition to 3G for the Ericsson BSS, Nokia BSS and Nortel BSS. In each case the recommended values required to implement the above mentioned T-Mobile strategy are presented. Since the reselection is carried out from the 2G side, the target 3G system is immaterial to this discussion. In general, the algorithms detailed here are applicable for transition to any 3G network including the Ericsson 3G network.
13.1.Ericsson 2G to Ericsson 3G Reselection The following discussion is valid for Ericsson BSS version R12. The parameter COEXUMTS is used to enable the GSM-UMTS Cell Reselection feature. The following are the possible values for this parameter.
COEXUMTS = 0 (OFF): In this case, none of the GSM – UMTS features is activated.
COEXUMTS = 1 (ON): In this case, the GSM – UMTS Cell Reselection and Handover features are activated.
COEXUMTS = 2 (ONADDINFO): In this case, the GSM-UMTS Cell Reselection and Handover, as well as Combined Reselection Triggering GSM to WCDMA (this feature is detailed in the following sections) are activated.
The recommended value for this parameter is 2 (ONADDINFO).
8.1.1. UTRAN Neighbor Definitions and System Information The UTRAN cells to be monitored for inter system cell reselection are defined in the 3G neighboring cell list which is broadcast on BCCH using the System Information Type 2quater (SI 2quater). If a PBCCH is also configured, the 3G neighboring cell list is also broadcast on PBCCH using the Packet System Information Type 3quater (PSI 3quater). The SI 2quater and PSI 3 quarter messages are only broadcast if any UTRAN neighbor cells exist and if the parameter COEXUMTS is not set to OFF. In T-Mobile GSM networks, PBCCH is currently not configured. Hence, only the SI 2quater message will be broadcast. SI 2quater can be broadcast either on BCCH Normal or BCCH Extended. If all the information doesn’t fit into a single SI 2quater message, the remaining information will be sent in other instances of this message. When SI 2quater is sent, AGBLK is recommended to be set to 1 when SI 2bis and SI 2ter are sent, when GPRS/EGPRS is active and SI 2bis is sent, and when GPRS/EGPRS is active and SI 2ter is sent. This is because SI 2quater will share the same resources as SI 13
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
113 of 214
Ericsson UMTS Feature Guidelines
and/or SI 2ter on BCCH normal implying longer cycle for the System Information to be broadcast. This could impact cell selection/reselection performance. When AGBLK = 1, either SI2quater or SI 13 are placed on BCCH extended in the above cases. However, use of BCCH extended implies reduction of the paging capacity since BCCH extended shares the resource with PCH and AGCH. UTRAN FDD neighboring cells are identified with a frequency and scrambling code combination. In idle mode, the measurement frequency (MFDDARFCN) and scrambling code (MSCRCODE) for the neighboring UTRAN cells are defined within the parameter UMFI. This parameter is also used to define if diversity is applied or not for an UTRAN cell. Up to 64 UTRAN neighboring cells may be defined per GSM cell.
13.1.1.
Measurements on WCDMA neighbors in idle mode
In addition to measurements on surrounding GSM/GPRS/EGPRS cells, a Multi-RAT mobile also performs measurements on UTRAN neighboring cells. The parameter QSI can be used to enable measurements on UTRAN cells in idle mode and packet switched modes. This parameter is broadcast on BCCH and PBCCH (if PBCCH is enabled). There are four possible scenarios based on value of QSI for measurements on UTRAN neighbors.
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is above the threshold set by QSI.
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is below the threshold set by QSI.
UTRAN neighboring cells are always measured.
UTRAN neighboring cells are never measured.
Since T-Mobile camping strategy is to have the mobiles camp on the UMTS network, whenever UMTS coverage is available, this parameter QSI should be set to ‘always’, so that UTRAN cells are measured even when the GSM signal strength is good. Recommended Value: The parameter QSI is recommended to be set to 7 (= always).
13.1.2. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation This section is focused on the reselection algorithm used for mobiles that don’t support RSCP evaluation. A similar algorithm to the one for GSM reselection is used for the GSM to UMTS cell reselection. Since the modulation technique used for UMTS is completely different from GSM, there is a difference in the evaluation of signal quality for GSM and UMTS measurements. Hence a mapping of UMTS signal strength is performed in such a way that it can be compared to GSM signal strength values. The following two criteria have to be fulfilled for a period of 5 seconds for a multi-RAT mobile to reselect a suitable UTRAN cell. CPICH Ec/No > FDDQMIN
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
114 of 214
Ericsson UMTS Feature Guidelines
and CPICH RSCP > RLA(s+n) + FDDQOFF Where RLA(s+n) refers to the Received Level Average of the serving and neighboring GSM cells. RLA is the average of the received signal levels measured in dBm for all monitored GSM frequencies in the BA list. FDDQMIN is the minimum quality of a UTRAN cell for cell reselection. This parameter ensures a sufficient quality of the candidate UTRAN cell. FDDQOFF is the key parameter to control the behavior of inter-system cell reselection. It defines an offset between the signal strength of UTRAN and GSM cells. Lower values of the parameter FDDQOFF can be used to off-load the GSM system, while higher values can be used to keep multi-RAT mobiles in the GSM system. Since the values of GSM signal strength and UTRAN CPICH RSCP are not of the same kind, the balance between the two should be set with the offset FDDQOFF. Cell reselection back to UTRAN will not occur within 5 seconds after a previous cell reselection from UTRAN. If a cell reselection occurred within the previous 15 seconds, an additional offset of 5 dB is added to FDDQOFF by the mobile. These conditions prevent ping-pong for a mobile that has just entered GSM. To achieve the preferred camping strategy of the mobile camping on UMTS, whenever UTRAN coverage is available, the value of FDDQOFF should be such that the UTRAN CPICH RSCP always looks better than the GSM RLA. A negative value of FDDQOFF would achieve this by making a UTRAN cell always look better than a GSM cell. Since this might sometimes result in cell reselection to a weak UMTS cell, the value of parameter FDDQMIN should be set to control this. A value of FDDQMIN such that FDDQMIN > qQualMin + sRatSearch would prevent the mobile from making cell reselection to a weak UTRAN cell. This setting would also ensure that the MS will not start to measure on GSM cells immediately after reselecting a UTRAN cell. For details on these parameters with respect to the Ericsson RAN, refer to the Chapter â&#x20AC;&#x153;Cell Reselection Parameters from 3G to 2Gâ&#x20AC;?. The available values for parameter FDDQMIN are one of [-20dBm, -6dBm, -18dBm, -8dBm, -16dBm, -10dBm, -14dBm, -12dBm]. Since the recommended value for qQualMin = -18 dB and sRatSearch = 4 dB, the parameter FDDQMIN should be greater than -14 dB. The lowest value that achieves this condition (-12 dB) should be selected to speed up the reselection of a UTRAN cell. Recommended Values: From the above reasoning, the recommended value of FDDQOFF = infinity and FDDQMIN = -12 dB. This would allow the MS to camp on UMTS, whenever UTRAN coverage is available, irrespective of the signal strength of GSM. These settings would result in a cell reselection algorithm that is based only on the quality of the UTRAN cell, since the reselection criterion 2 is always satisfied. Refer to section 13.4 for a quick look at the recommended values for all 2G to 3G reselection parameters.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
115 of 214
Ericsson UMTS Feature Guidelines
13.1.3.
Cell Reselection to UMTS for mobiles that support RSCP evaluation
For mobiles that support RSCP evaluation for reselection to 3G, an additional criterion is used to further minimize the number of ping pong cell reselections. This is achieved by adding a threshold for CPICH RSCP measurements to assure a sufficient downlink signal strength, which in turn increases the possibility for the mobile to reach the network in the uplink. The following three criteria have to be fulfilled for a period of 5 seconds for a multi-RAT mobile with RSCP evaluation capability to reselect a suitable UTRAN cell. CPICH RSCP > RLA(s+n) + FDDQOFF CPICH Ec/No > FDDQMIN – FDDQMINOFF and CPICH RSCP > FDDRSCPMIN - min((P_MAX-21), 3dB) Where RLA(s+n) refers to the Received Level Average of the serving and neighboring GSM cells. RLA is the average of the received signal levels measured in dBm for all monitored GSM frequencies in the BA list. FDDQMIN is the minimum quality of a UTRAN cell for cell reselection. This parameter ensures a sufficient quality of the candidate UTRAN cell. FDDQMINOFF defines an offset to the threshold FDDQMIN. FDDQOFF defines an offset between the signal strength of UTRAN and GSM cells. FDDRSCPMIN defines the minimum threshold for the “signal strength” measure CPICH RSCP for cell reselection to UTRAN. P_MAX is the maximum RF output power of the MS in UTRAN FDD mode. For a Class 3 mobile, this is equal to 24 dBm. The recommended values for FDDQMIN and FDDQOFF are equal to -12 dB and –infinity as explained in the previous section. The recommended value for FDDQMINOFF = 0 dB, which would keep FDDQMIN – FDDQMINOFF > qQualMin + sRatSearch (= -14 dB). The absolute minimum CPICH RSCP value to reselect a UTRAN cell is given by the selection parameter qRxLevMin in UTRAN. A setting of FDDRSCPMIN such that FDDRSCPMIN > qRxLevMin + hysteresis prevents the multi-RAT mobile to trigger a reselection to a weak UTRAN cell. The recommended value for FDDRSCPMIN = -102 dBm, which would result in a Class 3 MS (P_MAX = 24 dBm) reselecting a 3G cell when the cell’s CPICH RSCP > -105 dBm, and a Class 4 MS (P_MAX = 21 dBm) reselecting a 3G cell when the CPICH RSCP > -102 dBm. Refer to section 13.4 for a quick look at the recommended values for all 2G to 3G reselection parameters.
13.2.Nokia 2G to Ericsson 3G Reselection The following discussion is valid for Nokia BSS version S11.5. The ISHO_SUPPORT_IN_BSC option must be in use to handle, modify and output any of the GSM-WCDMA Inter System
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
116 of 214
Ericsson UMTS Feature Guidelines
Handover and Cell Reselection parameters which are not GPRS related. To enable the GPRS capable mobiles on PBCCH to measure and select an adjacent WCDMA cell the ISHO_SUPPORT_IN_BSC and BSC_GPRS_PARAM_ENABLED options must be in use. As per the current T-Mobile implementation there is no PBCCH configured in the GSM networks, hence the parameter BSC_GPRS_PARAM_ENABLED should be set to False.
13.2.1.
UTRAN Neighbor Definitions and System Information
The UTRAN cells to be monitored for inter system cell reselection are defined in the 3G neighboring cell list which is broadcast on BCCH using the System Information Type 2quater (SI 2quater). If a PBCCH is also configured, the 3G neighboring cell list is also broadcast on PBCCH using the Packet System Information Type 3quater (PSI 3quater). The SI 2quater and PSI 3 quarter messages are only broadcast if UTRAN neighbor cells are defined. These messages may contain more than one instance. The dual mode GSM/WCDMA mobiles are divided into two separate categories according to the GPRS capabilities: GPRS and non-GPRS capable mobiles. There are both common and category specific user defined parameters for the adjustment of the mobile functionality in the idle state, packet idle mode, dedicated state and packet transfer mode. For the BSC radio network parameter handling, this means that most if the WCDMA related idle state parameters are applicable foe all mobiles. However, the operator is also able to define the GPRS capability specific neighbor WCDMA cell measuring and reselection threshold values for the WCDMA capable mobiles. The dual mode GSM/WCDMA mobiles are able to find and identify a WCDMA RAN cell by the information included in the parameters WCDMA downlink carrier frequency (FREQ), scrambling code SCC), and downlink transmission diversity (DIV). The maximum number of 3G neighboring cells per serving GSM cell is limited to 32 cells over 3 frequencies. If GSM-WCDMA Inter-System Handover is in use, the maximum number of neighbor GSM cells (ADJC) per a serving cell (or segment) is 31 without Common BCCH Control in BSC or 30 if there is also at least one of the Common BCCH software activated. If GSM-WCDMA Inter-System Handover is in use, the maximum number of frequencies in a BCCH Allocation (BA) list is 31 without Common BCCH Control in BSC or 30 if there is also at least one of the Common BCCH software activated. A serving GSM cell cannot have two or more neighbor WCDMA RAN cells with the same UARFCN and scrambling code. A serving GSM cell cannot have two or more neighbor WCDMA RAN cells which use the same MCC + MNC + RNC id + CI combination and/or WCDMA RAN cell index value.
13.2.2.
Measurements on WCDMA neighbors in idle mode
In addition to measurements on surrounding GSM/GPRS/EGPRS cells, a Multi-RAT mobile also performs measurements on UTRAN neighboring cells. The parameter qSearchI for nonGPRS and qSearchP for GPRS capable UEs can be used to enable measurements on UTRAN cells in idle mode and packet switched modes. This parameter is broadcast on BCCH and PBCCH (if PBCCH is enabled).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
117 of 214
Ericsson UMTS Feature Guidelines
There are four possible scenarios based on value of qSearchI for non-GPRS capable mobiles (qSearchP for GPRS capable mobiles) for measurements on UTRAN neighbors.
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is above the threshold set by qSearchI (qSearchP).
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is below the threshold set by qSearchI (qSearchP).
UTRAN neighboring cells are always measured.
UTRAN neighboring cells are never measured.
Since T-Mobile camping strategy is to have the mobiles camp on the UMTS network, whenever UMTS coverage is available, the parameters qSearchI and qSearchP should be set to ‘always’, so that the UTRAN cells are measured even when the GSM signal strength is good. Recommended Value: The parameters qSearchI and qSearchP are recommended to be set to 7 (= always).
13.2.3. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation A similar algorithm to the one for GSM reselection is used for the GSM to UMTS cell reselection. Since the modulation technique used for UMTS is completely different from GSM, there is a difference in the evaluation of signal quality for GSM and UMTS measurements. Hence a mapping of UMTS signal strength is performed in such a way that it can be compared to GSM signal strength values. The following two criteria have to be fulfilled for a period of 5 seconds for a multi-RAT mobile to reselect a suitable UTRAN cell.
For a Non-GPRS capable UE: CPICH Ec/No > fddQMin and CPICH RSCP > RLA_C + fddQOffset
For a GPRS capable UE: CPICH Ec/No > gprsFddQMin and CPICH RSCP > RLA_C + fddGprsQOffset Where RLA_C refers to the Received Level Average of the serving GSM cells. RLA is the average of the received signal level measured in dBm for the serving GSM. fddQMin and gprsFddQMin are the minimum quality of a UTRAN cell for cell reselection for non-GPRS and GPRS capable UEs, respectively. These parameters ensure a sufficient quality for the candidate UTRAN cell. fddQOffset and fddGprsQOffset are the key parameters to control the behavior of intersystem cell reselection for non-GPRS and GPRS capable UEs, respectively. They define an
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
118 of 214
Ericsson UMTS Feature Guidelines
offset between the signal strength of UTRAN and GSM cells. Lower values of these parameters can be used to off-load the GSM system, while higher values can be used to keep multi-RAT mobiles in the GSM system. Since the values of GSM signal strength and UTRAN CPICH RSCP are not of the same kind, the balance between the two should be set with the offsets fddQOffset and fddGprsQOffset for non-GPRS and GPRS capable UEs, respectively. If more than one WCDMA cell fulfils the above criteria, the cell with the best RSCP is selected for reselection. The parameters that are required to determine whether the WCDMA RAN cell is suitable are broadcast on BCCH of the WCDMA RAN cell. A mobile may start re-selection towards the WCDMA RAN cell before decoding the BCCH of the WCDMA RAN cell. If the WCDMA RAN cell is not suitable, this leads to a short interruption of service. Cell reselection back to UTRAN will not occur within 5 seconds after a previous cell reselection from UTRAN. If a cell reselection occurred within the previous 15 seconds, the value of parameters fddQOffset and fddGprsQOffset is increased by 5 dB by the mobile. These conditions prevent ping-pong for a mobile that has just entered GSM. To achieve the preferred camping strategy of the mobile camping on UMTS, whenever UTRAN coverage is available, the value of fddQOffset (fddGprsQOffset) should be such that the UTRAN CPICH RSCP always looks better than the GSM RLA_C. A negative value of fddQOffset (fddGprsQOffset) would achieve this by making a UTRAN cell always look better than a GSM cell. Since this might result sometimes in cell reselection to a weak UMTS cell, the value of parameter fddQMin (gprsFddQMin) should be set to control this. A value of fddQMin (gprsFddQMin) such that fddQMin (gprsFddQMin) > qQualMin + sRatSearch would prevent the mobile from making cell reselection to a weak UTRAN cell. This setting would also ensure that the MS will not start to measure on GSM cells immediately after reselecting a UTRAN cell. For details on these parameters qQualMin and sRatSearch, refer to Chapter â&#x20AC;&#x153;Cell Reselection Parameters from 3G to 2Gâ&#x20AC;? for Ericsson 3G networks. The available values for parameter fddQMin (gprsFddQMin) are one of [-20dBm, -6dBm, 18dBm, -8dBm, -16dBm, -10dBm, -14dBm, -12dBm]. Since the recommended value for qQualMin = -18 dB and sRatSearch = 4 dB, the parameter fddQMin (gprsFddQMin) should be greater than -14 dB. The lowest value that achieves this condition (-12 dB) should be selected to speed up the reselection of a UTRAN cell. Recommended Values: From the above reasoning, the recommended value of fddQOffset (fddGprsQOffset) = -infinity and fddQMin (gprsFddQMin) = -12 dB. This would allow the MS to camp on UMTS, whenever UTRAN coverage is available, irrespective of the signal strength of GSM. These settings would result in a call reselection algorithm that is based only on the quality of the UTRAN cell, since the reselection criterion 2 is always satisfied. Refer to section 13.4 for a quick look at the recommended values for all 2G to 3G reselection parameters.
13.2.4.
Cell Reselection to UMTS for mobiles that support RSCP evaluation
For mobiles that support RSCP evaluation for reselection to 3G, an additional criterion is used to further minimize the number of ping pong cell reselections. This is achieved by
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
119 of 214
Ericsson UMTS Feature Guidelines
adding a threshold for CPICH RSCP measurements to assure a sufficient downlink signal strength, which in turn increases the possibility for the mobile to reach the network in the uplink. As per 3GPP, the additional criterion is given by CPICH RSCP > FDD_RSCP_threshold for a period of 5s, where FDD_RSCP_threshold = FDD_RSCPmin – min((P_MAX – 21 dBm), 3 dB) if FDD_RSCPmin is broadcast on the serving cell, else Qrxlevmin + Pcompensation + 10 dB, if these parameters are available, otherwise the default value of FDD_RSCPmin. Nokia 2G doesn’t support the availability of the parameter FDD_RSCPmin until BSS V13. Hence for a MS that supports RSCP evaluation, the CPICH RSCP of the 3G cell is compared to the default value of FDD_RSCPmin, which is equal to -102 dBm minus the value of min(P_MAX – 21 dBm, 3 dB). Hence for a Class 3 mobile that supports RSCP evaluation for cell reselection, a 3G cell is reselected when the RSCP > -105 dBm, in addition to the 2 criteria covered in the previous section for a time equal to 5 seconds.
13.3.Nortel 2G to Ericsson 3G Reselection The following discussion is valid for Nortel BSS version V16. GSM to UMTS Mobility is provided to UEs in Idle Mode to reselect to the 3G network. This section does not deal with UEs in connected mode. The parameter “uMTSReselectionARFCN” should be set to a nonnull value in order for the SI2quater message containing the UMTS neighbor cell information to be broadcast on the BCCH. A null value for this parameter would otherwise disable this feature and prevent reselection to UMTS.
8.1.2. UTRAN Neighbor Definitions and System Information The cell reselection does not require any specific algorithm in the GSM-BSS. The intersystem reselection only requires new piece of information to be broadcast on the BCCH by the GSMBSS:
new intersystem cell reselection control parameters
neighboring UMTS cell list
The broadcast of parameters required for 2G to 3G reselection is done using the "System Information 2quater" message. Due to the volume of information, it may happen that the set of data exceeds the 23 byte limit for "System Information" messages sent on BCCH. In such a case, the information is segmented into several parts i.e. several instances of the System Information 2quater message, each of them tagged with an INDEX from 0 to COUNT, (COUNT + 1) being the number of segments. When the information is updated (following a change at the OMC-R), the CHANGE MARK bit is set to a new value. The System Information 2quater is scheduled either on Normal or Extended BCCH
If sent on Normal BCCH: It shall be sent when TC = 5 if neither of 2bis and 2ter are used, otherwise it shall be sent at least once within any of 4 consecutive occurrences of TC = 4.
If sent on BCCH Ext, it is sent at least once within any of 4 consecutive occurrences of TC = 5.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
120 of 214
Ericsson UMTS Feature Guidelines
As a consequence, System Information 3 message has been updated in order to indicate to the mobile:
Whether or not SI2quater is broadcast.
If broadcast is done on Normal or Extended BCCH.
The current Nortel implementation doesn’t support UMTS neighbor definitions for the serving GSM cell. Only the UMTS FDD_ARFCN is defined on a BTS level. Hence the neighboring cell scrambling codes are not broadcast in the Nortel implementation, only FDD_ARFCN will be broadcast using SI 2quater.
13.3.1.
Measurements on WCDMA neighbors in idle mode
The parameter “uMTSSearchLevel” can be used to enable measurements on UTRAN cells in idle mode. This parameter is broadcast on BCCH. There are four possible scenarios based on value of “uMTSSearchLevel” for measurements on UTRAN neighbors.
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is above the threshold set by uMTSSearchLevel.
UTRAN neighbors are measured only when the signal strength of the GSM serving cell is below the threshold set by uMTSSearchLevel.
UTRAN neighboring cells are always measured.
UTRAN neighboring cells are never measured.
Since T-Mobile camping strategy is to have the mobiles camp on the UMTS network, whenever UMTS coverage is available, this parameter uMTSSearchLevel should be set to ‘always’, so that the UTRAN cells are measured even when the GSM signal strength is good. Recommended Value: The parameter uMTSSearchLevel is recommended to be set to 7 (= always).
13.3.2. Cell Reselection to UMTS for mobiles that don’t support RSCP evaluation Instead of C2 criterion used in a GSM-only network, the multimode cell reselection uses a criteria based on RLA_C (Received Level Averages for Circuit services), which is an unweighted average of the received signal levels measured in dBm. The UE starts measuring 3G cells based on the serving GSM cell’s RLA_C with respect to the setting of the parameter uMTSSearchLevel. The following two criteria have to be fulfilled for a period of 5 seconds for a multi-RAT mobile to reselect a suitable UTRAN cell. CPICH Ec/No(n) > uMTSAccessMinLevel and CPICH RSCP(n) > RLA_Cserving + uMTSReselectionOffset The parameter “uMTSAccessMinLevel” is the Nortel implementation of the 3GPP parameter FDD_Qmin and is the minimum quality of a UTRAN cell for cell reselection. This parameter ensures a sufficient quality of the candidate UTRAN cell.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
121 of 214
Ericsson UMTS Feature Guidelines
The parameter “uMTSReselectionOffset” is the key parameter to control the behavior of inter-system cell reselection and is the Nortel implementation of the 3GPP parameter FDD_Qoffset. It defines an offset between the signal strength of UTRAN and GSM cells. Lower values of this parameter can be used to off-load the GSM system, while higher values can be used to keep multi-RAT mobiles in the GSM system. Since the values of GSM signal strength and UTRAN CPICH RSCP are not of the same kind, the balance between the two should be set with the offset uMTSReselectionOffset. To achieve the preferred camping strategy of the mobile camping on UMTS, whenever UTRAN coverage is available, the value of uMTSReselectionOffset should be such that the UTRAN CPICH RSCP always looks better than the GSM RLA_C. A negative value of uMTSReselectionOffset would achieve this by making a UTRAN cell always look better than a GSM cell. Since this might sometimes result in cell reselection to a weak UMTS cell, the value of parameter uMTSAccessMinLevel should be set to control this. A value of uMTSAccessMinLevel such that uMTSAccessMinLevel > qQualMin + sRatSearch would prevent the mobile from making cell reselection to a weak UTRAN cell. This setting would also ensure that the MS will not start to measure on GSM cells immediately after reselecting a UTRAN cell. For details on these parameters with respect to the Ericsson RAN, refer to the Chapter “Cell Reselection Parameters from 3G to 2G”. The available values for parameter uMTSAccessMinLevel are one of [-20dB, -6dB, -18dB, 8dB, -16dB, -10dB, -14dB, -12dB]. Since the recommended value for qQualMin = -18 dB and sRatSearch = 4 dB, the parameter uMTSAccessMinLevel should be greater than -14 dB. The lowest available value that achieves this condition (-12 dB) should be selected to speed up the reselection of a UTRAN cell. Recommended Values: From the above reasoning, the recommended value of uMTSReselectionOffset = -infinity and uMTSAccessMinLevel = -12 dB. This would allow the MS to camp on UMTS, whenever UTRAN coverage is available, irrespective of the signal strength of GSM. These settings would result in a cell reselection algorithm that is based only on the quality of the UTRAN cell, since the reselection criterion 2 is always satisfied. Refer to section 13.4 for a quick look at the recommended values for all 2G to 3G reselection parameters.
13.3.3.
Cell Reselection to UMTS for mobiles that support RSCP evaluation
For mobiles that support RSCP evaluation for reselection to 3G, an additional criterion is used to further minimize the number of ping pong cell reselections. This is achieved by adding a threshold for CPICH RSCP measurements to assure a sufficient downlink signal strength, which in turn increases the possibility for the mobile to reach the network in the uplink. As per 3GPP, the additional criterion is given by CPICH RSCP > FDD_RSCP_threshold for a period of 5s, where FDD_RSCP_threshold = FDD_RSCPmin – min((P_MAX – 21 dBm), 3 dB) if FDD_RSCPmin is broadcast on the serving cell, else Qrxlevmin + Pcompensation + 10 dB, if these parameters are available, otherwise the default value of FDD_RSCPmin.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
122 of 214
Ericsson UMTS Feature Guidelines
Nortel 2G doesn’t support the availability of the parameter FDD_RSCPmin until BSS V17. Hence for a MS that supports RSCP evaluation, the CPICH RSCP of the 3G cell is compared to the default value of FDD_RSCPmin, which is equal to -102 dBm minus the value of min(P_MAX – 21 dBm, 3 dB). Hence for a Class 3 mobile that supports RSCP evaluation for cell reselection, a 3G cell is reselected when the RSCP > -105 dBm, in addition to the two criteria covered in the previous section for a time equal to 5 seconds.
13.4. 2G to 3G Reselection Parameter Recommendations 13.4.1.
Ericsson BSS Parameter Name COEXUMTS FDDQMIN FDDQMINOFF FDDQOFF FDDRSCPMIN QSI
13.4.2.
Recommended Value
BSC BTS BTS BTS BTS BTS
ON 7 (-12 dB) 0 (0 dB) 0 (-infinity) 6 (-102 dBm) 7 (always)
Nokia BSS Parameter Name fddQOffset (FDD) fddQMin (FDM) fddGprsQOffset (GFDD) gprsFddQMin (GFDM) qSearchI (QSRI) qSearchP (QSRP)
13.4.3.
Object Name
Object Name
Recommended Value
BTS BTS
N (-infinity) -12 dB
BTS
N (-infinity)
BTS BTS BTS
-12 dB 7 (always) 7 (always)
Nortel BSS Parameter Name
Object Name
uMTSAccessMinLevel
BTS
uMTSReselectionARFCN uMTSReselectionOffset uMTSSearchLevel
BTS BTS BTS
T-Mobile USA, INC. Confidential
Rev. 3.0
Recommended Value -12 dB ARFCN of UMTS carrier -infinity 7 (always)
Sep 11, 2008
123 of 214
Ericsson UMTS Feature Guidelines
14. Capacity Management Overview The fundamental algorithms associated with capacity management are Admission Control, and Congestion Control. These algorithms depend on Ericsson’s Dedicated Monitored Resource Handling function to supervise the utilization of system resources and provide inputs to the admission and Congestion Control programs. Figure 22 illustrates Ericsson’s capacity management functions. Admission Control is invoked whenever new or additional resources are required; such as an access attempt or a soft handover request. In either of these cases, the Admission Control algorithm must confirm there are adequate system resources available to support this new request. Examples of these resources include codes, power and channel elements. Congestion Control is invoked when the utilization of resources is reaching a critical limit and this contention needs to be resolved. An example of this would be downlink power nearing one hundred percent. In this case, resources dedicated to users may be reduced, or in the extreme case removed, to eliminate congestion. Both power and orthogonal codes are a limited resource. In general, once a cell’s capacity demands consume these resources, the only option is to add a new site or a second frequency in order to offload the cell’s usage. On the other hand, channel elements are typically limited by license agreements between Ericsson and T-Mobile. Once the user capacity needs consistently approach a predefined channel element threshold, more channel elements will have to be licensed. Before getting into the details of the capacity management algorithms, this section will discuss resources that are monitored by the capacity management algorithms. Resources are consumed to support overhead channels (e.g. the Pilot channel), as well as common user channels (e.g. the FACH or HS-DSCH channels). Additionally resources are obviously made use of to support dedicated channels. The term dedicated channel (DCH) refers to a channel which is only used by a single user (e.g. a CS voice call), and consumes resources that are solely allocated to this user. Every DCH requires the use of orthogonal codes, channel elements and power. The consumption of these resources is described in the following sections.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
124 of 214
Ericsson UMTS Feature Guidelines
Figure 22 - Overview of Ericsson Capacity Management Functions
14.1.Overview of UMTS Resources The resources that are monitored by the capacity management algorithms include power, orthogonal codes and channel elements. In addition the uplink noise rise is monitored as well. In this section, some properties of these resources, as well as some of their configurable parameters (if applicable) will be discussed.
14.1.1.
DL Power
All physical channels require an allocation of downlink power. The power for common channels is typically fixed and parametrically controlled. On the other hand, dedicated channels utilize power dynamically depending on RF conditions (i.e. interference) and distance from the cell (i.e. pathloss). When a dedicated channel is configured, the amount of downlink power it uses is controlled by closed loop power control. If the transport channelâ&#x20AC;&#x2122;s configured Block Error Rate (BLER) is not met, outer loop power control raises the SIR target, which results in increased DL power. If the maximum power for a given DCH was not limited by some mechanism, it is possible that a majority of the cellâ&#x20AC;&#x2122;s power could be consumed by a single user. In order to curtail the amount of power that a single user can use, a maximum downlink transmitted code power is defined. This is defined per cell, by use of the interpolation curve shown in Figure 23 - Bit Rate (bps) versus Maximum Downlink Transmitted Code Power. As the figure illustrates, the curve is defined by six parameters: minPwrMax; minimumRate; interPwrMax; interRate; maxPwrMax; maxRate. In this manner, the maximum power for a DCH can be limited based on its data rate, and a single user can not consume an excessive amount of power. For data rates that fall between these parameter data points, interpolation is used. As an example, the maximum power a 12.2 kbps voice call can use is less than the maximum power a 384 kbps PS radio bearer can use. Since these two dedicated channels use a 128 bit code and an 8 bit code respectively, the processing gain of the PS call is approximately 12 dB less than the CS call. Therefore it is logical that the PS call will need more power than the CS call to maintain the same coverage within the cell. In addition to this power limiting effect described above, soft and softer handover also add to the consumption of downlink power. Assuming that the average soft handover factor was 1.8 radio links per user, each user would require power from 1.8 cells, on an average (excluding the HS-PDSCH).
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
125 of 214
Ericsson UMTS Feature Guidelines
Figure 23 - Bit Rate (bps) versus Maximum Downlink Transmitted Code Power
14.1.2.
Received Total Wideband Power
All transmissions in the uplink contribute to the increase in uplink noise, or Received Total Wideband Power (RTWP). To limit the interference a UE can create, the parameter maxTxPwrUl is used to control the maximum power the UE can transmit. This parameter is typically configured to be 24 dBm for a Class 3 UE.
14.1.3.
OVSF Codes
Every dedicated channel that is configured utilizes an orthogonal code, or an Orthogonal Variable Spreading Factor (OVSF), from the code tree. In addition, some common channels also consume OVSF codes. Unfortunately, the number of available codes is limited within each cell. Figure 24 illustrates a portion of the OVSF code tree (reference 3GPP TR 25.292). As the figure shows, the number of available codes is equal to the number of bits in the code (e.g. there are two 2 bit codes, four 4 bits codes, etc.). In addition, once a specific code is allocated, other codes on the same branch of the code tree become unavailable for use. For example, if the 4 bit code (1,1,-1,-1) is assigned, all preceding codes on the same branch, such as (1, 1), are unusable. In addition, all the codes the follow on the same branch are unusable as well. This would include (1,1,-1,-1, 1,1,-1,-1), (1,1,-1,-1, -1,-1,1,1), as well as all the 16, 32, 64, 128, and 256 bit codes that are decedents of this 4 bit code. These codes are unusable because the orthogonal properties of OVSF codes do not exist between parent codes and their descendants.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
126 of 214
Ericsson UMTS Feature Guidelines
c4,1 = (1,1,1,1)
C8,1 C8,2
c4,2 = (1,1,-1,-1)
C8,3 C8,4
c2,1 = (1,1)
c1,1 = (1)
Unusable Codes
c4,3 = (1,-1,1,-1)
Allocated Code
c2,2 = (1,-1) c4,4 = (1,-1,-1,1)
SF = 1
SF = 2
Unusable Codes
SF = 4
Figure 24 â&#x20AC;&#x201C; OVSF Code Tree Based on the properties of OVSF codes discussed above, it is apparent why codes can be consumed so quickly. Table 4 provides a sample of downlink code utilization of miscellaneous user applications. Because the descendants of codes become unusable, a user utilizing an 8 bit OVSF for a 384 kbps session reduces the pool of available 128 bit codes by 16 codes. This has a direct impact on 128 bit code availability for 12.2 kbps AMR voice calls. User Application 5.9 AMR CS 12.2 AMR CS HSDPA Code DCH 64k PS DCH 128k PS DCH 384k PS
DL Code Length 256 bit 128 bit 16 bit 32 bit 16 bit 8 bit
Available Codes 256 128 16 32 16 8
Table 4 - Code Utilization of Misc. User Applications In addition to this code limiting effect described above, soft and softer handover also add to the consumption of OVSF codes. Assuming that the average soft handover factor was 1.8 radio links per user, each user would require 1.8 codes on an average (excluding the HSPDSCH).
14.1.4.
RBS Channel Elements
The term channel element (CE) is used to quantify processing power in the Node B chipset. The number of channel elements available for users is dependant on hardware configuration, and number of licensed channel elements enabled. In general, channel elements for the common and overhead channels are included with the Node B, and do not take from the pool of licensed channel elements. In the Ericsson Node B, channel elements for uplink are located on the Random Access and Receiver (RAX) board. The total number of CE available is dependant on the type of RAX board, as well as the number of RAX boards that are installed in the Node B. As an example, the high capacity 3206 RBS can contain 8 RAX R2 boards with 128 channel element each, for a total of 1024 channel elements.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
127 of 214
Ericsson UMTS Feature Guidelines
The channel elements for the downlink are located on the transmitter card. The total number of CE available is dependant on the number of transmitter boards installed. The 3206 RBS can be configured with 2 transmitter cards with 256 channel elements each, for a total of 512 channel elements. The number of channel elements utilized by a UE is dependant on several factors. This includes the RAB type used, as well as the soft/softer handover state of the UE. Table 5 provides some examples of downlink and uplink CE usage based on RAB type. As the table shows, RABs with high data rates require additional processing and therefore more channel elements. When a UE is in soft handover, the CE requirement obviously increases since multiple Node Bs are involved. However, when a UE is in softer handover, the same CE will process the multiple radio links within the same Node B. CS/PS RAB Speech 64 kbps 128 kbps 384 kbps
Downlink (CE) 1 2 4 8
Uplink (CE) 1 4 8 16
Table 5 - Channel Element Consumption by RAB Type
14.2.Common Resource Utilization In general, capacity management is typically focused on controlling resources for dedicated channels. However, common channels also consume resources and affect the pool of resources available for dedicated channels. In order to better understand how capacity management operates, this section will review the utilization of common resources.
14.2.1.
Overhead and Common Channels
The term overhead channels refer to the set of channels that are required for the network to operate, however they are not used to relay user plane data (i.e. a CS call or PS data). Common channels, such as the Forward Access Channel, do have the capability to deliver user specific data over a common resource. All of these channels require the use of orthogonal codes, channel elements, and downlink power. In general, channel elements for the overhead channels are included with the Node B, and do not take from the pool of licensed channel elements. The consumption of the downlink power and codes resources, for each of the overhead and common physical layer channels, is described in the following sections. Primary Common Pilot Channel The Primary Common Pilot Channel (CPICH), also known has the pilot, is an overhead channel that is constantly broadcast. The CPICH utilizes a 256 bit orthogonal code, and its power is configured by the parameter primaryCpichPower. Typically the CPICH is set to approximately 10% of the cellâ&#x20AC;&#x2122;s output power capability. Because this parameter is set at the antenna reference point (see figure below), the insertion loss of the feeder lines, and other miscellaneous coupler losses should be considered when setting this parameter. As an example, assume the Node B has a 40 watt (i.e. 46 dBm) power amplifier (PA), and the total insertion loss was 3 dB between the Node B and the antenna reference point. If the desired CPICH power was 10% of the total PA power, primaryCpichPower would be
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
128 of 214
Ericsson UMTS Feature Guidelines
set to 33 dBm. This based on a maximum Node B output of 43 dBm (46 -3 = 43) at the antenna reference point; and 10 % of 43 dBm is 33 dBm.
Antenna Reference Point
Node B
Figure 25: Antenna Reference point Primary Common Control Physical Channel The Broadcast Channel (BCH) is used to transmit system and cell specific information to idle UEs. The BCH is mapped to the Primary Common Control Physical Channel (P-CCPCH). The P-CCPCH utilizes a 256 bit orthogonal code, and its power is configured relative to the CPICH by the parameter bchPower. Secondary Common Control Physical Channel The Paging Channel (PCH) and the Forward Access Channel (FACH) transport channels are mapped to the Secondary Common Control Physical Channel (S-CCPCH). It is possible to map the PCH and the FACH to a single S-CCPCH, or to map each of them to a unique SCCPCH. Typically the S-CCPCH with the FACH mapped to it will have a 64 bit orthogonal code, while a stand alone PCH mapped S-CCPCH only requires a 128 bit orthogonal code. The power for the PCH is controlled by the parameter pchPower; and the maximum power for FACH is configured by maxFach1Power. Both of these parameters are configured relative to the CPICH power. If a second FACH channel is configured, the power is configured with the parameter maxFach2Power. Primary and Secondary Synchronization Channels The Primary Synchronization Channel (P-SCH) and Primary Synchronization Channel (S-SCH) are used by the UE to obtain slot and frame synchronization. The P-SCH and S-SCH only exist at the physical layer, and do not consume orthogonal codes. The power for the PSCH, and the S-SCH are configured relative to the CPICH power by the parameters primarySchPower, and secondarySchPower respectively. Paging Indication Channel The Paging Indication Channel (PICH) is used by the network to instruct the UE to monitor the Paging Channel for a possible page. The PICH was introduced into the 3GPP standard to improve UE battery life. This channel only exists at the physical layer and does not
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
129 of 214
Ericsson UMTS Feature Guidelines
consume any orthogonal codes. The power for the PICH is configured relative to the pilot by the parameter pichPower. Acquisition Indication Channel The Acquisition Indication Channel (AICH) is used to acknowledge random access preambles when the UE is attempting to access the network. The AICH only exists at the physical layer and does not consume any orthogonal codes from the code tree. The power for the AICH is configured relative to the pilot by the parameter aichPower.
14.2.2.
Maximum Downlink Transmission Power
The maximum downlink power transmitted from a cell can be limited by the configurable parameter maximumTransmissionPower. As described earlier in the section, the reference point for this parameter is at the antenna reference point. This parameter allows limiting the power to a level lower than the actual power available, which is reported by the Node B as maxDlPowerCapability. This reported power available is derived from the maximum PA output power, less the insertion losses between the PA and the antenna reference point. If the parameter maximumTransmissionPower is configured to a value that differs from the maxDlPowerCapability reported by the Node B, the lesser of the two values will be utilized.
14.2.3.
HSDPA Resources
High Speed Downlink Packet Access (HSDPA) uses the High Speed Physical Downlink Shared Channel (HS-PDSCH) to deliver user data to HS capable UEs. This channel utilizes 16 bit orthogonal codes, as well as the remaining unused power in the cell. The number of orthogonal codes utilized for HS is controlled by multiple parameters, and will be described below. The parameter numHsPdschCodes is used to reserve a fixed number of 16 bit orthogonal codes for use by the HSDPA scheduler. In this manner, HS users are guaranteed codes regardless of DCH resource requests. However, these reserved codes will be unavailable for DCH resource requests, even if there are not any HSDPA users in the cell. It is possible to dynamically allocate more HS-PDSCH codes by enabling the HSDPA Dynamic Code Allocation algorithm by setting the parameter dynamicHsPdschCodeAdditionOn to TRUE. This algorithm will periodically assess the use of 16 codes every second. If there are any unused codes available, they will be temporarily made available to the scheduler. However, if there is a need for codes to support DCH requests, they will be immediately deallocated from the scheduler (excluding those reserved by the parameter numHsPdschCodes). The maximum number of simultaneous codes used by the HSPDSCH at any give time is limited by the configurable parameter maxNumHsPdschCodes. Care should be taken when configuring the parameter numHsPdschCodes. If the value is set too high, the potential of blocking DCH users (e.g. CS calls), is increased. However, setting this value too low may starve HS cell throughput if DCH traffic is high. This parameter is configured at the cell level and therefore can be tuned to meet user requirements. In addition to HS-PDSCH, the High Speed Shared Control Channel (HS-SCCH) requires a 128 bit orthogonal code. The parameter numHsScchCodes controls the number of HS-SCCH broadcast per cell. The number of HS users that can be simultaneously allocated resources
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
130 of 214
Ericsson UMTS Feature Guidelines
by the scheduler per 2 ms Transport Time Interval (TTI) is directly related to the number of HS-SCCH broadcast (maximum is 4). If a cell has a high HS traffic load, and a low DCH load, it may be beneficial to increase the number of broadcast HS-SCCH. However, if the overall cell throughput is limited due to power, HS-PDSCH codes or transport limitations, consuming another 128 bit code to support an additional HS-SCCH is unneeded.
14.3.Dedicated Monitor Resource Handling The utilization of system resources is constantly changing based on several factors. These factors include the number of users, the RF conditions each user is experiencing, the applications they are using, their soft handover state, etc. Because of this dynamic use of resources, the Ericsson UTRAN monitors the most critical resources. The admission and Congestion Control algorithms depend on Ericsson’s Dedicated Monitored Resource Handling function to supervise the utilization of system resources and provide inputs to the admission and Congestion Control programs. The following resources are monitored on a cell basis.
Downlink channelization codes
Downlink transmitted carrier power, non-HS part and HS-required part
Air Interface Speech Equivalents (ASE) in uplink and downlink
Uplink Received Total Wideband Power (RTWP)
The number of radio links per DL Spreading Factor (not including the codes (spreading factor = 16) reserved for or used by HSDPA connections)
The number of radio links per UL Spreading Factor (not including codes used by EUL)
The number of radio links in compressed mode
The number of serving HS connections
Some of these are discussed in detail in the following sections.
14.3.1.
Downlink Channelization Code Monitor
The Downlink Channelization Code Monitor tracks the usage of OVSF codes. The fraction of code tree usage is reported to the capacity management programs. Both common and dedicated OVSF code usage is accounted for when calculating the fraction of code tree usage. This monitor is used by Admission Control to reserve OVSF codes for handover admission requests. The fraction of codes in use is calculated as Sum
user
(( 1 + p * 1/16) / SF
user))
+ Sum
user
(( 1 + p * 1/16) / SF
cch))
Where SF user is the DL spreading factor relating to the set of DCHs of the user (including the
A-DCHs), SF CCH is the spreading factor of the common control channels and p is the number of DL codes reserved (SF = 16) for HS-DSCH.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
131 of 214
Ericsson UMTS Feature Guidelines
14.3.2.
Downlink Transmitted Carrier Power
The downlink transmitted carrier power is obviously a limited resource. The use of this resource must be monitored to provide input to the Admission Control and Congestion Control algorithms. Two mechanisms are used by the Node B to report the total transmitted carrier power of the cell to the RNC. Periodic reports are used by Admission Control to determine if admission requests, soft handover requests, and radio link reconfiguration requests will be granted or denied. Periodic reports are also used to determine the initial rate selection. The amount of non-HSDPA power and HS-required DL transmitted carrier power is reported periodically to the RNC for Admission control purposes. In addition, event based measurements are used when the total downlink non-HS power usage exceeds a predefined threshold and Congestion Control must offload users. This is accomplished by the RBS reporting the event of the non-HSDPA DL transmitted carrier power in a cell exceeding a level for some time, and reporting the event of the non-HSDPA DL transmitted carrier power in a cell getting below that level for some time to the RNC. In order to detect and resolve the DL HS overload, the amount of non-HSDPA power and HS-required DL transmitted carrier power is combined. Periodic Measurement Report When a cell is integrated and enabled in the UTRAN, the controlling RNC utilizes NBAP messaging to initiate periodic measurement reports for the downlink transmitted carrier power. These periodic reports are filtered in the RNC, and tracked by the Downlink Transmitted Carrier Power Monitor. In addition to the reported carrier power, this monitor also estimates power utilization for pending radio links that have been granted admission, but may have not had time to be implemented. These estimates decay over time and allow the Admission Control algorithm to handle new requests while previously admitted radio links are being set up. Equation below illustrates how the monitor derives the downlink transmitted carrier power.
P_Monitore d P_Measure_ Filter f P_Estimate _RL Equation 6 - Monitored Downlink Carrier Power where: P_Monitored
Total monitored power
P_Measure_Filter
Filtered periodic measurement of downlink transmitted carrier
f(P_Estimate_RL)
Sum of all decaying estimates of recently admitted radio links
power The estimated power for recently admitted radio links is derived by providing a scaling factor based on the type of radio link; and multiplying it to the maximum transmitted code power for that type of radio link. This scaling factor is based on characteristics for that specific type of radio link (i.e. activity factor, discontinuous transmission, etc.). The derivation of this estimated radio link power is provided in Equation below.
P_Estimate_RL F * P_Max_RL
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
132 of 214
Ericsson UMTS Feature Guidelines
Equation 7 - Estimated Radio Link Power Where: P_ Estimate_RL
Estimated power of the recently admitted radio link
F
Scaling factor for the specific type of radio link
P_Max_RL
Maximum transmitted code power for the specific type of radio
link Event Based Measurement Report Event based measurement reports are also set up by NBAP signaling when a Node B is integrated into the network. The thresholds for the (downlink transmitted carrier power) event based measurements are configured by Congestion Control parameters. These parameters define at what carrier power level congestion is triggered, and at what power level congestion is resolved. Event based measurement reports are sent to the RNC when the total downlink power of the cell exceeds the congestion threshold; and an additional event based measurement report is sent once the carrier power drops below the congestion resolution threshold. The details regarding these parameters, as well as the Congestion Control algorithm, will be covered in later sections.
14.3.3.
ASE Monitor
The Air Interface Speech Equivalent (ASE) is an Ericsson specific term used to quantitatively describe the interference caused by a single 12.2 AMR speech call (excluding the SRB). The term is used for both the uplink and downlink. As an example, a PS 384 has an ASE equal to 39.78 in the downlink. This implies that a 384 kbps downlink radio bearer, including its SRB, contributes 39.78 times the amount of interference in the downlink than a single 12.2 kbps speech call does. Some ASE values for some sample radio connections are provided in the table below. Note that the values provided below and utilized by the capacity control algorithm account for the 0.61 ASE load contributed by the 3.4 kbps SRB. The number of uplink ASEs credited to a cell, from a specific UE, is dependant on the soft handover state of that UE. The ASE load for a cell is divided by the number of radio links in the active set. If a UE is in 2 way soft handover, ASE load for each cell will be halved. This is because of the reduced uplink interference due to soft handover gain. Radio Connection Type Uplink ASEs Downlink ASEs SRB 13.6 kbps 0.45 0.45 AMR 12.2 1.12 1.12 CS64 10.61 10.61 PS16/64 4.25 10.10 (Streaming) PS64/384 MultiRAB (speech+PS64/64)
7.83 8.83
39.78 8.83
PS64/HS
7.83
0.12
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
133 of 214
Ericsson UMTS Feature Guidelines
Table 6 - ASE Value per Radio link
14.3.4.
RTWP Monitor
All transmissions in the uplink contribute to the increase in uplink noise, or Received Total Wideband Power (RTWP). The RTWP monitor tracks the noise rise by mean of event based measurement reports configured via NBAP signaling. The thresholds for the RTWP event based measurements are configured by Congestion Control parameters. These parameters define at what uplink noise level congestion is triggered, and at what noise level congestion is resolved. Event based measurement reports are sent to the RNC when the RTWP of the cell exceeds the congestion threshold; and an additional event based measurement report is sent once the RTWP drops below the congestion resolved threshold. The details regarding these parameters, as well as the Congestion Control algorithm, will be covered in later sections.
14.3.5.
RBS Hardware Monitor
The RBS Hardware Monitor tracks both uplink and downlink CE utilization. As described previously, the term channel element (CE) is used to quantify processing power in the Node B chipset. The number of channel elements available for users is dependant on hardware configuration and the number of licensed channel elements enabled. The Node Bâ&#x20AC;&#x2122;s CE consumption is tracked as a percentage, based on the number of dedicated radio links in the cell, the type of radio link, and the amount of available licensed channel elements. The admission thresholds for both uplink and downlink CE usage are configured by Admission Control parameters. The details regarding these parameters, as well as the Admission Control algorithm, will be covered in the next section.
14.4.Services Class and Setup Type Service class and setup type of a specific user are used to prioritize the allocation of dedicated resources, and the retention of resources when the system becomes congested.
14.4.1.
Service Class
The service classes are divided into 2 specific groups: 1. Guaranteed: A request is guaranteed when requesting minimum amount of resources for a radio connection satisfying its QoS (this is referred to lowest retainable rate). Example of a guaranteed request is CS conversational, CS or PS streaming and PS interactive 8/8. 2. Non-guaranteed: When the request is for resources exceeding the minimum needed for satisfying the QoS (for example up-switch interactive PS to a higher dedicated rate), the request is non-guaranteed. Example of a non-guaranteed request is PS interactive.
14.4.2.
Setup Type
The setup type is divided and prioritized into two groups: 1. Handover: This setup type refers to requests for resources when a connection exists, and an additional radio link is requested to support soft handover.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
134 of 214
Ericsson UMTS Feature Guidelines
2. Non-handover: This setup type refers to requests for resources when there is no existing connection (i.e. a new call setup request). The thought behind this prioritization is that a user denied admission to setup a new call will be less â&#x20AC;&#x153;irritatedâ&#x20AC;? than a user that drops a call due to a failed handover. In addition, a denied handover request is likely to result in a degradation of resources in the target cell. This is due to the additional uplink and downlink interference the target cell will be subjected to if it can not power control the UE as it enters the target cells coverage area.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
135 of 214
Ericsson UMTS Feature Guidelines
15. Admission Control Admission Control is invoked whenever new or additional dedicated resources are required; such as an access attempt, a soft handover request, or a radio bearer reconfiguration request. In either of these cases, the Admission Control algorithm must confirm there are adequate system resources available to support this new request. Examples of these resources include codes, power and channel elements. In the case of an access attempt, the Admission Control algorithm may be invoked multiple times. When a RRC Connection Request message is received on the RACH, the corresponding RRC Connection Setup Complete message typically instructs the UE to setup a dedicated SRB. Regardless if the request is for CS, PS or simply a reselection, Admission Control must confirm resources are available to support the requested SRB. In addition, the algorithm is invoked again once the RNC receives a RAB Assignment Request from the core network. In the case of CS call, the SRB is reconfigured to include the AMR transport channels; and resources must be confirmed. If the RAB Assignment Request is for PS Services, Admission Control must confirm that DCH or HS resources are available. In the case of an ongoing DCH PS session, a radio bearer reconfiguration may be requested by the channel switching algorithm to support higher user throughput. Since this reconfiguration would require additional codes, power, and channel elements, Admission Control would obviously be triggered. As mentioned previously, the admission request may also originate from a UE requesting soft handover. Although these types of requests do take priority over new call setups, the Admission Control algorithm must confirm the cell can handle the additional load. In order to assess the resource availability, every admission request must include the following information:
Request type (e.g. handover/non-handover)
Request class (e.g. non-guaranteed, guaranteed)
Additional resources requested
Additional requested uplink and downlink ASEs
Additional requested compressed mode resources
Pre-emption capability of the request
Priority of the request
In Ericsson P6, the admission control mechanism has been enhanced to include the 3GPP mechanism for allocation or retention as a basis for prioritizing between services during resource shortage. The pre-emption and priority attributes of an admission request are determined from the Allocation Retention Priority (ARP) attributes. ARP attributes are by default defined statically as function of RANAP attributes, or can optionally be defined by the operator.. The following sections will describe the different aspects of the Admission Control algorithm, and the parameters and counters associated with them. In addition, impacts of parameter changes to system performance will be discussed.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
136 of 214
Ericsson UMTS Feature Guidelines
15.1. ARP attributes 15.2. Enhanced Soft Congestion Enhanced soft congestion is a feature of Admission Control that reduces the resource utilization of low priority users, when admission thresholds have been reached. In this manner other users can be admitted into the cell, by down switching existing low priority users. Resources requirements that can trigger soft congestion include downlink transmitted carrier power, downlink OVSF codes, and uplink/downlink channel elements. The behavior of soft congestion depends on the request type.
Non guaranteed requests: These requests can reduce the rate of other lower priority, non-guaranteed connection parts in steps (for example from interactive PS 384/64 to interactive PS 128/64), down to their lowest retainable rate. Equal priority request and connection parts will equally balance their resource utilization (for example a request for interactive PS 64/64 can reduce the rate of an equal priority interactive PS 128/64 RAB to interactive PS 64/64, but not to lower rates).
Guaranteed requests: These requests can reduce the rate of any priority, nonguaranteed connection parts in steps down to their lowest retainable rate. If that is not sufficient, the Soft Congestion feature can pre-empt existing guaranteed RABs of lower priority, or non-guaranteed RABs at the lowest retainable rate if the request is pre-emption capable and connection part targeted is pre-emption vulnerable (for example conv. CS Speech (priority=3, pre-emption capable) can pre-empt conv. CS unknown (priority=4, pre-emption vulnerable).
Soft congestion doesn’t target requests over IuR.
15.3. Admission Policies Admission policies are a set of rules that evaluate a given admission request and produce one of the 3 following results
Admitted
Blocked
Conditionally Blocked – the request is admitted under the condition that soft congestion can free the required resources.
Admission policies are divided into the following categories.
15.3.1.
Downlink Channelization Code Admission
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter dlCodeAdm
Guaranteed, handover admission requests are conditionally blocked when the resource usage is at 100 %.
It is important to note that the Downlink Channelization Code Monitor does not account for 16 bit OVSF codes utilized by the HS-DSCH. Therefore if codes are statically allocated for
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
137 of 214
Ericsson UMTS Feature Guidelines
HS, by means of the parameter numHsPdschCodes, the allocation of these 16 bit codes for HS will not be tracked by the code monitor. That is the parameter dlCodeAdm is based on the code tree after excluding the codes reserved for HS-DSCH.
15.3.2.
Downlink Transmitted Carrier Power Admission
This admission policy is checked when there is a request for additional DL ASE.
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter pwrAdm.
Guaranteed, handover admission requests are conditionally blocked when the resource usage is at 100 %.
Admission requests are blocked in case the cell is either in DL overload or in DL HSDPA overload and lower priority users are being targeted to free resources.
15.3.3.
Downlink ASE Admission
This admission policy is checked when there is a request for additional DL ASE.
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter aseDlAdm.
Guaranteed, handover admission requests are never blocked.
15.3.4.
Uplink ASE Admission
This admission policy is checked when there is a request for additional UL ASE.
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter aseUlAdm.
Guaranteed, handover admission requests are never blocked.
15.3.5.
Downlink Spreading Factor Admission
Non-guaranteed, non-handover/handover admission requests for SF 8 in downlink are blocked when the usage of SF 8 exceeds sf8Adm.
Non-guaranteed, non-handover/handover admission requests for SF 6 in downlink are blocked when the usage of SF 16 exceeds sf16Adm.
Non-guaranteed, non-handover/handover admission requests for SF32 in downlink are blocked when the usage of SF 32 exceeds sf32Adm.
Guaranteed, non-handover/handover admission requests for SF 16 in DL are blocked if the resource usage plus the additional SF 16 required exceeds sf16gAdm.
15.3.6.
Uplink Spreading Factor Admission Non-guaranteed, non-handover/handover admission requests for SF 4 in uplink are blocked when the usage of SF 4 exceeds sf4AdmUl.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
138 of 214
Ericsson UMTS Feature Guidelines
Non-guaranteed, non-handover/handover admission requests for SF 8 in uplink are blocked when the usage of SF 8 exceeds sf8AdmUl.
Non-guaranteed, non-handover/handover admission requests for SF 16 in uplink are blocked when the usage of SF 16 exceeds sf16AdmUl.
Guaranteed, non-handover/handover admission requests for SF 8 in UL are blocked if the resource usage plus the additional SF 8 required exceeds sf8gAdmUl.
Figure 26 – Downlink SF Admission Limits for Non-guaranteed Users
15.3.7.
Compressed Mode Admission
The number of compressed mode radio links allowed in a cell at any given time is controlled by the parameter compModeAdm. Admission requests beyond this threshold are blocked.
15.3.8.
HSDPA Admission
HSDPA utilizes the HS-DSCH, which is a shared resource. Although HSDPA is a highly efficient means to deliver data to PS users, the number of simultaneous users monitoring the HS-SCCH should be limited. Excessive users monitoring the same HSDPA cell not only tax the scheduler’s processing capabilities, they can also impact the end user throughput and system capacity. At a first glance, it may seem advantageous to not limit HSDPA users, thus maximizing cell throughput. However, one must also consider the effect to system capacity. Currently, for every user that is assigned to a HSDPA serving cell, that user requires a downlink dedicated physical channel (DPDCH/DPCCH) to support RRC/NAS signaling and power control of the subsequent UL dedicated channel. This physical channel requires power, and a 256 bit downlink OVSF code. Although this may seem trivial, one must remember that for every HSDPA user assigned a 256 bit OVSF code to support this downlink DCH, a 16 bit code becomes unavailable for use by the HS-DSCH. As users continue to be added to a HSDPA serving cell, a point of diminishing returns is reached as 16 bit codes for the HS-DSCH become unavailable. In addition, each HSDPA user is assigned a High Speed Dedicated Physical Control Channel (HS-DPCCH) in the uplink. Each of these dedicated uplink
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
139 of 214
Ericsson UMTS Feature Guidelines
channels contribute to uplink noise rise, thus limiting system capacity. Optimizing the parameters related to state changes, to efficiently de-allocate HS resources from idle PS users, is the best way to maximize user access to HSDPA resources. The maximum number of HSDPA users per cell is defined by the parameter maxNumHsdpaUsers. This should be configured in accordance with the license key for TMobile. Admission requests for “new” HSDPA connections are limited by the parameter hsdpaUsersAdm. If an admission request is originated from an existing HSDPA connection, as a result of mobility, the request is not blocked based on hsdpaUsersAdm. The difference between the parameter maxNumHsdpaUsers and hsdpaUsersAdm defines the mobility margin for HSDPA calls. Hence the parameter should be set such that there is room for serving HSDPA cell changes so that the serving cell is always the optimal cell which will ensure good throughput and minimize the risk of dropped calls.
15.3.9.
Downlink Node B Hardware Admission
The RBS Hardware Monitor provides Admission Control with the estimation of the hardware usage per radio link type in a cell for the downlink.
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter dlHwAdm
Guaranteed, handover admission requests are conditionally blocked when the resource usage is at 100 %.
15.3.10. Uplink Node B Hardware Admission The RBS Hardware Monitor provides RN Admission Control with the estimation of the hardware usage per radio link type in a cell for the uplink.
Non-guaranteed, non-handover/handover admission requests and Guaranteed , non-handover requests are conditionally blocked when the resource usage exceeds the threshold given by the parameter ulHwAdm
Guaranteed, handover admission requests are conditionally blocked when the resource usage is at 100 %.
15.4. Counters Related to Admission Control Tracking performance statistics or counters allow monitoring and troubleshooting UTRAN system performance. The counters specifically related to Admission Control can be utilized to tune parameter settings, or trigger capacity/dimensioning related actions (e.g. channel element additions). The counters described in this section include some of the more important counters related to Admission Control. For a complete list of performance counters, refer to the Ericsson RNC Performance Management documentation [14]. Figures below provide a three part flowchart for the some of the counters related to Admission Control. The counters illustrated on the right side of Figure 27 include some of the level counters used by the Dedicated Monitored Resource Handling function (e.g. pmLevelSampAseUl, pmLevelSampAseDl, and pmLevelCompMode). These counters are incremented and decremented based on resource utilization and typically do not yield
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
140 of 214
Ericsson UMTS Feature Guidelines
useful information from a statistical or troubleshooting perspective. On the other hand, the left side of Figure 27 provides the path for failed admission requests. If enhanced soft congestion is triggered, the counter pmNoOfSwDownNgAdm is incremented. The fact that this counter was incremented does not indicate that the down switch was successful, rather that a down switch was attempted. For more information related to channel switching counters, refer to the Ericsson RNC Performance Management documentation [14]. If the down switch fails, the admission request will be denied and the counter pmNoReqDeniedAdm will be incremented. In addition, this counter is also incremented for failed admission requests that do not trigger enhanced soft congestion.
Figure 27 - Ericsson Admission Control Flowchart (1 of 3) Continuing down the path for failed admission requests, figure below illustrates when nonhandover related counters are incremented based on service type. If the failed admission
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
141 of 214
Ericsson UMTS Feature Guidelines
attempt is for a new speech connection (non-handover), the counter pmNoOfNonHoReqDeniedSpeech is incremented. For circuit switched data or circuit switched streaming admission requests, the counter pmNoOfNonHoReqDeniedCs is incremented, for non-handover scenarios.
Figure 28 - Ericsson Admission Control Flowchart (2 of 3) The counter pmNoOfNonHoReqDeniedInteractive is incremented if the failed admission request is for non-HS interactive packet switch RABs, while the counter pmNoOfNonHoReqDeniedPsStreaming is pegged if the request was for a non-HS streaming packet switched RAB. If the failed streaming PS RAB request was specifically for
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
142 of 214
Ericsson UMTS Feature Guidelines
a 128 kbps bearer, the counter pmNoOfNonHoReqDeniedPsStr128 would be incremented, along with pmNoOfNonHoReqDeniedPsStreaming. High speed admission failures are also counted, as shown in Figure 28 and Figure 29. The performance counter pmNoOfNonHoReqDeniedHs is incremented when non-handover, failed admission request occurs for HSDPA.
Figure 29 - Ericsson Admission Control Flowchart (3 of 3) In addition to the circumstances listed above, there are additional counters for handover related admission requests. When the handover request triggers enhanced soft congestion, the counter pmNoOfSwDownNgHo is incremented. The fact that this counter was increased does not indicate that the down switch was successful, rather that a down switch was attempted. If the handover request is denied due to admission (whether soft congestion is triggered or not) the counter pmNoRlDeniedAdm is pegged.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
143 of 214
Ericsson UMTS Feature Guidelines
16. Congestion Control Congestion Control monitors the dynamic utilization of specific cell resources and insures that overload conditions do not occur. If overload conditions do occur, Congestion Control will immediately restrict Admission Control from granting additional resources. In addition, Congestion Control will attempt to resolve the congestion by either down switching, or terminating existing users. Once the congestion is corrected, the congestion resolution actions will cease, and Admission Control will be enabled.
16.1.Congestion Detection Three types of overload are monitored as part of Congestion Control.
UL overload measures the UL interference in a cell.
DL overload measured with the DL non-HSDPA transmitted carrier power
Dl HSDPA overload measured with the available DL transmitted carrier power for HSDPA
The consumption of downlink carrier power is dynamic, and can change after users are admitted into the cell. As users travel within the cell, or the RF environment changes, their downlink power requirements can increase and drive the cell into congestion. For the uplink case, the mobility of users outside of the cell can affect the RTWP, and trigger congestion. The other resources controlled by Admission Control (e.g. OVSF code usage, or ASEs) will not dynamically change without the admission criterion being met; therefore there is no need for Congestion Control to monitor these resources. The following sections will describe the different aspects of the Congestion Control algorithm, and the parameters and counters associated with them. In addition, impacts of parameter changes to system performance will be discussed.
16.1.1.
Uplink Cell Congestion
The detection of uplink cell congestion is exclusively based on the utilization of RTWP measurements. As “out of cell” users approach the cell, their uplink transmissions may contribute to the cell’s noise rise prior to soft handover occurring. In addition, Admission Control does not monitor RTWP when evaluating admission requests for users. Situations may occur when excessive cell loading occurs as users are admitted. Finally, the uplink transmit power of users within the cell is dynamic based on mobility, resulting in variable noise rise. The net result of these various conditions can contribute to high uplink interference and trigger Congestion Control. The thresholds that define when uplink congestion is triggered, as well as resolved, are provided in the figure below. Congestion is triggered when the uplink RTWP exceeds the threshold given by the parameter iFCong for a period of time equal to the parameter iFHyst. Once congestion is triggered, actions will be taken to reduce the uplink noise rise until the congestion is considered to be resolved. Congestion is resolved when the uplink RTWP drops below the threshold defined by the parameter iFCong, for a hysteresis time equal to the parameter iFHyst. Event based measurement reports from the Node B, for the uplink RTWP, are set up by NBAP signaling when a Node B is configured. The thresholds for these event based
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
144 of 214
Ericsson UMTS Feature Guidelines
measurements are defined by the Congestion Control parameters described in the previous paragraph. Event based measurement reports are triggered when the uplink RTWP of the cell exceeds the congestion threshold, for the defined hysteresis time. Once this event based measurement report is triggered, periodic reports follow until the RTWP drops below the congestion resolution threshold, for the defined hysteresis time. At this point, a final measurement report is sent to the RNC indicating that the congestion has been resolved. By using event based measurements, the Node B can quickly report to the RNC when congestion occurs, and when it is resolved.
Figure 30 - Congestion Thresholds for Uplink RTWP Typically, system capacity is not uplink limited and this feature can be disabled. In fact the default values for the parameters controlling uplink Congestion Control do indeed disable the feature. By setting the parameter iFCong = -49.9 dBm, it is highly unlikely that uplink congestion will ever be triggered. The side effect of disabling this feature is the increased potential of cell breathing which may, or may not be an issue. If it is determined that system performance is being impacted by cell breathing, enabling the uplink congestion algorithm may be required. When configuring these parameters, the source of uplink noise must be considered. To begin with, thermal noise (i.e. kTB = -107.5 dBm) defines the best case value of RTWP. Added to this is the cascaded noise figure for the uplink path. This cascaded noise figure is based on the individual gain and noise figures of each stage of the uplink path (e.g. TMA, feeder loss, Node B LNA, etc.). This can be derived from TMA and Node B specifications, and results for antenna sweeps. Finally, the noise rise due to loading needs to be added. The target loading factor is typically defined in uplink link budgets, and is a function of the calculated pole capacity.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
145 of 214
Ericsson UMTS Feature Guidelines
Alternatively, another method to tune these parameters would employ the unloaded cellâ&#x20AC;&#x2122;s RTWP measurement to define a baseline; and then apply the designed noise rise due to loading (i.e. loading factor) to define the congestion threshold. The hysteresis iFHyst should be long enough to ignore short term spikes in RTWP.
16.1.2.
Downlink Cell Congestion
The detection of downlink cell congestion is based on the utilization of downlink transmitted carrier power. Although the allocation of this resource is controlled by Admission Control, the mobility of users within the cell is dynamic. As users move away from the cell, the power required for their dedicated channel is increased by the power control algorithm. This mobility can result in an overload situation for the downlink transmitted carrier power and trigger Congestion Control. The thresholds that define when downlink congestion is triggered, as well as resolved, are provided in the figure below. Congestion is triggered when the downlink carrier power exceeds the threshold equivalent to the summation of the parameters pwrAdm and pwrOffset (or pwrAdm + pwrOffset), for a period of time equal to the parameter pwrHyst. Once congestion is triggered, actions will be taken to reduce the downlink transmitted carrier power until the congestion is considered to be resolved. Congestion is resolved when the downlink carrier power drops below the threshold defined by the summation of the parameters pwrAdm, pwrOffset (or pwrAdm + pwrOffset), for a hysteresis time equal to the parameter pwrHyst. Event based measurement reports from the Node B, for the downlink transmitted carrier power, are set up by NBAP signaling when a Node B is configured. The thresholds for these event based measurements are defined by the Congestion Control parameters described in the previous paragraph. Event based measurement reports are triggered when the total downlink power of the cell exceeds the congestion threshold, for the defined hysteresis time. Once this event based measurement report is triggered, periodic reports follow until the carrier power drops below the congestion resolution threshold, for the defined hysteresis time. At this point, a final measurement report is sent to the RNC indicating that the congestion has been resolved. By using event based measurements, the Node B can quickly report to the RNC when congestion occurs, and when it is resolved.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
146 of 214
Ericsson UMTS Feature Guidelines
Figure 31 - Congestion Thresholds for Downlink Transmitter Carrier Power
16.1.3.
DL HSDPA Cell Congestion
DL HSDPA overload is detected when the DL Non-HSDPA power + HS-required DL power is greater than 100% utilization for a time period equal to the parameter maxPowerOverloadHystTime.
Figure 32: DL HSDPA congestion
16.2. Resolution of Congestion Once congestion is detected, due to downlink carrier power or uplink RTWP, Congestion Control takes actions to resolve the congestion. The first action taken is to limit additional
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
147 of 214
Ericsson UMTS Feature Guidelines
admissions to the cell. If congestion was triggered by downlink transmitted carrier power, all admissions are blocked until the congestion is resolved. Alternatively, if congestion is triggered by uplink RTWP, only non-handover admissions are prevented. Admission requests due to handover are allowed, for the uplink congestion case, because the user is likely a contributor of the uplink interference and admission to the cell will improve the situation. Note that blocking the admission of new users is the only action taken by Congestion Control when uplink congestion is triggered. When downlink congestion is detected, actions will be taken to resolve the issue. Congestion Control will achieve this by periodically releasing the amount of resources utilized by users in the cell. The amount of resources released periodically will be based on downlink air interface speech equivalents (ASEs). The users targeted will be based on their service class, as well as their specific resource consumption. The connections with the highest ASE in downlink are targeted first, if they have the same priority. The connections are targeted in order of ARP priority, ignoring the pre-emption vulnerability setting. After detection of overload, an immediate action is taken to release releaseAseDlNg of ASEs in downlink for non-guaranteed service class connection in order of priority and the timer tmInitialG is started. If after the initial congestion resolve action there are non-guaranteed service class connections remaining in the cell and the congestion situation persist, the release of ASEs in downlink is repeated with the period tmCongActionNg. In case the overload situation remains after all the ASEs in downlink of the non-guaranteed service class connections are released and the timer tmInitialG is expired, timer tmCongAction is started. Then, releaseAseDl amount of ASEs in downlink for guaranteed service class connections are released in a periodical fashion until the congestion situation in the downlink is resolved.
Figure 33 - Resolution of Downlink Congestion
16.3. Counters Related to Congestion Control Tracking performance statistics or counters allow monitoring and troubleshooting UTRAN system performance. The counters specifically related to Congestion Control can be utilized to tune parameter settings, or trigger capacity/dimensioning related actions. The counters described in this section include some of the more important counters related to Congestion Control. For a complete list of performance counters, refer to the Ericsson RNC Performance Management documentation [14]. The flowchart for the counters related to the detection of downlink congestion is provided in the figure below. As the flowchart indicates, the counter pmSumOfTimesMeasOlDl is
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
148 of 214
Ericsson UMTS Feature Guidelines
incremented when a NBAP common measurement report is received from Node B indicating that the non-HS downlink transmitted carrier power is above the congestion threshold. Note that this counter is not incremented by the reception of the periodic measurement reports that follow the initial congestion report. This counter only pegs once for each downlink congestion occasion. The total amount of time a cell is downlink congested (in seconds) is provided by the counter pmTotalTimeDlCellCong. This counter is incremented once every second the cell remains in the downlink congested state.
Figure 34: Ericsson Counter Flowchart for DL Congestion Detection (HS cell) The flowchart for the counters related to the detection of HSDPA overload is shown in the figure below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
149 of 214
Ericsson UMTS Feature Guidelines
Figure 35: Ericsson Counter Flowchart for HSDPA overload Detection (HS cell) The flowchart for the counters related to the detection of uplink congestion is provided in the figure below. As the flowchart indicates, the counter pmSumOfTimesMeasOlUl is incremented when a NBAP common measurement report is received from Node B indicating that the uplink RTWP is above the congestion threshold. Note that this counter is not incremented by the reception of the periodic measurement reports that follow the initial congestion report. This counter only increases once for each uplink congestion occasion. The total amount of time a cell is uplink congested (in seconds) is provided by the counter pmTotalTimeUlCellCong. This counter is incremented once every second the cell remains in the uplink congested state.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
150 of 214
Ericsson UMTS Feature Guidelines
Figure 36 â&#x20AC;&#x201C; Ericsson Counter Flowchart for UL Congestion Detection The actions taken for congestion resolution of non-guaranteed users are illustrated in the 3 figures below. If non-guaranteed users are down switched to common channels (non-Iur case) the counter pmNoOfSwDownNgCong is incremented by a number equal to the number of users affected. On the other hand, non-guaranteed users with an Iur connection (drift RNC) will increment pmNoOfIurSwDownNgCong accordingly. These figures also illustrate at what points the timers tmInitialG, and tmCongActionNg are started.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
151 of 214
Ericsson UMTS Feature Guidelines
Figure 37 - Resolution of Congestion (1 of 3)
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
152 of 214
Ericsson UMTS Feature Guidelines
Figure 38 - Resolution of Congestion (2 of 3)
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
153 of 214
Ericsson UMTS Feature Guidelines
Figure 39: Resolution of Congestion (3 of 3)
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
154 of 214
Ericsson UMTS Feature Guidelines
17. Power Control This section deals with the Power Control algorithms and parameters related to the Ericsson 3G RAN.
17.1.Importance of Power Control Any WCDMA system is limited by interference and it is important to minimize the interference level, since the lower the interference, the better the network capacity is. The intent of Power control is to allow as many users as possible into the WCDMA network, while keeping the interference caused by these users to a minimum. Power control aims at using the minimum signal to interference ratio (SIR) required for the quality of the connection to remain sufficient. Power control provides protection against large changes in shadowing, immediate response to fast changes in signal and interference levels. It is also needed to cope with the near-far problem found in WCDMA systems, and to bring the SIR back close to the target SIR as fast as possible after each transmission gap in compressed mode. The two main capabilities of Power Control in a WCDMA system are as follows:
To maintain the quality of connections (including common channels needed, for example, for call access)
To minimize the transmitted power in both uplink and downlink
Power Control works on a connection basis.
17.2.Overall Power Control Procedure There are three different types of power control in UMTS Open Loop: Open Loop power control is used when no feedback mechanism is possible. An estimate of the required power is made from measurements and system information. This is used for initial network access and finding initial power settings during dedicated mode. Closed Inner Loop: This power control technique uses a fast feedback mechanism to request an increase or decrease in output power based on the difference between the target and measured SIR. The feedback is provided via Transmit Power Control (TPC) bits on the DPCCH channel 1500 times per second. Inner loop power control exists in both the uplink and downlink. Closed Outer Loop: Outer loop power control is used to set the target SIR that is used during inner loop power control. For downlink power control this is set in the UE by an algorithm that is proprietary to the UE manufacturer. For uplink power control it is set by the RNC. The key difference between closed and open loop is the feedback cycle. Closed loop relies on feedback from the receiving node to adjust the power at the transmitting node. Open loop has no feedback on the amount to increase or decrease it’s transmit power.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
155 of 214
Ericsson UMTS Feature Guidelines
UMTS Power Control
Open Loop Power Control
Closed Loop Power Control
Power control during initial network access Inner Loop
Outer Loop
Fast power control for compensation of signal fluctuations
Slow power control for ensuring the desired signal power level
17.3.Power Control of downlink common channels This section outlines how the different downlink common channels handle Power Control. The following downlink common channels are not subject to dynamic Power control as they are required to cover the entire coverage area of the cell. The transmission powers of these channels are determined during radio network planning. Refer to [2] for the actual values. PCPICH: The transmission of the PCPICH determines the actual cell size. Its power primaryCpichPower is set to an absolute value, and the power level of every other downlink channel is expressed as an offset relative to it. PCCPCH: The PCCPCH carries the broadcast channel (BCH), which is broadcast time multiplexed with the SCH. The last 2304 chips of every slot transmit the PCCPCH. The parameter bchpower determines the power and is expressed as on offset of the PCPICH power. SCH: The SCH consists of a primary SCH (P-SCH) and a secondary SCH (S-SCH), used in the cell search procedure in the UE. Their powers are set as primarySchPower for P-SCH and secondarySchPower for S-SCH, and are expressed as offsets of the PCPICH power. AICH: The AICH carries the acquisition indication (AI), which is the response to the PRACH preambles. The AICH is not continuously broadcast in the cell. Its power is set by the parameter aichPower and is expressed as an offset relative to the PCPICH power. SCCPCH carrying FACH: When the SCCPCH carries the FACH transport channel, one of 2 parameters determines the power depending on the logical channels carried by the FACH. If the FACH frame carries a logical control channel (BCCH, CCCH, DCCH), the power is set through parameter maxFach1Power. If the FACH frame carries a logical traffic channel DTCH (in the case of CELL_FACH state), the power is then set through the parameter maxFach2Power. These are both expressed as offsets relative to the PCPICH power. The SCCPCH uses discontinuous transmission (DTX) to halt power transmission when there is no payload. Additional offset for the TFCI field of the SCCPCH carrying FACH frame can set
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
156 of 214
Ericsson UMTS Feature Guidelines
with the parameter pOffset1Fach and for the pilot field can be set as pOffset3Fach, which are relative to the power on the payload. SCCPCH carrying PCH: The parameter pchPower sets the power level, expressed as an offset relative to the PCPICH power. The SCCPCH uses discontinuous transmission (DTX) to halt power transmission when there is no payload. PICH: The PICH carries the paging indicators, which tell UEs belonging to specific paging groups to listen to the paging channel. The PICH power is set by the parameter pichPower, relative to the PCPICH power.
17.4.Open Loop Power Control (Power Control of uplink common channels) Need for Open Loop Power Control: The power control of the uplink control channels is done using the Open Loop Power control method. Uplink open loop power control is controlled by the UE. In a UMTS network, the UE always initiates the RRC connection setup procedure. This is applicable for mobile terminating calls (MTC) also in which case the network pages the UE, telling it to establish an RRC connection. The UE does this using the random access procedure. Before it initiates the random access procedure, the UE has to determine how much power it has to use in the uplink. If a UE uses a fixed power level for random access, and if it happens to be close to the BTS, then it would block out messages from the UEs farther away. Therefore the UE must always use the lowest possible transmission power. The goal of power control during call setup is for the UE to transmit the minimum amount of power required to access the network. At this time the UE does not know the power required to reach the system, so it estimates the initial preamble power (based on broadcast information and downlink measurements). If there is no acknowledgement from the RBS to this initial request (via acquisition indication sent by the RBS), the UE will increase its power based on predefined increments and retransmissions until it is heard. This procedure is known as ‘Power Ramping’ and because of the limited feedback provided by the network is termed ‘Open Loop Power Control’. The UE uses an equation to estimate the initial preamble transmit power on the Physical Random Access Channel (PRACH), based on CPICH received power and System Information (broadcast in the cell). P_PRACH = PCPICH DL Tx Power – CPICH_RSCP+UL Interference +constantValueCprach Where
P_PRACH
Power of the first preamble on the PRACH
PCPICH DL Tx Power
Primary CPICH transmit power (sent in SIB5)
CPICH_RSCP
Received CPICH RSCP measured by UE
UL Interference
UL Interference measured by RBS and broadcast by BCH
constantValueCprach
configurable parameter in object Rach used by the UE to calculate the initial power on the PRACH (SIB5)
(SIB7)
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
157 of 214
Ericsson UMTS Feature Guidelines
CPICH >> RSCP System Info >> BCCH >> P-CCPCH
UE measures CPICH RSCP and receives network parameters in the System Information (SIB) messages
CPICH DL Tx Power UL Interference Constant Value Power Ramp Step Preamble Retrans Max
P_PRACH = CPICH DL Tx Power â&#x20AC;&#x201C; CPICH_RSCP + UL Interference + Constant Value (+ Power Ramp Step)
UE uses a formula to calculate the initial transmit power, and increases the power each retry by Power Ramp Step
Once the first preamble is transmitted the UE monitors the Acquisition Indication Channel (AICH) to see if an Acquisition Indicator (AI) has been sent. The system will send an Acquisition Indicator only if the preamble has been received. If there is no Acquisition Indicator received on the AICH, the UE will transmit another preamble with an increased power, increasing the transmission power with respect to the previous preamble power by a parameter powerOffsetP0. It will continue to increase the preamble power until it is successfully received by the system and an Acquisition Indicator is received. If the preamble sequence finishes before an Acquisition Indicator is received, the UE may repeat the preamble sequence. If the preamble is not received by the network and the entire sequence has been completed, the call setup will be counted as an access failure. Once the Acquisition Indicator is received, the UE sends the PRACH message part that contains the internal details about the desired connection to the radio network. The power of the control part of the PRACH message is determined by the power of the last transmitted preamble and by an offset configurable by the parameter powerOffsetPpm. The power of the data part of the PRACH message is determined by the gain factors for PRACH, which is included in the System information. Preamble ramping does not go on indefinitely. The maximum number of steps in each preamble ramping cycle is set by the configurable parameter preambleRetransMax. When this maximum is reached, a new preamble ramping cycle is attempted. The maximum number of preamble ramping cycles before the access attempt is aborted is set by the configurable parameter maxPreambleCycle.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
158 of 214
Ericsson UMTS Feature Guidelines
17.5.Power Control of Dedicated channels The power control of dedicated channels is performed by a combination of the Outer loop power control and the inner loop power control procedures. Outer Loop power control adjusts the target SIR in the BTS according to the needs of the individual radio links and aims at constant quality, defined in terms of a certain block error rate (BLER). This target SIR is signaled to the inner loop power control, which is then used to compare against the received SIR by the BTS and the UE. In the Inner loop power control, the BTS and UE continuously compare the SIR of the received signal to the target SIR value for a particular connection. Based on this they tell each other to increase or decrease the transmission power. The inner loop power control can vary the transmission power from one slot to another. And since a WCDMA frame consists of 15 slots in a 10 ms duration, the inner loop power control can be performed at a maximum rate of 1500 times per second. Hence inner loop power control is also called fast closed loop power control. The overall power control procedure of dedicated channels is shown in the figure below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
159 of 214
Ericsson UMTS Feature Guidelines
The following sections detail the different steps involved in the outer loop and inner loop power control procedures.
17.5.1.
Initial Downlink Power Setting
RNC calculates initial DL power for dedicated channels (DPDCH/ DPCCH) and sends to RBS
UE RNC
RBS
An initial transmit power setting for the downlink dedicated channels (DPCCH/DPDCH) is calculated by the RNC and sent to the RBS utilizing open loop power control. This initial setting is intended to ensure a reliable radio connection setup while minimizing the impact on existing connections.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
160 of 214
Ericsson UMTS Feature Guidelines
The following equation is used to determine the initial power setting for the dedicated physical data channels (DPDCH). primaryCPI CHPower + (dlInitSirT arg et - PCPICH _ EcNo ) + P _ DL _ DPDCH =
cBackOff + 10 log
2 SF _ DL _ DPDCH
where P_DL_DPDCH is the Initial power setting for the Dedicated Physical Data Channel (DPDCH)
primaryCpichPower is the downlink output power used for the PCPICH in the cell where the connection is set up
PCPICH_EcNo is the measured Ec/No on PCPICH in the cell where the connection is set up, received from the UE.
dlInitSirTarget is the required initial SIR target for the downlink DPDCH. SF_DL_DPDCH is the Spreading Factor for the downlink DPDCH.
cBackOff is a configurable parameter to adjust the Open Loop Power Control estimate for the initial transmit power level on DPDCH. It can either back off the open loop power control estimate to a more conservative starting point or to increase the initial downlink power to improve the call setup reliability.
In the case of IRAT handover where there is no measured Ec/No, the system uses a default setting for Ec/No configured by the parameter ecNoPcpichDefault. This parameter should be set to a value typically seen at the cell edge. This is recommended to -14 dBm as per [2] for cell edge coverage value. The initial power setting for the dedicated control channels (DPCCH) is calculated using the following equations. P_DL_DPCCH_TFCI = (P_DL_DPDCH + pO1) P_DL_DPCCH_TPC = (P_DL_DPDCH + pO2) P_DL_DPCCH_PILOT = (P_DL_DPDCH + pO3) where P_DL_DPCCH_TFCI is the Initial output power for the DPCCH TFCI field.
pO1 is the power offset between the data field and the TFCI field of the downlink DPCCH, expressed in dB. This offset is constant, regardless of the service. P_DL_DPCCH_TPC is the initial output power for the DPCCH TPC field.
pO2 is the power offset between the data field and the TPC field of the downlink DPCCH, expressed in dB. This offset is constant, regardless of the service. P_DL_DPCCH_PILOT is the initial output power for the DPCCH Pilot field.
pO3 is the power offset between the data field and the Pilot field of the downlink DPCCH, expressed in dB. This offset is the same regardless of the service. The values of the parameters discussed above are shown in the table below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
161 of 214
Ericsson UMTS Feature Guidelines
The main reason for recommending a higher offset for pO2 when compared to pO1 and pO3 is that the TPC commands received from different RBSs are subject to logical combining in the UE. Consequently, the TPC command from each RBS must be decoded before being combined, whereas the user data, Pilot bits, and TFCI bits can be combined before decoding. To allow reliable decoding of TPC commands, it is advisable to increase their power with respect to the other fields of the DPCCH.
17.5.2.
Downlink Power Limits
RNC calculates max and min DL power limits and sends to RBS
RNC
RBS
UE
In power control systems there must be maximum and minimum limits for how much power can be transmitted. Maximum Downlink Transmitted Code Power: In the downlink, the maximum allowable transmit power is dependant upon the radio connection type, specifically the maximum data rate of the radio link. This is set on a per cell basis using a combination of parameters.
minPwrMax & minimumRate This sets the maximum transmit power (relative to CPICH)
for any services requiring minimumRate data transfer rates or less
interPwrMax & interRate
This is used to adjust the slope between minPwrMax and maxPwrMax. Any service that requires data transfer rates great than minRate and less than maxRate will be interpolated on this slope.
maxPwrMax & maxRate
This sets the maximum transmit power (relative to CPICH) for any services requiring maxRate data transfer rates or greater
The following table provides the maximum radio link data rate for different services. Radio Connection Type
T-Mobile USA, INC. Confidential
Maximum Radio Link Rate
Rev. 3.0
Sep 11, 2008
162 of 214
Ericsson UMTS Feature Guidelines
PS384/HS
3700
SRB
14800
AMR 12.2
15900
CS64
67700
PS64/64
70900
MultiRAB (CS64 + PS8/8)
76100
PS64/384
406900
Using the above table and the limits base on radio link data rates, the RNC calculates the max DL transmit power and sends it to the RBS. The following graph provides an example of the mapping of these parameters. Ericsson default parameters have been included in this example.
Minimum Downlink Transmitted Code Power: If the power of a radio link is very low, it is very sensitive to the impact from interference changes. To avoid this, the minimum downlink transmitted code power is set using the configurable parameter minPwrRl which is relative to the CPICH Tx Power.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
163 of 214
Ericsson UMTS Feature Guidelines
17.5.3.
Initial Uplink Power Setting
RNC Calculates DPCCH_POWER_OFFSET and sends to UE
DPCCH_POWER_OFFSET
UE RNC
RBS UE uses DPCCH_POWER_OFFSET and CPICH RSCP to determine initial UL DPCCH Power
The initial uplink power is set in a similar way to setting the initial downlink power by utilizing open loop power control. The power of the uplink dedicated physical control channel (DPCCH) is first set using the following equation. Power_UL_DPCCH_INIT = DPCCH_POWER_OFFSET - RSCP_PCPICH Where RSCP_PCPICH is the Received Signal Code Power (RSCP) measured on the PCPICH DPCCH_POWER_OFFSET = primaryCpichPower + RTWP + ulInitSirTarget - 10 log (SF_DPCCH) + cPO where
primaryCpichPower is the downlink power used for the PCPICH. If the serving RNC is not aware of the power on the PCPICH when another physical RNC controls the cell, it uses a configured default value pcpichPowerDefault, which is used only for this calculation. RTWP is the Received Total Wideband Power (uplink interference) level measured by the RBS.
ulInitSirTarget is the Initial value for the Uplink SIR Target, defined according to the minimum Spreading Factor (SF) of the uplink Dedicated Physical Data Channel (DPDCH): SF_DPCCH is the Spreading Factor for the DPCCH.
cPO is a parameter to set the uplink DPCCH power offset to a conservative level to avoid excessive UL interference DPCCH_POWER_OFFSET is calculated in the RNC and sent to the UE via the ul-DPCHPowerControlInfo part of the RRC Connection Setup (DL-CCCH) message. The initial uplink power in DPDCH is then determined from the initial uplink DPCCH power according to the relative power offsets between DPCCH and DPDCH (gain factor, as described in 3GPP TS 25.214). The UTRAN determines and sends to the UE the gain factor
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
164 of 214
Ericsson UMTS Feature Guidelines
for the reference Transport Format Combination (TFC) only. The UE, in turn computes the gain factors for other TFCs, based on the reference TFC.
17.5.4.
Initial Uplink SIR Target Setting
Initial Uplink SIR Target is a configurable parameter defined according to the minimum Spreading Factor (SF) of the uplink Dedicated Physical Data Channel (DPDCH). The following parameters are used to configure the initial uplink SIR target for different scenarios.
ulInitSirTargetSrb: Used for stand-alone SRB, i.e. RRC connection setup, Inter-RAT handover and common to dedicated(SRB) RAB release,
ulInitSirTargetLow: Used for RABs having minimum DPDCH SF equal to or higher than 32.
ulInitSirTargetHigh: Used for RABs having minimum DPDCH SF equal to 16 or 8. ulInitSirTargetExtraHigh: Used for RABs having minimum DPDCH SF equal to or lower than 4.
17.5.5.
Uplink Outer Loop Power Control
The purpose of outer loop power control in the uplink is to define the SIR target that the UE will attempt to maintain. By adjusting the SIR target, and consequently the transmission power levels, the outer loop power control aims at providing the required quality. Too high quality would waste the system capacity, so the goal is to use as little power as possible. The RNC uses the quality of the DPCCH to determine if the SIR target needs to be increased or decreased, and sends the new target to the RBS. Since AMR voice CRCs are received on 20 ms TTI boundaries, the fastest this outer loop power control method can be adjusted is 50 times a second. The RNC can use two methods to determine the new SIR target:. The parameter ulOuterLoopRegulator determines whether to use Constant Step Regulator or Jump Regulator. The default setting is Jump Regulator.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
165 of 214
Ericsson UMTS Feature Guidelines
The initial uplink SIR targets are determined by the parameters ulInitSirTargetLow, ulInitSirTargetHigh or ulInitSirTargetExtraHigh depending on the spreading factor of the DPDCH. There are limits set for the maximum and minimum SIR targets. These are set using the parameters sirMax and sirMin. Constant Step Regulator Whenever the Cyclic Redundancy Check (CRC) indicates that the reception of a transport block is erroneous, the uplink SIR target is increased by configurable increment ulSirStep, expressed in dB. Whenever NBR_OF_CRC_OK consecutive transport blocks are correctly received, the uplink SIR target is decreased by an equal step. The number of consecutive correct transport blocks needed to trigger a decrease of the uplink SIR target depends on the BLER target.
Jump Regulator The Jump Regulator increases the uplink SIR target by a configurable increment ulSirStep, expressed in dB, whenever a transport block is erroneously received. When a block is correctly received, the uplink SIR target is decreased by a fraction of ulSirStep. This fraction, denoted UP_DOWN_STEP_RATIO, depends on the BLER target.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
166 of 214
Ericsson UMTS Feature Guidelines
If several transport blocks are received in one Transmission Time Interval (TTI), the change in the uplink SIR target will be based on the accumulated change individually caused by each of the transport blocks. To reduce the variations of the uplink SIR target, the change of uplink SIR target is always scaled by the number of transport blocks received in the corresponding TTI, as SIRtarget_new = SIRtarget + ulSirStep [-X/(Z*UP_DOWN_STEP_RATIO)+Y/Z] where Z is the total number of received transport blocks. X is the number of transport blocks that have a CRC=OK. Y is the number of transport blocks that have a CRC=NG
17.5.6.
Downlink Outer Loop Power Control
The downlink outer loop power control is taken care by the UE using its own proprietary algorithm. The SIR target is set according to an autonomous function in the UE in order to achieve the same measured quality as the quality target set by the RNC. The quality target is set as the transport channel BLER value and signaled by the RNC to the UE. This resultant SIR target is used by the UE as an input to the downlink inner loop power control.
17.5.7.
Downlink Inner Loop Power Control
The UE power controls the RBS to maintain the call quality in the downlink. Based on the difference between the actual SIR and the target SIR, the UE will request the RBS to either increase or decrease its transmit power. The UE requests a power adjustment by sending a Transmit Power Control (TPC) command in every slot (1500 times per second). Actual SIR >= Target SIR ď&#x192;¨ UE sends Power Down command Actual SIR < Target SIR ď&#x192;¨ UE sends Power Up command
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
167 of 214
Ericsson UMTS Feature Guidelines
As soon as the RBS receives power control commands (TPC bits), it starts regulating the downlink power of the radio link according to these commands - increasing or decreasing the power by TPC equal to 0.5 dB (1.0 dB if the link is established over Iur).
17.5.8.
Uplink Inner Loop Power Control
Uplink inner loop power control uses a similar feedback method to downlink inner loop. The RBS sends power up or power down commands (TPC bits on the DPCCH) based on the difference between the target SIR and the measured SIR. The UE monitors the TPC bits on the DPCCH and increases or decreases its transmit power accordingly at the rate of 1500 times per second. The uplink transmit power is adjusted in steps of ±1dB. Actual SIR >= Target SIR RBS sends Power Down command Actual SIR < Target SIR RBS sends Power Up command
RBS compares measured SIR against target SIR (from UL outer loop PC) and determines if power up or power down is required
RBS requests power control adjustment in TPC command (1500 per second)
DPCCH/DPDCH sent with new power
UE RNC
RBS
UE monitors TPC commands sent in DPCCH and increases or decreases Tx power in steps ± 1dB
17.6.Power Control during Soft Handover During soft-handoff the UE has to manage power control to and from multiple RBSs. This is handled differently in both the uplink and downlink.
17.6.1.
Uplink power control during SHO
During uplink power control, the UE receives TPC bits from the RBS instructing it to either increase or decrease its transmit power. When the UE is in soft-handover it receives TPC bits from multiple RBSs at the same time. The received TPC bits from the different RBSs are independent from each other so there is a good chance that they will be different. The UE resolves this conflict using a simple rule: if any Node B commands the UE to reduce power, it will reduce power. This is called OR of the downs. The UE will increase the DPCCH power by 1 dB, only if all the RBSs in the active set send a power up command.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
168 of 214
Ericsson UMTS Feature Guidelines
TPC1
TPC2
UE RBS2
RBS1
Rule of the OR of the Down If any RBS requests the UE to power down, it will power down UE Tx Pwr (dB)
+1
-1
-1
+1
-1
-1
+1
-1
-1 Power Up
TPC1
Power Down Power Up
TPC2
Power Down
In the event of softer-handover, the UE should receive identical commands from the two cells. Knowing this, the UE â&#x20AC;&#x153;soft combinesâ&#x20AC;? the bits before making a decision on the value of the bit. Here, there is no OR of the downs. The reason is that if the signal is from two cells of the same Node B, the signal likely experiences the same general fading environment. The UE can tell whether two or more radio links are from the same Node B with the help of the TPC index.
17.6.2.
Downlink power control during Soft Handover
Initial Downlink power in Soft Handover During soft handover, the aim of power control is to equalize the power transmissions from the different RBSs, while compensating for differences in PCPICH power so that every signal is received with the same strength at the cell border. The first step in this process is to set the initial downlink power of the added radio link. The power for a radio link added through soft handover is initially set as
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
169 of 214
Ericsson UMTS Feature Guidelines
primaryCPI CHPower dlInitSirT arg et - EcNo _ PCPICH P _ DL _ DPDCH 2 cSho 10 log SF _ DL _ DPDCH
where P_DL_DPDCH is the Initial power setting for the Dedicated Physical Data Channel (DPDCH)
primaryCpichPower is the downlink output power used for the PCPICH in the cell where the connection is set up
EcNo_PCPICH is the measured Ec/No on PCPICH in the cell where the connection is set up, received from the UE.
dlInitSirTarget is the required initial SIR target for the downlink DPDCH. SF_DL_DPDCH is the Spreading Factor for the downlink DPDCH. cSho is a correction factor that takes into account the handover margin mSho and a configurable parameter initShoPowerParam Typically, a new radio link is added when the measured PCPICH Ec/No of the cell to be added is higher than the best PCPICH Ec/No of cells already having a radio link, lowered by a handover margin. It is desirable to let the different RBSs transmit the same power, but, due to handover margin (mSho), the received PCPICH Ec/No is lower in the new cell, resulting in a higher-than-required initial power. The correction factor cSho is used to compensate for this effect, ideally allowing every RBS in the active set to transmit the same downlink power. Its value is determined as a function of mSho, to which the configurable parameter initShoPowerParam is added. This parameter is mainly useful to help the UE in getting frame synchronization, in case high input signals are required by the base band processing. When entering soft handover, the downlink Inner Loop Power control of the existing branch is directly applied to the new branch. The initial power setting allows all branches to start with the correct power levels. Each RBS in the active set listens to the same sequence of TPC commands from the UE. However, due to the different radio conditions of the different soft handover links, the different TPC commands may be affected by different errors. Consequently, the transmitted power at different RBSs will start to drift, eventually leading to uncoordinated links. The Power Balancing mechanism prevents this power drift by using a modified type of power control during soft handover. Power Balancing: RNC calculates a single reference power based on the transmitted code power measured in each radio link, and periodically sends it to all the RBSs. Each RBS involved in soft handover makes synchronized adjustments of the downlink power of the
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
170 of 214
Ericsson UMTS Feature Guidelines
radio links according to the received reference power. This will result in the convergence of RBSs power levels and prevents the power drift. The Power balancing method works in conjunction with the downlink Inner Loop Power control based on the setting of the parameter dlPcMethod. If dlPcMethod is set to FIXED, both Power balancing and downlink Inner Loop Power control are disabled and the downlink power is kept at a constant level set by the parameter fixedPowerDL during the call. If dlPcMethod is set to NO BALANCING, downlink Inner Loop Power control is active, but Power Balancing is disabled. If dlPcMethod is set to BALANCING, downlink Inner Loop Power control is always active and Power Balancing runs in parallel with downlink Inner Loop power control when more than one radio link is involved. If dlPcMethod is set to FIXED BALANCING, downlink Inner loop power control is active as long as only one radio link is involved. As soon as an additional radio link is added to the active set, downlink inner loop power control is disabled, and Power balancing is activated; the downlink power stays at the configurable parameter fixedRefPower as long as the active set includes multiple radio links. The power control mechanism in a soft handover scenario is shown in the figure below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
171 of 214
Ericsson UMTS Feature Guidelines
17.7.Power Control during Compressed Mode 17.7.1.
Uplink Power Control in Compressed Mode
Power Control in uplink Compressed Mode aims at recovering the SIR target as quickly as possible after each transmission gap, in order to avoid block errors during and after the compressed frames. To achieve this recovery, the uplink Inner Loop Power Control increases the SIR target. The active set cells estimate the SIR value of the received uplink DPCCH, generate TPC commands, and transmit them one per slot, except during downlink transmission gaps, according to the following rule: If estimated SIR
SIR cm_target, the RBS sends a down command.
If estimated SIR < SIRcm_target, the RBS sends an up command. SIRcm_target is the target SIR during Compressed Mode, which is increased to compensate for the interruption in the Power Control due to transmission gaps, as well as for differences in the number of pilot bits in the uplink DPCCH. Compressed and non-compressed frames in the uplink DPCCH can have a different number of pilots per slot. The total number of transmitted slots in compressed frames is decreased, but the same number of bits as in a non-compressed frame must be sent. To accomplish this, some of the pilot bits are replaced with TFCI bits. The total pilot energy per slot should nevertheless be maintained, implying that an additional PILOT needs to be added to the transmitted uplink power. PILOT
= 10Log10 (N pilot,prev /N pilot,curr );
where N pilot,prev and Npilot,curr represent the number of pilot bits in the most recently transmitted slot and in the current slot respectively. Thus, the received SIR per slot will increase correspondingly, and so as not to misinterpret this as improved channel conditions, the SIR target is increased by SIR PILOT: SIR PILOT = 10Log10 (Npilot,N /N pilot,currframe ); where N pilot,N and Npilot,currframe represent the number of pilot bits per slot in a normal uplink frame (without transmission gap) and in the current uplink frame respectively.
17.7.2.
Downlink Power Control in Compressed Mode
Power Control in downlink Compressed Mode aims at recovering the SIR target as quickly as possible after each transmission gap, in order to avoid block errors during and after the compressed frames. To achieve this recovery, the Power Control increases the downlink power, and the RRC signaling increases the downlink SIR target used by the Power Control algorithm in the UE. In compressed frames, the transmission of downlink DPDCH and DPCCH stops during transmission gaps. Downlink Inner Loop Power Control is not active during the transmission gap. In every slot in Compressed Mode, except during downlink transmission gaps, UTRAN estimates the k-th TPC command and adjusts the current downlink power P(k-1) [dB] to the new value P(k) [dB], according to the following formula:
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
172 of 214
Ericsson UMTS Feature Guidelines
P(k) = P(k - 1) + PTPC(k) + PSIR(k) + P bal(k) where PTPC (k) is the k-th power adjustment due to the Inner Loop Power Control PSIR (k) is the k-th power adjustment due to the downlink SIR target variation Pbal (k) [dB] is the correction due to the Power Balancing Due to transmission gaps in uplink compressed frames, uplink TPC commands might be missing. If none is received, PTPC(k), derived by the Node B, is set to zero. Otherwise, PTPC(k) is calculated in the same way as in normal mode, but applying a step size STEP instead of TPC. STEP is set equal to 2 TPC during the slots belonging to the Recovery Period, after each transmission gap, and to TPC otherwise. The Recovery Period Length (RPL) is expressed as a number of slots, and is equal to MINIMUM(transmission gap length, 7). Refer to the ‘Compressed Mode’ section earlier in this document for details on the compressed mode feature. In Compressed Mode, the transmitted DPDCH power does not exceed the maximum transmission power by more than the accumulated effect of P SIR(k).
17.8.Power Control Scenarios 17.8.1.
Power Control steps for Radio Link Setup Procedure
When a dedicated radio link is established, the following power control actions are performed.
Set Initial Downlink Power
Set Downlink Power Limits
Set Initial Uplink Power
Set Initial Uplink SIR Targets
Start Uplink Outer Loop Power Control
Start Downlink Inner Loop Power Control
Start Uplink Inner Loop Power Control
The details of each of these actions are covered in the previous sections.
17.8.2.
Power Control steps for RAB Establishment
When a RAB is added to the existing connection, the following actions related to Power Control are taken.
Set Downlink Power Limits
Downlink Inner Loop Power Control is already running and no changes are made as a result of the addition of the service. Any requirements for increased power is handled through the regular downlink power updates ordered through the TPC commands sent on the uplink Dedicated Physical Control Channel (DPCCH).
Set Initial Uplink SIR Target
Start Uplink Outer Loop Power Control
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
173 of 214
Ericsson UMTS Feature Guidelines
17.8.3.
Uplink Inner Loop Power Control is already running, and no changes of the uplink DPCCH Power are made as a result of the addition of the service. Any requirements for increased power are handled through the regular uplink power updates ordered through the TPC commands sent on the downlink DPCCH.
Power Control steps for Soft Handover
When a radio link is added to the active set, the following actions related to Power Control are taken:
Set Initial Downlink Power
Set Downlink Power Limits
Start Power Balancing
Upon radio link addition, no Power Control actions are initially needed for the uplink, since the UE is already power controlled by the existing radio links. As soon as the added radio link obtains uplink synchronization, the RBS issues Power Control commands based on the SIR estimates for uplink Inner Loop Power Control. In case of softer handover, the instantaneous power level is copied from the existing to the new radio link. When a radio link is removed from the active set, no Power Control actions are taken, except for stopping Power Balancing when the soft handover ends.
17.9.Example of Power Control Procedure The following figure shows the steps involved in the power control procedure for the establishment of a speech call, followed by a soft handover. Each box in the figure represents NBAP/RRC procedure or power control action described in the above subsections.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
174 of 214
Ericsson UMTS Feature Guidelines
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
175 of 214
Ericsson UMTS Feature Guidelines
18. UE States In UMTS, a UE is said to be in idle mode when it has no RRC connection with the RNC. An RRC connection is a logical connection between UE and RAN used by two peer entities to support the upper layer exchange of information flows. A UE can have only one RRC connection. Several upper layer entities use the same RRC connection. A UE in RRC connected state can be in one of 4 states – CELL_DCH, CELL_FACH, CELL_PCH and URA_PCH. In the Ericsson implementation, the CELL_PCH state is not supported and is not covered in the rest of the document. The remaining 4 states are shown in the figure below.
Connected Mode
URA_PCH
Cell_DCH
Cell_FACH
Idle Mode
Figure 40: UE States in Ericsson UTRAN Each of these UE states is covered in detail below.
18.1.Cell_DCH The CELL_DCH state is characterized by:
A dedicated physical channel is allocated to the UE in uplink and downlink.
The UE is known on cell level according to its current active set.
The CELL_DCH-state is entered from the Idle Mode through the setup of an RRC connection, or by establishing a dedicated physical channel from the CELL_FACH state. In this state the UE is allocated a DCH/E-DCH (Dedicated Transport Channel) or HS-DSCH (Common Transport Channel). The logical channel DCCH (Dedicated Control Channels) is
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
176 of 214
Ericsson UMTS Feature Guidelines
used for control signaling and DTCH (Dedicated Traffic Channels) is used for user data transmission. They are mapped onto the Transport channels and further multiplexed onto Dedicated Physical Channels.
18.1.1.
CELL_DCH to CELL_FACH state
Switching from a dedicated transport channel to the common transport channels on RACH/FACH when the traffic volume is low makes better use of dedicated radio resources. It allows other users to take advantage of the unused resources. This switch is triggered by inactivity (uplink and downlink combined) and applies to all CELL_DCH rates including DCH/DCH, DCH/HS and EUL/HS. It is initiated by the S-RNC based on RLC throughput measurements and is triggered by the Dedicated to Common Evaluation algorithm (covered in the later section).
18.2.Cell_FACH The CELL_FACH state is characterized by:
No dedicated physical channel is allocated to the UE.
The UE continuously monitors a FACH in the downlink
The UE is assigned a default common or shared transport channel in the uplink (e.g. RACH) that it can use anytime according to the access procedure for that transport channel
The position of the UE is known by UTRAN on cell level according to the cell where the UE last made a cell update.
Cell Update In CELL_FACH state, the Cell Update procedure is used to keep the UTRAN informed about the UEs location on a cell level. Cell Update is initiated in the following cases when a UE is in the CELL_FACH state:
A UE in state CELL_FACH enters a new cell.
As part of a supervision mechanism, Cell Update is performed periodically by UEs in state CELL_FACH. The periodicity is controlled by the timer t305.
If a UE in state CELL_FACH re-enters the service area after having been out of coverage when a periodic Cell Update should have been sent.
UE in state CELL_FACH detects RLC unrecoverable error in an AM RLC entity.
In the CELL_FACH state, the UE is able to transmit control signals and data packets on the common transport channel RACH in the uplink direction and on the FACH in the downlink direction. A maximum of 32 kbps is available on downlink for user data transmission.
18.2.1.
CELL_FACH to CELL_DCH
A transition occurs, when a dedicated physical channel is established via explicit signaling. When the traffic volume of a UE on CELL_FACH state increases, it is switched to the 64/64, 64/HS or EUL/HS state if there are resources available. This is to better serve the needs of the UE and to keep the common channels available to others that require only small amount of resources. This switch is triggered by the Common to Dedicated Evaluation algorithm based on buffer load measurements made in the S-RNC and in the UE.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
177 of 214
Ericsson UMTS Feature Guidelines
18.2.2.
CELL_FACH to URA_PCH
A UE on CELL_FACH is switched down to URA_PCH if it shows no activity for a long period of time. This time is given by the RNC parameter inactivityTimer. In this way, system resources are freed and UE power consumption is reduced, since the UE does not have to monitor the FACH any more. This switch is triggered by the Common to URA_PCH algorithm based on complete inactivity on both the uplink and the downlink.
18.3.URA_PCH For a UE in URA_PCH state the service re-activation time is shorter compared to setting up the connection from idle mode. At the same time the UE requires less signaling and power consumption when in URA_PCH state compared to when on the common CELL_FACH channel. Hence, it is possible to keep the UE in URA_PCH state for long time and let the user benefit from the short service reactivation time. The URA_PCH state is characterized by:
Neither an uplink nor a downlink dedicated physical channel is allocated to the UE
The UE uses DRX for monitoring a PCH via an allocated PICH.
No uplink activity is possible
The location of the UE is known on UTRAN Registration area (URA) level according to the URA assigned to the UE during the last URA update in CELL_FACH state.
In this state the UE performs the following actions:
Monitor the paging occasions according to the DRX cycle and receive paging information on the PCH
Listens to the BCH transport channel of the serving cell for the decoding of system information messages
Initiates a URA updating procedure on URA change.
The Cell Update procedure in the URA_PCH state is for the following cases:
UE in state URA_PCH has uplink data to transmit
UE in state URA_PCH state is paged by the network. The page can be either UTRAN or CN initiated. URA Update
In state URA_PCH, the procedure URA Update is used to keep WCDMA RAN informed about the UEs location on a URA level. To perform the URA update procedure, UE is moved temporarily from URA_PCH to CELL_ FACH state. After the URA update is completed, UE state is changed back to URA _PCH. URA Update is initiated in the following cases:
A UE in state URA_PCH enters a new cell not belonging to the same URA that the UE is registered in.
The UE enters a cell that has no URAs defined. This will trigger a release of the RRC Connection and the UE enters idle mode.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
178 of 214
Ericsson UMTS Feature Guidelines
ď&#x201A;ˇ
As part of a supervision mechanism, URA Update is performed periodically. The periodicity is controlled by the timer t305.
In the response to the URA Update, WCDMA RAN selects which URA the UE shall be registered to. Also for periodical URA Updates, where the UE might not have moved, the selected URA has to be specified by the network. System Information Block Type 2 contains the URA identities of the URAs configured in the cell. The same cell can belong to a maximum of 4 different URAs. In the URA_PCH state, the UE is not able to transmit or receive any control signals or data packets.
18.3.1.
URA_PCH to CELL_FACH
When UE detects request for data activity on uplink it will send a cell-update message which triggers a switch to CELL_FACH state. When RNC detects need for data transmission on downlink it will send a URA page to UE which will trigger a cell-update leading to switch to CELL_FACH. Note that the release of an RRC connection is not possible in the URA_PCH State. The UE will first move to Cell_FACH state to perform the release signaling.
18.3.2.
URA_PCH to IDLE
Upon extended inactivity on both the uplink and the downlink, a URA_PCH state will be switched down to IDLE. This is controlled by the RNC parameter inactivityTimerPch timer which limits the time the connections stays in URA_PCH state. The switch is triggered by the URA_PCH to idle evaluation algorithm.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
179 of 214
Ericsson UMTS Feature Guidelines
19. R99 PS Data The aim of this section and the subsequent ones is to describe the important features offered in Ericsson Radio Access Network (RAN) that impact the delivery of R99 Packet Switch (PS) data services to T-Mobile’s customers. This section explains the different QoS and Traffic classes related to packet data services as well as the Radio Resource Management (RRM) functionality. The Channel Switching Algorithm is the main function inside the RRM that controls PS Data Services, which is covered in the subsequent sections.
19.1.Radio bearer QoS The Packet Switch data services are defined according to its Quality of Service (QoS) requirement in order to deliver the service effectively. For example certain applications are more tolerant to delay (latency) and can therefore be assigned a lower priority. The three main QoS service considerations that must be taken into account are:
Call quality - mapping of UMTS QoS parameters to the WCDMA transport and physical channel characteristics,
Priority - bearer admission and scheduling,
Service availability and blocking - perceived QoS in terms of service coverage and capacity.
19.2.Differentiation between traffic classes In general, the UMTS traffic classes provide the means for the network to differentiate between end-to-end user applications according to their required traffic characteristics for that service. The main differentiation between the traffic classes is based on how sensitive the service is to delay. Given that radio spectrum is a limited resource, the radio access bearers (RABs) are limiting factors in terms of the available resources (compared to a fixed network where additional circuits can be provided with the extension of hardware e.g. fiber cable,) then traffic must be prioritized and handled according to its service class attributes. However, it is the performance of both the radio and fixed bearers (Transmission infrastructure) that determine the overall QoS offered by the network. Table 11 shows the main characteristics of the QoS classes that are supported in UMTS.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
180 of 214
Ericsson UMTS Feature Guidelines
Table 7: Traffic Classes Characteristics Ericsson UTRAN does not differentiate between the traffic classes Interactive and Background.
19.3.Radio Resource Management for packet data services In addition to the Channel Switching algorithms, Congestion Control, Admission Control and Handover functions can also trigger switching of a transport channel for an interactive RAB to one with a lower rate. Admission Control switches a UE from one dedicated transport channel to another one at the next lower-rate when the resource is needed to establish a new connection for a UE with high priority. Congestion Control may switch a UE from a dedicated to a common transport channel to resolve a congestion situation. When the Soft Handover algorithm fails to add a radio link due to admission denial and the current connection has uplink and/or downlink rates higher than 64 kbps, it will switch the connection down to 64/64 or 64/HS before trying to add the radio link again. When a UE enters the area of a new RNC, while being in states FACH or URA_PCH, it will be switched down to IDLE state in order to avoid common transport channel (FACH/RACH) signaling over the Iur interface.
19.4. Active Queue Management feature The Active Queue Management for interactive RAB feature introduces an optimized buffer handling, which minimizes the buffering delays and interacts with the TCP protocol in a favorable manner, thereby significantly improving the quality of the service experienced by the end user. With Active Queue Management, a mechanism to detect link overload before the absolute limits of the buffer in the RNC have been reached is introduced. Through this, a carefully selected packet dropping profile is applied to the overloaded buffers in order to avoid uncontrolled packet losses and high buffering delays when link overload is detected. Active Queue Management can be turned on and off with the activeQueueMgmt parameter.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
181 of 214
Ericsson UMTS Feature Guidelines
19.5.Channel Switching Feature Traffic on the interactive Radio Access Bearer (RAB) causes large variations in offered traffic over time for a particular user. Consequently, it is not efficient to reserve resources for a dedicated channel continuously. Channel Switching is a feature that dynamically allocates resources to a user according to the amount of data that needs to be transmitted in the uplink and the downlink. This is achieved by switching the interactive RAB of the user between transport channels of different rates. When an interactive RAB has only a small amount of data to send and receive, it is switched to common transport channels .This allows more users to share the radio resources than in a circuit-switched scenario. When the traffic increases, the user is switched to a dedicated transport channel if there are resources available Channel Switching applies only to packet traffic on the interactive RAB, which has little or no quality of service attributes that apply. It belongs to the interactive and Background Quality of Service classes, which have no guaranteed bit rates and no packet delay requirements. When sufficient resources are available, the interactive RAB receives high bit rates but when the system is heavily loaded and not many resources are available, the bit rates offered may be low. In a heavily loaded situation, it may not be given any bandwidth at all, since there are no guarantees on resource allocation for the RAB. Channel Switching switches only between transport channels. The logical channels are not affected. The channel switching feature will only affect users that are turned on and in connect mode, sending or receiving data. The UEs in connected mode can be changed through the different states to optimize the resources. The channel switching feature consists of two parts: evaluation and execution. Channel switching evaluation is responsible for monitoring and reporting the needs of a UE by measurement reports received from the UE, RBS and RNC. The evaluation part will then send an execution request to the execution part when the criteria for a channel switch is fulfilled. Chanel switching execution is responsible for the allocation of resources according to the UE and cell capabilities and executing the Radio Bearer Reconfiguration procedure for performing the channel switch.
19.6.Channel Switching Triggers The Channel Switching Evaluation is based on two criteria ď&#x201A;ˇ
User activity measured in terms of either channel throughput or RLC (Radio Link Control) buffer load.
ď&#x201A;ˇ
Coverage condition measured in terms of downlink code power.
An upswitch is requested when high user activity is detected either on a dedicated channel (DCH) as high channel throughput close to the maximum capacity of the current transport channel or on FACH as high buffer load. For a dedicated to dedicated channel upswitch on the downlink, a test is also made to ensure that there will be sufficient coverage (downlink code power) after the switch. Upswitch from URA_PCH to FACH is triggered by user activity. When low or no user activity is detected, a downswitch is requested. When on a dedicated channel, the detection is based on throughput measurement and the connection will be
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
182 of 214
Ericsson UMTS Feature Guidelines
switched down either to a lower rate on a dedicated channel or to FACH depending on throughput level. This happens after periods defined by downswitch timers. When on FACH, a switch down request to URA_PCH state will be made based on user data inactivity after the period specified by an inactivity timer. Also, when on URA_PCH, the measurement is based on data inactivity and a request to release the connection will be made after the period specified by an inactivity timer. When the coverage on downlink of a connection falls below a certain threshold considered to be insufficient for the current rate, a downswitch to the next lower state will be requested. There is no coverage-triggered downswitch for the uplink. Also there is no coverage test for dedicated to dedicated channel upswitch on the uplink. The UE is expected to perform transport format reduction to compensate for insufficient uplink coverage.
19.7. Triggers for Dedicated to Dedicated channel switching 19.7.1.
Throughput-triggered Upswitch
This is triggered by high channel utilization in the uplink or the downlink as indicated by a measured channel throughput that is close to the maximum capacity of the current transport channel. The UE will be switched to a state with a higher rate in the link that triggered the switch. The HS-DSCH is the preferred channel for the downlink and E-DCH in the uplink. A check on the EUL/HS capability or DCH/HS capability of both the UE and the connected cells is made before the switch. If all are EUL/HS capable, the transition will be to the EUL/HS state. If both are DCH/HS capable but not EUL/HS capable the transition will be to 64/HS or 384/HS depending on the need. For an uplink trigger, the UE is switched to a state with a higher uplink rate without compromising the downlink rate and for downlink trigger; the UE is switched to a state with a higher downlink rate without compromising the uplink rate. A coverage test based on the current DL code power utilization is made to see if the UE has sufficient code power to switch up to the target state. This is to avoid loss of connection or immediate coverage triggered downswitch due to insufficient code power. Note that if the current best cell is not HSDPA enabled but a coverage related cell on another frequency is, the connection may be redirected to that cell. These transitions are triggered by the CELL_DCH to CELL_DCH Upswitch Evaluation algorithm.
19.7.2.
Throughput-triggered Downswitch
This is triggered by low channel utilization in the uplink or the downlink as indicated by a measured channel throughput that is below a certain percentage of the maximum capacity of the transport channel with the next lower rate. The UE will be switched down to a state with the next lower rate in the link that triggered the switch.
19.7.3.
Coverage-triggered downswitch
Insufficient downlink coverage is detected in the form of high downlink code power. This applies only to UEâ&#x20AC;&#x2122;s that have a DCH transport channel on the downlink. The downlink channel will be switched to one with the next lower rate, i.e., DCH/384 to DCH/128,
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
183 of 214
Ericsson UMTS Feature Guidelines
DCH/128 to DCH/64, with DCH equals 64,128 and 384. This is triggered by the CoverageTriggered Downswitch Evaluation algorithm.
19.8. Multi RAB State Transitions 19.8.1.
Speech + Interactive
Five different types of Channel Switching among the seven states Speech + 0/0, Speech + 64/64, Speech + 64/128, Speech + 64/384, Speech +128/64, Speech + 64/HS, Speech + 384/HS are available. The Multi-RAB Downswitch Evaluation monitors the states with a non-zero interactive rates and triggers a switch to the lowest state Speech + 0/0 (SP0) when there is no activity on the Interactive RAB for an extended period of time. If the state SP0 is not available (multiRabSp0Available set to 0), a request to release the Interactive RAB is made, instead. The Multi-RAB Upswitch Evaluation monitors the activity on both the uplink and the downlink of the SP0 state and switch it up to the Speech + 64/64 or Speech + 64/HS state if necessary. The CELL_DCH to CELL_DCH Upswitch Evaluation switching for a downlink trigger:
Speech + 64/64, Speech + 64/128, Speech + 64/384 to Speech + 64/HS
Speech + 128/64 to Speech + 384/HS
Speech + 64/64 and Speech+ 64/128 to Speech + 64/384
Speech +64/64 to Speech + 64/128.
The CELL_DCH to CELL_DCH Upswitch Evaluation switching for an uplink trigger:
Speech + 64/64, Speech + 64/128, Speech + 64/384, Speech + 128/64, Speech + 64/HS to Speech + 384/HS
Speech + 64/64 to Speech + 64/128
The CELL_DCH to CELL_DCH Downswitch Evaluation switching for a downlink trigger:
Speech + 64/384 to Speech + 64/128
Speech + 64/128 to Speech + 64/64.
The CELL_DCH to CELL_DCH Downswitch Evaluation switching for an uplink trigger:
Speech + 128/64 to Speech + 64/64
Speech + 384/HS to Speech + 64/HS.
The Coverage Triggered Downswitch Evaluation switches Speech + 64/384 to Speech + 64 /128 and switches Speech + 64/ 128 to Speech + 64/64.
19.8.2.
2xInteractive
Inactivity monitoring is available on the 2xInteractive multi-RAB. The Multi-RAB Downswitch Evaluation triggers a request to release one of the interactive RAB's upon a period of inactivity on both the uplink and the downlink for one of the RAB's.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
184 of 214
Ericsson UMTS Feature Guidelines
19.8.3.
Speech + 2xInteractive
Inactivity monitoring is available on the Speech + 2xInteractive multi-RAB. The Multi-RAB Downswitch Evaluation triggers a request to release one of the interactive RABâ&#x20AC;&#x2122;s upon a period of inactivity on both the uplink and the downlink for that RAB.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
185 of 214
Ericsson UMTS Feature Guidelines
20. Channel Switching The objective of the channel switching algorithms is to determine for each interactive RAB if there is a need to switch a UE from one transport channel to another and to select a transport channel with a user bit rate corresponding to the required bandwidth of the data transmission. The channel switching algorithms consist of the following sub-algorithms:
Common to Dedicated Evaluation
Dedicated to Common Evaluation
Common to URA Evaluation
URA to Idle Evaluation
Coverage Triggered Downswitch Evaluation
Dedicated to Dedicated Upswitch Evaluation
Throughput based Dedicated to Dedicated Downswitch Evaluation
Multi RAB Downswitch Evaluation
Multi RAB Upswitch Evaluation
The Channel Switching algorithms use buffer load, throughput, and transmitted code power as input to the algorithms. These terms are defined as follows:
Buffer load is defined as the minimum of the Radio Link Control (RLC) transmission window and the sum of bytes in the SDU (service data unit) buffers and retransmission buffers of some of the RLC instances (each interactive RAB connection consists of five RLC instances).
Throughput – Uplink throughput is defined as the number of bits transmitted from the MAC layer to the RLC layer. Downlink throughput is defined as the number of bits transmitted from the RLC layer to the MAC layer. The RLC instances to be considered for the buffer load and throughput measure depends on the UE state and the algorithm using the measure.
Transmitted code power is defined as the downlink power of the pilot bits of the DPCCH (Dedicated Physical Control Channel) field. For channel switching purposes, periodic reporting with a 1 second period is used.
The various channel switching algorithms and the related parameters are discussed in the following sections.
20.1.Common to Dedicated Evaluation The Common to Dedicated Evaluation algorithm monitors the amount of user data waiting to be transmitted (buffered) in the RNC or UE. If the buffer load increases and a switch from the common transport channels FACH/RACH to a higher bit rate dedicated transport channel is required, an upswitch request is sent to channel switching execution. The evaluation algorithm is activated at the entry of the common state, and uses RLC buffer loads in both the uplink and the downlink as input.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
186 of 214
Ericsson UMTS Feature Guidelines
When the RLC buffer load in the uplink exceeds the threshold value set by the RNC parameter ulRlcBufUpswitch, a measurement report is sent from the UE and an upswitch request is issued after the reception of the measurement report. A request is also issued when the RLC buffer load in the RNC, in the downlink exceeds the threshold value set by the RNC parameter dlRlcBufUpswitch. Channel switching execution thereafter performs the upswitch when permission is given from Admission Control. The common to dedicated switching function always tries to allocate a EUL/HS, ulPrefRate/HS or ulPrefRate/dlPrefRate transport channels, and in that order.
20.2. Dedicated to Common Evaluation The Dedicated to Common Evaluation algorithm monitors the transmitted user data. If user throughput decreases so that a switch from a dedicated transport channel to the common transport channels FACH/RACH is required, a downswitch request is sent to channel switching execution. The evaluation is activated once the dedicated state is entered and it uses throughput measurements, performed in the S-RNC, in both the uplink and downlink for both control and user data as input. When the throughput on both the uplink and downlink is below the threshold value set by the RNC parameter downswitchThreshold, the timer defined by the RNC parameter downswitchTimer is started for a DCH/DCH allocation or the timer defined by the RNC parameter hsdschInactivityTimer is started for a DCH/HS or EUL/HS allocation. If the throughput increases above a second threshold set by the parameter downswitchTimerThreshold before the timer expires, the timer is stopped and no switch is issued. This is done for stability reasons, and could be used to prevent switches back and forth at momentary dips in throughput.
Figure 41: Dedicated to common channel switching evaluation The example in the previous figure shows the following: 1. The throughput decreases below the downswitch threshold (downswitchThreshold) and the timer (downswitchTimer) is started.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
187 of 214
Ericsson UMTS Feature Guidelines
2. The throughput increases and exceeds the upper threshold (downswitchTimerThreshold) and the timer is stopped. 3. The throughput decreases again and the downswitch threshold (downswitchThreshold) is crossed, which starts the timer. 4. Finally, the timer expires and a switching request from the dedicated to the common state is issued. The evaluation is restarted when the switch request is issued to Channel Switching execution. This is necessary in order to handle failing downswitches. If the downswitch fails, a new request is issued when the restarted timer expires. A value of 0 for the downswitchTimer disables the Dedicated to Common Evaluation algorithm. When the UE is ordered to switch to the common state, no target cell is specified. This means that the UE selects a cell and performs a cell update procedure.
20.3.Common to URA Evaluation The Common to URA Evaluation releases UEs with no activity in order to free resources. It also decreases the power consumption of the UE, since the UE does not have to monitor the FACH for long periods of time. The algorithm is activated at the entry of the FACH state. Uplink and downlink activity is monitored and the algorithm requests a switch to URA_PCH state if no uplink or downlink activity is detected (i.e. no data has been transmitted) during a time defined by the RNC parameter inactivityTimer. If the URA_PCH state is not available, the UE is switched down to idle state.
20.4.URA to Idle Evaluation The URA to Idle Evaluation releases UEs with no activity in order to free resources. The algorithm is activated at the entry of the URA_PCH state. The algorithm requests a switch to idle mode if a UE has been allocated to URA_PCH state for a time defined by the RNC parameter InactivityTimerPch. The request is issued to the Signaling Connection Handling function. Signaling Connection Handling issues an Iu release request to the Core Network, which in turn decides whether the connection should be released.
20.5.Coverage Triggered Downswitch Evaluation The Coverage Triggered Downswitch Evaluation algorithm monitors the code power utilization on the downlink. If the code power increases so that a switch to a lower rate dedicated channel on the downlink is required due to coverage reasons, a downswitch request is sent to the Channel Switching Execution function. The goal is to minimize call drops due to bad link quality. When downlink transmitted code power increases to a value too close to its maximum, there is a risk that the link quality cannot be maintained. In this situation, a user should be switched down to a lower rate to decrease the needed downlink transmitted code power. This feature is used to prevent a user from using a data rate in an area where there is risk for no coverage of that particular rate.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
188 of 214
Ericsson UMTS Feature Guidelines
The algorithm monitors the downlink transmitted code power of all legs in the active set and the code power is then filtered by each Node B in the active set. A downswitch request is issued when all handover legs use a power above the power alarm threshold defined by the parameter downswitchPwrMargin below the maximum code power for a period defined by the parameter coverageTimer. If the transmitted downlink code power falls below the power alarm threshold while the timer defined by the parameter coverageTimer is running, the request will be cancelled and no downswitch is executed. This evaluation algorithm is started at the entry of the single RAB states DCH/384 and DCH/128 and Multi RAB states speech + 64/384 , speech + 64/128 and 64/128 + 64/128. The DL channel will be switched to one with the next lower rate without compromising the uplink rate.
Figure 42: Coverage Triggered Downswitch
20.6.Dedicated to Dedicated Upswitch Evaluation The Dedicated to Dedicated Upswitch Evaluation algorithm determines whether a switch to a higher rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB transitions. The algorithm monitors the uplink and the downlink throughput separately. A channel switch request to a higher uplink rate Radio Bearer (uplink triggered) or to a higher downlink rate Radio Bearer (downlink triggered) is issued if all of the following conditions are fulfilled: ď&#x201A;ˇ
The downlink throughput increases above the threshold specified by the RNC parameter bandwidthMargin for a period defined by the parameter upswitchTimer or the uplink throughput increases above the threshold specified by the RNC parameter bandwidthMarginUl for a period defined by the parameter upswitchTimerUl.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
189 of 214
Ericsson UMTS Feature Guidelines
For a trigger on the downlink, the transmitted code power consumption on the current rate is below the power upswitch threshold for all legs in the active set at the expiry of the timer set by the parameter upswitchTimer. Power upswitch threshold = Max code power - downswitchPowermargin – UpswitchPowerMargin – estimated power increase after upswitch
The maximum bit rate capability for QoS profiling does not indicate that the current rate is the maximum bit rate for the user
If the upswitch is following a previous throughput based downswitch, the downlink throughput has fallen below the threshold specified by dlThroughputAllowUpswitchThreshold or the uplink throughput has fallen below the threshold specified by ulThroughputAllowUpswitchThreshold.
The estimated power increase is based on the relative rate difference between the current and a higher rate. For an upswitch from 64 to 128 kbps, the estimated power increase is 2.9 dB and for the 128 to 384 kbps upswitch, it is 4.7 dB. When evaluating an upswitch from 64 kbps, rate 384 kbps is targeted as first alternative and rate 128 kbps as second alternative. If the bandwidthMargin parameter is set to 0 or the bandwidthMarginUl is set to 0, the Dedicated to Dedicated Upswitch evaluation is turned off for downlink or uplink respectively. If the dlThroughputAllowUpswitchThreshold parameter is set to 0 or the ulThroughputAllowUpswitchThreshold is set to 0, this condition is not used for downlink or uplink respectively. For an UL trigger, the UE is switched to a state with a higher UL rate without compromising the DL rate.
For both HSDPA and non-HSDPA capable UEs, UL rates lower than ulPrefRate will be switched to ulPrefRate. Otherwise, they will be switched to the next higher rate.
For non-HS capable UEs if the corresponding rate on DL is lower than the dlPrefRate, the downlink will also be switched to the dlPrefRate.
For a downlink trigger, the UE is switched to a state with a higher downlink rate without compromising the uplink rate.
All HSDPA capable UEs are switched from DCH/DCH to DCH/HS and UL rates lower then ulPrefRate will go to ulPrefRate.
For non-HSDPA capable UEs, DL rates lower than the dlPrefRate are switched to dlPrefRate. Otherwise, they will be switched directly to the highest DCH rate (384kbps). If the corresponding rate on uplink is lower than the ulPrefRate, the uplink will also be switched to the ulPrefRate.
If the coverage test fails, then the next higher rate is tried.
As long as the upswitch request cannot be fulfilled, the upswitch request will be repeated. An adaptive upswitch time is achieved by doubling the time between requests for each new request sent, where the time between first and second request is determined by upswitchTimer or by upswitchTimerUl. This decreases the possibility of immediately ending up in a congestion situation again when a congestion situation had just been resolved.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
190 of 214
Ericsson UMTS Feature Guidelines
Figure 43: Coverage testing before a downlink upswitch
20.7.Throughput Based Dedicated to Dedicated Downswitch Evaluation The Dedicated to Dedicated Downswitch Evaluation algorithm determines whether a switch to a lower rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB transitions. The uplink and the downlink throughput are monitored separately. A channel switch request to the next lower uplink rate Radio Bearer (uplink triggered) or to the next lower downlink rate Radio Bearer (downlink triggered) is issued when the downlink throughput decreases below the threshold specified by dlDownswitchBandwidthMargin for a period defined by the parameter dlThroughputDownswitchTimer or the uplink throughput decreases below the threshold specified by ulDownswitchBandwidthMargin for a period defined by the parameter ulThroughputDownswitchTimer. For an uplink trigger, the UE is switched to the state with the next lower uplink rate without compromising the downlink rate. For a downlink trigger, the UE is switched to the state with the next lower downlink rate without compromising the uplink rate. If the dlDownswitchBandwidthMargin parameter is set to 0 or the ulDownswitchBandwidthMargin parameter is set to 0, the Dedicated to Dedicated downswitch evaluation is turned off for downlink or uplink respectively.
20.8.Multi RAB Downswitch Evaluation This algorithm monitors the user data throughput both in the uplink and the downlink. A Speech + Interactive RAB (DCH/DCH) is downswitched to Speech + SP0 when there is no data transfer for a duration of downswitchTimerSp. A Speech + Interactive RAB (DCH/HS) is downswitched to Speech + SP0 when there is no data transfer for a
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
191 of 214
Ericsson UMTS Feature Guidelines
duration of hsdschInactivityTimer. If the state SP0 is not available, then the interactive part of the call is released. If there is inactivity for any interactive RAB in Speech + 2/3xInteractive multi-RAB, a 2/3xInteractive multi-RAB or a PS Streaming + Speech + 2xInteractive multi-RAB for a duration of timer inactivityTimeMultiPsInteractive, then the inactive interactive RAB part is released. The downswitch timer for the UDI + Interactive multi-RAB is given by the parameter downswitchTimerUp If the downswitchTimerSp or downswitchTimerUp parameter is set to 0, the corresponding Multi-RAB Downswitch Evaluation is turned off and no downswitches will occur irrespective of how long the throughput has been zero.
20.9.Multi RAB Upswitch Evaluation The Multi RAB Upswitch Evaluation algorithm is specific to the Speech + interactive multiRAB. It monitors the RLC buffer load on both the uplink and the downlink of the interactive part of the Speech + 0/0 state (SP0). The evaluation algorithm is activated at the entry of the Multi RAB SP0 state, and uses RLC buffer loads in both the uplink and the downlink as input. When the buffer load in the uplink exceeds the threshold value set by the parameter ulRlcBufUpswitchMrab, a measurement report is sent from the UE. An upswitch request is issued upon reception of the measurement report. A request is also issued when the RLC buffer load in the RNC exceeds the threshold value set by the parameter dlRlcBufUpswitchMrab. If the dlRlcBufUpswitchMrab parameter is set to 0, the Multi-RAB Upswitch Evaluation algorithm is turned off, meaning that no upswitches from SP0 will occur, irrespective of the RLC buffer load. Similar rules as in Single RAB transition are followed while trying to find a higher rate to upswitch to.
20.10.
Channel Switching Parameter Optimization
Optimization of channel switching is a trade-off between user throughput and system capacity. For example, the time a user stays on DCH can be increased so that a short period without traffic does not lead to a downswitch to FACH. This improves the user throughput since transmission can be started immediately after the short period without transmission. However, since the user then also holds the resources associated to a DCH for a longer time, the system capacity will decrease. When optimizing the parameter setting of channel switching it is also important to consider the different kinds of traffic and the different kinds of mobiles in the network since both traffic and mobile behavior can differ significantly. Optimization of the channel switching from common to dedicated channels depends on the parameter ulRlCBufUpswitch. A lower value for this parameter might be useful to trigger an upswitch to a dedicated state when a UE is used for an application like we browsing, but when used as a modem with a laptop, signaling from other applications might trigger an unwanted upswitch to a CELL_DCH state. The above discussion is also applicable to a downswitch from a dedicated to common channels. The setting of the downswitchThreshold parameter dictates when a UE changes
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
192 of 214
Ericsson UMTS Feature Guidelines
to a CELL_FACH state from a CELL_DCH state. While a value of 0 kbps for this parameter would be accurate for a UE doing a FTP download, when used as a modem, the applications on a laptop may create low level background traffic which would force the UE to stay in a CELL_DCH state when this parameter is set to 0 kbps. These are just some initial guidelines for trending of the channel switching parameters and actual recommended values for all related parameters would have to be evaluated with the help of network trials. A summary of the various channel switching mechanisms available along with the related parameters is shown in the table below. Channel Switching transition CELL_FACH to CELL_DCH upswitch
Reason
Direction
Related parameters
RLC buffer load
DL
dlRlcBufUpswitch
CELL_DCH to CELL_FACH downswitch CELL_FACH to URA_PCH downswitch URA_PCH to idle downswitch CELL_DCH to CELL_DCH upswitch
Throughput
UL DL & UL
Inactivity
DL & UL
ulRlcBufUpswitch downswitchThreshold, downswitchTimer, downswitchTimerThreshold inactivityTimer
Inactivity Throughput
DL & UL DL UL
CELL_DCH to CELL_DCH downswitch
Throughput
DL UL
Transmit code power
DL only
inactivityTimerPch bandwidthMargin, dlThroughputAllowUpswitchThreshold, upswitchPwrMargin, upswitchTimer bandwidthMarginUl, ulThroughputAllowUpswitchThreshold, upswitchTimerUl dlDownswitchBandwidthMargin, dlThroughputDownswitchTimer ulDownswitchBandwidthMargin, ulThroughputDownswitchTimer coverageTimer, downswitchPwrMargin
Table 8: Summary of channel switching options and related parameters for single RAB transitions A summary of the Multi RAB state transitions due to inactivity along with the related parameters is shown below. Multi RAB transition Speech + HS to Speech + SP0 downswitch Speech + PS R99 to Speech + SP0 downswitch Speech + SP0 to Speech + PS 64 upswitch 2 * PS interactive to idle downswitch UDI + PS to idle downswitch
Direction DL and UL DL and UL
Related parameters hsdschInactivityTimer downswitchTimerSp
DL UL DL and UL DL and UL
dlRlcBufUpswitchMrab ulRlcBufUpswitchMrab inactivityTimeMultiPsInteractive downswitchTimerUp
Table 9: Parameters for multi rab state transitions due to inactivity
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
193 of 214
Ericsson UMTS Feature Guidelines
21. High Speed Downlink Packet Access (HSDPA) HSDPA is the evolution of UMTS for better support of data services. The main goal of HSDPA is to offer high speed downlink data service to users. Higher data rates when compared to UMTS R99 can be offered with HSDPA due to the use of the following key concepts.
New shared channel for data transmission
Smaller Transmission Time Interval (TTI) of 2 ms
Faster channel dependent schedulers
Faster link adaptation
Modulation schemes of 16 QAM in addition to QPSK
Hybrid ARQ – faster retransmission mechanism
These concepts are important to the understanding of HSDPA, and it is assumed that the reader is familiar with these basic 3GPP features. This document only discusses the implementation of HSDPA from an Ericsson point of view.
21.1. HSDPA Codes Allocation SF16 codes are used by the high speed physical downlink shared channel (HS – PDSCH). TMobile’s current license allows the maximum number of 15 codes to be enabled per Node B if needed. The parameter numHsPdschCodes defines the number of allocated HS-PDSCH codes per cell. These codes cannot be used for DCH users even if there are no HSDPA users in that cell. Using the Dynamic Code Allocation feature gives greater flexibility in using the 15 HS-DSCH codes in the 3 cells belonging to this Node-B. It is activated by setting the parameter dynamicHsPdschCodeAdditionOn to TRUE. The maximum number of HS-PDSCH codes that can be used per cell can be defined by the parameter maxNumHsPdschCodes. If the parameter numHsPdschCodes is set to a value larger than maxNumHsPdschCodes, then the remaining codes can be borrowed from other cells in the site as long as there are unused codes available. A cell in a 3-sectored site can have up to 13 HS-PDSCH codes available for use ( 1 code per cell is left reserved and can’t be shared) as long as these codes are not being used by the other cells. All the HS-PDSCH codes can be assigned to a single HSDPA user or to different users. This feature of sharing codes between more than one HSDPA user in the same 2ms transmission time interval (TTI) is called code multiplexing. Code multiplexing is useful when the site is configured for 15 codes and the majority of the HSDPA terminals in the network can only receive 5 or 10 codes at a time, which would be most of the handsets that are available initially after network launch. In order for more than one UE to share the codes within a 2ms TTI, more than 1 HS-SCCH needs to be enabled. This can be enabled by setting the parameter numHsScchCodes to a value greater than 1 (up to a maximum value of 4).
21.2. HSDPA Scheduler Option The parameter queueSelectAlgorithm is used to decide the scheduling option used to allocate HSDPA resources to users. The recommended value for this parameter is
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
194 of 214
Ericsson UMTS Feature Guidelines
Proportional_Fair_High, which ensures that users are selected for HSDPA scheduling using a high fairness factor. In this case, CQI is less important for scheduling, and even users in bad channel conditions would be allocated HSDPA resources.
21.3. Hybrid ARQ Options One benefit of the MAC-hs protocol is the Hybrid Automatic Repeat Request (HARQ) retransmission scheme, which enables so-called soft combining, where the UE decodes data efficiently by using the data in the original transmission and combining it with the data in subsequent retransmissions. The combining scheme minimizes the required energy needed to transmit the data with a certain block error probability, and thereby increases cell throughput. It further adds robustness to errors in the link adaptation. The HARQ scheme can be selected between Chase Combining (CC) or Incremental redundancy (IR). Incremental redundancy can be enabled by setting parameter hsIncrementalRedundancyOn to TRUE. In the case of IR, the retransmission consists of a different set of coded bits than the original transmission attempt. CC is a special case of IR where the retransmission contains the same coded bits as the original transmission; this is done by prioritizing systematic bits and generating the same redundancy version. The benefits of IR are scenario dependant but as a general rule, its benefits as compared to CC are most apparent in scenarios with high initial coding rates and in non- or moderately fading channel conditions.
21.4. Admission and Congestion Control for HSDPA HSDPA Admission is discussed in detail in the section “HSDPA Admission”. Some of the important concepts are recapped here. The maximum number of HSDPA users per cell is defined by the parameter maxNumHsdpaUsers. This should be configured in accordance with the license key for TMobile. Admission requests for “new” HSDPA connections are limited by the parameter hsdpaUsersAdm. If an admission request is originated from an existing HSDPA connection, as a result of mobility, the request is not blocked based on hsdpaUsersAdm. The difference between the parameter maxNumHsdpaUsers and hsdpaUsersAdm defines the mobility margin for HSDPA calls. Hence the parameter should be set such that there is room for serving HSDPA cell changes so that the serving cell is always the optimal cell which will ensure good throughput and minimize the risk of dropped calls. Further details on Admission Control of HSDPA users with respect to power, channel elements and OVSF codes can be found in section 15 and details on Congestion Control with respect to HSDPA is discussed in section 16.
21.4.1.
Channel type selection between HS-DSCH and DCH
If HSDPA is enabled in the cell, a PS interactive call is always first tried on the HS-DSCH channel as long as the UE is able to support HSDPA services. If the best cell has HSDPA enabled, the connection is tried on this cell. The best cell is the strongest cell in the active set in terms of Ec/No or RSCP. The RNC parameter hsQualityEstimate decides which of these 2 measures is actually used to determine the best cell for HSDPA.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
195 of 214
Ericsson UMTS Feature Guidelines
The default setting for this parameter is CPICH RSCP, since the RSCP doesn’t depend on cell load. The CPICH Ec/No measurement fluctuates with the cell load. If an active set cell is a DRNC cell over Iur, then parameter cellCapability.hsdschSupport must be set to “On” for the Iurlink. If the best cell in the active set doesn’t support HSDPA or if admission control restricts HSDPA call establishment on the best cell, depending on the RNC parameter hsOnlyBestCell, a HSDPA call can be tried on another cell in the active set. If the parameter hsOnlyBestCell is set to TRUE, then HSDPA call cannot be tried on any other cell and an R99 radio bearer is used to set up the PS interactive/background call. If the parameter hsOnlyBestCell is set to FALSE, then an HSDPA call can be tried on a cell other than the best cell in the active set, if a coverage relation is defined between the serving cell and a HSDPA enabled target cell, and the parameter coverageindicator is set to COVERS or OVERLAPS. In this case, the target cell is selected if the path loss of the target cell is less than the value specified by the parameter hsPathlossThreshold. The serving cell and the target cell have to belong to the same RNC for a coverage relation to be defined between them. Since for a successful call setup, the serving cell and target cell will need to have similar coverage areas, a coverage relation should not be defined for cells belonging to the same frequency carrier except in case of macro – indoor cell combinations. The coverage relation feature is intended for use in case of 2 carrier networks to direct a HSDPA connection to the appropriate frequency layer. Since at this time, T-Mobile, USA only has single carrier networks in deployment, the details of the coverage relation feature are not covered here. If a HSDPA connection can’t be established on the best cell in the active set, 2 the call will be established on either the DCH or FACH channel based on the UtranCell parameter rateSelectionPsInteractive.channelType when the feature Dynamic PS Interactive/Background RAB Establishment is enabled. If DCH is the preferred channel type, but it is not possible to establish a call on DCH then the common channels will be used to establish the call. In addition the DCH/DCH can be established with operator specified preferred rates in DL and UL if the feature Flexible Initial Rate Selection, PS Interactive is enabled. The preferred rates in DL (if HSDPA is not available for call establishment) is configured by the UtranCell parameter rateSelectionPsInteractive.dlPrefRate and the preferred rate in uplink can be set with the UtranCell parameter rateSelectionPsInteractive.ulPrefRate. If the active set has more than one cell, the minimum preferred rate of the cells connected in the active set of the connection is chosen as the preferred rate. Fallback on lower DCH rates than the preferred rate is always allowed and fallback on a higher DCH rate of 64 kbps is allowed if the preferred lower rate (below 64 kbps) is not available. The preferred rate for active set cells in other RNCs is taken to be 64kbps. In the case the feature Flexible Initial Rate Selection, PS Interactive is disabled, the preferred rate for UL and DL is considered to be 64 kbps in both UL and DL.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
196 of 214
Ericsson UMTS Feature Guidelines
21.5. HSDPA Power Control 21.5.1.
HSDPA Power Usage
Unlike the R99 traffic channels, the HS-DSCH and the HS-SCCH are not fast power controlled. Hence power management of these channels is crucial to successful operation of HSDPA. In Ericsson’s implementation, HSDPA shared channels, HS-PDSCH and HS-SCCH will take power that is left in the Node B after common channels and R99 dedicated channels are allocated. This approach ensures that voice users are given priority over HSDPA. The cell loading is calculated in the following way.
For a HSDPA capable cell, the measurement type ‘Transmitted carrier power of all codes not used for HS-PDSCH or HS-SCCH’ is used for cell load calculations
For a cell that is not HSDPA capable, ‘Transmitted Carrier Power’ is used for cell load calculations.
The total power available for HSDPA is estimated as PHS = Pmax - hsPowerMargin - Pnon-HS Where Pmax is the maximum downlink transmission power in dBm, set by the parameter maximumTransmissionPower and Pnon-HS is the total transmitted carrier power of all codes not used by HS-PDSCH and HS-SCCH. It is possible to use all the remaining power of the Node B after common channel and R99 dedicated channel allocation for HSDPA, and this can be achieved by setting the parameter hsPowerMargin to 0. But for a more conservative approach and in order to give some headroom in the total carrier power, hsPowerMargin is set to a non-zero value. The recommended value for this parameter is 0.2 dB, which is the Ericsson default. This parameter can be changed to a higher value if needed after HSDPA deployment on cells that exhibit power stability problems. The power available to the HS-PDSCH channel can be calculated in dBm as PPDSCH = PHS - PHsscchPower where PHsscchPower is the code power used for the HS-SCCH channel. Optimization Note: The power allocated to HSDPA channels can be limited by setting a larger value for the parameter hspowermargin, in order to control the load generated by HSDPA users if needed.
21.5.2.
HS-SCCH Power
In order to ensure a high percentage of decoding for the HS-SCCH which carrier signaling information, HS-SCCH power can be allocated to a static value defined by the parameter hsScchMaxCodePower. This is expressed as an offset of the PCIPCH power.
21.5.3.
HS-DPCCH Power Control
The HS-DPCCH power is set relative to the uplink DPCCH power. The offsets are specified separately for the ACK, NACK and CQI fields. Two sets of ACK, NACK and CQI offsets are defined depending on whether there are 1 or more RBSs involved in the active set. The parameters deltaAck1, deltaNack1 and deltaCqi1 are used when the active set includes
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
197 of 214
Ericsson UMTS Feature Guidelines
only cells from 1 RBS. The parameters deltaAck2, deltaNack2 and deltaCqi2 are used when the active set includes cells from more than 1 RBS. The update of these offsets is triggered as soon as possible after an active set update and has the same priority as a handover.
21.6.Channel Quality Estimation Scheduling of HSDPA resources by the Node B is based on the channel quality indicators (CQI) sent by the UE. The CQI is defined such that when the Node B transmits data as per this CQI, then the achieved BLER is 10 % or less. The Node B can’t use this CQI exactly for transmitting data since this CQI is based on the UE’s assumption of the PDSCH power, which is different from the actual PDSCH power available in the Node B. Hence the Node B converts this CQI report into a channel quality estimate which is used to send data to the UE. Ericsson has a CQI Adjustment feature that can be enabled by setting parameter cqiAdjustmentOn to TRUE. The intent of this feature is to have a consistent CQI reporting among the various mobiles. In very good conditions, the NACK value should be better than its target value. However as per Ericsson, with CQI adjustment enabled, the NACK values would still approach 10 % even in these good conditions resulting in lower throughputs. Hence this parameter should only be enabled on a per cell basis based on the channel conditions. NACK ration in these cells (especially indoor cells) can be evaluated based on available counters before enabling the CQI adjustment feature. The channel quality estimate is defined as ChQual = CQI – (PCPICH_TX +
)
Where PCPICH_TX is the CPICH transmission power and
is defined by the parameter
hsMeasurementPowerOffset. This parameter can take a value in the range -6 to 13 dB
and is used to offset the difference between the UE’s assumed PDSCH power and the actual available PDSCH power at the Node B, and allows the UE to use the entire range of CQI values from 0 to 30. If this parameter is set to a very low value, the UE will use only the lower end of the CQI range, and if the value is high, then only the higher end of the CQI range is used by the UE. The default value for this parameter is 8 dB.
21.7. Iub Flow Control For HSDPA, the RNC is unaware of the current capacity of the Iub interface or the current buffer capacity in the Node B, since the Node B is in charge of the processing and transmission of the data on the high speed channels. Hence the Node B is responsible for providing to the RNC the amount of data it is allowed to transmit with the use of a Capacity Allocation message. The purpose of the Iub flow control algorithm is to have the priority queues in the Node B appropriately filled so as not to overload the transport network. The calculation of the Capacity Allocation is based on the parameter maxHsRate, which is the maximum possible bit rate that the HSDPA traffic can use on the Iub. The Iub flow control algorithm for HSDPA is shown in Figure 44. These are the steps involved in this algorithm.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
198 of 214
Ericsson UMTS Feature Guidelines
The Node B receives HS-DSCH data frames from the RNC and stores the correctly received MAC-d PDUs in priority queues.
Based on the maximum possible air interface bit rate, which is the maximum bit rate a priority queue flow could get if it is the only one in the cell, along with the priority queue status and number of users in the cell, the Node B calculates the estimated bit rate per flow.
The Iub flow control algorithm in the Node B also identifies if a priority queue flow is active or inactive. An inactive flow is one that hasn’t received a data frame for a while or has indicated a zero user buffer size. When a data frame is received with a user buffer size greater than zero, the flow becomes active.
The Iub flow control algorithm in the Node B adjusts to the congestion on the Iub by using a reference bit rate called targetHsRate which is initially set equal to maxHsRate. Iub congestions over a certain value decreases the reference bit rate, while the absence of congestions for a certain period of time increases this reference. Several consecutive congestion detections increase the speed with which targetHsRate is decreased, similarly, several consecutive detections of no congestion increase the targetHsRate in larger steps. This enables faster adaptation to sudden HSDPA bandwidth reductions.
If the Iub HSDPA bandwidth is identified as a bottleneck, the reference value targetHsRate is used to reduce the Capacity Allocation bit rates. The aggregated bit rate of all active priority queues is compared to targetHsRate and if higher, the bit rate for a flow is reduced. The active flows are assigned this reduced calculated bit rate, while the inactive flows are assigned a low bit rate.
This calculated bit rate is translated to a bit rate expressed as credits and put in a Capacity Allocation control frame. The bit rate evaluation of a priority queue flow is done every 100 ms, but a bit rate hysteresis is used to send Capacity Allocation frames only when a calculated bit rate deviates by a certain percentage from the previous one.
Based on the received Capacity Allocation frames, and the received IP packets from the SGSN, the RNC sends HS-DSCH data frames to the Node B. After a cell change, the RNC switches sending of data frames to the target cell. The RNC must receive Capacity Allocation frames from the target cell before it can send HS-DSCH data frames to the target cell.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
199 of 214
Ericsson UMTS Feature Guidelines
Figure 44: HSDPA Iub Flow Control
21.8.HSDPA Mobility â&#x20AC;&#x201C; Serving HS-DSCH Cell Change As per 3GPP, the HS-DSCH shared channel canâ&#x20AC;&#x2122;t be in soft handover as the other DCH channels do. This is required in order to achieve the higher throughputs associated with HSDPA and also to minimize the complexity in handover implementation for HSDPA. The HSDPA connection for a UE is maintained by transitioning the UE in between HSDPA enabled cells using the serving HS-DSCH cell change procedure, which is described below.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
200 of 214
Ericsson UMTS Feature Guidelines
The serving HS-DSCH cell change procedure is only allowed if the parameter hsCellChangeAllowed is set to TRUE. It can be triggered either by
Change of best cell in the active set (event 1d HS)
Removal of the current serving HS-DSCH cell from the active set (event 1b or event 1c).
21.8.1.
HS-DSCH Cell Change due to change of best cell
Event 1d HS is used to monitor a change of best cell in the active set. When a PS interactive RAB using R99 DCH or HSDPA is active, a separate event 1d HS is set up by the ‘Measurement Control’ message sent to the UE. This event 1d HS is different from the soft handover related event 1d. The main difference is that event 1d HS is only evaluated on the cells in the Active set (while event 1d could be triggered for any cell which is not the best cell). By having a separate event 1d HS, the serving HS-DSCH cell change can be based on a different quality criterion than event 1d thus not affecting the soft/softer handover procedures. The quality criterion for event 1d HS can be set with the parameter hsQualityEstimate. In fact, CPICH RSCP is the preferred trigger for event 1d HS, as opposed to CPICH Ec/No for event 1d. The reason for this is that CPICH RSCP measurements are not impacted by cell load and lead to a more stable behavior when compared to CPICH Ec/No. Also if CPICH Ec/No was used, after a HS-DSCH cell change, the old serving cell looks better in terms of CPICH Ec/No than the current cell, possibly leading to an undesirable ping pong behavior. Event 1d HS is triggered if the following condition is true for a time set by the parameter
hsTimeToTrigger1d
10 LogM InActiveset _ cell 10 LogM Current _ servingcell hsHysteresis1d / 2 The following conditions have to be met for a suitable HS-DSCH cell to be found for cell change to take place.
Parameter hsCellChangeAllowed is set to TRUE.
If the target cell is a DRNC cell over Iur then the parameter cellCapabilityControl.hsdschSupport must be set to “On” for the Iur link.
The target cell should be better than the current serving cell by a factor of hsHysteresis1d/2.
If a suitable HS cell is found, then the RNC will start the serving HS-DSCH cell change execution. Admission Control is not checked before a serving HS-DSCH cell change is executed. If hsCellChangeAllowed is set to FALSE, or if no suitable HSDPA cell is found or if the cell change fails and the call doesn’t drop, the RNC checks the parameter hsToDchTrigger.changeOfBestCellIntraRnc. If this parameter is set to ON (recommended value), then a downswitch to DCH is attempted. If the active set contains any cells over IuR, then the parameter
hsToDchTrigger.changeOfBestCellInterRnc should be set to “On” to enable the
transition to DCH.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
201 of 214
Ericsson UMTS Feature Guidelines
If the transition to DCH fails or is not possible due to Admission control, then no further action is taken.
21.8.2.
HS-DSCH Cell Change due to removal of serving HS cell
A serving HS-DSCH cell change can also be possible due to event 1b or event 1c, which triggers a removal of the serving HS cell from the active set. The following conditions have to be met for a suitable HS-DSCH cell to be found for cell change to take place.
Parameter hsCellChangeAllowed is set to TRUE.
If the target cell is a DRNC cell over Iur then the parameter cellCapabilityControl.hsdschSupport must be set to “On” for the Iur link.
The target cell should be better than the current serving cell by a factor of hsHysteresis1d/2.
If a suitable HS cell is found, then the RNC will start the serving HS-DSCH cell change execution. Admission Control is not checked before a serving HS-DSCH cell change is executed. If hsCellChangeAllowed is set to FALSE, or if no suitable HSDPA cell is found or if the cell change fails and the call doesn’t drop, the RNC checks the parameter hsToDchTrigger.servHsChangeIntraRnc when the best cell is an intra-RNC cell or the parameter hsToDchTrigger.servHsChangeInterRnc when the best cell belongs to a different RNC. If these parameters are set to ON (recommended value), then a downswitch to DCH is attempted. If the transition to DCH fails or is not possible due to Admission control, then the connection is released.
21.9. HSDPA Mobility – Coverage triggered downswitch Events 2d, 2f, 6d and 6b are also used for HS-DSCH to monitor bad quality in DL or UL. Compressed mode, inter RAT or inter frequency handovers are not supported for HSDPA. So if an event 2d or 6d is triggered and if the parameter hsToDchTrigger.poorQualityDetected is set to ON, then a downswitch to DCH is attempted. If this parameter is set to OFF, or if the transition to DCH fails or is not possible due to Admission control, then no further action is taken. After the connection has been downswitched to DCH, then an IRAT or inter-frequency handover can be attempted as described in section 10.
21.10.
HSDPA Mobility over IuR without HS support
When UE moves from an SRNC area to a DRNC, then the external cell in the DRNC is added to the active set and a new A-DCH radio link is setup over IuR. If this external cell later becomes the best cell, then a serving HS-DSCH cell change is triggered, but since this target cell belongs to a separate RNC and HS support over IuR is not configured (cellCapabilityControl.hsdschSupport is set to OFF), the serving cell change can’t be carried out over the IuR link, and reconfiguration to DCH is attempted instead. The UE then
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
202 of 214
Ericsson UMTS Feature Guidelines
continues into the DRNC area using the R99 PS interactive RAB. After transition to the DRNC area, it is possible to reconfigure the connection back to HSDPA. If the transition to DCH is not possible due to admission control or if parameter hsToDchTrigger.changeOfBestCellInterRnc is set to OFF, then the call will continue on HSDPA using the old serving cell, until event 1b or 1c is triggered. In this case, if a transition to DCH is still not possible due to parameter hsToDchTrigger.servHsChangeInterRnc being set to OFF, then the call will be released. If the call release happens when the best cell belongs to the external DRNC, then the release cause Direct Signaling Connection Re-establishment (DSCR) is used and the UE is asked to re-establish the connection in the DRNC. The PDP context is maintained to minimize the interruption time. DSCR will also be used when a reconfiguration to FACH is triggered over Iur, since the FACH state is not supported over Iur. Transitions from HSDPA to R99 DCH require that the feature HS mobility phase2 is active. Even if this feature were active, the transition can be blocked if the HSDPA cell is configured to use RLC PDU size 656 bits as shown in the table below.
Figure 45: Scenarios for HSDPA to R99 DCH transition
21.11.
Effect of HSDPA on R99
As mentioned in section 14.4.1, for admission and congestion control, the ‘Guaranteed’ service class which includes conversational and streaming services is prioritized over the ‘Guaranteed-HS’ service class which includes the HSDPA radio bearer. Due to this reason, voice is always given preference over HSDPA for admission and when congestion is encountered, HSDPA service is released before voice users (with the recommended parameters settings). For this reason, it can be concluded that offering HSDPA services would cause minimal disruption to voice users. On the contrary, HSDPA service is prioritized over the ‘Non-Guaranteed’ service class which includes the R99 data bearers. The reason for this is that HSDPA offers better throughput
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
203 of 214
Ericsson UMTS Feature Guidelines
and latency over R99 data services, and is hence more efficient in providing data services as long as it is configured accurately.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
204 of 214
Ericsson UMTS Feature Guidelines
22. Data Services Strategy HSDPA offers the following advantages over R99 in providing data services.
Uses a shared pipe instead of the dedicated DCH channel of R99.
Uses a spreading factor of SF16 as opposed to the SF8 of the PS 384 bearer. The smaller the spreading factor, the smaller the processing gain and hence larger the power consumption, and hence PS 384 bearer uses more power than HSDPA.
Since the PS 384 bearer uses a spreading factor of 8, a single PS 384 user would block out 16 voice users as opposed to HSDPA with SF 16 that would only consume the codes equivalent to 8 voice users.
HSDPA offers lower latency than R99 data.
Due to the above reasons, HSDPA is preferred over R99 to provide data services to customers. In the Ericsson implementation, an interactive data call is first tried to be set up on the HS-DSCH channel, and only if this is not possible, the call is then tried to be set up on R99 DCH channel. This implementation is preferred given the ability of HSDPA to provide superior data services over R99. In the current deployment of UMTS, networks are limited to 1 T1 per site, and this poses limitations in the throughput that can be offered to HSDPA users. However the inherent advantages due to higher spreading gain, lower power requirement as well as lower latency of HSDPA can still be used to provide efficient data services. In addition as can be seen from the previous section, parameters can be set such that voice users are given preference over HSDPA users when admission and congestion issues are encountered. Hence HSDPA resources can be controlled when required so as not to interfere with voice services. The parameter recommendations for realizing the data strategy outlined here are presented in section 23.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
205 of 214
Ericsson UMTS Feature Guidelines
23. Parameter Recommendations Recommended Values for relevant UTRAN parameters are available from the Info Router at the link below. http://docs.eng.t-mobile.com/inforouter/docs/~D461982 In case of a conflict between values specified in this Feature Guide document with the ones from the above link, the values from the Info Router link will prevail.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
206 of 214
Ericsson UMTS Feature Guidelines
24. Appendix A: Weighting Factor Analysis for Soft Handover Algorithm A weighting factor is used to include active cells other than the best cell in the evaluation criteria for reporting events. The measured value after weighting will be
NA W 10 Log M i (1 W ) 10 LogM Best i 1 where Mi is a measurement result of a cell in the active set NA is the number of cells in the current active set MBest is the measurement result of the cell in the active set with the highest measurement result W is the weighting factor When W = 0, as can be seen from the above equation, only the best cell’s measured value is considered for event analysis. Consider the following example of the influence of a nonzero weighting factor on event 1a and event 1b evaluation.
24.1.Event 1a evaluation When there is only 1 cell in the active set, the value of W doesn’t influence the measurement result, and hence the example below considers a case where there are 2 cells in the active set, and a third cell is being considered to trigger either event 1a. Consider that the active set has only 2 cells, cell A with CPICH Ec/No = -8 dB, and cell B with CPICH Ec/No = -12 dB. Assume the following values for the different soft handover related parameters. reportingrange1a = 3 dB hysteresis1a = 0 individualoffset = 0 With these values, the Event 1a conditions simplifies to
10 LogM
New
NA w1a 10 Log M i (1 w1a ) 10 LogM i 1
best
reportingR ange 1a
If W1a = 0, then the right hand part of the above equation equals -11 dB, which means that Event 1a is satisfied when the neighboring cell’s CPICH Ec/No is greater than or equal to -11 dB. If W1a = 0.5, then the right hand part of the above equation equals -9.9, which means that Event 1a is met when a neighboring cell’s CPICH Ec/No is greater than or equal to -9.9 dB. So in this case, a neighbor cell has to be stronger than the previous case in order to be added to the active set.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
207 of 214
Ericsson UMTS Feature Guidelines
If W1a = 1, then the right hand part of the above equation equals -8.8, which means that Event 1a is met when a neighboring cell’s CPICH Ec/No is greater than or equal to -8.8 dB. So in this case, a neighbor cell has to be even stronger than the previous two cases in order to be added to the active set.
24.2.Event 1b evaluation Consider that the active set has only 2 cells, cell A with CPICH Ec/No = -8 dB, and cell B with CPICH Ec/No = -12 dB. Assume the following values for the different soft handover related parameters. reportingrange1b = 5 dB hysteresis1b = 0 individualoffset = 0 With these values, the Event 1b conditions simplifies to
10 LogM Old
NA w1b 10 Log M i (1 w1b) 10 LogM best reportingR ange1b i 1
If W1b = 0, then the right hand part of the above equation equals -13 dB, which means that Event 1b is satisfied when the neighboring cell’s CPICH Ec/No is less than or equal to 13 dB. If W1b = 0.5, then the right hand part of the above equation equals -11.9, which means that Event 1b is met when a neighboring cell’s CPICH Ec/No is less than or equal to -11.9 dB. So in this case, a neighbor cell has to be stronger than the previous case in order to remain in the active set. If W1b = 1, then the right hand part of the above equation equals -10.8, which means that Event 1b is met when a neighboring cell’s CPICH Ec/No is less than or equal to -10.8 dB. So in this case, a neighbor cell has to be even stronger than the previous two cases in order to remain in the active set.
24.3.Tradeoff due to weighting factor From the above two cases it can be inferred that for a non-zero value of the weighting factor, a neighboring cell has to be stronger than when the weighting factor = 0, for it to be added to the Active set or retained in the Active set. Hence a non-zero weighting factor would result in a small reduction in the Active set size. Note that this reduction is only valid when the Active set size is at least equal to 2. A larger value of W will result in a reduction in the Active Set size, thus saving network capacity. However a large value of W would mean that the a possible neighbor is added less quickly into the Active set, which might impact call quality negatively in some cases. Also delaying the addition of a neighbor into the Active set would result in larger number of measurement reports being sent to the RNC for the same candidate cell, thus more processing would be needed from the RNC to handle this increase in received measurement reports.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
208 of 214
Ericsson UMTS Feature Guidelines
In networks where capacity is an issue, a larger value of W might be more useful as long as the reporting ranges are modified for this newer value of W. For initial network launch, a value of W = 0 is still recommended. Further tests in the field will be performed to assess the impact of the weighting factor on Soft Handover performance.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
209 of 214
Ericsson UMTS Feature Guidelines
25. Appendix B: Monitored Set Creation Field Example 25.1.Description This test will compare a theoretical monitored set against a measured monitored set after SHO has occurred between 2 cells with a mixture of common and unique neighbors.
25.2.Execution The following is the list of the test steps that were performed.
Begin a CS voice call on BQU4659C (SC165)
Drive until BQU4841A (SC221) is added to the active set
Record new monitored set from TEMS
Compare against theoretical neighbor list
25.3.Neighbor Lists Neighbor List - BQU4659C (SC165) 1 2 3 4 5 6 149 157 52 68 323 331 17 18 19 20 21 22 403
7 221 23
8 229 24
9 124 25
10 133 26
11 141 27
12 268 28
13 395 29
14 28 30
15 36 31
16 237 32
Neighbor List - BQU4841A (SC221) 1 2 3 4 5 6 229 237 395 403 165 268 17 18 19 20 21 22 213 125 96
7 323 23
8 331 24
9 68 25
10 141 26
11 28 27
12 149 28
13 157 29
14 181 30
15 155 31
16 236 32
25.4.Results The following shows the steps in the monitored set creation for this test case. Original List - Serving 1 2 3 4 165 149 157 52 17 18 19 20 237 403
Cell = BQU4659C 5 6 7 68 323 331 21 22 23
(SC165) 8 9 221 229 24 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
BQU4841A (SC221) added to Active Set - Calculate New Monitored List STEP 1 - Add both the active cells (A) and (B) to the listed set in the same position as they existed previously. New List 1 2 165
3
T-Mobile USA, INC. Confidential
4
5
6
7
8 221
Rev. 3.0
9
10
Sep 11, 2008
11
12
13
14
15
16
210 of 214
Ericsson UMTS Feature Guidelines
17
18
Old List 1 2 165 149 17 18 237 403
19
20
21
22
23
24
25
26
27
28
29
30
31
32
3 157 19
4 52 20
5 68 21
6 323 22
7 331 23
8 221 24
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
STEP 2 - Take the neighbor cell with the highest priority for the best active set cell, cell(A), and if it already exists in the old listed set add it to the new listed set in the same position. If it does not exist in the old listed set, then the position does not matter, therefore store it for addition later in a temporary array. New 1 165 17
List 2 149 18
3
4
5
6
7
19
20
21
22
3 157 19
4 52 20
5 68 21
Temporary List 1 2 3
4
17
20
Old List 1 2 165 149 17 18 237 403
18
19
9
10
11
12
13
14
15
16
23
8 221 24
25
26
27
28
29
30
31
32
6 323 22
7 331 23
8 221 24
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
5
6
7
8
9
10
11
12
13
14
15
16
21
22
23
24
25
26
27
28
29
30
31
32
STEP 3 - Take the neighbor cell with the highest priority for the second best active set cell (B), and if it already exists in the old listed set add it to the new listed set in the same position. If it does not exist in the old listed set, then the position does not matter and it can be stored in a temporary array for later addition. Store the neighboring cell only if it does not already exist in the temporary array (avoid duplicate). If it is already stored in the temporary array, take the next neighboring cell in priority order from the next cell in the Active Set, cell (A) applying the same rules. New 1 165 17
List 2 149 18
3
4
5
6
7
19
20
21
22
23
8 221 24
9 229 25
10
11
12
13
14
15
16
26
27
28
29
30
31
32
Old List
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
211 of 214
Ericsson UMTS Feature Guidelines
1 165 17 237
2 149 18 403
4 52 20
5 68 21
6 323 22
7 331 23
8 221 24
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
Temporary List 1 2 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
20
21
22
23
24
25
26
27
28
29
30
31
32
18
3 157 19
19
STEP 4 - Repeat until all neighbor cells have been processed or until MaxIafMonSubsetIAF neighboring cells have been selected for the listed set. New 1 165 17 237
List 2 149 18 403
3 157 19
4 52 20
5 68 21
6 323 22
7 331 23
8 221 24
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
Old List 1 2 165 149 17 18 237 403
3 157 19
4 52 20
5 68 21
6 323 22
7 331 23
8 221 24
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
Temporary 1 2 149 157 17 18
List 3 181 19
4 155 20
5 236 21
6 213 22
7 125 23
8 96 24
9
10
11
12
13
14
15
16
25
26
27
28
29
30
31
32
STEP 5 - Take the cells that have been selected to be included in the new listed set (stored in the temporary array) and add them to the listed set by filling the spaces that have not been filled in step (c), the neighboring cells are picked from the temporary array in the order they was stored (FIFO). (This makes sure that neighboring cells stored early in the temporary array will be the first to fill out the spaces in the listed set). New 1 165 17 237
List 2 149 18 403
Old List 1 2
3 157 19 181
4 52 20 155
5 68 21 236
6 323 22 213
7 331 23 125
8 221 24 96
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
3
4
5
6
7
8
9
10
11
12
13
14
15
16
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
212 of 214
Ericsson UMTS Feature Guidelines
165 17 237
149 18 403
Temporary 1 2 181 155 17 18
157 19
52 20
68 21
323 22
331 23
221 24
229 25
124 26
133 27
141 28
268 29
395 30
28 31
36 32
List 3 236 19
4 213 20
5 125 21
6 96 22
7
8
9
10
11
12
13
14
15
16
23
24
25
26
27
28
29
30
31
32
5 68 21 236
6 323 22 213
7 331 23 125
8 221 24 96
9 229 25
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
5 68 21 155
6 323 22 236
7 331 23 213
8 221 24 125
9 229 25 96
10 124 26
11 133 27
12 141 28
13 268 29
14 395 30
15 28 31
16 36 32
COMPARISON - PASS Theoretical 1 2 165 149 17 18 237 403
New List 3 4 157 52 19 20 181 155
Measured List 1 2 3 165 149 157 17 18 19 237 403 403
T-Mobile USA, INC. Confidential
4 52 20 181
Rev. 3.0
Sep 11, 2008
213 of 214
Ericsson UMTS Feature Guidelines
26. References 1. 3GPP TS 25.331 V 5.19.0 “UMTS Radio Resource Control Protocol Specification”. 2. Allan Orbigo, Christophe Vidal, UMTS RF Planning and Design Guidelines. 3. Alejandro Aguirre, Sireesha Panchagnula Ericsson UTRAN Parameters. 4. 3GPP TS 25.304 V 5.9.0 “UMTS UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode”. 5. UMTS Network KPI, U12 UMTS Network KPI v6.14 080406TMO LR.doc 6. UMTS Network KPI Level 2, UMTS Network KPI Level-2_v1_20070205ERI_Updated.doc 7. UMTS RNC LCS KPI definitions and Formulas, Michael Gebretsadik 8. 3GPP TS 25.331, UMTS RRC protocol specification. 9. 3GPP TS 25.211 V 5.8.0, “UMTS Physical channels and mapping of transport channels onto physical channels”. 10. 3GPP TS 25.413 V 5.12.0, “UTRAN Iu Interface RANAP Signaling”. 11. 3GPP TS 25.214, ”UMTS Physical Layer Procedures FDD”. 12. Ericsson Product Documentation, EN/LZN 733 0017 R4A. 13. Ericsson Product Documentation, “Guidelines for LA/RA/URA planning” 14. Ericsson Product Documentation 58/1551-AXD 105 03/1 Uen G, “Performance Statistics RNC 3810”. 15. Nabeel Lughmani, Pradeep Singh, Tim Zhang, “Paging Performance Guidelines”. 16. Sireesha Panchagnula, “UMTS Paging Concepts”.
T-Mobile USA, INC. Confidential
Rev. 3.0
Sep 11, 2008
214 of 214